Разместите еще и ссылку на подробнейшее объяснение, что это такое, и почему: timhydr.livejournal.com/60400.html (то ли владелец, то ли один их менеджеров Ринета)
По ссылке:
"
RiNet — провайдер старый (один из первых в стране), но маленький. Мы люди не скандальные. Работящие. Просто делаем свое дело. Но скажу честно — тут нам стало просто обидно. Я — понимаю это глупо. Тем не менее. Собственно в основе этой акции — «Чистый интернет» — лежала простая мысль — творится абсурд. Как можно ответить на исходящий сверху абсурд? Только встречным абсурдом. Что еще мы можем сделать в сложившейся ситуации? Только смеяться. Ну вот еще можно попиариться :-/ Хотя, Гугл свидетель, дурные пиар акции — не наш стиль.
Но попробую в этом тексте все таки сказать несколько серьезных вещей.
"
С другой стороны Apple тут тоже причем :) Потому что iMessage тоже играет на том же поле (и достаточно активно используется пользователями яблочной продукции).
Шикарная вещь. Как некогда обладатель, гарантирую. Причем не только и не столько возможностями для программирования, сколько количеством возможностей для мат. вычислений.
Основной локомотив по добыванию денег у них все равно Офис, винда, емнип, на втором месте (очень крупном и вкусном, но втором). А дальше все упирается в банальные подсчеты и планирование: если бесплатная винда позволит сохранить доминирование на десктопе и даст толчок мобильному подразделению, то даже от такого куска можно отказаться и раздавать его дешево или бесплатно.
Тем более, что у них перед шлазами есть Apple, который уже давно и успешно пользуется этой стратегией.
+ ко всему описываемому в комментах: а как у него с подключением внешних мониторов/проекторов? А то на роате у Делловцев с Убунту постоянно проблемы (то работает, то не работает, то работает в одних случаях и не работает в других).
Было бы от чего быть батхерту. Батхерт на протяжении всего этого топика (и любого другого про ноду) у нодежсников. Еще бы его у них не было. Им впарили аналог nginx+php-fpm, а они рады. Вот и приходится делать невероятные усилия, чтобы не обращать на этот факт внимания. От этого и попоболь.
> Но я ж не бегаю по этому поводу срать кирпичами в эрланговский блог, как товарисч из первого поста.
Товарищ из первого поста внятно и аргументировал свою позицию, в отличие от школоты на ноде, у которой единственные «аргументы»:
— зато удобно писать
— кофескрипт — это удобно
и не забыть
— зато удобно писать
Вы читали комментарий по ссылке, что я привел? Видимо, не читали. Понять, что там написано, вы тоже не в состоянии.
Дам только домашнее задание.
Дано: обработка данных.
В случае, если VM одна, и она способна перекидывать задания самостоятельно между CPU, такая VM способна распределить нагрузку между ядрами самостоятельно. При этом той же VM доступна простейшая оптимизация: так как VM одна, то данные туда-сюда копировать не надо, достаточно передавать указатель.
В случае, если VM несколько? А ничего. Любые данные между этими VM будут копироваться при каждой попытке передать данные туда-сюда. Это, безусловно, архитектурно правильное и мегаудобное решение, ага.
Про то, что VM, знающая, что такое multicore, способна грамотно управлять процессами и структурами данных, чтобы минимизировать прочие накладные расходы, я умолчу, для вас это будет высшая математика. Радуйтесь, что вы переизобрели nginx + php-fpm под другим, более хайповым названием.
> а то вы все время вырываете цитату из контекста — «мы истекали кровью на всем протяжении разработки, но я не никогда не видел команды, делающей интересное приложение, без кровопролития, связанного с инструментами и компонентами».
Люде не говорят «истекали кровью», а «было сложно», «мы столкнулись с такими-то и такими-то трудностями» и т.п.
> в JS совсем недавно появилась поддержка потоков (воркеров), и люди начали ее понимать. Почему бы не сделать по такой же схеме многопроцессорное распределение?
Ну попытайтесь его сделать в VM/фреймворке, который не поддерживает многопроцессорность и является однопоточной по определению.
> Да, печалько, что оно не шарит память, но возможности для машстабирования предусматривают не только наращивание процессоров, а и серверов и вы сможете легко и безболезненно перейти к выполнению скриптов на другом сервере
Тогда нет никакой разницы между node.js и, скажем, php-fpm. Но я понимаю, хайп, да. Не говоря о том, что возможность использовать несколько ядер не отменяет возможности масштабирования на несколько серверов, и наоборот.
> Это как бы признание того, что быстроподнятное упавшим не считается.
Ситуация с node.js вообще напомниает ранние Rails, в которых тоже все падало, глючило, все было дико сырое, но все делали хорошую мину при плохой игре. И только пару лет спустя DHH, автор Rails, сказал: это было такое говно, что мы его по скрипту прибивали и перезапускали раз в нцать минут. Точно такие же детские проблемы сейчас переживает и node.
> Вы не в состоянии сделать первое (во всяком случае разумными методами) и не в состоянии контролировать второе, пусть у VM голова и болит, что и как делать.
Вы не способны понять, что VM неспособна сделать все, о чем я говорил
> А я спрашивал — какой конкретный паттерн проектирования не может быть реализован в ноде.
Школоло. Паттерны программирования не ограничиваются паттернами объектно-ориентированного программирования.
В общем, прекращаю этот разговор в одностороннем порядке. Мне не платят за то, чтобы обучать школьников.
По ссылке:
"
RiNet — провайдер старый (один из первых в стране), но маленький. Мы люди не скандальные. Работящие. Просто делаем свое дело. Но скажу честно — тут нам стало просто обидно. Я — понимаю это глупо. Тем не менее. Собственно в основе этой акции — «Чистый интернет» — лежала простая мысль — творится абсурд. Как можно ответить на исходящий сверху абсурд? Только встречным абсурдом. Что еще мы можем сделать в сложившейся ситуации? Только смеяться. Ну вот еще можно попиариться :-/ Хотя, Гугл свидетель, дурные пиар акции — не наш стиль.
Но попробую в этом тексте все таки сказать несколько серьезных вещей.
"
А при чем тут Apple?
Хотя да, вопрос о лицензировании корректен.
Тем более, что у них перед шлазами есть Apple, который уже давно и успешно пользуется этой стратегией.
Про Erlang я речь даже не заводил. Но ваш текст показателен по силе батхерта у нодежсников.
> рассказывать про высосанные из пальца проблемы
Высосаные из пальца? Ну-ну.
Товарищ из первого поста внятно и аргументировал свою позицию, в отличие от школоты на ноде, у которой единственные «аргументы»:
— зато удобно писать
— кофескрипт — это удобно
и не забыть
— зато удобно писать
Остальное тут: habrahabr.ru/post/160447/#comment_5505921
Дам только домашнее задание.
Дано: обработка данных.
В случае, если VM одна, и она способна перекидывать задания самостоятельно между CPU, такая VM способна распределить нагрузку между ядрами самостоятельно. При этом той же VM доступна простейшая оптимизация: так как VM одна, то данные туда-сюда копировать не надо, достаточно передавать указатель.
В случае, если VM несколько? А ничего. Любые данные между этими VM будут копироваться при каждой попытке передать данные туда-сюда. Это, безусловно, архитектурно правильное и мегаудобное решение, ага.
Про то, что VM, знающая, что такое multicore, способна грамотно управлять процессами и структурами данных, чтобы минимизировать прочие накладные расходы, я умолчу, для вас это будет высшая математика. Радуйтесь, что вы переизобрели nginx + php-fpm под другим, более хайповым названием.
Вы вообще поняли, что я написал?
> Или ерланг не использует передачу сокета между процессами?????????????????
Что вы имеет в виду под «передачей сокета между процессами» и зачем это нужно процессам в Эрланге?
Он меня не смущает. Он показывает, насколько это костыль. здесь я уже все описал
> P.S. Признайтесь, что пофигу что там нода — важно, что не ваш любимый ерланг?
Да пофиг, что. Хоть Ява. Но я понимаю, хайп — это дело такое. Заставляет любить даже очевидные недостатки.
Только nginx + php-fpm (или ruby или питон или...) не притворяются «platform for easily building fast, scalable network applications».
Если взять только Nginx, то он явно отличается от node.js хотя бы тем, что умеет работать с несколькими ядрами: nginx.org/en/docs/ngx_core_module.html#worker_cpu_affinity
> так что можно спокойно писать, хуже уже не будет.
# should be
# res.redirect long_url, 301
# but crashes and I dont know why :(
и трижды скопипастеный код в разных файлах.
О да, хуже действительно не будет. Просто некуда.
Люде не говорят «истекали кровью», а «было сложно», «мы столкнулись с такими-то и такими-то трудностями» и т.п.
> в JS совсем недавно появилась поддержка потоков (воркеров), и люди начали ее понимать. Почему бы не сделать по такой же схеме многопроцессорное распределение?
Ну попытайтесь его сделать в VM/фреймворке, который не поддерживает многопроцессорность и является однопоточной по определению.
> Да, печалько, что оно не шарит память, но возможности для машстабирования предусматривают не только наращивание процессоров, а и серверов и вы сможете легко и безболезненно перейти к выполнению скриптов на другом сервере
Тогда нет никакой разницы между node.js и, скажем, php-fpm. Но я понимаю, хайп, да. Не говоря о том, что возможность использовать несколько ядер не отменяет возможности масштабирования на несколько серверов, и наоборот.
> Это как бы признание того, что быстроподнятное упавшим не считается.
Ситуация с node.js вообще напомниает ранние Rails, в которых тоже все падало, глючило, все было дико сырое, но все делали хорошую мину при плохой игре. И только пару лет спустя DHH, автор Rails, сказал: это было такое говно, что мы его по скрипту прибивали и перезапускали раз в нцать минут. Точно такие же детские проблемы сейчас переживает и node.
Да
> Вы не в состоянии сделать первое (во всяком случае разумными методами) и не в состоянии контролировать второе, пусть у VM голова и болит, что и как делать.
Вы не способны понять, что VM неспособна сделать все, о чем я говорил
> А я спрашивал — какой конкретный паттерн проектирования не может быть реализован в ноде.
Школоло. Паттерны программирования не ограничиваются паттернами объектно-ориентированного программирования.
В общем, прекращаю этот разговор в одностороннем порядке. Мне не платят за то, чтобы обучать школьников.