Дак по вашей логике все друг друга копируют. В винде окна полупрозрачные как в макоси, опять же рабочие столы вирутальные появились в десятке на манер *nix'ов. Той же макоси или любой другой линуксовой DE. Кнопки вообще типа как в Dock'е macOS. Unity тот же появился почти одновременно с 7-кой, в которой были первые большие кнопки, которые можно было давно сделать в кедах или XFCE. Еще раз говорю по вашей логике все тырят у Xerox поэтому нет смысла сравнивать.
Если вы пишете софт заточенный чисто Linux?
Разумеется, запускать его через какой-нибудь Docker будет явно быстрее, чем через виртуальную машину как это нужно делать в Windows/MacOS
Под все, и даже под встраиваемые системы. Чаще это Embedded Soft, микроконтроллеры, DSP, вплоть до кроссплатформенных апок для Win/Lin/OSX и иногда даже бекенды на java/js/python/go/C#/C++.
У меня нет такой жесткой привязки софта. Я вот пришу софт под Linux, но запускаю его под Windows, потом просто перекомпилируется перед отправкой в production. Благо в Go это элементарно. Тут все от возможностей вашего инструмента зависит и архитектуры вашего приложения.
Все что мне нужно размазано по трем осям. Не вижу никаких проблем разрабатывать под языки типа Rust/Go под линуксом. Это все работает приблизительно одинаково на всех трех осях.
Понадобится частичная эмуляция Linux — запускается щелчком и быстро — WSL. Понадобится полная эмуляция — Vagrant. А тут скоро WSL 2 будет (в бета-версии уже доступен), так там полная эмуляция одним щелчком.
Не, у WSL что 1, что 2 — куча проблем. Я пока как человек имеющий экспертизу в ядре linux считаю это поделием.
На современном железе — виртуалки не напрягают. У меня вот IDE от JetBrains больше жрет чем весь разрабатываемый прямо сейчас мною софт серверный, если его в виртуалках запускать.
Ну замечательно. У меня например проблемы с кривым индусским менеджером ресурсов в винде поэтому я свои исследования для PhD по AI провожу на рабочей станции на втором тредрипере и о GeForce'ах под Арчем, а macOS Mojave мне, соответственно, не позволяет подключить ExtGPU 4 RTX'а, собственно, как и High Sierra. Виртуалку макоси не нарушая закона вы не на маке вообще не запустите. Не важно vmWare это, QEMU с Pass Thru или еще что.
А в каком месте гном и кеды виндообразные? Или скажем юнити? В чем они старательно копируют вынь или макось? Там вообще ниче не нужно настраивать, как почти в люом DE, Типа Budgie, да даже пантеон, который явно напоминает макось «изкоробки» красив и функционален. Что-то вы не то говорите.
Речь шла о разработке. Разработка в линуксе пока лучше даже чем на макоси. Про гуй речь идет в другой ветке. И да, я пользуюсь Win, Linux, macOS. И в винде он таки самый говеный, неудобный, непродуманный и туповатый.
Это все голословные утверждения не имеющие ничего общего с реальностью. Ладно бы еще сравнивать с macOS потому что по завершенности он наверное самый лучший, хотя тоже есть нарекания, но корявый виндовый интерфейс сравнивать… Что касается копирования, то почти все основное придумали в Xerox и пока ничего особо нового и революционного после этого не появилось. Все копируют у них. Ну и как-то глупо спорить с очевидными вещами.
Давно там не нужно ни с чем бороться. Это уже мифы. Что касается разработки, то в Linux или macOS давно все прекрасно работает и танцев с бубнами не нужно. Все делается быстренько из консольки и работает как часы. Чего не могу сказать о связке Windows + WSL2 где все мягко говоря через одно место.
Я думаю, вы прекрасно поняли что я хотел сказать. Я уверен в этом. Возможно вы линукс видели последний раз в 2003-ем? Потому что по части GUI дистрибутивы линукса давно уже перегнали десятку. А некоторые DE уже и к макоси приблизились, а в чем-то даже перегнали.
Какой вы обидчивый. Вы знаете, буду летом в гостях в кампусе гугла — я обязательно байку про вас расскажу, только до этого я не собирался упоминать ваш ник, а сейчас думаю что стоит.
Слушайте, очень печально что вы разрабатываете хромиум, раз вы даже в упор не видите что вы скидываете мне ссылку на «V8 Bindings Design». Почитайте, разберитесь и не морочьте голову, недоразработчик, спросите у вашего тех лида наконец.
Я не могу понять, или я слишком сложно объясняю, или что.
Тут в принципе не важно как это называется внутри кода на JS. Есть механизм расширения чего бы там ни было. Если бы JS или Python в принципе могли нативно запускать машинный код библиотеки на С/С++, пусть даже объектный, и имели бы прямой доступ к языковым конструкциям этих языков они бы могли считаться рапперами. Так как ни один из них в принципе такого не умеет, то все, что происходит лишь экспортирование дополнительного набора команд для интерпретатора или виртуальной машины. затем уже, во время выполнения когда виртуальная машина или интерпретатор видят определенную языковую конструкцию они начинают по этому ключу дергать нативный для себя код. А так как они написаны на С/С++ для них это не проблема. Поэтому это и называется байндингом, потому что мы байндим исполнение какого-то нативного кода к инструкции виртуальной машины или интерпретатора.
У меня такое же впечателение после этой ветки о вас сложилось. И я уже несколько лет являюсь разработчиком Chromium и занимаюсь как раз расширением API V8 для специфических задач. Внезапно, да?
Ну печально тогда. Тут есть два варианта: вы в принципе не понимаете как это работает, вы не поняли о чем именно спор. В любом случае я предлагаю вам описать механизм запуска «нативного» C/C++ кода с помощью JS скрипта, назовите это раппером, как хотите. Просто опишите.
=)))))))))) Слушайте, ну это реально смешно. То что вы пытаетесь за уши притянуть JS раппинг C++ объекта говорит лишь о том, что вы ничерта не понимаете, как это работает. Ну серьезно, вам даже в последней ссылке пишут «bindings». То что вы в C++ модуле экспортируете какие-то языковые конструкции в пространство виртуальной машины V8 а потом наворачиваете сверху уже js раппер над этими командами не делает это раппером над C++.
И даже класс который называется Wrappable вас не смущает? Да, этот класс и будет раппером. Но это С++ класс.
«v8::Object as platform object is called „wrapper object“.»
Нет, CPP модуль это не байндинг, это раппер и модуль экспорта в нод. Байндинги на JS это то что потом будет импортироваться в zlib.js и сам zlib.js. Никаких вопросов с терминологией, никаких рапперов.
Помню как-то забил на хабр когда все начали моргать светодиодами на ардуине. И все такие «IoT!», а ты уже давно пишешь модули ядра и разрабатываешь сложные распределенные программно-аппаратные комплексы. Потом года 3-4 назад все массово кинулись в веб апы и облака, а теперь я спорю о том что есть рапперы и байндинги. Совсем грустно. Разочарован.
Простите, а встроенный модуль как-то особенно отлично работает? Какая разница? Даже я вижу (тот человек, который на JS не пишет ежедневно) что там InternalBinding вначале. Или как-то это все внезапно перестало быть байндингом и вдруг стало раппером?
Спор то с человеком о том что wrapper в принципе может быть только тогда когда код wrapper'a имеет прямой доступ к коду того что он оборачивает.
Вот как-то только тут есть одно упоминание раппера:
In computing, a binding from a programming language to a library or operating system service is an application programming interface (API) providing glue code to use that library or service in a given programming language.
Binding generally refers to a mapping of one thing to another. In the context of software libraries, bindings are wrapper libraries that bridge two programming languages, so that a library written for one language can be used in another language.
Вообще спор напоминает объяснение плоскоземельщику что «Dude, after some amount of mass under the influence of self produced gravitational force any body tends to take the form of a ball!», а он тебе: «I can not see the curve.». Как-то так.
Экий вы тугой. Я даже уже не знаю, как вам объяснить, что в принципе не может быть никакого JS враппера над C++. Вот вообще никак, физически невозможно. Но вы продолжайте, я с удовольствием повеселюсь над тем что вы не понимаете принципа работы вашего же инструмента и не понимаете отличия между binding и wrapper.
А вы вообще в курсе, чем отличается wrapper от interface? Не удивительно что вы ничего не поняли.
Не знаю, где Вы такое там прочитали? JS это реализация ECMAScript, как язык вообще что то может исполнять, если на то пошло, еще и «нативно»? И как С код в принципе может исполняться нативно, т.е без компиляции в байткод?
Какой-то фарс, вы читать умеете вообще? Я вам поясню, вы путаете интерфейс и обертку. Так вот обертка изменяет и расширяет исходный объект будь то класс или функция то что вы дальше описываете это интерфейс. Есть С++ или С модуль который обворачивает zlib и расширяет пространство команд интерпретатора или виртуальной машины. В случае использования JS + JIT + Node.js это будет виртуальная машина. Для Пайтона будет оба варианта.
Нет, системные модули это JS обертка с расширением некритичного API над native модулями, написанных на C++. Без понятия при чем тут с++ оберткаи над чем там она должна быть…
Так это и есть интерфейс. Но вы почему-то упорно называете его оберткой. Могу рассказать как на самом деле работает обертка. Так как zlib написана на С мы экспортируем ее функции так, чтобы рантайм С++ их понимал и мог исполнять, далее мы можем все это дело точно так же обернуть в Managed С++ и уже его использовать для того чтобы подключить как assembly в C# и вот это будет zlib C# wrapper. Поэтому делаю вывод что вы плохо понимаете как работает Node.js под капотом.
И да, называть это js оберткой на С++, во-первых, крайне неграмотно, во-вторых, потом еще и спорить — это крайне глупо.
Ну а как же еще?! Серьезно?! Интерфейс к утилите командной строки?! Нет? С каких это пор JS умеет нативно исполнять C код? Если бы вы сказали С++ wrapper я бы еще промолчал.
Под все, и даже под встраиваемые системы. Чаще это Embedded Soft, микроконтроллеры, DSP, вплоть до кроссплатформенных апок для Win/Lin/OSX и иногда даже бекенды на java/js/python/go/C#/C++.
Все что мне нужно размазано по трем осям. Не вижу никаких проблем разрабатывать под языки типа Rust/Go под линуксом. Это все работает приблизительно одинаково на всех трех осях.
Не, у WSL что 1, что 2 — куча проблем. Я пока как человек имеющий экспертизу в ядре linux считаю это поделием.
Ну замечательно. У меня например проблемы с кривым индусским менеджером ресурсов в винде поэтому я свои исследования для PhD по AI провожу на рабочей станции на втором тредрипере и о GeForce'ах под Арчем, а macOS Mojave мне, соответственно, не позволяет подключить ExtGPU 4 RTX'а, собственно, как и High Sierra. Виртуалку макоси не нарушая закона вы не на маке вообще не запустите. Не важно vmWare это, QEMU с Pass Thru или еще что.
What is your point? I'm not getting it.
Тут в принципе не важно как это называется внутри кода на JS. Есть механизм расширения чего бы там ни было. Если бы JS или Python в принципе могли нативно запускать машинный код библиотеки на С/С++, пусть даже объектный, и имели бы прямой доступ к языковым конструкциям этих языков они бы могли считаться рапперами. Так как ни один из них в принципе такого не умеет, то все, что происходит лишь экспортирование дополнительного набора команд для интерпретатора или виртуальной машины. затем уже, во время выполнения когда виртуальная машина или интерпретатор видят определенную языковую конструкцию они начинают по этому ключу дергать нативный для себя код. А так как они написаны на С/С++ для них это не проблема. Поэтому это и называется байндингом, потому что мы байндим исполнение какого-то нативного кода к инструкции виртуальной машины или интерпретатора.
И даже класс который называется Wrappable вас не смущает? Да, этот класс и будет раппером. Но это С++ класс.
Как вы это не понимаете?
Помню как-то забил на хабр когда все начали моргать светодиодами на ардуине. И все такие «IoT!», а ты уже давно пишешь модули ядра и разрабатываешь сложные распределенные программно-аппаратные комплексы. Потом года 3-4 назад все массово кинулись в веб апы и облака, а теперь я спорю о том что есть рапперы и байндинги. Совсем грустно. Разочарован.
InternalBindingвначале. Или как-то это все внезапно перестало быть байндингом и вдруг стало раппером?Спор то с человеком о том что wrapper в принципе может быть только тогда когда код wrapper'a имеет прямой доступ к коду того что он оборачивает.
Вот как-то только тут есть одно упоминание раппера:
Вообще спор напоминает объяснение плоскоземельщику что «Dude, after some amount of mass under the influence of self produced gravitational force any body tends to take the form of a ball!», а он тебе: «I can not see the curve.». Как-то так.
Итак идем в папочку ./node_modules/zlib/
Потом смотрим че у нас там:
├── LICENSE├── Makefile
├── README.md
├── configure
├── index.js
├── lib
│ └── zlib.js
├── package.json
├── src
│ └── node-zlib.cc
├── test
│ ├── deflate.test.js
│ └── inflate.test.js
└── wscript
Итак что мы видим? Файл сборки для
wafи о чудо!!!zlib C++ wrapper!
Дальше сами разберетесь или помочь?
А вы вообще в курсе, чем отличается wrapper от interface? Не удивительно что вы ничего не поняли.
Какой-то фарс, вы читать умеете вообще? Я вам поясню, вы путаете интерфейс и обертку. Так вот обертка изменяет и расширяет исходный объект будь то класс или функция то что вы дальше описываете это интерфейс. Есть С++ или С модуль который обворачивает zlib и расширяет пространство команд интерпретатора или виртуальной машины. В случае использования JS + JIT + Node.js это будет виртуальная машина. Для Пайтона будет оба варианта.
Так это и есть интерфейс. Но вы почему-то упорно называете его оберткой. Могу рассказать как на самом деле работает обертка. Так как zlib написана на С мы экспортируем ее функции так, чтобы рантайм С++ их понимал и мог исполнять, далее мы можем все это дело точно так же обернуть в Managed С++ и уже его использовать для того чтобы подключить как assembly в C# и вот это будет zlib C# wrapper. Поэтому делаю вывод что вы плохо понимаете как работает Node.js под капотом.
И да, называть это js оберткой на С++, во-первых, крайне неграмотно, во-вторых, потом еще и спорить — это крайне глупо.