Нет. Эта технология называется Authomatic Private IP Addressing (APIPA). Вот статья о том, как это работает.
The Internet Assigned Numbers Authority (IANA) has reserved 169.254.0.0-169.254.255.255 for Automatic Private IP Addressing. As a result, APIPA provides an address that is guaranteed not to conflict with routable addresses
И каждый раз будут выдаваться новые ошибки, которым можно удивляться. Описанная в статье претензия претензия относится к разряду "Компьютер (операционная система) работает не так, как я хочу!". Ну, ок.
В качестве наглядного примера можно привести ядро Linux, которое в 1992 году состояло из примерно 10 000 строк кода. Спустя двадцать лет, его размер достиг около 30 миллионов строк.
Откуда берется столько кода? Я не думаю, что расширение функциональности может объяснить такой рост его объёма; скорее, это связано с нашим подходом к разработке ПО. Обычно новые функции в программе добавляются поверх уже существующих, как при строительстве пирамиды.
Мне кажется, что ядро Linux - не очень удачный пример иллюстрации многослойности ПО. Оно в значительной степени разрослось из-за расширения спектра поддерживаемых платформ и разнообразных периферийных устройств.
Взаимодействие с современными веб-сервисами может быть осложнено из-за отсутствия поддержки TLS1.2 и устаревших сертификатов (проверка сертификатов легко обходится специальным костылем, а вот TLS — нет).
В этой организации код ещё пару десятков лет назад писался почти исключительно на ассемблере, поскольку и чипы с рядом компонентов были не самые новые. Так, например, в 2006 году миссии THEMIS и STEREO работали на базе процессоров Intel 8085, выпущенных ещё в 1976 году. Степень новизны чипов не объясняет, почему нельзя было использовать кросс-компиляцию, например, с Си? Разве что сами программы настолько примитивны, что решили не тратить время на инструментарий.
На RK3229 выпущена масса изделий в одинаковых корпусах и на очень похожих платах, но несколько отличающихся электронной начинкой. Такая проблема - постоянные ошибки при попытке прошивки - может быть из-за того, что выбранный образ с ПО просто не подходит к этому конкретному экземпляру.
Хороший обзор. Но психология человека такова, что самоограничения требуют работы мысли, сильной воли и зрелого характера. Поэтому на них сложно рассчитывать в повседневной деятельности. С точки зрения той же психологии, чтобы добиться от человека определённого поведения, лучше создать внешние условия, чтобы в этих условиях ему было проще вести себя именно требуемым образом. А в рассматриваемом контексте такие условия может создать как раз ограниченный протокол.
Девайс оснащен полноценной ОС, это Debian, с которой можно взаимодействовать посредством сенсорного экрана. Версия Debian — 10.0. К сожалению, пока неизвестно, может ли работать этот девайс под управлением других дистрибутивов Linux.
А что может в этом случае (если Debian работает) помешать использованию других дистрибутивов?
На ДВК в текстовом режиме были реализованы игры ТЕТРИС (всем понятно, что это), ИСТРА (рыбалка, в которой надо было смотреть на поплавок и в нужный момент делать подсечку клавишей пробел), РАЛЛИ (вертикально отображается трасса с препятствиями и изгибами, которая прокручивается вниз, а в нижней строке находится символ автомобиля, который можно сдвигать влево-вправо) и отличная реализация XONIX (захват кусков территории на прямоугольном поле, по которому прыгают мячики).
Да, можно сказать, что все перечисленные продукты используют язык программирования dBASE и базы данных DBF. Clipper - это компилятор языка, остальные - интерпретаторы и интегрированные среды разработки/исполнения. А "browse" - один из аргументов, почему надо было использовать эти продукты, а не, например, Turbo Pascal.
В общем-то да, но порог вхождения, на мой взгляд, был немного выше. Ну и всё-таки это системы разработки приложений с графическим интерфейсом пользователя, которому, как ни крути, надо уделять больше внимания, чем текстовому интерфейсу. Что касается поддержки баз данных MDB - она была то ли интегрирована в операционную Windows, то ли требовала установки небольшого компонента - уже не помню. С ними можно было даже на Visual Basic Script работать.
Ну, формально жив даже dBASE - пожалуй, наиболее близкий аналог FoxPro for DOS. И неизвестно, насколько эта система была бы сейчас востребована, если бы не $99 за непонятную лицензию. То, что он "для DOS", не может служить причиной отказа, потому что в эмуляторе DosBox тот же FoxPro работает не хуже, чем на аппаратной платформе. А эмулятор этот портирован даже на мобильные устройства.
В те времена (начало 2000-х) программистов на FoxPro было примерно столько же, сколько сейчас на 1С. Да и FoxPro этот был не такой чтобы уж совсем универсальный язык программирования, а скорее фреймворк для файловых БД. Так что разобраться в коде большого труда не составляло. Сам язык - не сложнее структурного Бейсика.
Я учился только по встроенной справочной системе. Этого было более чем достаточно. По всем операторам и функциям - подробное описание с примерами использования. Вот только не пользовался конструкторами форм, отчётов и запросов. При некотором опыте всё записывалось намного проще прямо в коде.
А экранные формы делать в условиях, когда у тебя всегда поле 80x25 символов, а не окно непредсказуемой геометрии, - одно удовольствие! Опять же, это ограничение стимулирует к тому, чтобы не перегружать интерфейс. При необходимости можно было создавать многоэкранные формы, которые работали по принципу современных "мастеров" (wizards).
А ведь задачи, которые решались "старыми технологиями" никуда не исчезли. Есть малый бизнес и индивидуальные предприниматели, которым достаточно того, что умел FoxPro - приложения с локальной базой данных. В нынешнем мире я не вижу инструмента, настолько пригодного для описанной сферы. Может быть, ближе всего к нему 1С, что и обусловило популярность этой среды. Возможно, подобное можно делать средствами Java - насколько понимаю, там есть локальная СУБД. Но насколько же просто в FoxPro for DOS было делать экранные формочки! Прототип приложения (БД + интерфейс) можно было набросать за несколько часов! Не редки случаи, когда полноценные системы учёта разрабатывались и сопровождались одним программистом. Причём те, что я видел, было совсем нетрудно поддерживать и вносить в них изменения при необходимости: понятная архитектура, инструкции для пользователя - прямо на форме ввода данных. Возможно, это просто привычка, и современные средства не хуже?
Интересно, что на заводе "Интеграл" ещё продаётся микропроцессорный комплект КР588, на котором, как я понимаю, можно собрать клон PDP-11. Операционная система ДЕМОС уже есть. Любопытный мог бы получиться проект...
А в мире Linux/Unix/MacOS то же самое называется Zeroconf-Avahi-Bonjour и основывается на RFC3927. Об этом (писали на Хабре)[https://habr.com/ru/articles/66020/].
Нет. Эта технология называется Authomatic Private IP Addressing (APIPA). Вот статья о том, как это работает.
В том случае, который описан в статье, пользователи явно указывают в командной строке, какой они хотят использовать командный интерпретатор:
$ sh 03_synthesize_for_fpga.bash
От этого никакие декларации не помогут. Но таким пользователям можно предложить попробовать ещё много неработающих вариантов:
$ perl 03_synthesize_for_fpga.bash
$ python 03_synthesize_for_fpga.bash
$ ...
И каждый раз будут выдаваться новые ошибки, которым можно удивляться.
Описанная в статье претензия претензия относится к разряду "Компьютер (операционная система) работает не так, как я хочу!". Ну, ок.
Мне кажется, что ядро Linux - не очень удачный пример иллюстрации многослойности ПО. Оно в значительной степени разрослось из-за расширения спектра поддерживаемых платформ и разнообразных периферийных устройств.
По идее, поддержку TLS1.2 можно реализовать с помощью библиотек The Bouncy Castle Crypto API.
Или несколько слоёв "защитных стёкол", как в мобильных телефонах, которые просто сбрасывать по мере загрязнения.
В этой организации код ещё пару десятков лет назад писался почти исключительно на ассемблере, поскольку и чипы с рядом компонентов были не самые новые. Так, например, в 2006 году миссии THEMIS и STEREO работали на базе процессоров Intel 8085, выпущенных ещё в 1976 году.
Степень новизны чипов не объясняет, почему нельзя было использовать кросс-компиляцию, например, с Си? Разве что сами программы настолько примитивны, что решили не тратить время на инструментарий.
На RK3229 выпущена масса изделий в одинаковых корпусах и на очень похожих платах, но несколько отличающихся электронной начинкой. Такая проблема - постоянные ошибки при попытке прошивки - может быть из-за того, что выбранный образ с ПО просто не подходит к этому конкретному экземпляру.
Кроме Android на этом устройстве можно попробовать LibreELEC - медиацентр Kodi на базе Linux и Lakka - эмулятор retroarch тоже на базе Linux.
По поводу LibreELEC: https://forum.libreelec.tv/thread/25236-unofficial-rk3228-rk3229-libreelec-builds/ и https://forum.libreelec.tv/thread/21117-unoffical-le-9-2-9-80-images-for-rk3229-rk3228/
По поводу Lakka на официальном сайте информации нет, но есть ссылка на образ (вероятно неофициальный) в archive.org. Теоретически, retroarch с библиотеками можно перенести из Lakka в LibreELEC, и он должен работать.
Хороший обзор. Но психология человека такова, что самоограничения требуют работы мысли, сильной воли и зрелого характера. Поэтому на них сложно рассчитывать в повседневной деятельности. С точки зрения той же психологии, чтобы добиться от человека определённого поведения, лучше создать внешние условия, чтобы в этих условиях ему было проще вести себя именно требуемым образом. А в рассматриваемом контексте такие условия может создать как раз ограниченный протокол.
Девайс оснащен полноценной ОС, это Debian, с которой можно взаимодействовать посредством сенсорного экрана. Версия Debian — 10.0. К сожалению, пока неизвестно, может ли работать этот девайс под управлением других дистрибутивов Linux.
А что может в этом случае (если Debian работает) помешать использованию других дистрибутивов?
Может быть, Gemini?
На ДВК в текстовом режиме были реализованы игры ТЕТРИС (всем понятно, что это), ИСТРА (рыбалка, в которой надо было смотреть на поплавок и в нужный момент делать подсечку клавишей пробел), РАЛЛИ (вертикально отображается трасса с препятствиями и изгибами, которая прокручивается вниз, а в нижней строке находится символ автомобиля, который можно сдвигать влево-вправо) и отличная реализация XONIX (захват кусков территории на прямоугольном поле, по которому прыгают мячики).
Да, можно сказать, что все перечисленные продукты используют язык программирования dBASE и базы данных DBF. Clipper - это компилятор языка, остальные - интерпретаторы и интегрированные среды разработки/исполнения. А "browse" - один из аргументов, почему надо было использовать эти продукты, а не, например, Turbo Pascal.
В общем-то да, но порог вхождения, на мой взгляд, был немного выше. Ну и всё-таки это системы разработки приложений с графическим интерфейсом пользователя, которому, как ни крути, надо уделять больше внимания, чем текстовому интерфейсу. Что касается поддержки баз данных MDB - она была то ли интегрирована в операционную Windows, то ли требовала установки небольшого компонента - уже не помню. С ними можно было даже на Visual Basic Script работать.
Ну, формально жив даже dBASE - пожалуй, наиболее близкий аналог FoxPro for DOS. И неизвестно, насколько эта система была бы сейчас востребована, если бы не $99 за непонятную лицензию. То, что он "для DOS", не может служить причиной отказа, потому что в эмуляторе DosBox тот же FoxPro работает не хуже, чем на аппаратной платформе. А эмулятор этот портирован даже на мобильные устройства.
В те времена (начало 2000-х) программистов на FoxPro было примерно столько же, сколько сейчас на 1С. Да и FoxPro этот был не такой чтобы уж совсем универсальный язык программирования, а скорее фреймворк для файловых БД. Так что разобраться в коде большого труда не составляло. Сам язык - не сложнее структурного Бейсика.
Я учился только по встроенной справочной системе. Этого было более чем достаточно. По всем операторам и функциям - подробное описание с примерами использования. Вот только не пользовался конструкторами форм, отчётов и запросов. При некотором опыте всё записывалось намного проще прямо в коде.
А экранные формы делать в условиях, когда у тебя всегда поле 80x25 символов, а не окно непредсказуемой геометрии, - одно удовольствие! Опять же, это ограничение стимулирует к тому, чтобы не перегружать интерфейс. При необходимости можно было создавать многоэкранные формы, которые работали по принципу современных "мастеров" (wizards).
А ведь задачи, которые решались "старыми технологиями" никуда не исчезли. Есть малый бизнес и индивидуальные предприниматели, которым достаточно того, что умел FoxPro - приложения с локальной базой данных. В нынешнем мире я не вижу инструмента, настолько пригодного для описанной сферы. Может быть, ближе всего к нему 1С, что и обусловило популярность этой среды. Возможно, подобное можно делать средствами Java - насколько понимаю, там есть локальная СУБД. Но насколько же просто в FoxPro for DOS было делать экранные формочки! Прототип приложения (БД + интерфейс) можно было набросать за несколько часов! Не редки случаи, когда полноценные системы учёта разрабатывались и сопровождались одним программистом. Причём те, что я видел, было совсем нетрудно поддерживать и вносить в них изменения при необходимости: понятная архитектура, инструкции для пользователя - прямо на форме ввода данных. Возможно, это просто привычка, и современные средства не хуже?
Интересно, что на заводе "Интеграл" ещё продаётся микропроцессорный комплект КР588, на котором, как я понимаю, можно собрать клон PDP-11. Операционная система ДЕМОС уже есть. Любопытный мог бы получиться проект...