Ну если байтом называть не 8 бит, а минимально адресуему единицу информации (то, на что может указывать указатель), то да — байт может занимать и 16 и 32 бита.
С utf-16 ничего не просто. Просто только с UCS2. Некоторые символы в представлении UTF-16 могут занимать больше 16 бит. Так же не следует забывать о UTF-16LE и UTF-16ВE.
Лично моей работы здесь не так уж и много. Я внес некоторые исправления в аудиокодек, добавил поддержку клавиатуры Ritmix'а (у Ramos она немного другая), завел радио (в экземпляре wodz'а радио отсутствует) и подкорректировал некоторые плагины (просмотр картинок/видео, пара демок и игрушек), чтобы заставить их работать.
Да, совсем не много :)
Я посморел патч, не сказать, что там мало работы, на самом то деле.
Ну у меня на декстопе /proc/sys/kernel/random/ показывает 180, а /proc/sys/kernel/random/ (сколько бит энтропии надо для разблокировки вызывающего процесса) — 64. Так что значения довольно таки стрёмные.
На сервере количество энтропии может быть ещё меньше — мышки и клавы то нету…
Так что в общем из /dev/random лучше не читать без сильной на то обходимости.
А зачем читать случайные данные из /dev/random? Здесь же не нужен криптографический надежный источник случайных чисел. А так у чтения из /dev/random есть два минуса:
1. Если в системе недостаточно энтропии, чтение из /dev/random может заблокировать вызывающий поток. Думаю, nginx будет не рад :)
2. Лишние файловые операции. Зачем, если можно обойтись?
Ведь здесь хватит и простого random(). Если мучит паранойя — можно захешировать.
А как вы будете их стирать? Их стирает контроллер когда посчитает нужным (точнее, когда точно знает, что страница уже не используется). Можно конечно попытаться записать во все сектора 0xFF. Но контроллер всё равно будет считать, что страница используется.
Конечно, если контроллер умный, и увидит что страница чистая, то возможно он второй раз стирать её не будет. Но я, честно говоря не знаю, бывают ли такие контроллеры.
Кстати, на самом деле размер страницы всегда больше, чем чем степень двойки (на 32,64,128 байт, зависит от размера страницы). Остальная часть используется для out-of-band data (служебных меток, информации для востановления данных, и т.д.). Вполне возможно, что если записать в сектор 0xFF, то контроллер запихнет в область OOB какие-то свои данные (типа счетчика стирания и ECC). И ему потом всё равно придется стирать всю страницу целиком, что бы обновить информацию.
Хотя, SSD контроллеры поддерживают функцию TRIM. Она как раз сообщает что сектор (страница) не используется и её можно стереть. Понимают ли USB флешки такую штуку — я не знаю.
Теория хорошая, но к сожалению флешки работают по другому. Флешка разбита на страницы (например — 4кб). Единственный способ записи одного бита — это перевести 1 в 0. Единственный бит невозможно</b/ перевести из 0 в 1. Можно только стереть полностью страницу. Стирание страницы как раз и приводит к установке всех её бит в 1. И как раз самая длительная операция — это стирание. Я не помню точных цифр, но она занимает на порядки больше времени, чем запись ( перевод 1 в 0).
Кстати, знаете почему флешки так называются? :) Для стирания на ячейки надо подать импульс высокого напряжения — около 12В (насколько я помню). Этот импульс (вспышка) и стирает ячейки. С другой стороны USB обеспеычивает питание только 5В. До 12В напряжение подымается специальными «насосами заряда» (charge pump). Которым тоже нужно время для зарядки.
А здесь — что-то вроде студнческой рассчетной работы по методичке. Кому надо — тот и так знает. А кому не надо — тот не узнет ничего интересного.
Да, совсем не много :)
Я посморел патч, не сказать, что там мало работы, на самом то деле.
На сервере количество энтропии может быть ещё меньше — мышки и клавы то нету…
Так что в общем из /dev/random лучше не читать без сильной на то обходимости.
1. Если в системе недостаточно энтропии, чтение из /dev/random может заблокировать вызывающий поток. Думаю, nginx будет не рад :)
2. Лишние файловые операции. Зачем, если можно обойтись?
Ведь здесь хватит и простого random(). Если мучит паранойя — можно захешировать.
У Hexagon совсем другая архитектура.
Например линуксовое ядро проверяется тулзой Sparse. Она в принципе находит разные косяки, но большого опыта работы с ней у меня небыло.
Конечно, если контроллер умный, и увидит что страница чистая, то возможно он второй раз стирать её не будет. Но я, честно говоря не знаю, бывают ли такие контроллеры.
Кстати, на самом деле размер страницы всегда больше, чем чем степень двойки (на 32,64,128 байт, зависит от размера страницы). Остальная часть используется для out-of-band data (служебных меток, информации для востановления данных, и т.д.). Вполне возможно, что если записать в сектор 0xFF, то контроллер запихнет в область OOB какие-то свои данные (типа счетчика стирания и ECC). И ему потом всё равно придется стирать всю страницу целиком, что бы обновить информацию.
Хотя, SSD контроллеры поддерживают функцию TRIM. Она как раз сообщает что сектор (страница) не используется и её можно стереть. Понимают ли USB флешки такую штуку — я не знаю.
Кстати, знаете почему флешки так называются? :) Для стирания на ячейки надо подать импульс высокого напряжения — около 12В (насколько я помню). Этот импульс (вспышка) и стирает ячейки. С другой стороны USB обеспеычивает питание только 5В. До 12В напряжение подымается специальными «насосами заряда» (charge pump). Которым тоже нужно время для зарядки.