Так лучше, я что-то сразу не учел, что сортировка будет по ключу, а у него индекс на b-дереве, т.е. сортировка бесплатная. Но остается проблема с дырками в ключах.
Хотя нет, одним запросом с подзапросом вроде не обойтись, подзапрос все равно будет выполнятся для каждой записи. Тогда получается то же, что и с «LIMIT rand_row, 1», либо хранимая процедура, либо доп. код на каком-нибудь языке. Но предложенный тут вариант выдает более качественный результат.
По ссылке просто кривое решение… Далее, использовать < или > без сортировки несколько опасно. Совершенно нет гарантии, что в таблице строки идут по порядку. Может получится так, что SELECT без ORDER BY выдаст в начале запись с id 1000, а потом с id 10… Т.е. теоретически используя этот способ запись с id 10 вообще никогда не будет получена. Хотя на практике с LIMIT 1 все работает вроде корректно, но вообще поведение не очень предсказуемо. Я из своей тестовой таблицы я удалил несколько строк расположенных вначале и добавил новую, в результате получил следующее:
Что уже не очень соответствует ожиданиям, но без limit 10 запись 12876 выдается первой. Если добавить ORDER BY, сделав тем самым поведение полностью предсказуемым, то чем оно принципиально лучше предложенного автором LIMIT? Единственный плюс, используя этот подход можно обойтись одним SQL запросом с одним подзапросом.
Вообще я не за ORDER BY RAND(), хотя считаю что в большинстве случаев это решение приемлемо, я против решения предложенного в сообщении выше :) Оно еще хуже и не правильно решает задачу, точнее вообще не решает ее, т.к. выдает полный бред.
Хм, сделал табличку, загнал в нее около 12к записей, структура такая
|int pk|varchar(255) data|
выполняю:
mysql> SELECT `pk`, substr(`data`,1,20) FROM `test` ORDER BY RAND() LIMIT 1;
+------+----------------------+
| pk | substr(`data`,1,20) |
+------+----------------------+
| 1612 | ark2K9bS0NeHWk34ZDAc |
+------+----------------------+
1 row in set (0.15 sec)
mysql> SELECT `pk`, substr(`data`,1,20) FROM `test` WHERE `pk` >= (SELECT FLOOR( MAX(`pk`) * RAND()) FROM `test`) ORDER BY `pk` LIMIT 1;
+----+----------------------+
| pk | substr(`data`,1,20) |
+----+----------------------+
| 48 | juuZeRXMUJxyp1GV8EZM |
+----+----------------------+
1 row in set (1.52 sec)
mysql> SELECT `pk`, substr(`data`,1,20) FROM `test` WHERE `pk` >= (SELECT FLOOR( MAX(`pk`) * RAND()) FROM `test`) ORDER BY `pk` LIMIT 1;
+-----+----------------------+
| pk | substr(`data`,1,20) |
+-----+----------------------+
| 173 | qQOA1ptDKU9qrJTDzf2j |
+-----+----------------------+
1 row in set (5.35 sec)
И т.п., для первого варианта время выполнения всегда примерно 0,15 сек, для предложенного, каждый раз отличается. Более того, значение pk в выбранных строках не большие (в районе 100). Весь фокус в том, что запрос (SELECT FLOOR( MAX(pk_column) * RAND()) FROM my_table) выполняется для каждой записи… Не надо верить комментариям к мануалу, как самому мануалу ;)
P.S. mysql крутится на втором пне с частотой 450МГц, по тому для ощутимого времени выполнения большого кол-ва записей не понадобилось.
По моему multilib тут не причем. Есть ядро, оно 64 битное, при chroot появляется новое окружение и в этом окружении уже загружается /bin/bash, он уже никакого отношения к исходной системе не имеет (почти), все библиотеки подгружаются из нового окружения, в том числе и glibc. Если ядро может выполнять 32 битный код, то все должно работать.
1) Загрузочный диск надо иметь той же архитектуры (т.е. если у вас x86_64 — лайвсиди нужен x86_64 и т.п.)
Можно и старше. Т.е. если стоит i386, можно сделать chroot из x86_64, но не наоборот. Исключение, вырубленная в 64 битном ядре поддержка 32 битных бинарок, но это редкость.
Вы можете сказать конструктивно, какие недочеты в статье, это было бы полезно, и интересно :)
Я могу сказать, информация про reiserfs не верна. Не доработанные ФС в ванильную ветку просто так не включают, если действительно известны случаи порчи данных по вине ФС. Или хотя бы ставят пометку DANGEROUS или EXPERIMENTAL. В википедии описана пара недостатков, которые возможно больше соответствуют действительности, а так же пройдя через нескольких людей могут быть искажены:
— Reiser3 может быть повреждена в результате перестройки дерева во время проверки. Перестройка дерева нужна при условии, если метаданные очень сильно повреждены.
— Версии ReiserFS, включённые в ядро Linux младше версии 2.4.10, признаны нестабильными компанией Namesys и не рекомендованы для промышленного использования, особенно в связке с NFS.
Сильное повреждение метаданных происходит в основном в случае аппаратных проблем, причем не просто отключения электричества. А 2.4.10 это уже история :)
Неужели от самого Линуса? :) 91 год это первый релиз ядра… Конечно познакомится с системой можно было, но вот что бы «с 91го года на линуксе» это громко сказано :)
Так и надо было писать что это относится к 4ке. 3 стабильная, ничего не теряется (больше 5ти лет использую, были и вырубания электричества и просто ребуты из-за кривых дров и экспериментов), в ванильной ветки живет очень давно. А 4ку до сих пор не включили.
Это точно был слой? Я что-то такого не припомню. И сейчас проверил, именно слой можно двигать куда угодно и возвращать обратно, изображение цело. А вот при вставке новый слой по умолчанию не создается, а создается как бы «виртуальный» слой, который так же можно двигать туда-сюда, но вот если его передвинуть за пределы слоя, расположенного под ним и закончить редактирование, то он сольется с тем слоем и естественно часть изображения потеряется. Для того, что бы создать новый слой из вставленной картинки можно нажать на кнопку создания слоя. Это верно для GIMP 2.4 и в более ранних такого не замечал, а 2.6 пока не смотрел, но не думаю что там это изменилось.
Независимость от DE это отсутствие интеграции с DE. В Linux ассоциация типов файлов с программой осуществляется средствами DE (хотя может какой-нибудь стандарт уже есть). Нужен ли такой менеджер? Уж лучше по менеджеру на DE :) А так есть например gentoo (не путать с дистрибутивом), страшненький, зато тянет не много либ :)
Я себе такую взял Клавиатура Krauler PK-S306 Black, X-Slim, USB+PS/2. Конечно не без лишних клавиш, но они не напрягают. Раскладка вполне привычная. Единственное ход, бывает, что по ощущениям нажал, а нет. Обычно с большими клавишами так.
Полностью согласен. Хочется собирать софт и вытачивать систему, Gentoo отличный выбор. Если не хочется собирать софт, но все таки знаешь, что тебе нужно, Debian отличный выбор. А вот ставить Debian и пересобриать его руками, по моему это что-то не то :)
RISC от CISC отличаются тем, что команды в RISC проще и фиксированной длинны, а в CISC могут быть разной. Принципиальных отличий (в контексте темы топика) в вычислениях между ними нет. Все те же биты и детерминированные операции над ними… Почему после слов «RISC архитектурой» в скобках стоит PowerPC? PowerPC, так же как и ARM, архитектура построенные по принципу RISC, но к почему к ней особое внимание? В общем чему-то не тому вас учили :)
У AnyDVD не все чисто с законом. С таким же успехом можно было дать ссылку на какой-нибудь торрент с BD-Rip :)
Когда люди покупают материальный носитель они склонны хотеть им обладать, а вот когда просто просмотр — тут сложнее.
По моему отмирание физических носителей (речь естественно не про каналы связи) как формы распространения контента это вопрос времени.
Хотя всё равно с фильмами ничего сделать нельзя: не так сложно снять информацию прямо с контроллера LCD, а для появления фильмов в torrent'е нужна всего-то одна копия.
Это да, всегда будут создавать защиту и всегда ее будут ломать. Но я говорил не об обходе защиты, а о том, что под видом защиты своих авторских прав возможно введения слишком сильных ограничений, вплоть до объявления ПО, которое не контролирует пользователя незаконным.
Что в принципе соответствует моим ожиданиям. Но:
Что уже не очень соответствует ожиданиям, но без limit 10 запись 12876 выдается первой. Если добавить ORDER BY, сделав тем самым поведение полностью предсказуемым, то чем оно принципиально лучше предложенного автором LIMIT? Единственный плюс, используя этот подход можно обойтись одним SQL запросом с одним подзапросом.
|int pk|varchar(255) data|
выполняю:
И т.п., для первого варианта время выполнения всегда примерно 0,15 сек, для предложенного, каждый раз отличается. Более того, значение pk в выбранных строках не большие (в районе 100). Весь фокус в том, что запрос (SELECT FLOOR( MAX(pk_column) * RAND()) FROM my_table) выполняется для каждой записи… Не надо верить комментариям к мануалу, как самому мануалу ;)
P.S. mysql крутится на втором пне с частотой 450МГц, по тому для ощутимого времени выполнения большого кол-ва записей не понадобилось.
Можно и старше. Т.е. если стоит i386, можно сделать chroot из x86_64, но не наоборот. Исключение, вырубленная в 64 битном ядре поддержка 32 битных бинарок, но это редкость.
Я могу сказать, информация про reiserfs не верна. Не доработанные ФС в ванильную ветку просто так не включают, если действительно известны случаи порчи данных по вине ФС. Или хотя бы ставят пометку DANGEROUS или EXPERIMENTAL. В википедии описана пара недостатков, которые возможно больше соответствуют действительности, а так же пройдя через нескольких людей могут быть искажены:
Сильное повреждение метаданных происходит в основном в случае аппаратных проблем, причем не просто отключения электричества. А 2.4.10 это уже история :)
По моему отмирание физических носителей (речь естественно не про каналы связи) как формы распространения контента это вопрос времени.
Это да, всегда будут создавать защиту и всегда ее будут ломать. Но я говорил не об обходе защиты, а о том, что под видом защиты своих авторских прав возможно введения слишком сильных ограничений, вплоть до объявления ПО, которое не контролирует пользователя незаконным.