Скорее всего вы что-то путаете.
Файлы прошивки BIOS не должны монтироваться, более того это адресное пространство должно быть недоступно в пространстве пользователя операционной системы.
Возможно вы имели ввиду монтирование переменных EFI в директорию sys. Но тут тоже, согласно UEFI спецификации, затирание этих переменных не должно быть критическим и при следующем запуске должны установиться значения по умолчанию.
Я в курсе, что был какой-то случай на компьютерах MSI, когда затирание переменных EFI приводило к краху, но это частный случай и ошибка разработчиков прошивок для компьютеров MSI.
Но мне кажется, что вышеобозначеная команда даже не дойдёт до директории sys, а споткнётся о невозможности удалить белочные устройства в /dev. Кроме этого может рано или поздно возникнуть ошибка ядра и далее не удасться породить новый процесс. Дальше только hard reset.
Поэтому ничего опасного, кроме удаления пользовательских файлов эта команда делать не должна.
По такой логике и layout страницы ничто не мешает представлять в виде наложенных друг на друга таблиц разной ширины и длины.
Мне кажется все таки список — это список, а меню — это меню.
Другой вопрос, что соответствующего тэга для меню пока нет, но скоро должен появится. И тогда всех, кто делает меню на списках — будут так же шеймить, как и тех, кто делает верстку на таблицах.
Иначе мы придём к выводу, что такие тэги как section, article и так далее не нужны и все можно сделать на div.
Кроме этого нужно не забывать ещё про Accessibility.
Пожалуй тут вы правы. Генту не очень удачный пример. Но это не отменяет мысли, что Python не является само-собой разумеющимся компонентом системы.
Я бы ещё сопоставил эту проблему с проблемой оболочек командной строки. Подавляющее большинство исходников ориентируются на sh-подобный синтаксис (Bourne shell). И по этой причине разработчики, конечно, включают её в стандартный набор ПО. Но тем не менее в качестве оболочки по-умолчанию может использоваться оболочка с другим скриптовым синтаксисом. И получается, что даже тут теоретически можно жить без sh/bash/zsh, поставив какой-нибудь tcsh или fish.
Все Линукс системы идут с Python языком, чем он не угодил?
Поскольку у самого ядра нет бинарной зависимости от Python, то не все дистрибутивы включают интерпретатор по-умолчанию. Отсюда в минималистичных дистрибутивах (таких как ArchLinux, Gentoo и тем более LFS) вполне можно работать без Python. К FreeBSD это, кстати, тоже относится.
Пару лет просидел на ArchLinux. И помнится, что даже когда накатывал GUI (чаще всего плазму), то Python и в этом случае не требовался. Но, конечно, когда начинаешь устанавливать пакет за пакетом, то где-то в зависимостях Python и проскочит.
Зачем создавать еще один язык программирования для этого?
Мне кажется невозможно создать универсальный язык программирования, пригодный для решения любых задач. Это как набор взаимоисключающих параграфов. Даже если попытаться, то рано или поздно придётся пойти на компромисс с решением какой-то проблемы. К тому же у разных людей своих вкусы, предпочтения и взгляды на то, какой должен быть их любимый язык. Из каждого языка ещё дополнительно выходит культура разработки на нём.
На мой взгляд гораздо интереснее, когда много культур и подходов, чем какой-то один. Как, например, был бы какой-то один музыкальный жанр. Ведь программирование — это тоже немножко искусство и творчество.
Ещё можно поразмыслить с той точки зрения, что языки конкурируют между собой, а это повышает требования к качеству с каждым днем, что в свою очередь ускоряет развитие и эволюцию. Разработчики новых и старых языков учатся на ошибках друг друга, следят за тенденциями итак далее.
Что касается самого языка Vala, то я вижу в нем достаточно неплохое компромиссное решение между Java, C++ и C. Из Java взят удобный стиль объектно-ориентированного описания, но при этом отсутствие виртуальной машины, трансляция кода в C и последующая компиляция в бинарь. Также совместимость с библиотеками C/C++. Я считаю такой язык имеет место быть.
К тому же ребята из популярного Linux дистрибутива elementaryOS совсем даже не чураются его использовать и декларируют как основной язык разработки приложений для своей операционной системы.
Как у него с поддержкой гуя с нативными виджетами?
Довольно таки неплохо. В Python у меня был опыт с двумя тулкитами, поддерживающими нативный интерфейс системы: PyQt и PySide. Оба этих пакета используют биндинги на Qt фреймворк, а он, как известно, отрисовывает окна в нативном стиле.
К тому же эти пакеты различаются типом лицензирования, поэтому можно выбрать ту, что наиболее подходит при конкретной разработке. Поэтому возможность разрабатывать GUI приложения на Python существует. При том без танцев с бубном.
Другой вопрос, что сама разработка GUI приложений на Python является экзотикой и является весьма спорной с эстетической точки зрения.
Скорее всего вы что-то путаете.
Файлы прошивки BIOS не должны монтироваться, более того это адресное пространство должно быть недоступно в пространстве пользователя операционной системы.
Возможно вы имели ввиду монтирование переменных EFI в директорию sys. Но тут тоже, согласно UEFI спецификации, затирание этих переменных не должно быть критическим и при следующем запуске должны установиться значения по умолчанию.
Я в курсе, что был какой-то случай на компьютерах MSI, когда затирание переменных EFI приводило к краху, но это частный случай и ошибка разработчиков прошивок для компьютеров MSI.
Но мне кажется, что вышеобозначеная команда даже не дойдёт до директории sys, а споткнётся о невозможности удалить белочные устройства в /dev. Кроме этого может рано или поздно возникнуть ошибка ядра и далее не удасться породить новый процесс. Дальше только hard reset.
Поэтому ничего опасного, кроме удаления пользовательских файлов эта команда делать не должна.
Мне кажется все таки список — это список, а меню — это меню.
Другой вопрос, что соответствующего тэга для меню пока нет, но скоро должен появится. И тогда всех, кто делает меню на списках — будут так же шеймить, как и тех, кто делает верстку на таблицах.
Иначе мы придём к выводу, что такие тэги как section, article и так далее не нужны и все можно сделать на div.
Кроме этого нужно не забывать ещё про Accessibility.
«СберPhone делает революцию на ранке мобильных гаджетов»
Я бы ещё сопоставил эту проблему с проблемой оболочек командной строки. Подавляющее большинство исходников ориентируются на sh-подобный синтаксис (Bourne shell). И по этой причине разработчики, конечно, включают её в стандартный набор ПО. Но тем не менее в качестве оболочки по-умолчанию может использоваться оболочка с другим скриптовым синтаксисом. И получается, что даже тут теоретически можно жить без sh/bash/zsh, поставив какой-нибудь tcsh или fish.
Поскольку у самого ядра нет бинарной зависимости от Python, то не все дистрибутивы включают интерпретатор по-умолчанию. Отсюда в минималистичных дистрибутивах (таких как ArchLinux, Gentoo и тем более LFS) вполне можно работать без Python. К FreeBSD это, кстати, тоже относится.
Пару лет просидел на ArchLinux. И помнится, что даже когда накатывал GUI (чаще всего плазму), то Python и в этом случае не требовался. Но, конечно, когда начинаешь устанавливать пакет за пакетом, то где-то в зависимостях Python и проскочит.
Мне кажется невозможно создать универсальный язык программирования, пригодный для решения любых задач. Это как набор взаимоисключающих параграфов. Даже если попытаться, то рано или поздно придётся пойти на компромисс с решением какой-то проблемы. К тому же у разных людей своих вкусы, предпочтения и взгляды на то, какой должен быть их любимый язык. Из каждого языка ещё дополнительно выходит культура разработки на нём.
На мой взгляд гораздо интереснее, когда много культур и подходов, чем какой-то один. Как, например, был бы какой-то один музыкальный жанр. Ведь программирование — это тоже немножко искусство и творчество.
Ещё можно поразмыслить с той точки зрения, что языки конкурируют между собой, а это повышает требования к качеству с каждым днем, что в свою очередь ускоряет развитие и эволюцию. Разработчики новых и старых языков учатся на ошибках друг друга, следят за тенденциями итак далее.
Что касается самого языка Vala, то я вижу в нем достаточно неплохое компромиссное решение между Java, C++ и C. Из Java взят удобный стиль объектно-ориентированного описания, но при этом отсутствие виртуальной машины, трансляция кода в C и последующая компиляция в бинарь. Также совместимость с библиотеками C/C++. Я считаю такой язык имеет место быть.
К тому же ребята из популярного Linux дистрибутива elementaryOS совсем даже не чураются его использовать и декларируют как основной язык разработки приложений для своей операционной системы.
Довольно таки неплохо. В Python у меня был опыт с двумя тулкитами, поддерживающими нативный интерфейс системы: PyQt и PySide. Оба этих пакета используют биндинги на Qt фреймворк, а он, как известно, отрисовывает окна в нативном стиле.
К тому же эти пакеты различаются типом лицензирования, поэтому можно выбрать ту, что наиболее подходит при конкретной разработке. Поэтому возможность разрабатывать GUI приложения на Python существует. При том без танцев с бубном.
Другой вопрос, что сама разработка GUI приложений на Python является экзотикой и является весьма спорной с эстетической точки зрения.