Я хостился во fiord.ru (ушел туда из мастерхоста), вообще доволен. Были только какие-то непонятки с тем, что несколько раз внезапно пропадал Ethernet Link, и они что-то там перетыкали. Саппорт работал хорошо и адекватно.
Правда с тех пор я избавился от нескольких проектов проектов, а что осталось хостится на неттопе в агаве, за меньшее бабло :)
Например, ноубучный акк при весе пару сотен грамм может держать примерно 75ватт*часов. ( Я взял Appleовские самые последние для примера ). Это значит в 45 килограммах ~ 17 квт*ч.
Первые самолеты летали на моторах в несколько десятков лошадиных сил (то есть несколько десятков киловатт мощности ). При этом весили под тонну, а этот — примерно 200 кг.
То есть, например, с мотором мощностью 30 квт этот самолет может летать пол часа.
Что, исходя из описанного радиуса полета в 80 км вполне правдоподобно ( при скорости 240 км/ч)
То есть грубые прикидки показывают, что все вполне осуществимо. И что, действительно, емкость батарей надо повышать в несколько раз.
У меня сейчас Macbook Pro, я в курсе про их возможности.
Все таки, если Macbook Pro держит хотя бы 5 часов с процессором Core 2 Duo с его потреблением 25-35 ватт, то в цифре 16 часов нет ничего неправдоподобного при потреблении ARM процессора с чипсетом в 1 ватт.
И может быть для этого нужен не самый дорогой уже аккумулятор.
И вот nVidia выпускает свой Tegra. Вполне может быть и ноут на нем будет такой, как я хочу. Грамм 700-800, дешевый. Эх…
Нет, я хочу эту штуку не использовать как планшет. Скорее мне интересен легкий относительно маломощный и очень долгоиграющий ноут, с Linux окружением. Очень круто, если у него будет приятный дизайн. Этот подходит вполне, если держит 16 часов. Я правда не понял — на обратной стороне у него есть что то типа клавы или он просто сенсорный экран с крышкой. Забавно, если у него будет тачскрин.
Если нету клавы — то это не совсем то, чего я хочу.
В одной конторе, где я работал ( около 6000 сотрудников, разбитых по разным отделениям в разных странах ) было сделано так
1) Был изготовлен образ для install. Покупались только определенные железки. Каждая новый тип железки требовал одобрения IT отдела.
2) Новая железка втыкалась в сеть. Через netboot сразу на нее заливался ставился один из подоговленных образов ( RHEL, SUSE)
3) Ничего кроме OS и личного хлама ( то есть какие-нибудь mp3) локально не хранилось. Все /home/[username] монтировались через NFS, по моему с NetApp. Он бэкапился на ленты.
4) Весь софт, не шедший в составе ОС лежал на опредленном сетевом диске. Причем, если, например требовались sparc версии софта, то манутился том, где этот набор софта лежал под спарк, 64bit SuSe — соответствующие версии софта под него и так далее, то есть скрипт мог использовать инструменты оттуда и быть уверенным, что софт под эту платформу лежит там где надо.
5) Апдейты накатывались штатными средствами из репо, который был прописан при сборе диска, тут ничего изобретать не надо.
Как-то так все было построено, что никакого ада в управлении правами не было, потому что Unix идеология с юзерами и группами идеально и легла, с ACL бы все повесились наверное.
Больше гемороя было с глобальными сетевыми томами, или их синхронизацией между регионами — я не знаю как оно там внутри работало.
Виндовые чуваки авторизовались через AD, Unix — через OpenLDAP, пароль сотрудник менял на интранетовском сайте и мог логиниться сразу везде ( используя свой сетевой Home конечно же ). Забыв — мог резетить с помощью железки выдающей всякие странные номера :) Но — сетевые home под *nix и windows различались.
Если человек не умел пользоваться Unix, то скорее всего бы просто не получил бы вакансию — найти программера, умеющего пользоваться Unix не сложно.
НО — это НЕ миграция с Windows. Контора писала под Unix еще с 80-х, теперь и под Linux, а Windows версии софта выпускаются далеко не все.
А куда вы съедете то? См. ниже, у другого, в 2 раза более дорогого хостера, который конечно имеет более сильный PR отдел, та же фигня, это мой опыт. А что вы будете делать когда мамка на сервере сдохнет? Ну то есть если 12 часовой простой реально критичный, то как-то надо это решать заранее, планируя размещение, а не надеятся, что хостер перевыполнит предусмотренный в договоре процент аптайма. А то ВНЕЗАПНО выясняется, что 99% аптайма — это 3 дня простоя в год.
И вдруг выясняется, что за аптайм реально платить никто не хочет, что это себя не окупает, второй сервер в другом ДЦ, SLA и прочее, а все просто истерят, но ничего не предлагают, кроме перевезти единственную и неповторимую коробку в другой ДЦ, «отомстить гадам», а в итоге будет ну все тоже самое. Разработчик, конечно, может порекомендовать хостера и сервер, но есть еще какая-то бизнес-целесообразность.
В третьих — вы почему-то зациклились на теме оправдания, я не знаю зачем вообще оправдываться в этой ситуации. Я же имел ввиду, что если цель — высокая доступность сервиса, то стоит как-то проанализировать от чего он вообще бывает недоступный, а не раздувать один единственный повод, который достаточно дорого как-то радикально уменьшить.
Насчет нафига — а нафига программисты вообще программисты? Понимаете, с такой позиции оправдание всегда можно найти, это будет «начальник-мудак», «зарплата низкая», «меня все зае… ло», и так далее. Либо человек находится в позиции жертвы и ищет оправдания, которые, как и дырка в жопе, есть у каждого, либо что то делает. Эта позиция связана со структурой личности, а не с «внешними обстоятельствами».
Я написал коммент, чтобы показать, что это такой же рабочий момент, как и все остальное, и нет причин для истерики. От нее ничего быстрее не произойдет, как и в случае ошибок в коде. Может кто-то таки напишет регрессию даже :)
Разница в том, что вы предлагаете так общаться уже с собственными клиентами, с позиции во первых, почему-то самооправдания, во вторых — в виде достаточно жесткого наезда, бесмысленного и беспощадного, вместо того, чтобы это разруливать на основании договора. На основании моего объяснения ничего «разруливать» и «говорить» клиентам со стороны же провайдеров никто не собирается? Или вы что, решили что я в агаве работаю что ли?
Блин, я просто фигею с истерии. Не, я знаю что бывают enterprise сервисы, и каждому админу хочется считать свой проект самым-самым интырпрайзовым, а если он поляжет, то, конечно, настанет конец света, цвета и более 9000 убытков.
Но, положа руку на сердце — у скольких из этих проектов, для которых «12 часов простоя критичны вплодь до смены хостера» написана нормальная регрессия? Сколько часов они пролежали из-за неправильного коммита или деплоя в репозиторий? Сколько раз, приходя в понедельник, выяснялось, что часть функционала в выходные отвалилась и «не очень то работала»? Сколько раз все валилось, потому что предыдущая комманда ушла, не оставив документации, и предположение о том, как что работает, оказывалось не совсем точным?
Я просто описываю достаточно типичную ситуацию в типичном рунетовском проекте, исходя из своего опыта, я видел, что бывает и не так. Но редко.
Но тут. Ура!!! Наконец то НЕ МЫ ВИНОВАТЫ! Это все ОНИ! Плохие хостеры! Расстрелять!
Цель то какая? Минимизировать простои? Ну так я сильно сомневаюсь, что хостер — это причина самых больших простоев. Наконец-то с облегчением сказать, что не разработчки слабое звено?
Как объяснять «клиентам» — ссылками в договор с клиентом. Вот и все. Рабочая ситуация.
«В связи с острой технической необходимостью, вызванной нехваткой мощностей систем электропитания и кондиционирования в Дата-центре, принадлежащем ООО „xxxxxxxxxx“ на ул. xxxxxxxxxxx, уведомляем Вас о подготовке к экстренному перевозу Вашего оборудования в ночь с 09 на 10 ноября xxxx года в Дата-центр, расположенный по адресу: yyyyyyyyyyyyy.»
Прислано одним достаточно дорогим провайдером на букву «М» 7 ноября.
В плюс той истории — никаких сетевых настроек менять не понадобилось, видимо как-то разрулили.
Впрочем, а нафига проблему то из этого раздувать? За месяц предупреждать… Это что, шутка? Че делать целый месяц?
Для начала стоит автомтизировать геренацию excel и рассылку его по почте. + сделать веб интерфейс, где хранились бы эти excelи за последний месяц-другой, куда и отправлять тех, кто спрашивает о старой версии.
Дальше беседовать с начальством саботирующего IT шника.
Пиратство можно победить только сменой бизнес моделей. Придумать какую-то схему зарабатывания денег, а потом обвинить людей в том, что они козлы, а схема то правильная и идеальная — порочный путь.
С развитием интернета старые схемы зарабатывания денег отваливаются. Надо думать и придумывать.
По поводу send_file — лучше проанализировать, на каком сервере будет работать production и отправлять заголовок либо X-Sendfile для Apache2, либо X-Accel-Recirect для nginx. Ну в development будет send_file, да. Был какой-то плагин даже для этого.
На одном проекте выставление заголовка для nginx позволило сменить состояние сервера с «пипец какой загруженнй» до «сервак то вообщем простаивает».
Правда с тех пор я избавился от нескольких проектов проектов, а что осталось хостится на неттопе в агаве, за меньшее бабло :)
Первые самолеты летали на моторах в несколько десятков лошадиных сил (то есть несколько десятков киловатт мощности ). При этом весили под тонну, а этот — примерно 200 кг.
То есть, например, с мотором мощностью 30 квт этот самолет может летать пол часа.
Что, исходя из описанного радиуса полета в 80 км вполне правдоподобно ( при скорости 240 км/ч)
То есть грубые прикидки показывают, что все вполне осуществимо. И что, действительно, емкость батарей надо повышать в несколько раз.
Все таки, если Macbook Pro держит хотя бы 5 часов с процессором Core 2 Duo с его потреблением 25-35 ватт, то в цифре 16 часов нет ничего неправдоподобного при потреблении ARM процессора с чипсетом в 1 ватт.
И может быть для этого нужен не самый дорогой уже аккумулятор.
И вот nVidia выпускает свой Tegra. Вполне может быть и ноут на нем будет такой, как я хочу. Грамм 700-800, дешевый. Эх…
Если нету клавы — то это не совсем то, чего я хочу.
1) Был изготовлен образ для install. Покупались только определенные железки. Каждая новый тип железки требовал одобрения IT отдела.
2) Новая железка втыкалась в сеть. Через netboot сразу на нее заливался ставился один из подоговленных образов ( RHEL, SUSE)
3) Ничего кроме OS и личного хлама ( то есть какие-нибудь mp3) локально не хранилось. Все /home/[username] монтировались через NFS, по моему с NetApp. Он бэкапился на ленты.
4) Весь софт, не шедший в составе ОС лежал на опредленном сетевом диске. Причем, если, например требовались sparc версии софта, то манутился том, где этот набор софта лежал под спарк, 64bit SuSe — соответствующие версии софта под него и так далее, то есть скрипт мог использовать инструменты оттуда и быть уверенным, что софт под эту платформу лежит там где надо.
5) Апдейты накатывались штатными средствами из репо, который был прописан при сборе диска, тут ничего изобретать не надо.
Как-то так все было построено, что никакого ада в управлении правами не было, потому что Unix идеология с юзерами и группами идеально и легла, с ACL бы все повесились наверное.
Больше гемороя было с глобальными сетевыми томами, или их синхронизацией между регионами — я не знаю как оно там внутри работало.
Виндовые чуваки авторизовались через AD, Unix — через OpenLDAP, пароль сотрудник менял на интранетовском сайте и мог логиниться сразу везде ( используя свой сетевой Home конечно же ). Забыв — мог резетить с помощью железки выдающей всякие странные номера :) Но — сетевые home под *nix и windows различались.
Если человек не умел пользоваться Unix, то скорее всего бы просто не получил бы вакансию — найти программера, умеющего пользоваться Unix не сложно.
НО — это НЕ миграция с Windows. Контора писала под Unix еще с 80-х, теперь и под Linux, а Windows версии софта выпускаются далеко не все.
И вдруг выясняется, что за аптайм реально платить никто не хочет, что это себя не окупает, второй сервер в другом ДЦ, SLA и прочее, а все просто истерят, но ничего не предлагают, кроме перевезти единственную и неповторимую коробку в другой ДЦ, «отомстить гадам», а в итоге будет ну все тоже самое. Разработчик, конечно, может порекомендовать хостера и сервер, но есть еще какая-то бизнес-целесообразность.
В третьих — вы почему-то зациклились на теме оправдания, я не знаю зачем вообще оправдываться в этой ситуации. Я же имел ввиду, что если цель — высокая доступность сервиса, то стоит как-то проанализировать от чего он вообще бывает недоступный, а не раздувать один единственный повод, который достаточно дорого как-то радикально уменьшить.
Насчет нафига — а нафига программисты вообще программисты? Понимаете, с такой позиции оправдание всегда можно найти, это будет «начальник-мудак», «зарплата низкая», «меня все зае… ло», и так далее. Либо человек находится в позиции жертвы и ищет оправдания, которые, как и дырка в жопе, есть у каждого, либо что то делает. Эта позиция связана со структурой личности, а не с «внешними обстоятельствами».
Разница в том, что вы предлагаете так общаться уже с собственными клиентами, с позиции во первых, почему-то самооправдания, во вторых — в виде достаточно жесткого наезда, бесмысленного и беспощадного, вместо того, чтобы это разруливать на основании договора. На основании моего объяснения ничего «разруливать» и «говорить» клиентам со стороны же провайдеров никто не собирается? Или вы что, решили что я в агаве работаю что ли?
Но, положа руку на сердце — у скольких из этих проектов, для которых «12 часов простоя критичны вплодь до смены хостера» написана нормальная регрессия? Сколько часов они пролежали из-за неправильного коммита или деплоя в репозиторий? Сколько раз, приходя в понедельник, выяснялось, что часть функционала в выходные отвалилась и «не очень то работала»? Сколько раз все валилось, потому что предыдущая комманда ушла, не оставив документации, и предположение о том, как что работает, оказывалось не совсем точным?
Я просто описываю достаточно типичную ситуацию в типичном рунетовском проекте, исходя из своего опыта, я видел, что бывает и не так. Но редко.
Но тут. Ура!!! Наконец то НЕ МЫ ВИНОВАТЫ! Это все ОНИ! Плохие хостеры! Расстрелять!
Цель то какая? Минимизировать простои? Ну так я сильно сомневаюсь, что хостер — это причина самых больших простоев. Наконец-то с облегчением сказать, что не разработчки слабое звено?
Как объяснять «клиентам» — ссылками в договор с клиентом. Вот и все. Рабочая ситуация.
«В связи с острой технической необходимостью, вызванной нехваткой мощностей систем электропитания и кондиционирования в Дата-центре, принадлежащем ООО „xxxxxxxxxx“ на ул. xxxxxxxxxxx, уведомляем Вас о подготовке к экстренному перевозу Вашего оборудования в ночь с 09 на 10 ноября xxxx года в Дата-центр, расположенный по адресу: yyyyyyyyyyyyy.»
Прислано одним достаточно дорогим провайдером на букву «М» 7 ноября.
В плюс той истории — никаких сетевых настроек менять не понадобилось, видимо как-то разрулили.
Впрочем, а нафига проблему то из этого раздувать? За месяц предупреждать… Это что, шутка? Че делать целый месяц?
Дальше беседовать с начальством саботирующего IT шника.
С развитием интернета старые схемы зарабатывания денег отваливаются. Надо думать и придумывать.
На одном проекте выставление заголовка для nginx позволило сменить состояние сервера с «пипец какой загруженнй» до «сервак то вообщем простаивает».