если квартира расположена около автомобильной дороги (большинство квартир в городе), то система на базе esp32 предположительно сможет подавить до 80% входящего городского шума;
А это откуда такие сведения, из статьи непонятно. Кто-то ставил такой эксперимент?
На сколько я понимаю, одним динамиком можно создать только небольшую зону на определённом расстоянии, чуть влево-вниз-вперёд и всё, уже может быть усиление, ведь пути распространения разные. То есть надо создавать поле, для этого нужна согласованная работа множества динамиков/микрофонов.
Ну и если конкретная FS по своему личному стандарту поддерживает конкретную кодировку - то и реализация линукса её будет поддерживать так, как надо для этой FS, разве нет?
Вот именно что, если в спецификации есть, но как раз основная родная фс ext4 кодировку как раз и не специфицирует! Не знаю как с остальными типа xfs, btrfs и прочие zfs. И после этого Торвальдс говорит что-то про какие-то проблемы регистронезависимых ФС...
Но тем не менее такими шрифтами пользовались, и не устраивали забастовок "дайте нам ноль без палочки, мы иначе работать не можем".
И было всё прекрасно, я считаю. Но в какой-то момент кто-то (Микрософт?) вернул нули без палочки (каламбурчик). И это как-то распространилось везде, даже на Линукс, интересно почему.
это всё равно не решит проблемы aа cс yу MМ и иже с ним
Разумеется не решит. С регистронезависимостью проблемы примерно такого же порядка, как и с аа сс уу, с ними в принципе можно жить. Но если ФС (в том числе регистронезависимая) чётко определит в спецификации, какие символы и в какой кодировке допустимы в её именах (и будет за этим следить), то мир станет лучше. :)
А если в имени одного файла буквы из 12 разных языков?
В имени файла 12ть разных языков в 12и разных кодировках? С языками та ещё засада. Равна ли украинская "а" русской "а"? Допустим равна, а почему тогда английская "а" не равна русской "а"? :) Понятно что разные алфавиты, но всё же... По хорошему из ФС надо бы узнать язык, алфавит (а некоторые языки могут использовать два алфавита!), кодировку каждого из кусочка имени файла, если разрешать это. Либо можно просто запретить смешивать кодировки в имени.
Одинаково выглядящие буквы алфавита, типа cс, aа - ну как ни старайся, будут выглядет одинаково
О чём и речь, про что я и начал писать @MountainGoat (в прошлом посте перепутал его с ( @RedEyedAnonymous ) что это проблема глобальна и присутствует даже в рамках одного алфавита одной кодировки, что уж там говорить о разных алфавитах и кодировках и уж тем более юникоде...
Одинаково выглядящие начертания букв в одном алфавите плюс цифры в одном шрифте - косяк шрифта.
От того что мы это обозначим косяком шрифта или ещё чьим-то (например алфавита) проблема-то никуда не денется. Никто же не бросится из-за этого переделывать шрифты, потому что есть ещё множество других, порой противоречивых требований к ним. В классическом нуле нет чёрточки никакой, потому что цифры и буквы возникли задолго до компьютеров и никому тогда не могло прийти в голову что их будут где-то путать. Так что я не согласен что это всего лишь косяк шрифта, потому что косяк можно было бы легко исправить. Но это не так, этот "косяк" останется с нами ещё надолго и никто его исправлять не будет. С ним надо как-то привыкать жить.
То, что в UI должен быть способ различать такие миксы из алфавитов, особенно в URL и прочих местах хотя бы для борьбы с фишингом - вряд ли кто-то будет спорить. Но наверное это всё-таки вопрос к UI, а не FS...
Файловая система должна для начала предоставить информацию о кодировке, прежде чем UI что-то будет пытаться сделать. Как минимум это имеет отношение к FS. Но там на пути до UI лежит ещё толстый-претолстый слой юникода, который сам по себе - огромный косяк :)
Но ведь это проблема шрифта, а не кодировки. В кодировке эти символы имеют различные коды и термин "похожесть" к ним не применим.
Это просто один пример из множества случаев, когда пользователю трудно отличить названия файлов в ФС, таким примеров можно придумать много. В Линуксе в ФС вообще нет понятия кодировка, там просто какие-то байты в названии
Изначально речь шла про ситуацию, когда на диске есть два файла, с выглядящими одинаково названиями. Это может быть по разным причинам. Сначала речь была о примере, что файлы в разных кодировках одного языка. Например есть один файл Ёж в koi-8r, другой в cp866. Но как раз здесь @RedEyedAnonymous и перемудрил, потому что если кодировка имени хранится вместе с файлом на диске, то как раз есть шанс проверить их соответствие, если перекодировать из одной кодировки в другую. Если же файлы в одной кодировке, как в случае с 1 и l или массой других ситуаций в юникоде или других кодировках, то всё усложняется.
Но сейчас же в Линуксе вообще всё очень хреново: на диске хранятся просто байты и вообще неизвестно какая кодировка, что есть конечно же неправильное решение. Это решение конечно в своё время сильно облегчило жизнь разработчикам ФС, но от этого оно не становится правильным.
Даже если решить что все файлы кодируются исключительно только в utf-8, это не полностью решает проблему, потому что в юникоде есть несколько способов закодировать один символ и остаётся вопрос с одинаково выглядящими символами.
Если... А если нет? 99% людей не будут заморачиваться и воспользуются тем что есть. Прямо сейчас в этом окошке у меня l и I не отличаются. На картинке у вас 1 и l можно тоже перепутать по невнимательности.
С чем реально есть проблема - это с буквами одинакового начертания из разных алфавитов в одному шрифте. Но это уже "несколько другая"
Это ровно та проблема, которая здесь обсуждается - символы с разными кодами выглядят одинаково.
Просто слово биоритм в русском языке имеет разные значения. В русской Википедии тема раскрыта полнее
https://ru.wikipedia.org/wiki/Биоритм
А это откуда такие сведения, из статьи непонятно. Кто-то ставил такой эксперимент?
На сколько я понимаю, одним динамиком можно создать только небольшую зону на определённом расстоянии, чуть влево-вниз-вперёд и всё, уже может быть усиление, ведь пути распространения разные. То есть надо создавать поле, для этого нужна согласованная работа множества динамиков/микрофонов.
А что с Луной, какие есть методы?
А как же свободные
openshotи shotcut?открыли бы исходники вовремя, ещё неизвестно, чем бы дело кончилось
Вот именно что, если в спецификации есть, но как раз основная родная фс ext4 кодировку как раз и не специфицирует! Не знаю как с остальными типа xfs, btrfs и прочие zfs. И после этого Торвальдс говорит что-то про какие-то проблемы регистронезависимых ФС...
При чём тут LSB? Это должно быть в спецификации файловой системы. ext4, например.
Например в ntfs вроде юникод как раз, но не utf8 а что-то вроде utf-16, могу ошибаться
Так Freedos тоже хорош, там тоже текстовый моноширинный шрифт :)
Так я про это и говорю... Хотя бы так... Написали бы в спецификации, мол utf-8 такой-то версии. Так нет же, даже этого нет!
при желании можно и ДОС поставить, там тоже нолик по-умолчанию перечёркнут, как раз свежий Freedos вышел :)
Да я про это и говорю, надо хотя бы указать кодировку. Проблему "аа сс" не решит, но уже будет шаг вперёд.
Да, неприятно, но не смертельно.
И было всё прекрасно, я считаю. Но в какой-то момент кто-то (Микрософт?) вернул нули без палочки (каламбурчик). И это как-то распространилось везде, даже на Линукс, интересно почему.
Разумеется не решит. С регистронезависимостью проблемы примерно такого же порядка, как и с аа сс уу, с ними в принципе можно жить. Но если ФС (в том числе регистронезависимая) чётко определит в спецификации, какие символы и в какой кодировке допустимы в её именах (и будет за этим следить), то мир станет лучше. :)
В имени файла 12ть разных языков в 12и разных кодировках? С языками та ещё засада. Равна ли украинская "а" русской "а"? Допустим равна, а почему тогда английская "а" не равна русской "а"? :) Понятно что разные алфавиты, но всё же... По хорошему из ФС надо бы узнать язык, алфавит (а некоторые языки могут использовать два алфавита!), кодировку каждого из кусочка имени файла, если разрешать это. Либо можно просто запретить смешивать кодировки в имени.
это как?
О чём и речь, про что я и начал писать @MountainGoat (в прошлом посте перепутал его с ( @RedEyedAnonymous ) что это проблема глобальна и присутствует даже в рамках одного алфавита одной кодировки, что уж там говорить о разных алфавитах и кодировках и уж тем более юникоде...
От того что мы это обозначим косяком шрифта или ещё чьим-то (например алфавита) проблема-то никуда не денется. Никто же не бросится из-за этого переделывать шрифты, потому что есть ещё множество других, порой противоречивых требований к ним. В классическом нуле нет чёрточки никакой, потому что цифры и буквы возникли задолго до компьютеров и никому тогда не могло прийти в голову что их будут где-то путать. Так что я не согласен что это всего лишь косяк шрифта, потому что косяк можно было бы легко исправить. Но это не так, этот "косяк" останется с нами ещё надолго и никто его исправлять не будет. С ним надо как-то привыкать жить.
Файловая система должна для начала предоставить информацию о кодировке, прежде чем UI что-то будет пытаться сделать. Как минимум это имеет отношение к FS. Но там на пути до UI лежит ещё толстый-претолстый слой юникода, который сам по себе - огромный косяк :)
Это просто один пример из множества случаев, когда пользователю трудно отличить названия файлов в ФС, таким примеров можно придумать много. В Линуксе в ФС вообще нет понятия кодировка, там просто какие-то байты в названии
Изначально речь шла про ситуацию, когда на диске есть два файла, с выглядящими одинаково названиями. Это может быть по разным причинам. Сначала речь была о примере, что файлы в разных кодировках одного языка. Например есть один файл Ёж в koi-8r, другой в cp866. Но как раз здесь @RedEyedAnonymous и перемудрил, потому что если кодировка имени хранится вместе с файлом на диске, то как раз есть шанс проверить их соответствие, если перекодировать из одной кодировки в другую. Если же файлы в одной кодировке, как в случае с 1 и l или массой других ситуаций в юникоде или других кодировках, то всё усложняется.
Но сейчас же в Линуксе вообще всё очень хреново: на диске хранятся просто байты и вообще неизвестно какая кодировка, что есть конечно же неправильное решение. Это решение конечно в своё время сильно облегчило жизнь разработчикам ФС, но от этого оно не становится правильным.
Даже если решить что все файлы кодируются исключительно только в utf-8, это не полностью решает проблему, потому что в юникоде есть несколько способов закодировать один символ и остаётся вопрос с одинаково выглядящими символами.
Точнее это конечно не ровно та проблема, но схожая возникает в Юникоде.
Если... А если нет? 99% людей не будут заморачиваться и воспользуются тем что есть. Прямо сейчас в этом окошке у меня l и I не отличаются. На картинке у вас 1 и l можно тоже перепутать по невнимательности.
Это ровно та проблема, которая здесь обсуждается - символы с разными кодами выглядят одинаково.
Видимо делают скидку, если ты продаёшь только компы с виндосом. А так как большинство покупает в виндосом им выгодней отказаться от других ОС.
=но если это просто байка, то должно быть либо 6+3 либо 9+3
Да, вопрос, чем пожертвовали, символом в таблице или возможностью сделать имена файлов на целый символ длиннее. Судя по 8+3, таки длиной имени файла.