Если на той платформе, что Вы имеете ввиду, есть возможность обеспечить доступ к куску памяти на выполнение, помимо записи и чтения, то можно и на ней. В статье пример с виндовым VirtualAlloc(Ex), в который можно передать MemoryProtection.Execute*. Если будете работать под .NET Core в Linux/macOS, то выделить кусок памяти можете через Marshal, а потом запротектить этот кусок самописной на С простой либой, которая просто вызывает mprotect, ну а вызвать этот метод либы можно стандартным для .NET DllImport.
Да, очень интересно. Но большого смысла не имеет. Много сложной работы, шансы ошибиться и закрашить приложение, процессорозависимый нативный код из платформонезависимого C#/Java и т.д…
К сожалению, сейчас .NET Core не покрывает нужды десктопной разработки. Возможно, когда-нибудь это изменится. Но это уже совсем другая история.
.NET Core, как и старший .NET Framework, умеет в DllImport, маршалинг между managed и unmanaged. Т.е. платформа как исполнитель управляемого кода и интегратор с неуправляемым ОС-специфичным кодом как раз все позволяет и покрывает. Поэтому правильнее говорить, что нынешний набор пакетов не покрывает все нужды десктопной разработки.
Нет, но это означает, что они часть системы, которая наделяет определенные частицы зарядом, который дает им возможность взаимодействовать. Вернее наделяет чем-то таким, за счет чего они взаимодействуют, а заряд — это мера взаимодействия.
А нет ли противоречий в том, что переносчиком электромагнитного взаимодействия между заряженными частицами выступает беззарядовый фотон, по современным представлениям?
Не обращайте внимания. Ваш комментарий по своему интересен, где-то лет 10 назад в унвере читал что-то про электрон как композицию из нескольких фотонов.
Да вообще интересно как взаимодействуют фотон и электрон. Загадочное исчезновение фотона при столкновении с атомом с последующим переходом электрона атома на следующий энергетический уровень. Или обратный процесс, загадочное рождение и испускание фотона с переходом электрона на более стабильный нижний энергетический уровень. Вот что там происходит? Может быть правда есть какие-то нити, клубки? Может они интересным образом сплетаются друг в друга и расплетаются при определенных обстоятельствах. Вот непонятно! Что есть энергетический уровень электрона в атоме? При этом вне атома электроны и фотоны взаимодействуют слабо, никаких поглощений и испусканий нет, только небольшое рассеяние друг о друга. Может быть электрон в атоме правда вовсе не электрон, а вместе с протоном нечто качественно новое? Ой меня понесло. Заминусуют!
Вы не допускаете, что какие-то элементы, обладающие некоторыми свойствами, при объединении в некую систему, могут зарождать новые явления, качественно новые свойства системы, доступные только на ее уровне и недоступные на уровне отдельно взятых элементов?
Скажите, «вынесение JVM в отдельный процесс» будет единственным вариантом использованиям, или опция запуска в том же процессе останется? Такое ощущение, что для .NET Core Вы в итоге запилите как раз «тонкий клиент», т.к. это проще.
Также в планах есть вынесение JVM в отдельный процесс и полноценный тонкий клиент на чистом дотнете.
А это не будет затратнее? Добавите целых 2 прослойки сетевого взаимодействия, по 1 на каждой из сторон. Что есть сейчас — очень привлекательно. Тут вообще вопрос в том, что зачем брать отдельным сервисом какое-то хранилище, если его можно использовать прям в этом же процессе, т.е. избавить от оверхеда на сетевой трафик запрос-ответ и инфраструктуру их обслуживания.
На сайте написано ".NET starts the JVM in the same process and communicates with it via JNI & C++". Это именно то, что Вы описали в Межпроцессном взаимодействии?
Ну да. Сначала 10Гб новостей погоды с рисунками, «основными новостями», «полезный» текст, хоть и read-only, но классно. А как взлетит и капитализируется, объем данных вырастит до 50Гб, будет 10Гб новостей погоды с рисунками, «основными новостями», «полезный» текст, хоть и read-only, но классно; и 40Гб «отбираемыми» админами рекламы, навешивания лапшы на уши и развлекательных шоу, и конечно же в режиме read-only. Так и не понял, чем это отличается от ТВ, которое итак есть по всему шарику, нужна лишь тарелка и приставка, что тоже можно уложить далеко до 100$.
Время от времени подумываю о своей востребованности как программиста в 40 лет (через 10 лет) и сильно парюсь… А есть вот прям замечательные примеры, когда в 40 только приходят в сферу.
Успехов!
Да, Вы правы. Комментарий выше про САО более точен, т.к. САО — это и БТА и РАТАН и РТФ-32 в одном флаконе. И расположение высоко в горах с практически чистым от светового загрязнения небом явно более выгодное, чем пример в статье из Лос-Анжелеса, где фиг его знает как вообще обсерватория работает при таком ярком городе.
Вы правы, между собой коммерческие вопросы они могут решать как хотят. Я не утверждал, что кто-то здесь неправ. Просто столкнулся с проблемой, нужна была отладка, а другие инструменты для меня крайне неудобны и их пришлось использовать.
Например, мне хочется видеть .NET (если отбросить детали, продукт МС) в мире Linux, видеть как платформа займет свою нишу, где успешно крутится та же JVM. Мне кажется C# имеет все шансы занять Enterprise тему и потеснить Java, когда .NET Core будет достаточно стабилен. Хочу делать кроссплатформенные продукты на C#. Вы и все интересующиеся .NET Core комьюнити таким образом двигаете платформу в этом направлении.
Мне удобно писать в Rider'е, так производительнее для меня, т.к. Rider это не только редактор и плагины для подсветки, это куча классных инспекций из ReSharper, которые я использую каждый день и не собираюсь отказываться. Вам удобно делать свои .NET Core продукты в Visual Studio Code — Ваше право. Почему в итоге мы с Вами не можем двигать продукт (не важно коммерческий он для них или нет, они его двигают всеми силами) МС .NET Core удобным для нас с Вами способом?
Если на той платформе, что Вы имеете ввиду, есть возможность обеспечить доступ к куску памяти на выполнение, помимо записи и чтения, то можно и на ней. В статье пример с виндовым VirtualAlloc(Ex), в который можно передать MemoryProtection.Execute*. Если будете работать под .NET Core в Linux/macOS, то выделить кусок памяти можете через Marshal, а потом запротектить этот кусок самописной на С простой либой, которая просто вызывает mprotect, ну а вызвать этот метод либы можно стандартным для .NET DllImport.
.NET Core, как и старший .NET Framework, умеет в DllImport, маршалинг между managed и unmanaged. Т.е. платформа как исполнитель управляемого кода и интегратор с неуправляемым ОС-специфичным кодом как раз все позволяет и покрывает. Поэтому правильнее говорить, что нынешний набор пакетов не покрывает все нужды десктопной разработки.
Да вообще интересно как взаимодействуют фотон и электрон. Загадочное исчезновение фотона при столкновении с атомом с последующим переходом электрона атома на следующий энергетический уровень. Или обратный процесс, загадочное рождение и испускание фотона с переходом электрона на более стабильный нижний энергетический уровень. Вот что там происходит? Может быть правда есть какие-то нити, клубки? Может они интересным образом сплетаются друг в друга и расплетаются при определенных обстоятельствах. Вот непонятно! Что есть энергетический уровень электрона в атоме? При этом вне атома электроны и фотоны взаимодействуют слабо, никаких поглощений и испусканий нет, только небольшое рассеяние друг о друга. Может быть электрон в атоме правда вовсе не электрон, а вместе с протоном нечто качественно новое? Ой меня понесло. Заминусуют!
А это не будет затратнее? Добавите целых 2 прослойки сетевого взаимодействия, по 1 на каждой из сторон. Что есть сейчас — очень привлекательно. Тут вообще вопрос в том, что зачем брать отдельным сервисом какое-то хранилище, если его можно использовать прям в этом же процессе, т.е. избавить от оверхеда на сетевой трафик запрос-ответ и инфраструктуру их обслуживания.
Успехов!
Мне удобно писать в Rider'е, так производительнее для меня, т.к. Rider это не только редактор и плагины для подсветки, это куча классных инспекций из ReSharper, которые я использую каждый день и не собираюсь отказываться. Вам удобно делать свои .NET Core продукты в Visual Studio Code — Ваше право. Почему в итоге мы с Вами не можем двигать продукт (не важно коммерческий он для них или нет, они его двигают всеми силами) МС .NET Core удобным для нас с Вами способом?