bash скрипт в cron, который переписывает зону и обновляет честный KnotDNS, тоже сойдёт. Цены на подходящий хостинг начинаются, кажется, с 90 рублей в месяц.
Именно 1:1 такую же программу делать дистанционной очень мало смысла. Сложно представить, чтоб дистанционно можно было заставить значимое количество студентов спать по 4 часа в день, и в нужные часы, пока есть возможность задать вопрос, соответственно, бодрствовать. Тут нужно личное участие с полным вовлечением.
IMHO, а также не очень нравится привязанность к Java и JWM…
Да, концентрация сторонников тут аномально высокая. Впрочем, нельзя сказать, чтобы это было таким уж тревожным звоночком, как обычно на других образовательных программах.
А на кой она, Европа? Мы с Китаем дружим, а не с Европой, вообше-то. У нас ШОС основной военный блок. Ездить к марионеткам, так сказать, потенциального противника вне зависимости от пребывания в Крыму значит напрашиваться на разного рода неприятности.
gprbuild (в составе дистрибутивов GNAT, хотя можно и отдельно установить) эволюцонировал из чисто адских gnatmake, а потом gprmake, чтобы лучше поддерживать смешанные C/C++ проекты. И настолько в этом преуспел, что и для проектов без языка Ада хорошо подходит. После gprbuild я не переварил CMake. Не знаю, чего с него так тащатся. Может, gprbuild никогда не видели.
А то GUI, которое не на Аде, оно на языках какого года?
Мне, кстати, больше всего GUI Cocoa нравится, а оно не просто так получилось таким. Оно восходит к Objective C (тогда ещё без дефиса) и его библиотек из тех самых страшных 80х. Но в тех самых страшных 80х оно, наверное, по сравнению с другими, было не очень, а за прошедшее время устаканилось, и поэтому такое хорошее. Иметь время устаканиться и быть на свежем языке — вещи не очень совместимые.
EmScripten = Asm.js и Wasm
Первый транслятор Wasm был конвертером из Asm.js
И люди, которые Wasm подняли, вроде те же, что и за Asm.js.
А PNaCl? Пока он только в одном браузере, это ни о чём было. Вот FlasCC — другое дело.
И я не видел, чтоб там QIP, The Bat!, Total Commander или ещё какое-то типичное десктопное приложение «спокойно» портировалось в веб с помощью одной из этих технологий. Даже под Linux с большим спокойствием портировали с Windows приложения, хотя там запрос меньше.
Ну типа небезопасно и нестабильно — это когда корректное состояние сменяется другим корректным «по индукции». А если к индукционному переходу доверия нет, то нужны а) перекрёстные проверки, б) в случае, если выявлена лажа, по возможности починить состояние.
Например, CCured, CHERI и Эльбрус делают указатели разбухшими до четырёх раз, накачивая метаданными, но зато становится возможно проверить валидность. В автоматическом режиме, не переписывая на Аду, принудить код Си и C++ к корректности можно только так.
Возможность починить состояние: если лажу оперативно выявлять и пресекать, то и нечего чинить, а вот если крутится Си или C++, без CCured, CHERI или Эльбруса, то остаётся такой радикальный способ, как изолироваться от плюсовой лажи границами процесса. Там, в компостной яме изолированного процесса пусть всё протекает и гниёт как хочет, а граница процесса удерживает гниль от распространения. Но эти границы вроде бы тоже чего-то да стоят по памяти.
браузеру нужно эти процессы поддерживать как единое целое
И что там поддерживать? HWND для отрисовки поделиться? Кукисы заброадкастить?
И какие данные там дублировать? Основное, что раздувает память, это DOM, JavaScript объекты и 400% мусора от них, а они не дублируются. К сожалению, отсутствие слабых ссылок усложняет задачу избавления от мусора, так что в JavaScript по принципу и так сойдёт остаётся даже больше мусора (формально достижимого), чем в других системах с TGC, но где слабые ссылки есть.
Кеш? Ну, может быть. shmem для кеша нетривиален. Могли недостаточно хорошо сделать.
Но мне кажется, они там не за безопасность думали, а как прикрыть свой зад. Я когда Safari пользовался, когда он ещё второй версии был, он падал, потому что не на Аде был написан. OmniWeb ещё пользовался, и он тоже был не на Аде написан, и поэтому падал, но ещё чаще. Падал сразу весь, с текстами недописанными в каких-то вкладках, и это мегафейл. Не считая переписывания на Аде и последующего прозрения, от чего ж там на самом деле падает, и исправления найденных косяков, запилить это в отдельные процессы, похоже было единственной альтернативой. Не решить проблему, а замести под ковёр.
Mozilla тут проще, у них нейтральный к языку XPCOM, разные компоненты по отдельности можно апгрейдить на Аду. В WebKit нет XPCOM, но есть Objective-C runtime, тоже потенциально многоязыковой движок.
Ну и давайте уже какие-то пруфы про трассирующую эту сборку. Ваши фантазии читать не особо интересно.
Что до Ады, беглый гуглинг говорит, что для данной задачи оно не подходит, т.к. безопасность уровня Rust не дает.
Сколько на ней пишу, даёт. И ещё даёт ООП внятное, сопоставимое с подмножеством, используемым в C++ и Delphi. Не такая эзотерика с типажами, как в Rust, под которую нужно всё через колено ломать. И исключения вменяемые. Растовские паники (а переполнения чисел и выходы за границы массивов производят именно их) — это почти как апокалипсис. Перехват паники — нештатная операция, и даже, если перехватить, то ещё штатный обработчик успеет нагадить в консоль своё бесполезное сообщение, и его тоже тогда надо перехватывать, чтоб не гадил. Я такую обработку ошибок последний раз в Turbo Pascal видел. Там галочки проверять диапазоны и переполнения были в настройках, но если их включить, происходили такие же апокалипсисы. В Delphi версии этак с четвёртой человеческие исключения возбуждаются, в языке Ада изначально по-человечески.
если бы webkit начали писать на этом языке, то можно было быть уверенным, что до наших дней он бы не дожил, т.к. его бы некому было писать
Да те же, кто пишут браузеры, и писали бы их на Аде. Чтоб спецы могли запрогать рендеринг не заточенного под это CSS в слои OpenGL, а с одного языка с RAII, шаблонами и ООП не могли перейти на другой язык с RAII, шаблонами и ООП, — да ну, бред какой-то. Кто бы стал там держать принципиально необучаемых. Всё они могут.
По существу процессы отнюдь не такое дорогое удовольствие. Операционные системы умеют shmem и mmap, и даже при ASLR умеют кешировать версии с релокациями. А вот трассирующая сборка мусора висит камнем на шее. Чтобы имело смысл проводить трассирующую сборку мусора, мусорить нужно обильно, в 5 раз больше, чем реально используется памяти. И без слабых ссылок всё ещё хуже.
Альтернатива плюсам существует 23 года, ещё когда никакого Rust в проекте не было, и это Ада. Вообще, первый, кто задумался о безопасности в языках программирования, — это Никлаус Вирт. Это он первый придумал проверять границы и переполнения. И это был язык Паскаль. И естественным образом это унаследовано потомками Паскаля.
За слепошарых мозилловцев ничего не могу сказать. Ну, странные люди.
Под Windows проще всего собирать. Под Windows компоновщики не лезут в system32 убедиться, что там в DLL есть нужные входы. Под Windows это вообще, не их, компоновщиков, собачье дело, а существует ли вообще DLL в природе.
На macOS ты попробуй только не дай ld пощупать каждый dylib, и каждую зависимость каждого dylib. Всё, не хочу, не буду компоновать.
На Linux в бинарники зашивается rpath. На macOS в каждый dylib зашивается, «где меня искать», и когда ld щупает все dylib, он копирует это в те файлы, которые компонует. Они теперь будут искать по тому адресу, который увидели в dyld.
Таблица импорта в Windows и macOS двухэтажная, то есть, понятно, какой символ из какой библиотеки, на Linux одноэтажная.
Гораздо проще с Windows. Не зря полнятся фрисофты и софтпорталы экзешниками.
Если б не было плевать, писали браузер на Аде. Что-то я такой реальной заботы о безопасности не наблюдаю. Больше похоже на симуляцию бурной деятельности.
Память там отъедается мощно трассирующей сборкой мусора. Про то, как надёжно запечатаны двери в светлое будущее, где счётчиками ссылок и слабыми ссылками сберегается память, я уже написал.
Из немаркетинговых доводов, которые я видел, в браузере реализовано автоматическое открытие клавиатуры при навигации по полям с планшета типа Surface Pro, а на обычном GUI с osk.exe не смогли разобраться, или в чём-то таком проблема.
Но вообще проблема в том, что хочется всё и сразу, и веб, и не веб. И Электрон позволяет это, но тогда нужно прогнуться под правила веб. А нет такого решения, чтоб, наоборот, прогнуть веб, а на десктопе и сервере было всё хорошо, как обычно.
Что можно было брать QIP'ы и The Bat! ы, с многопоточностью на мониторах, а не на хоаровских сообщениях, и загонять в веб, каких бы костылей это ни стоило. Я пытаюсь сделать это темой своей магистерской работы.
Можно писать под GNUStep или Cocotron, а под Mac нативно. Лучше Mac-like на Win, чем Win-like на Mac. Яблочники довольны, а вендопользователям, а тем более линукс всё равно не привыкать. В среднем, всем хорошо.
Те, кто заботятся о безопасности, и те, кто пишут на C++, — это непересекающиеся множества.
К памяти можно было бы относиться более бережливо, если б были счётчики ссылок и слабые ссылки, и только на крайние случаи сборщики мусора. Но за столько лет в JavaScript так и не сделали слабые ссылки.
Плевать там все хотели и на безопасность, и на потребение памяти.
Да, концентрация сторонников тут аномально высокая. Впрочем, нельзя сказать, чтобы это было таким уж тревожным звоночком, как обычно на других образовательных программах.
gnoga.com/#tools — движок для облачных приложений
github.com/mosteo/adagio — p2p (Gnutella2) сервачок
ironsides.martincarlisle.com — верифицированный DNS сервер на SPARK
parasail-lang.org — виртуальная машина (чем-то напоминает Erlang) и 4 языка программирования
www.pegasoft.ca/tia.html — консольный редактор
gprbuild (в составе дистрибутивов GNAT, хотя можно и отдельно установить) эволюцонировал из чисто адских gnatmake, а потом gprmake, чтобы лучше поддерживать смешанные C/C++ проекты. И настолько в этом преуспел, что и для проектов без языка Ада хорошо подходит. После gprbuild я не переварил CMake. Не знаю, чего с него так тащатся. Может, gprbuild никогда не видели.
muen.sk — верифицированный гипервизор
Мне, кстати, больше всего GUI Cocoa нравится, а оно не просто так получилось таким. Оно восходит к Objective C (тогда ещё без дефиса) и его библиотек из тех самых страшных 80х. Но в тех самых страшных 80х оно, наверное, по сравнению с другими, было не очень, а за прошедшее время устаканилось, и поэтому такое хорошее. Иметь время устаканиться и быть на свежем языке — вещи не очень совместимые.
Первый транслятор Wasm был конвертером из Asm.js
И люди, которые Wasm подняли, вроде те же, что и за Asm.js.
А PNaCl? Пока он только в одном браузере, это ни о чём было. Вот FlasCC — другое дело.
И я не видел, чтоб там QIP, The Bat!, Total Commander или ещё какое-то типичное десктопное приложение «спокойно» портировалось в веб с помощью одной из этих технологий. Даже под Linux с большим спокойствием портировали с Windows приложения, хотя там запрос меньше.
Например, CCured, CHERI и Эльбрус делают указатели разбухшими до четырёх раз, накачивая метаданными, но зато становится возможно проверить валидность. В автоматическом режиме, не переписывая на Аду, принудить код Си и C++ к корректности можно только так.
Возможность починить состояние: если лажу оперативно выявлять и пресекать, то и нечего чинить, а вот если крутится Си или C++, без CCured, CHERI или Эльбруса, то остаётся такой радикальный способ, как изолироваться от плюсовой лажи границами процесса. Там, в компостной яме изолированного процесса пусть всё протекает и гниёт как хочет, а граница процесса удерживает гниль от распространения. Но эти границы вроде бы тоже чего-то да стоят по памяти.
И что там поддерживать? HWND для отрисовки поделиться? Кукисы заброадкастить?
И какие данные там дублировать? Основное, что раздувает память, это DOM, JavaScript объекты и 400% мусора от них, а они не дублируются. К сожалению, отсутствие слабых ссылок усложняет задачу избавления от мусора, так что в JavaScript по принципу и так сойдёт остаётся даже больше мусора (формально достижимого), чем в других системах с TGC, но где слабые ссылки есть.
Кеш? Ну, может быть. shmem для кеша нетривиален. Могли недостаточно хорошо сделать.
Но мне кажется, они там не за безопасность думали, а как прикрыть свой зад. Я когда Safari пользовался, когда он ещё второй версии был, он падал, потому что не на Аде был написан. OmniWeb ещё пользовался, и он тоже был не на Аде написан, и поэтому падал, но ещё чаще. Падал сразу весь, с текстами недописанными в каких-то вкладках, и это мегафейл. Не считая переписывания на Аде и последующего прозрения, от чего ж там на самом деле падает, и исправления найденных косяков, запилить это в отдельные процессы, похоже было единственной альтернативой. Не решить проблему, а замести под ковёр.
Mozilla тут проще, у них нейтральный к языку XPCOM, разные компоненты по отдельности можно апгрейдить на Аду. В WebKit нет XPCOM, но есть Objective-C runtime, тоже потенциально многоязыковой движок.
Почему веб-приложения на мобильных платформах работают медленно
Сколько на ней пишу, даёт. И ещё даёт ООП внятное, сопоставимое с подмножеством, используемым в C++ и Delphi. Не такая эзотерика с типажами, как в Rust, под которую нужно всё через колено ломать. И исключения вменяемые. Растовские паники (а переполнения чисел и выходы за границы массивов производят именно их) — это почти как апокалипсис. Перехват паники — нештатная операция, и даже, если перехватить, то ещё штатный обработчик успеет нагадить в консоль своё бесполезное сообщение, и его тоже тогда надо перехватывать, чтоб не гадил. Я такую обработку ошибок последний раз в Turbo Pascal видел. Там галочки проверять диапазоны и переполнения были в настройках, но если их включить, происходили такие же апокалипсисы. В Delphi версии этак с четвёртой человеческие исключения возбуждаются, в языке Ада изначально по-человечески.
Да те же, кто пишут браузеры, и писали бы их на Аде. Чтоб спецы могли запрогать рендеринг не заточенного под это CSS в слои OpenGL, а с одного языка с RAII, шаблонами и ООП не могли перейти на другой язык с RAII, шаблонами и ООП, — да ну, бред какой-то. Кто бы стал там держать принципиально необучаемых. Всё они могут.
В книге Putting Metaclasses to Work на какой-то странице реальная диаграмма классов System Object Model. Там 4 уровня.
Альтернатива плюсам существует 23 года, ещё когда никакого Rust в проекте не было, и это Ада. Вообще, первый, кто задумался о безопасности в языках программирования, — это Никлаус Вирт. Это он первый придумал проверять границы и переполнения. И это был язык Паскаль. И естественным образом это унаследовано потомками Паскаля.
За слепошарых мозилловцев ничего не могу сказать. Ну, странные люди.
На macOS ты попробуй только не дай ld пощупать каждый dylib, и каждую зависимость каждого dylib. Всё, не хочу, не буду компоновать.
На Linux в бинарники зашивается rpath. На macOS в каждый dylib зашивается, «где меня искать», и когда ld щупает все dylib, он копирует это в те файлы, которые компонует. Они теперь будут искать по тому адресу, который увидели в dyld.
Таблица импорта в Windows и macOS двухэтажная, то есть, понятно, какой символ из какой библиотеки, на Linux одноэтажная.
Гораздо проще с Windows. Не зря полнятся фрисофты и софтпорталы экзешниками.
за глючную тормозную программу.
Ну и, может, как-то заказчикам консолидироваться, чтоб для Ады рынок надёжного и быстрого ПО был, тогда будет не редкой технологией.
Память там отъедается мощно трассирующей сборкой мусора. Про то, как надёжно запечатаны двери в светлое будущее, где счётчиками ссылок и слабыми ссылками сберегается память, я уже написал.
Но вообще проблема в том, что хочется всё и сразу, и веб, и не веб. И Электрон позволяет это, но тогда нужно прогнуться под правила веб. А нет такого решения, чтоб, наоборот, прогнуть веб, а на десктопе и сервере было всё хорошо, как обычно.
Что можно было брать QIP'ы и The Bat! ы, с многопоточностью на мониторах, а не на хоаровских сообщениях, и загонять в веб, каких бы костылей это ни стоило. Я пытаюсь сделать это темой своей магистерской работы.
К памяти можно было бы относиться более бережливо, если б были счётчики ссылок и слабые ссылки, и только на крайние случаи сборщики мусора. Но за столько лет в JavaScript так и не сделали слабые ссылки.
Плевать там все хотели и на безопасность, и на потребение памяти.