Именно это и имею ввиду - откуда и куда и на какой порт. Его можно отфильтровать через тот же графвиз и выгрузить в svg, который можно нормально масштабировать хоть в браузере, хоть и inkscape или подобной софтине. Или нужно было что-то другое?
Э... Как бы сказать... Ну не нужно путать Power и PowerPC, первая немного другой внутренней архитектуры, хотя система команд одинаковая. Что касается FPU, то он по производительности ничем, в конечном счете не отличается от архитектур на X86, более того, сопроцессоры у всех очень похожи. Преимуществ нет никаких на данный момент, а по производительности оно сейчас как CortexM4 (или ARM A7) с одинаковой частотой, тем более, что есть чипы и с FPU.
Ну а как разработчик с 15-ти летним стажем под эту архитектуру (начиная с PPC601, далее везде от микроконтроллеров до PPC G5), они начали сливать интелу как раз из-за частоты и и политических разногласий уже в районе G3 vs Pentium III. Единственное преимущество было - грелись меньше, но и это потом сошло на нет.
Да, архитектура была хороша, но для своего времени, в микроконтроллерах и сейчас применяется. ARM победил как раз тем, что не нужно отчислять большое бабло на лицензии, жадность здесь сгубила, MIPS - бОльшим альянсом, SPARK вообще халявой. А PPC только у IBM и Freescale (Motorola) остались. Один развивает Power, другой микроконтроллеры для ракет трайдент и прочей космонавтики. Да и то, потому что туда столько бабла вложено и ими самими и заказчиками/кастомерами...
Ладно, сильно в дебри вдаваться не буду, все уже давно описано до меня. В общем: было, да сплыло, увы.
А смысл именно в PPC?! Может быть легче купить эвалюэйшин боард с чем нибудь типа моторолы MPC860, как раз на такой лет 5 назад ядро портировал с эзернетом, uboot-ом, гусарами, рулеткой и куртизанками.
Купить борду можно на ебее, и легче и проще и не нужно обходить эпловые загрузчики/защиты.
А вообще-то мир на армы переходит....
Если первый контекст не является финальным, то да, убираем тру/катч и передаем исключение дальше.
И если второй контекст является "финальным", то обрабатываем исключение и/или прерываемся, например этот контекст используется для логирования, то такое поведение нормально. Тем более, если нам захочется его как-то расширить, например передавать код ошибки через вебсервис, то мы легко это сделаем всего лишь в одном месте.
И да, когда-то сам делал инициализацию через NullPointerException :-) , так что понимаю о чем пишу, да удобно, но как-то тормозливо, и как-то не там...
В этом случае (и остальных!!!) выкидывать его на самый верх в бизнеслогику. Я так и предпочитаю, все исключения как раз и должны быть на уровне бизнеслогики., остальное проверяется без исключений. Соответственно, все что можно выкидываем на верх, остальное проверяем.
Пример, открыть файл и если его нет, создать новый. Кажется, вот оно хорошее место для исключений - не ведитесь на это, просто проверьте перед открытием, что файло существует, и если нет, создайте его без исключений.
Тогда и ваш код будет совсем без try/catch, который будут только в самых существенных местах. Иногда, конечно, раздражает кортеж исключений в определении метода, ну так перейдите в этом случае на родителя (на класс выше) и будет щазтие. Ну и это как минимум повод задуматься, почему у меня тут и исключения от базы и от файлов и еще куча всякого... что-то явно не так тут...
Поддержу, супермайкро хороши. Вот только про апгрейдопрогодность я бы сильно не думал, особенно через 5 лет! тогда ни памяти ни процессоров таких не будет, а если и будут, то за те деньги легче новый собрать. И время жизни серверов лет 5 обычно. И что дома делать с зионом я понятия не имею, лучше i7 ограничиться.. А еще лучше взять самую простую мать.
Проблемы? Да их есть куча!!! вот например с мускулом - habrahabr.ru/company/bitrix/blog/146490
Для ростгреса практически все также актуально, как собственно и для оракла сайбейса и всех остальных.
Тем более, что в изначальном вопросе был намек на быстрое добавление новых нод (в том числе, как я понял и баз данных), что в случае с мастер-мастер приведет к лавионобразному росту трафика, блокировакам, рассинхронизации данных и всему остальному хорошему.
Попробуйте для себя разбить задачу на три:
- добавление новых нод
- резервирование данных
- восстановление после сбоя
И мир будет без мастер-мастер репликации.
Мастер-мастер иногда нужна, когда есть приложение, а программистов для него уже нет. Вот тут ничего другого и не остается, увы... Но делать так с самого начала - увольте.
Отказоустойчивости - никак, а про нее в изначальном вопросе ничего и не было сказано. А если про нее говорить, то делайте мастер-слейв репликацию, вот отказоустойчивость и появится. Или для таких случаем держите бакап-базу (две-три если нужно), куда раз в сколько-то сливайте все изменения со всех серверов, и когда шардинг рассыпается, то подключайтесь к ней на чтение. В любом случае политик здесь будет гораздо больше, чем непрерывно лить изменения со всех на все. Или как политика, если какой-то кусок шардинга недоступен, то льем данные в локальную базу, а потом переливаем куда нужно, при этом кусок данных упавшего сервера будет конечно недоступен, а вот критично это или нет - все зависит как построить приложение...
Ну, вот :-( Всё, что не стоит делать, мы и делаем. Забег по граблям объявляем открытым?
PS. Поставьте glusterfs и избавьтесь от репликации и шардируйте базы данных.
И да, это потребует некоторого вмешательства в код (для шардинга), но это на порядок, именно на порядок, лучшее решение, чем городить промежуточный слой с кучей проблем в дальнейшем.
Для этого, если хостинг, файлы не редактирую напрямую на нем! А делают их локально, и только потом заливают отлаженную версию на сервер или хотинг. Какие, собственно, проблемы поднять у себя апач/нгинх/пехапе/мускул?! Я бы руки разработчику оторвал, если бы он у меня правил файлы на рабочем сервере, сначала минус премия, а затем и досвидание..
У! На очень многое способен! Может даже зафаерволенные хосты определять по клиентским сокетам.. Это когда хотс на пинг не отвечает и закрыто почти все...
