URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 101482
[ Назад ]

Исходное сообщение
"Управление проектом Node.js переходит к руки некоммерческой ..."

Отправлено opennews , 12-Фев-15 23:19 
Компании Joyent объявила (https://www.joyent.com/blog/introducing-the-nodejs-foundation) об учреждении некоммерческой организации Node.js Foundation, которой будет передано управление разработкой Node.js (http://nodejs.org/) и вся связанная с проектом интеллектуальная собственность. Вопросы, касающиеся развития проекта и технических решений будут решать совет директоров и технический совет, в которые войдут сотрудники Joyent и наиболее активные представители сообщества и участвующих в разработке Node.js компаний. Таким образом, разработка будет перенесена на нейтральную площадку, а все процессы принятия решения будут  максимально прозрачны для сообщества.

Куратором проекта выступит организация Linux Foundation, которая поможет сформировать эффективную и независимою площадку для разработки Node.js. Компания Joyent продолжит своё участие в разработке, поддержке и финансировании проекта, но будет это делать сообща с другими заинтересованными лицами. Кроме  Joyent, в число основателей Node.js Foundation вошли такие компании, как IBM, Microsoft, PayPal, Fidelity и SAP.


Создание Node.js Foundation  является достаточно запоздалой попыткой пойти на встречу пожеланиям сообщества, выражавшего недовольство излишним контролем над проектом  в руках компании Joyent, единолично принимавшей решения о приоритетах в разработке проекта, что, в конечном счёте, привело (http://www.opennet.me/opennews/art.shtml?num=41144) к расколу сообщества и созданию форка io.js (http://www.opennet.me/opennews/art.shtml?num=41452). К разработке форка подключилось 5 из 7 ключевых разработчиков Node.js, среди которых Айзек Шлютер (Isaac Schlueter), бывший лидера проекта.

URL: https://www.joyent.com/blog/introducing-the-nodejs-foundation
Новость: http://www.opennet.me/opennews/art.shtml?num=41662


Содержание

Сообщения в этом обсуждении
"Управление проектом Node.js переходит к руки некоммерческой ..."
Отправлено asavah , 12-Фев-15 23:19 
Вот что fork животворящий делает!

"Управление проектом Node.js переходит к руки некоммерческой ..."
Отправлено Аноним , 13-Фев-15 04:21 
И я думаю что с учетом IBM, Microsoft, PayPal, Fidelity и SAP - будет намного лучше если форк будет оставиться на световые годы в стороне от этих контор.

"Управление проектом Node.js переходит к руки некоммерческой ..."
Отправлено Аноним , 14-Фев-15 04:49 
Ага. То есть программисты по твоему едят байты из интернета? И тупо еда им не нужна?

В конце 1980-х у СССР были _очень_ конкурентоспособные учёные, инженеры и даже программисты. Потом их перестали кормить. Они все теперь за бугром, а в России с этим, за редкими исключениями, чуть хуже чем никак :(

Ладно, танцпол получился, но это горькая правда. Даже те кто приезжает нынче - лишь бледная тень индусов.


"Управление проектом Node.js переходит к руки некоммерческой ..."
Отправлено Аноним , 14-Фев-15 06:23 
> Ага. То есть программисты по твоему едят байты из интернета?

А это кто как. А вот перечисленные конторы энтузиазм могут вызвать разве что у забитых индусов.


"Управление проектом Node.js переходит к руки некоммерческой ..."
Отправлено Michael Shigorin , 14-Фев-15 11:56 
> Они все теперь за бугром

...а технологии в России самозарождаются, ага.

> Даже те кто приезжает нынче

У тех, кто приезжает нынче, с головой совсем беда (в восьмидесятые-то получалось было умных, но наивных, обманывать "американской мечтой" да джинсами).

PS: звали; нет.


"Управление проектом Node.js переходит к руки некоммерческой ..."
Отправлено Аноним , 16-Фев-15 04:08 
>...а технологии в России самозарождаются, ага.

Ну кинь пример действительно рождённой новой полезной технологии.
И всех то дел. И я поскуливая уползу под лавку.
PS: Не приведешь, будешь тут неимеющиеаналогофф приводить и пилково всякое.


"Управление проектом Node.js переходит к руки некоммерческой ..."
Отправлено Аноним , 16-Фев-15 04:33 
Какие могут быть технологии в стране, где возродилась духовность?

"Управление проектом Node.js переходит к руки некоммерческой ..."
Отправлено Michael Shigorin , 16-Фев-15 17:32 
>> Ну кинь пример действительно рождённой новой полезной технологии.

Например, моя технология сборки связных наборов образов или вот это изобретение знакомого: http://www.freepatent.ru/patents/2434437; если хочется "поинтересней" -- от парашюта и синтетического каучука до abstract state machines и графена.

> Какие могут быть технологии в стране, где возродилась духовность?

Отличные технологии, красивые.  Надо быть дремучим неучем, чтобы не видеть этого по тем же самолётам.  Таким, который сам ничего не изобрёл и неспособен к этому в принципе.


"многопоточность"
Отправлено ТотСамыйИз4х , 12-Фев-15 23:35 
Слушайте, а многопоточность будет встроена в iojs или nodejs хотя бы в ближайшем будущем?

"многопоточность"
Отправлено Аноним , 13-Фев-15 00:18 
Она там и так есть. Можно использовать либо нативный, но излишне громоздкий инструментарий "Child Process", либо удобный (но без поддержки асинхронности) модуль Parallel.js, который по сути является оберткой вокруг первого.

p.s. JavaScript изначально однопоточный язык, оттуда такие неудобства.


"многопоточность"
Отправлено ТотСамыйИз4х , 13-Фев-15 00:46 
я посмотрел. Там вроде один "поток" будет целым отдельным процессом.

"многопоточность"
Отправлено dchusovitin , 13-Фев-15 01:39 
Ага, просто порождает дочерние процессы.

Многопоточности в node.js/io.js особо ждать не стоит. Ибо изначально противоречит идеи проекта, один процесс и асинхронный IO.
Хотя есть JXCore (http://jxcore.com/home/), который, как пишут "multithreaded". Сам не пробовал.
Как вариант, многопоточность можно организовать на c/с++, порождает потоки, считает и возвращает конечный результат.

Когда сталкивался с этим, то написал отдельное приложение (не на node.js). И далее через zeromq общение между двумя приложениями.


"многопоточность"
Отправлено Аноним , 13-Фев-15 07:44 
какой эпичный набор костылей. А в Go достаточно запускать функции в отдельных горутинах и завести переменную типа "канал" для передачи сообщений.

"многопоточность"
Отправлено Andrew Kolchoogin , 13-Фев-15 10:02 
А на языке Ассемблера можно та-а-а-акое наваять... ;)

"многопоточность"
Отправлено анонимус , 13-Фев-15 12:00 
Причем тут язык ассемблера? Во всех вменяемых языках можно использовать потоки, которые не являются отдлельным процессами, прости господи.

"многопоточность"
Отправлено Аноним , 13-Фев-15 14:45 
Не во всех. В некоторых особенно известных популярных Thread идет не из коробки, а прикручивается отдельно.

"многопоточность"
Отправлено ананим.orig , 13-Фев-15 09:25 
> я посмотрел. Там вроде один "поток" будет целым отдельным процессом.

для linux это один хрен
> man pthreds
> Both threading implementations employ the Linux clone(2) system call.  In NPTL, thread synchronization primitives (mutexes, thread joining, and so on) are implemented using the Linux futex(2) system call.

а на офтопик нас рать.


"многопоточность"
Отправлено Мяут , 13-Фев-15 11:26 
Ну во первых в более Unix'овых системах (Solaris (Joyent SmartOS кстати его дальний родственник), FreeBSD) есть легковесные процессы (LWP), и потоки работают именно через них. Во вторых цены fork() и pthread_create() даже в Linux отличаются.

"многопоточность"
Отправлено ананим.orig , 13-Фев-15 11:55 
Во-первых — если читать книжки 20-30-летней давности, то это безусловно так.
Во-вторых — в линухе тоже есть легковесные процессы. И они тоже создаются сисколом clone.
В-третьих — с учётом cow и clone в линухе фактически нет разницы (ни по скорости создания, ни по ресурсоёмкости) между созданием процесса и потока. А все реализации (аля pthreads, с++11 threads,..) всего-лишь надстройки над этим.

Поднимать эту тему (по крайней мере в линухе) уже просто моветон (фф и хром не с болды перешли от трэдов к многопроцессности).
По этому вопросу уже можно определять пользователей легаси-ос. Ну или людей с устаревшими знаниями по этому вопросу.


"многопоточность"
Отправлено анонимус , 13-Фев-15 12:01 
>[оверквотинг удален]
> Во-вторых — в линухе тоже есть легковесные процессы. И они тоже создаются
> сисколом clone.
> В-третьих — с учётом cow и clone в линухе фактически нет разницы
> (ни по скорости создания, ни по ресурсоёмкости) между созданием процесса и
> потока. А все реализации (аля pthreads, с++11 threads,..) всего-лишь надстройки над
> этим.
> Поднимать эту тему (по крайней мере в линухе) уже просто моветон (фф
> и хром не с болды перешли от трэдов к многопроцессности).
> По этому вопросу уже можно определять пользователей легаси-ос. Ну или людей с
> устаревшими знаниями по этому вопросу.

Угу. Только память у этих процессов будет разная.


"многопоточность"
Отправлено анонимус , 13-Фев-15 12:42 
>[оверквотинг удален]
>> сисколом clone.
>> В-третьих — с учётом cow и clone в линухе фактически нет разницы
>> (ни по скорости создания, ни по ресурсоёмкости) между созданием процесса и
>> потока. А все реализации (аля pthreads, с++11 threads,..) всего-лишь надстройки над
>> этим.
>> Поднимать эту тему (по крайней мере в линухе) уже просто моветон (фф
>> и хром не с болды перешли от трэдов к многопроцессности).
>> По этому вопросу уже можно определять пользователей легаси-ос. Ну или людей с
>> устаревшими знаниями по этому вопросу.
> Угу. Только память у этих процессов будет разная.

Ну и насчет clone():

       The  main  use  of clone() is to implement threads: multiple threads of
       control in a program that run concurrently in a shared memory space.


"многопоточность"
Отправлено ананим.orig , 13-Фев-15 13:38 
и что?
Вариантов потоков больше.
Вот и всё.

В линухе вообще процесс — это частный случай потока.
fork реализован через clone.


"многопоточность"
Отправлено анонимус , 13-Фев-15 13:42 
> и что?
> Вариантов потоков больше.
> Вот и всё.
> В линухе вообще процесс — это частный случай потока.
> fork реализован через clone.

Уф. Ещё раз. У процесса своя память. У потока -- нет. Отсюда и различные сценарии использования.


"многопоточность"
Отправлено ананим.orig , 13-Фев-15 13:54 
Да, это первый курс, первый семестр.
А вот что далее? Какова реализация всего этого? При чём аппаратная.

Короче, ман «страничная память», ман «cow», ман «сlone».
«Своя память» в страничных таблицах (термин такой — страничные таблицы) «превращается» в одни и те же физические ячейки памяти, при этом особенности аппаратной архитектуры таковы, что скопировать страницу порой проще и быстрее, чем один байт.

зыж
вы вообще про шарэд-объекты в курсе? .so? .dll?
Ну вот тоже самое, только на уровне ядра и на аппаратном уровне проца (и памяти) давно уж как реализовано. Некоторые ОС этим активно пользуются.


"многопоточность"
Отправлено клоун , 13-Фев-15 15:26 
Есть функции, позволяющие расшарить свою память (shared memory) для других процессов. Есть меж-процессное взаимодействие (IPC), которое позволяет синхронизировать выполнение между несколькими процессами/потоками.

"многопоточность"
Отправлено анонимус , 13-Фев-15 16:08 
> Есть функции, позволяющие расшарить свою память (shared memory) для других процессов. Есть
> меж-процессное взаимодействие (IPC), которое позволяет синхронизировать выполнение
> между несколькими процессами/потоками.

Есть. Только зачем мне всё это, если я хочу очередь обрабатывать?


"многопоточность"
Отправлено анонимус , 13-Фев-15 16:09 
>> У нас есть процесс. У него есть доступ к своей памяти.
> Ещё раз, для отстающих.
> У процесса (и потока) есть доступ к своей ВИРТУАЛЬНОЙ памяти.
> Своей физической памяти у него нет и не может быть.

А кто тут говорит про физическую память?

> Всё остальное — наслоение одних упрощённых понятий на другие. Ну первый курс,
> первый семестр, чесслово.

Это называется "абстракции". Их придумали, чтобы не писать всё на ASM. Знакомься, чо.


"многопоточность"
Отправлено ананим.orig , 13-Фев-15 16:28 
> Это называется "абстракции". Их придумали, чтобы не писать всё на ASM. Знакомься, чо.

Это называется троллинг.
Потому как "спорить" ты стал не о каких то "абстракциях", а о реализации в ядре линукса.
Поскольку знаний, умений и навыков не хватило (а также воспитания), то вот, результат.

Алё! Какой asm? clone — это сискол. Это API ядра. Хоть из bash-скриптов вызывай.


"многопоточность"
Отправлено ананим.orig , 13-Фев-15 16:01 
> Это ты умничаешь без необходимости.
> Процесс объединяет все используемые программой ресурсы, но диспетчеризация задач производится ОС на основании потоков.

Я вполне могу создать 2-а (и более) процесса (не потока. Будут в списке процессов) с адним и тем же адресным пространством.
clone позволяет мне это делать штатно и легально и не зависимо от того что за понятия в ваших мозгах по этому поводу сформировались. ☺


"многопоточность"
Отправлено анонимус , 13-Фев-15 16:10 
>> Это ты умничаешь без необходимости.
>> Процесс объединяет все используемые программой ресурсы, но диспетчеризация задач производится ОС на основании потоков.
> Я вполне могу создать 2-а (и более) процесса (не потока. Будут в
> списке процессов) с адним и тем же адресным пространством.
> clone позволяет мне это делать штатно и легально и не зависимо от
> того что за понятия в ваших мозгах по этому поводу сформировались.
> ☺

Это называется терминология. Опять же, знакомься.


"многопоточность"
Отправлено ананим.orig , 13-Фев-15 16:16 
Это называется «не лезь не в свой разговор».
Вон выше повод для размышлений для тебя оставил, а сюда тебе пока рано.

зыж
> Это называется терминология. Опять же, знакомься.

вот именно.
и эти термины далеко не аксиомы 20-30 летней давности.


"многопоточность"
Отправлено ананим.orig , 13-Фев-15 16:09 
> но диспетчеризация задач производится ОС на основании потоков.

тоже не верно.
диспетчер манипулирует контекстом выполнения. иногда в литературе называют задача(task).
ни к потоку, ни к процессу не имеет отношения в общем случае.


"многопоточность"
Отправлено ананим.orig , 13-Фев-15 17:14 
> Процесс и поток - это термины Windows, в Линукс они называются процесс и нить соотв.

Да ладно! Что за чушь.
Термины process и thread есть в обоих ОС. В доках, манах,.. в коментариях исходного кода.
И мелкософт вроде никак не патентовал их перевод на русский.

Следовательно всё что вы сказали — не верно сформированные понятия терминов в процессе вашего обучения.
Ещё проще — суеверия. :D

Зыж
> Рекомендую черпать знания не из литературных источников, а из технической документации.

Очевидно что в отличие от вас я именно так и сделал. Включая и исходный код.
Так что не вам давать мне советы. По крайней мере не по этому вопросу уж точно. :D


"многопоточность"
Отправлено ананим.orig , 13-Фев-15 13:45 
зыж
> ЗАМЕЧАНИЯ
>       В  Linux,  fork()  реализован  с  помощью  «копирования  страниц  при записи» (copy-on-write, COW), поэтому расходы на вызов состоят из времени и памяти, требуемой на копирование страничных таблиц родителя и создания уникальной структуры, описывающей задачу.
>       Начиная с версии 2.3.3, вместо того, чтобы вызывать системный вызов fork(), обёрточная функция fork() в glibc, как часть реализации нитей NPTL,  вызывает  clone(2)  с флагами,  которые  обеспечивают  поведение  традиционного  системного вызова (вызов fork() эквивалентен вызову clone(2), если значение равно flags SIGCHLD). Обёртка в glibc вызывает все обработчики при ветвлении (fork), которые были зарегистрированы с помощью pthread_atfork(3).

Вывод из $ man fork.
В свою очередь потоки из стандарта C++11 реализованы через pthreads, т.е. всё таже обертка над clone. Ну и тд и тп.


"многопоточность"
Отправлено ананим.orig , 13-Фев-15 13:36 
> Угу. Только память у этих процессов будет разная.

Ну и что? Память то виртуальная.
Вопрос только в относительной ценности единовременно выделяемых ресурсов. И не факт, что сильно больше, чем у потоков.
Да и то только при записи туда.
При чтении виртуальные адреса ссылаются на те же физические ячейки памяти.
Ман cow.
clone вообще настолько гибкий сискол и там столько вариантов создания потоков/процессов, что и поток может быть со своим адресным пространством (и для данных, стэка,.. и для команд).


"многопоточность"
Отправлено анонимус , 13-Фев-15 13:43 
>> Угу. Только память у этих процессов будет разная.
> Ну и что? Память то виртуальная.
> Вопрос только в относительной ценности единовременно выделяемых ресурсов. И не факт, что
> сильно больше, чем у потоков.
> Да и то только при записи туда.
> При чтении виртуальные адреса ссылаются на те же физические ячейки памяти.
> Ман cow.
> clone вообще настолько гибкий сискол и там столько вариантов создания потоков/процессов,
> что и поток может быть со своим адресным пространством (и для
> данных, стэка,.. и для команд).

Причем тут ресурсы? У потоков общая память. В этом весь смысл, упростить работу с общей памятью.


"многопоточность"
Отправлено ананим.orig , 13-Фев-15 14:44 
Ззззззззыж
> У потоков общая память. В этом весь смысл, упростить работу с общей памятью.

С теоретической точки зрения. При чём 20-летней давности.
А практически это озночает, что у потоков страничные таблицы указывают на одни и теже физические ячейки памяти.
В линухе с процессами тоже самое, но до того момента, пока один из процессов не начнёт писать  в память (очевидно это различного рода переменные).
К тому же вполне возможно при помощи clone (не fork. fork — это частный случай) создать процесс (не поток) с общим адресным пространством.

По поводу "упростить работу". Угу. Потом думай о блокировках, критических секциях, фьютексах, мьютексах сам.
При этом если напортачил, то падает/блокируется не один поток, а все сразу.
Поэтому и важно знать как именно управляет процессами/потоками сама ОС, а не тот минимум, что вынесен в абстрактный уровень различных языков высокого уровня.
А там реально минимум по сравнению с clone.


"многопоточность"
Отправлено Мяут , 13-Фев-15 19:27 
> в линухе

Но я ведь не про линух. А не в линухе как раз использование fork() - моветон ;) И тем более моветон, что основная статья дохода Joyent - это не линух. Хотя они вроде бы lx-зоны вернули.


"многопоточность"
Отправлено ананим.orig , 13-Фев-15 20:52 
> Но я ведь не про линух. А не в линухе как раз использование fork() - моветон ;)

это в каких? так или иначе, но почти во всех никс-лайк системах примерно так же (±, но не только glibc использует ос-специфичные особенности внутри реализации С/С++ стандартов).

если вы вантуз имели в виду, то так и скажите. ☺


"многопоточность"
Отправлено Аноним , 13-Фев-15 06:50 
Много поточность и много процессорность разные вежи.

"многопоточность"
Отправлено Аноним , 13-Фев-15 08:50 
много процессорность и много процессность это тоже разные вещи

"многопоточность"
Отправлено casm , 13-Фев-15 10:01 
Посмотрите модуль cluster. Он позволяет запускать несколько workers на разных ядрах, но которые отвечают через один общий tcp порт.
Если найдёте книгу Node.js in action, это в ней это описывается в разделе 12.3.2 либо в описании к модулю в npm.

"многопоточность"
Отправлено Анононим , 13-Фев-15 14:24 
есть ещё один форк, называется jxcore. в котором, по заявлением разработчиков, это основная фича

"Управление проектом Node.js перейдёт в руки некоммерческой о..."
Отправлено A.Stahl , 12-Фев-15 23:44 
>К разработке форка подключилось 5 из 7 ключевых разработчиков

Node.js`у реорганизация как мёртвому припарки.
Доктор сказал: "в Apache Foundation".


"Управление проектом Node.js перейдёт в руки некоммерческой о..."
Отправлено Вадик , 12-Фев-15 23:54 
Поздно. Главный разраб потерял веру в проект и росил их уйдя к будущим конкурентам, форк сделали, а в руки некоммерческой организухе передали... ну что же посмотрим как она сможет управиться с такой махиной...

"Управление проектом Node.js перейдёт в руки некоммерческой о..."
Отправлено Аноним , 13-Фев-15 00:39 
> Поздно. Главный разраб потерял веру в проект и росил их уйдя к
> будущим конкурентам, форк сделали, а в руки некоммерческой организухе передали... ну
> что же посмотрим как она сможет управиться с такой махиной...

TJ Holowaychuk то? Он никогда не был главным разрабом node, просто автор нескольких популярных пакетов в npm. Кстати, некоторым из ним (express, например) его уход пошел явно на пользу.

Главный разраб у них сейчас TJ Fontaine, а изначально автор - Ryan Lienhart Dahl, который во время работы в Joyent и создал Joyent :)


"Управление проектом Node.js перейдёт в руки некоммерческой о..."
Отправлено Аноним , 13-Фев-15 08:00 
Тогда получается что в заголовке соврали. Подали что дескать все бросили, а оказывается опять ушли любители не скучных обоев.

"Управление проектом Node.js переходит к руки некоммерческой ..."
Отправлено Michael Shigorin , 13-Фев-15 00:36 
No Joy Foundation?

"Управление проектом Node.js переходит к руки некоммерческой ..."
Отправлено Аноним , 13-Фев-15 13:48 
> No Joy Foundation?

JoyNo Foundation - сокр. от Joyent Node.js Foundation.


"Управление проектом Node.js перейдёт в руки некоммерческой о..."
Отправлено Капитан , 13-Фев-15 01:02 
> Linux Foundation

Очередной Vendor lock-in


"Управление проектом Node.js перейдёт в руки некоммерческой о..."
Отправлено ананим.orig , 13-Фев-15 09:42 
А чего именно он вендор?

"Управление проектом Node.js перейдёт в руки некоммерческой о..."
Отправлено Аноним , 13-Фев-15 02:51 
Ну и кто кого?

"Управление проектом Node.js перейдёт в руки некоммерческой о..."
Отправлено Аноним , 13-Фев-15 10:12 
Вчера качал версию node.js под Win32 так и не понял куда ставятся пакеты. На столько извратили этот NPM и вообще идею CLASS_PATH, что дальше некуда. Пришлось к проекту класть node_modules. Парни нельзя же так. Зачем писать в мой Rouming? Нужно сначала спросить у среды где я собираюсь хранить пакеты, а там уже и указать. Сколько не менял перменные среды NODE так ничего и не поменялось. Вообщем впечатление подпортили.

"Управление проектом Node.js перейдёт в руки некоммерческой о..."
Отправлено Аноним , 13-Фев-15 10:51 
А не надо пользоваться оффтопиком.

"Управление проектом Node.js перейдёт в руки некоммерческой о..."
Отправлено Аноним , 13-Фев-15 11:39 
почитайте чтоли туториалы. В Node.js ставить все подряд с ключем "-g" считается плохой практикой, а

>Пришлось к проекту класть node_modules

- хорошей, позволяющей избежать проблем с несовместимостью версий и т.п.