@Gineaser, мирюсь с linux и со всеми мелочами которые так сильно раздражают, только лишь потому, что разрабатывать под WEB из под Windows раздражает на несколько порядков больше.
я очень ленивый шиндусятник пересевший по необходимости на linux (debian, ubuntu-gnome). Банально, но linux удобнее, windows сейчас запускаю только когда надо IE, и то как-то редко и только в виртуалке), на работе Mac + все та же Ubuntu gnome. Была б моя воля, сидел бы на Windows (и сидел какое-то время), но если жить мне в нем комфортно, сделать разработку в ней комфортнее у меня не вышло. Финал в этом всем поставила необходимость поработать с Docker.
Я очень ленивый человек, я не хочу тратить неделю на настройку "своего любимого arch linux", как это делал один мой коллега. Так же да, была некоторая проблема с драйверами видео под AMD, благо вроде как начали исправляться, на ядре 3,13 + последняя версия драйверов, почти все баги пропали, но частенько приходится перезапускать gdm при выходе ноута из режима сна.
Так же есть небольшая проблема с сопутствующим ПО. В частности дико расстраивает ситуация с аудиоплеерами, то что pulseaudio отжирает в дефолтной настройке одно ядро из четырех доступных (пришлось долго долго эксперементировать с различными вариантами что бы жить стало комфортнее). До сих пор есть кое-какие проблемы, типа крэши моего любимого (из того что есть под линь) клементина (я так понимаю всему виной некоторые плагины старые для GStreamer, но я уже не жду что клементин перейдет на актуальную ветку оного). Ситуация с плеерами настолько грустна, что я от безнадеги сижу сейчас и пишу еще один свой. Есть правда пара интересных проектов, у которых я черпаю вдохновение, но они либо сырые и полумертвые, либо мертвые.
Это все сугубо мое личное мнение, все эти проблемы - сущая мелочь. Но меня эти мелочи ооочень сильно раздражают. Пытаться предложить решение проблем так же смысла не вижу. Решений нету. Нужно просто надеяться что с развитием таких штук как StreamOS разработчики снизойдут до линукса.
1) я так и не понял как этот бенчмарк относится к задаче.
2) зато позволяет более гибко подойти к разработке. А код на сервере будет в любом случае, и дублирования я не вижу. Только "лишний" запрос на сервер. Возможно я просто не знаю деталей вашей задачи.
3) раскройте пожалуйста мысль, как вы себе это представляете?
Вообще у меня сложилось впечатление что я вас вообще не так понял. Пример "желаемого" инструмента был бы уместен.
@Ruslan72 верного нету. Есть три варианта, ActiveMQ, Gearman, Beanstalkd. Пробегитесь по документации, посмотрите есть ли под PHP библиотеки-фронтэнды...
@TsarS, под PHP/Ruby нету тех средств анализа, что есть для Python. numpy - это очень мощная библиотека для научных вычислений, аналогов ее нету ни под php ни по ruby, а без таких инструментов построение моделей что бы их можно было посчитать будет в десятки раз больше времени занимать. Не говоря уж того, что считаться все это будет банально быстрее (все тяжелое, преобразования различные и т.д. реализованы на C с различными оптимизациями, векторизацией вычислений и т.д.).
Методология... у вас черный ящик, который представляет собой систему компонентов. Внутри - более мелкие черные ящики... ну и т.д. То есть вы моделируете всю систему за счет более мелкий ее деталей. Во всяком случае я бы подходил с этой стороны к данному вопросу. То есть вы подаете в камеру сгорания смесь воздуха и топлива в определенном соотношении, вам известны параметры топлива, из этих данных нам известно и количество энергии, выделяемой при "взрыве", инициируемого свечей зажигания (еще один компонент, состояние которого зависит от времени). Далее мы можем посчитать давление, оказываемое на поршень (еще один компонент), момент вращения и все такое, все что относится непосредственно к поршню (мы же знаем все параметры системы в которой находится поршень). Отсюда мы можем посчитать моменты инерации и все такое (возможно что-то другое, я сейчас в пятничном настраении и где-то могу наврать) и мы можем спрогнозировать, в каком положении будет поршень в какой-то момент времени после взрыва. Ну и далее, по мере продолжения цикла, параметры системы будут чуть меняться (скажем поршню будет проще "проворачиваться"), усилится компрессия или что там... вот честно, не особо в теме.
Нууу... больше я наверное ничего не скажу... Может кто скажет, тема довольно интересная. Но обычно моделировать всю систему начинают исходя из ее компонентов и их взаимодействия друг с другом.
В контексте вопроса, мне было бы любопытней как реализуются модели ядерных взрывов, термоядерных процессов внутри звезд и т.д.
модификатора g и нет, уберите его. В JS он говорит о том, что бы шаблон применять глобально а не до первого вхождения... А в PHP это дело по умолчанию таково, так что нужды в этом модификаторе и нету.
@sannek8552 имхо, считаю это бредом, писать базовое правило, так как возникает желание забить на грамотную структуру урлов и делать абы как (собственно во всех проектах на Yii такую картину наблюдаю).
@Color именно так. Вообще мне очень сложно представить что заставило вас писать свой HTTP сервер на raw сокетах. Вам же столько всего нужно имплементить, и буферизацию пакетов, и контроль насыщения, и много прочего...
