Подождите-ка. Эти «космические скорости» — это не скорость, которую должен развить космический корабль. Это скорость, с которой минимально достаточно запустить с земли предмет, чтобы вывести на орбиту (1 — вокруг Земли, 2 — вокруг Солнца, 3 — в межзвёздное пространство). Например, катапультой выкидывать объект на орбиту (представьте себе, какое ускорение будет!). По указанной ссылке же и написано: «Предполагается, что после приобретения телом этой скорости оно более не получает негравитационного ускорения (двигатель выключен, атмосфера отсутствует).»
Что запретит покоящемуся на земле телу с ускорением в 1,05 «же» покинуть Землю? Ничего. Потихоньку вылетит на орбиту, на 100 км поднимется за 24 минуты, на тысячу км за 1 час 15 минут (h = (a-g) * t ^ 2).
Единственно что — даст ли сабжевый двигатель такое ускорение (больше 10 м/с^2) для корабля массой 150 тонн.
Интересно, изнутри робота есть ограничения на доступный код? Можно ли получить код робота противника и проанализировать его (например, для расчёта упреждения)?
По событию onScannedRobot(e) можно получить ссылку на обнаруженного робота e.robot, и у него уже получить код:
Robot.prototype.onScannedRobot = function(ev) {
var r = ev.robot;
var enemyCode = ev.scannedRobot.onIdle;
r.rotateCannon( analyzeEnemyMovement(enemyCode) );
r.fire();
//…
};
Понятно, что функция analyzeEnemyMovement получится непростой, но всё же…
Да, я понял уже. Нам это практически ничем не может повредить.
Но интересен сам факт, упомянутый в той передаче, что современная наука не может пересадить ОДИН ген, а пересаживается сразу довольно большой участок ДНК. Утверждается, что кроме требуемого гена переносится ещё несколько с неизвестным эффектом.
Я хотел уточнить, не встречались ли вы с такими фактами. Может, там в передаче вообще нагнали (любят телевизионщики это дело) и уже умеют точечно перемещать конкретные гены (о чём вы в статье и говорите).
А, да, я понял, вы правы. Я что-то забыл, что у нас всё «в котёл» попадает…
Там в программе говорилось, что проблема может быть в самой ДНК с обрывком, торчащим в середине, что они будут химически активны и смогут разрушать окружающие молекулы. Что приведёт к болезням того ГМ-организма.
Если в форме регистрации есть второе поле с паролем для проверки — можно ли сделать так, чтобы при генерации пароля второе поле автоматически тоже заполнялось?
Кстати, тот плагин simplePassMeter (который с «more»), зря вы сразу его отсеяли, очень даже неплохой. У него есть пару интересных фишек — проверки matchField (указываем поле с pass2, чтобы оба введённых пароля совпадали) и noMatchField (указываем поле с логином, чтобы не совпадали). Самый большой недостаток — плохая модульность, сложно переводить и ещё сложнее сделать его мультиязычным.
Спасибо за статью, отлично!
Я примерно так всё и представлял, аргументация и методичность рассмотрения темы понравились.
Не знал такие подробности про селекцию.
Я вообще считаю, что без ГМ невозможно решить проблему голода на земле, особенно с учётом продолжения увеличения населения нашей планеты. Исследования генной инжинетрии не просто хорошо бы продолжать, их необходимо продолжать.
В одной передаче про ГМО (не помню, какая именно, вроде «Среда обитания», но там не было «ужас-ужас») была интересная инфа. Какой-то профессор говорил, что современные методы перемещения генов несовершенны, невозможно взять именно один ген и пересадить только его. При перемещении у донора вырезается целый кусок ДНК и пересаживается реципиенту. Причём кусок отрезается не ровно «по границе генов», а как придётся, от чего в итоговой ДНК могут появиться оборванные цепочки — свободные радикалы, имеющие ненулевой электрический потенциал и химическую активность.
Именно это я вижу как наибольшую опасность. Не сами ГМО, не гипотетическое «свиное рыло от ГМ-свниниы», а повышенную аллергичность (особенно для аллергиков).
Хотя, в случае «жёсткой» селекции должны появляться такие же «хвосты» из радикалов…
Интересно было бы услышать мнение топикстартера по этому поводу.
Классная статья, спасибо! Есть один вопрос.
В файле /etc/nginx/templates/php параметр
fastcgi_pass unix:/tmp/wwwpool.sock;
этот конфиг подходит, если nginx стоит на той же машине, где и php-fpm. Если php-fpm на другой машине, то нужно писать
fastcgi_pass 10.0.0.1:9000;
А что делать, если используется несколько машин с php через upstream? Можно ли написать так:
upstream backend-php {
server 10.0.0.1:9000;
server 10.0.0.2:9000;
}
…
fastcgi_pass backend-php;
Есть интересный сервис xeround.com/lp/free-cloud-database/ — бесплатный облачный хостинг MySQL, как они говорят. Я не нашёл у них, за что деньги брать собираются и какие ограничения. Может, уже после регистрации скажут?
К сожалению, не могу проверить.
Я себе поставил на сервер систему виртуализации Proxmox (была на хабре пара статей о ней. Коротко — класс!), которая поддерживает OpenVZ- и kvm-виртуализацию. Но у меня только одна машина, поэтому миграцию не могу попробовать… А хотелось бы.
Но по прикидкам — нужно записать память в файл, передать по сети на соседнюю машину и там распаковать обратно в память. Пару секунд сохранять память, чуть дольше передавать и там ещё пару секунд запускать.
В общем, несколько секунд, вряд ли больше 2-3 минут. Но зависит от объёма памяти.
По крайней мере в технологии OpenVZ возможен перенос процессов на другую физическую машину без потери сетевых соединений. ru.wikipedia.org/wiki/OpenVZ#Чекпоинтинг_и_миграция_на_лету
>Так как все детали состояния VE, включая открытые сетевые соединения, сохраняются, то с точки зрения пользователя VE процесс миграции выглядит как задержка в ответе: скажем, одна из транзакций базы данных заняла больше времени, чем обычно, и далее работа продолжается как обычно; таким образом, пользователь не замечает, что его сервер баз данных работает уже на другом физическом сервере.
Спасибо за ссылку.
>Each of EVE's 5000+ star systems is loaded as a separate process onto any one of hundreds of IBM blade servers, with some high-load systems being given a server all to themselves and many low-load systems being combined and run on servers together
Интересно, что здесь не говорится про облако — «Каждая из 5000+ звёздных систем загружены как отдельные процессы на одном из сотен блейд-серверов».
Я сейчас не говорю что у них плохая система (всё-таки справляется с впечатляющей нагрузкой). Но, судя по всему, «на горячую» они переносить процессы не могут, и балансируется нагрузка не в реальном времени, а по статистике — «эти 4500 систем малопосещаемые, а эти 500 — загруженные, перетасуем их вместе».
Хочу немного порассуждать об архитектуре подобной системы.
Сейчас, как я понимаю, несколько процессов обработки систем (назову их нодами) висят на одном сервере, и разделить их сложно — необходимо остановить процесс (с потерей соединений) и поднять на новой машине.
А теперь пофантазируем. Поместим все расчётные ноды в облачный кластер — отдельный процесс обработки солнечной системы (ноду) в отдельную ВМ. За счёт возможности миграции виртуальной машины на другой узел кластера без остановки самой виртуальной машины появляется куча интересных возможностей по гибкому управлению нодами — балансировка нагрузкой серверов за счёт переноса нод, освобождение мощности сервера под возросшую нагрузку одной ноды вынесением остальных с сервера.
Получится ли перенести ноду, держащую нужную систему на сервер помощнее, как миграция относится к постоянным коннектам, сохранит ли?
За какое время осуществляется миграция, и что при этом происходит с самой машиной? Замораживается на несколько секунд/минут? Продолжает работать в штатном режиме, обрабатывая запросы?
P.S. Я только начал изучать возможности виртуализации, так что если вопрос ламерский — не обессудьте…
Вот такой пример. Предметная область — транспорт.
class Transport {...}
class RoadTransport extends Transport {...}
class AirTransport extends Transport {...}
А теперь нужно добавить подтип — пассажирский транспорт и грузовой. И пошли плодить подклассы:
PassengerRoadTransport, CargoRoadTransport, PassengerAirTransport, CargoAirTransport.
Либо наоборот — от транспорта наследовать грузовой/пассажирский, и от них уже наследоваться авто/жд/воздушный:
А можно сделать трейты Cargo и Passenger, в которых реализовать специфичные реализации (виртуальных) методов.
class Bus extends RoadTransport {
use Passenger;
…
}
P.S. Если можно как-то оптимизировать структуру дерева классов без трейтов — подскажите, я что-то не соображу…
Что запретит покоящемуся на земле телу с ускорением в 1,05 «же» покинуть Землю? Ничего. Потихоньку вылетит на орбиту, на 100 км поднимется за 24 минуты, на тысячу км за 1 час 15 минут (h = (a-g) * t ^ 2).
Единственно что — даст ли сабжевый двигатель такое ускорение (больше 10 м/с^2) для корабля массой 150 тонн.
var enemyCode = ev.scannedRobot.prototype.onIdle;
По событию onScannedRobot(e) можно получить ссылку на обнаруженного робота e.robot, и у него уже получить код:
Robot.prototype.onScannedRobot = function(ev) {
var r = ev.robot;
var enemyCode = ev.scannedRobot.onIdle;
r.rotateCannon( analyzeEnemyMovement(enemyCode) );
r.fire();
//…
};
Понятно, что функция analyzeEnemyMovement получится непростой, но всё же…
Но интересен сам факт, упомянутый в той передаче, что современная наука не может пересадить ОДИН ген, а пересаживается сразу довольно большой участок ДНК. Утверждается, что кроме требуемого гена переносится ещё несколько с неизвестным эффектом.
Я хотел уточнить, не встречались ли вы с такими фактами. Может, там в передаче вообще нагнали (любят телевизионщики это дело) и уже умеют точечно перемещать конкретные гены (о чём вы в статье и говорите).
Там в программе говорилось, что проблема может быть в самой ДНК с обрывком, торчащим в середине, что они будут химически активны и смогут разрушать окружающие молекулы. Что приведёт к болезням того ГМ-организма.
Если в форме регистрации есть второе поле с паролем для проверки — можно ли сделать так, чтобы при генерации пароля второе поле автоматически тоже заполнялось?
Кстати, тот плагин simplePassMeter (который с «more»), зря вы сразу его отсеяли, очень даже неплохой. У него есть пару интересных фишек — проверки matchField (указываем поле с pass2, чтобы оба введённых пароля совпадали) и noMatchField (указываем поле с логином, чтобы не совпадали). Самый большой недостаток — плохая модульность, сложно переводить и ещё сложнее сделать его мультиязычным.
Я примерно так всё и представлял, аргументация и методичность рассмотрения темы понравились.
Не знал такие подробности про селекцию.
Я вообще считаю, что без ГМ невозможно решить проблему голода на земле, особенно с учётом продолжения увеличения населения нашей планеты. Исследования генной инжинетрии не просто хорошо бы продолжать, их необходимо продолжать.
В одной передаче про ГМО (не помню, какая именно, вроде «Среда обитания», но там не было «ужас-ужас») была интересная инфа. Какой-то профессор говорил, что современные методы перемещения генов несовершенны, невозможно взять именно один ген и пересадить только его. При перемещении у донора вырезается целый кусок ДНК и пересаживается реципиенту. Причём кусок отрезается не ровно «по границе генов», а как придётся, от чего в итоговой ДНК могут появиться оборванные цепочки — свободные радикалы, имеющие ненулевой электрический потенциал и химическую активность.
Именно это я вижу как наибольшую опасность. Не сами ГМО, не гипотетическое «свиное рыло от ГМ-свниниы», а повышенную аллергичность (особенно для аллергиков).
Хотя, в случае «жёсткой» селекции должны появляться такие же «хвосты» из радикалов…
Интересно было бы услышать мнение топикстартера по этому поводу.
В файле /etc/nginx/templates/php параметр
fastcgi_pass unix:/tmp/wwwpool.sock;
этот конфиг подходит, если nginx стоит на той же машине, где и php-fpm. Если php-fpm на другой машине, то нужно писать
fastcgi_pass 10.0.0.1:9000;
А что делать, если используется несколько машин с php через upstream? Можно ли написать так:
upstream backend-php {
server 10.0.0.1:9000;
server 10.0.0.2:9000;
}
…
fastcgi_pass backend-php;
Я себе поставил на сервер систему виртуализации Proxmox (была на хабре пара статей о ней. Коротко — класс!), которая поддерживает OpenVZ- и kvm-виртуализацию. Но у меня только одна машина, поэтому миграцию не могу попробовать… А хотелось бы.
Но по прикидкам — нужно записать память в файл, передать по сети на соседнюю машину и там распаковать обратно в память. Пару секунд сохранять память, чуть дольше передавать и там ещё пару секунд запускать.
В общем, несколько секунд, вряд ли больше 2-3 минут. Но зависит от объёма памяти.
ru.wikipedia.org/wiki/OpenVZ#Чекпоинтинг_и_миграция_на_лету
>Так как все детали состояния VE, включая открытые сетевые соединения, сохраняются, то с точки зрения пользователя VE процесс миграции выглядит как задержка в ответе: скажем, одна из транзакций базы данных заняла больше времени, чем обычно, и далее работа продолжается как обычно; таким образом, пользователь не замечает, что его сервер баз данных работает уже на другом физическом сервере.
>Each of EVE's 5000+ star systems is loaded as a separate process onto any one of hundreds of IBM blade servers, with some high-load systems being given a server all to themselves and many low-load systems being combined and run on servers together
Интересно, что здесь не говорится про облако — «Каждая из 5000+ звёздных систем загружены как отдельные процессы на одном из сотен блейд-серверов».
Я сейчас не говорю что у них плохая система (всё-таки справляется с впечатляющей нагрузкой). Но, судя по всему, «на горячую» они переносить процессы не могут, и балансируется нагрузка не в реальном времени, а по статистике — «эти 4500 систем малопосещаемые, а эти 500 — загруженные, перетасуем их вместе».
Сейчас, как я понимаю, несколько процессов обработки систем (назову их нодами) висят на одном сервере, и разделить их сложно — необходимо остановить процесс (с потерей соединений) и поднять на новой машине.
А теперь пофантазируем. Поместим все расчётные ноды в облачный кластер — отдельный процесс обработки солнечной системы (ноду) в отдельную ВМ. За счёт возможности миграции виртуальной машины на другой узел кластера без остановки самой виртуальной машины появляется куча интересных возможностей по гибкому управлению нодами — балансировка нагрузкой серверов за счёт переноса нод, освобождение мощности сервера под возросшую нагрузку одной ноды вынесением остальных с сервера.
Получится ли перенести ноду, держащую нужную систему на сервер помощнее, как миграция относится к постоянным коннектам, сохранит ли?
За какое время осуществляется миграция, и что при этом происходит с самой машиной? Замораживается на несколько секунд/минут? Продолжает работать в штатном режиме, обрабатывая запросы?
P.S. Я только начал изучать возможности виртуализации, так что если вопрос ламерский — не обессудьте…
class Transport {...}
class RoadTransport extends Transport {...}
class AirTransport extends Transport {...}
А теперь нужно добавить подтип — пассажирский транспорт и грузовой. И пошли плодить подклассы:
PassengerRoadTransport, CargoRoadTransport, PassengerAirTransport, CargoAirTransport.
Либо наоборот — от транспорта наследовать грузовой/пассажирский, и от них уже наследоваться авто/жд/воздушный:
А можно сделать трейты Cargo и Passenger, в которых реализовать специфичные реализации (виртуальных) методов.
class Bus extends RoadTransport {
use Passenger;
…
}
P.S. Если можно как-то оптимизировать структуру дерева классов без трейтов — подскажите, я что-то не соображу…