ZeroNet Blogs

Static ZeroNet blogs mirror

LuaJIT

- Posted in Geekless.Blog by with comments

LuaJIT написан гением. Mike Pall практически на коленке реализовал трассирующий JIT-компилятор, который в тестах производительности либо рвёт, либо идёт ноздря в ноздрю с продуктом крутой гигантской корпорации — V8. Я думаю, сравнивать реализации JS и Lua вполне уместно, поскольку оба имеют очень похожую систему типов, набор фич и область применения. JIT-компилятор при генерации кода у обоих языков решает примерно одни и те же задачи.

В отдельных случаях скорость исполнения кода в LuaJIT приближается к скорости кода на Си, скомпилированного без оптимизаций. Под «приближается» я имею в виду: отстаёт всего в несколько раз, а не на два порядка, как это обычно. И это динамически типизированный скриптовый язык.

Никакие Перлы, Руби, Питоны и PHP и близко не лежали. Питоновский pypy умеет только жрать память и тормозить после стольких человеко-лет разработки. Про ванильный python в разговоре о производительности вспоминать вообще неприлично.

Только одна вещь меня расстраивает в LuaJIT — это Lua. Почти всё можно простить языку, но адресация массивов с единицы — такого прощать нельзя.

Очень хочется взять сорцы LuaJIT и перепилить их под компиляцию JavaScript. Можно будет встраивать этот интерпретатор JS даже в утюги, и такой утюг будет летать. Это будет бомба, котаны!

Не знаю, доберусь когда-нибудь ли я до этого, но руки чешутся очень. Напишите в комментариях, если у вас тоже. Может быть, совместно что-то выгорит.

Some user ID statistics

- Posted in Geekless.Blog by with comments

At the moment, I have 545 zites hosted on my computer:

$ find * -maxdepth 0 -type d | wc -l
545

So I decided to get some stats.


I extracted user names from content.json files:

$ find . -name 'content.json' | xargs grep -h -o '"cert_user_id":.*' | grep -o '[^"]*@[^"]*' > /tmp/all_nicknames

Total count is 70950:

$ wc -l /tmp/all_nicknames
70950

That is how many times different users are logged in on different zites.

Okay, how about counting only the unique entries? 31256 unique users in total:

$ sort /tmp/all_nicknames | uniq > /tmp/uniq_nicknames
$ wc -l /tmp/uniq_nicknames
31256

Let's count, how much different ID providers are popular:

$ grep -o '@.*' /tmp/uniq_nicknames | sort | uniq -c | sort -nr
  29314 @zeroid.bit
    741 @zv.anonymous
    508 @millchan
    242 @ifs.anonymous
    195 @kaffie.bit
    104 @zeroverse.bit
     66 @cryptoid.bit
     53 @0ch.anonymous
     26 @nobody
      4 @kxoid.bit
      2 @zeropolska.bit
      1 @sorasumi.bit

Top 50 active users by the number of zites they use:

$ sort /tmp/all_nicknames | uniq -c | sort -nr | head -50
     92 ssdifnskdjfnsdjk@zeroid.bit
     81 balancer73@zeroid.bit
     77 krixano@zeroid.bit
     72 gitcenter@zeroid.bit
     68 binchan2@zeroid.bit
     65 geekless@zeroid.bit
     60 putsan@zeroid.bit
     58 kaffie@zeroid.bit
     57 glightstar@zeroid.bit
     55 zalex@zeroid.bit
     50 anonymouslogin@zeroid.bit
     47 styromaniac@zeroid.bit
     44 sirenyc@zeroid.bit
     42 ulrichard@zeroid.bit
     42 polar@zeroid.bit
     42 piloth@zeroid.bit
     42 eibriel@zeroid.bit
     41 trooper@zeroid.bit
     40 weakish@zeroid.bit
     39 thunder33345@zeroid.bit
     39 qiwi@zeroid.bit
     39 muja@zeroid.bit
     39 erkan@zeroid.bit
     39 atheist@zeroid.bit
     38 caryoscelus@zeroid.bit
     38 blurhy@zeroid.bit
     37 tangdou@zeroid.bit
     37 p2p@zeroid.bit
     37 nippletwister@zeroid.bit
     36 musickiller@zeroid.bit
     36 jad@zeroid.bit
     35 htgozn@zeroid.bit
     35 frayoshi@zeroid.bit
     34 zerolstn@zeroid.bit
     34 ks@zeroid.bit
     33 yilmazerkan@zeroverse.bit
     33 wanditoast@zeroid.bit
     33 schiz0@zeroid.bit
     33 l8@zeroid.bit
     33 aimaster@zeroid.bit
     32 nofish@zeroid.bit
     32 booma@zeroid.bit
     30 nishikinomaki@zeroid.bit
     30 nekocross@zeroid.bit
     30 mkg20001@zeroid.bit
     30 cer@zeroid.bit
     30 beelzebub@zeroid.bit
     30 a7oiz@zeroid.bit
     29 scrub@zeroid.bit
     29 nekololi@zeroid.bit

Top 50 active users of non-default ID providers:

$ grep -v '@zeroid.bit' /tmp/all_nicknames | sort | uniq -c | sort -nr | head -50
     33 yilmazerkan@zeroverse.bit
     10 inner-iframe@zv.anonymous
      8 glightstar@kaffie.bit
      5 zeroali@kaffie.bit
      4 zero@kaffie.bit
      4 v0net@cryptoid.bit
      4 shouko@kaffie.bit
      4 sayo@kaffie.bit
      4 redacted@zeroverse.bit
      4 mydf@zeroverse.bit
      4 love is love@kaffie.bit
      4 iforgotmyusernam@zeroverse.bit
      4 anoni2p@zeroverse.bit
      3 zeroday@zeroverse.bit
      3 yinyue@zeroverse.bit
      3 waterfire@kaffie.bit
      3 wanditoast@kaffie.bit
      3 user0@kaffie.bit
      3 tomato@zeroverse.bit
      3 skwerlman@kaffie.bit
      3 secc@zeroverse.bit
      3 rJZLkfoUeskWN@ifs.anonymous
      3 repository@kaffie.bit
      3 Q5eqdoI7jBend@ifs.anonymous
      3 priviet@zeroverse.bit
      3 polar@kaffie.bit
      3 phantom@cryptoid.bit
      3 nofish@kaffie.bit
      3 misaka@kaffie.bit
      3 linuxguy@zeroverse.bit
      3 lily@zeroverse.bit
      3 krixano@cryptoid.bit
      3 @kaffie.bit
      3 iWsOx4FYrGECf@ifs.anonymous
      3 ivesen@kaffie.bit
      3 gt@zeroverse.bit
      3 fengyun007@kaffie.bit
      3 dfgdf@kaffie.bit
      3 comeon@kaffie.bit
      3 bSKC5cV07XI15@ifs.anonymous
      3 botkek001@zeroverse.bit
      3 a@zeroverse.bit
      3 1HNdbW1A9dgLH@kaffie.bit
      3 0penworld@zeroverse.bit
      2 zyo@kaffie.bit
      2 zenplayer@kaffie.bit
      2 Xme4c0hLbApjv@ifs.anonymous
      2 xijinping@zeroverse.bit
      2 xAPMjs9kQtoC7@ifs.anonymous
      2 waxmiguel@kaffie.bit

How many users use 10 or more zites:

$ sort /tmp/all_nicknames | uniq -c | sed 's/^ *//' | awk '{ if ($1 >= 10) print $2 }' | wc -l
716

How many users use 5 or more zites:

$ sort /tmp/all_nicknames | uniq -c | sed 's/^ *//' | awk '{ if ($1 >= 5) print $2 }' | wc -l
2482

A site owner has:

  • The private key.

  • The content she wants to sign and publish.

She calculates the public key from the private key and then calculates the hash sum of it. The hash sum is what we know as a site address, such as 1BLoGBTid3NhGu8ts3fAfHJprnbrH3wfTV.

Using the private key and the content, she calculates the sign. We can consider the sign as a cryptographic mix of the private key and the content. We can't extract the private key back from it, but, with the content provided, we can mix it futher and produce the same public key, that can be calculated from the private key itself.

So, the site owner publishes the data:

  • The site address, i.e. the hash sum of the public key.

  • The sign.

  • The content.

When a visitor gets to the site, he verifies the data provided. He applies the content to the sign and calculates the public key. Then he calculates the hash sum and compares it to the site address. If they are equal the verification is successful, and he can be sure the content belongs to the site owner. If not, either the data was corrupted during transfer, or someone tries to fool him, providing a modified, unsigned content.

              SITE OWNER                |  NETWORK  |               VISITOR
                                        |           |
          +----> public key -> hash sum --------------------------------------> should be queal
          |                             |           |                           ^
private key -+-> sign --------------------------------> public key -> hash sum -+
                 ^                      |           |   ^
content ---------+--------------------------------------+---------------------> content is verified
                                        |           |

About user verification process

- Posted in Geekless.Blog by with comments

Daniell Mesquita wrote a post at ZeroMedium: (part 2) How do I envision ZeroNet to be ready for mass of users. I posted a comment about the user ID verification system he proposed, but it turned out ZeroMedium had no support for markdown in comments, nor it allowed editing them. So I repost it here.

ZeroID should have a user verification feature, in which Nofish (verified user on Generation 1), can verify other users (they will be also Generation 1). Then when the Generation 1 users (except Nofish) verifies other users, they will be Generation 2, and following at this form.

I don't think it's an option.

  1. Any verification system is a kind of 3rd-party censorship, and ZeroNet is totally about not having any 3rd-party censorship and moderation ever possible in a forced way. It is up to the user to decide, what content she wants to see and what she doesn't.

  2. Nofish, or any other trusted user, has no actual knowledge about users he verifies. Nothing can prevent a spammer from sending humanish-looking automated verification requests and getting lots of new accounts.

  3. Speaking about it, a manual verification system cannot scale and can be easily DoSed.

  4. Generation 1, 2 and so on actually look like we have first-class and second-class citizens. The system is not only unfriendly to new users, but also looks really scaring. I believe, many people will wonder: "Do you develop some kind of nazism there?"

An idea just came to my mind. I recently posted the proposal for 3-way white/gray/black-list-driven processing of user data. If it will be implemented, we can also add more ranking algorithms, not just pretty random one, I proposed there. So, we can require some proof-of-work from a gray user to recieve, store and dispatch her files.

It is calculated as p = pow(N, user_cert), with N included in the content.json - I mean, it is pow for your ID, not for your data, so you don't have to recalculate it on every message. N can be changed at any time, so you can run mining on your computer and use your ID at the same time. While you have a poor PoW, you are probably considered as a spammer by the most hosts, but getting better and better PoW allows you to become trusted enough for most of the network.

Since a pow is applied to an ID, the network can require a costly enough pow, without being to laggy for an end user. (If you ever try sending a large message via BitMessage - it takes veeeery looooong time, since pow is calculated for all the data). If you're a real user, you can even pay some money to a mining farm to get nice pow. And if you're a spammer, you just have no profit, paying for each new short-living ID. Probably, hosts can guess the optimal pow limit, based on typical pow values of whitelisted users and adjust it dinamically.

В ходе дискуссии с @leftside родилась идея: основанный на криптографии контроль доступа к постам блога.

Если у меня будет время, попытаюсь реализовать в ZeroBlog++.


Как это выглядит для пользователя:

При редактировании поста автор блога может указать его видимость: публичная или ограниченная.

Если он выбрал ограниченную видимость, он может указать список user ID-ов, которые могут видеть пост. Если он никого не указал, пост видит только он сам.

Обойти эти права доступа невозможно: посты с ограниченной вимостью зашифрованы.

Под капотом:

Куча криптографии, которую мне лень описывать. Самое важное, что для пользователя всё это будет не видно, пользователь не обязан ичего знать о криптографии.

Отдельные проблемы, которые могут потребовать больше времени, чем само шифрование постов:

  • Изображения и другие аттачи к посту также необходимо шифровать.

  • Для удобства потребуется интерфейс управления группами пользователей.

  • Комментарии к шифрованным постам должны быть либо запрещены (плохо), либо также быть шифрованы (требуется реализация шифрованного чата).

(English)

A new idea: access control for blog posts

During the discussion with @leftside, an idea came to my mind: cryptography-based access control for posts in a blog.

I'll try to implement it in ZeroBlog++, if I have enough time.

How it looks to the user:

When editing a post, the blog's author can choose the post's visibility: public or restricted.

If she choose the restricted one, she is able to specify user IDs, who are able to see the post. If she didn't specify any user IDs, it is only her who is able to see the post.

It is not possible to bypass the access control, since the restricted posts are encrypted.

Under the hood:

There are lots of cryptography there, and I'm too lazy to explain it here in details. The most important thing is that it adds no complication to the user experience, the user don't have to know anything about cryptography.

Some problems, that can take more time than the implementation of the feature itself:

  • Images ang other attaches should be encrypted as well.

  • The UI to control user groups is required for better experience.

  • Comments for restricted posts should be either disabled (bad thing!) or encrypted as well (a lot of work to implement a fully-functional encrypted chat).

Только что в блоге @nofish появился анонс свежих изменений:

Shared tracker list between users:

New tracker IPs automatically discovered from other users to reduce centralization and avoid the blocking of the trackers.

To start new tracker: Enable the Bootstrapper plugin with opened port, then it will automatically share your client's ip with other users as a possible tracker. (It's only recommended to do this if you have static ip and planning to keep your client running 24/7)

Only the working trackers (successful result in past hour) are shared with other peers and the discovery request done in every 5 minutes until your client found 5 working shared trackers. This feature is also got limited to zero:// trackers only as it more suited for ZeroNet, because it allows multiple sites announce in same request and the storage of .onion addresses.

Итак, теперь узлы сети могут сами находить новые трекеры — пока только трекеры с публичным IP, но я думаю, что доработка для трекеров на onion-адресах будет не сложной. ZeroNet становится всё более отказоустойчивой и независимой.

В самом начале своего существования сеть работала через torrent-трекеры и была полностью зависима от них. Потом появились собственные zero-трекеры, способные работать как через IP, так и через Tor. Также появился собственный механизм обмена пирами.

В прошлом месяце в ZeroNet была добавлена возможность вручную добавлять пиры для зайтов.

И вот теперь пиры могут обмениваться также и списками трекеров.

Это означает, что теперь бутстрап-узлом при запуске нового узла может быть абсолютно любой узел сети. Достаточно указать известный узел в качестве пира, и затем ZeroNet найдёт с его помощью доступные трекеры и выйдет на полностью рабочий режим.

Ранее я уже писал о проблеме малого количестве трекеров в ZeroNet. К сожалению, при работе в режиме Tor: Always проблема усугубляется.


Вот список трекеров, используемых сетью по умолчанию в настоящий момент:

        trackers = [
            "zero://boot3rdez4rzn36x.onion:15441",
            "zero://zero.booth.moe#f36ca555bee6ba216b14d10f38c16f7769ff064e0e37d887603548cc2e64191d:443",  # US/NY
            "udp://tracker.coppersurfer.tk:6969",  # DE
            "udp://tracker.leechers-paradise.org:6969",  # NL
            "udp://104.238.198.186:8000",  # US/LA
            "http://tracker.skyts.cn:6969/announce",  # CN
            "http://open.acgnxtracker.com:80/announce",  # DE
            "http://retracker.mgts.by:80/announce"  # BY
        ]

Разберёмся, что тут к чему.

  • Адреса, начинающиеся на udp:// — это BitTorrent-трекеры, работающие по UDP. При работе через Tor они недоступны. Совсем.
  • Адреса, начинающиеся на http:// — это BitTorrent-трекеры, работающие по HTTP. Мы можем получить от них адреса пиров в клирнете, но не можем через них анонсировать onion-адреса. BitTorrent-трекер увидит и запомнит лишь IP-адрес exit-ноды Tor-а, который для входящих подключений бесполезен. Трекер ничего не знает про Tor.
  • Адреса, начинающиеся на zero:// — это собственные трекеры ZeroNet, работающие по внутрисетевому протоколу. Трекеры ZeroNet умеют работать как с IP-адресами, так и с onion-адресами пиров.

Как видим, собственных трекеров сети всего два. Один из них расположен в клирнете, а другой — в Tor.

Именно на этих двух трекерах и держится связность сети в режиме Tor: Always. Отключение этих узлов приведёт к невозможности пользоваться сетью в анонимном режиме.

Пока сохраняются BitTorrent-трекеры, и есть узлы сети на IP-адресах, к которым мы можем открыть входящие соединения, проблема может быть не критичной, тем не менее, это принципиальная проблема. Если завтра все участники сети решат пользоваться сетью без разглашения своих IP, то именно эти два узла станут самой уязвимой точкой отказа.

Как решать эту проблему? В три этапа:

  1. Поднимать новые ZeroNet-трекеры на своих компьютерах.
  2. Публиковать их onion-адреса и призывать других участников сети пользоваться ими, рассказывая, почему и зачем это нужно.
  3. Разрабатывать и внедрять в движок ZN новые механизмы анаонсирования узлов, такие как DHT или автоматический внутрисетевой поиск трекеров.

Что касается пункта 1, внутрисетевой трекер реализуется плагином Bootstrapper, поставляющимся с ZeroNet. Плагин по умолчанию отключен, и документации на него никакой нет; вся документация — только его исходники. Насколько я понимаю, два трекера из списка выше работают именно через этот плагин. Сам я еще не разбирался с тем, как там что.

Если я правильно понимаю, достаточно запустить ноду ZeroNet с включенным плагином, чтобы она слушала порт на локальном интерфейсе, и затем средствами Tor поднять hidden service с фиксированным адресом, который будет проксировать входящие подключения на порт ZeroNet. Но это пока теоретические соображения.

В скрипт docker-zeronet добавил опцию -T, обеспечивающую подключение списка трекеров из репозитория github.com/ngosang/trackerslist.

В одном из компьютеров разбивал диск на разделы еще под grub 1-й версии, который не умел работать с LVM. Из-за этого /boot всех линуксов пришлось вынести на отдельный раздел вне LVM. Получился такой усложненный конфиг:

    sda1 — boot <- тут grub, который грузится через бутсектор
    sda2 — linuxboot <- тут ядра линукса
    sda3 — LVM:
        archlinux
        voidlinux
        debian

Монтировался /boot в каждой системе примерно так:

/dev/disk/by-label/linuxboot      /mountpoints/linuxboot       ext4         defaults,noatime                 0      1
/mountpoints/linuxboot/voidlinux  /boot                        none         defaults,bind                    0      0

Давно мигрировал на grub2, но сейчас наконец-то дошли руки переделать загрузку.


Вернул ядро системы на корневой раздел:

mount -o bind / /tmp/tmp_root/
rsync -aHAX /boot/ /tmp/tmp_root/boot/
umount /boot/

Перегенерировал grub для корня:

grub-install -v --no-bootsector --target i386-pc /dev/mapper/sm-sm_voidlinux
  • --no-bootsector — чтобы grub не пытался свой бутсектор никуда установить. Он не BIOS-ом у нас будет грузиться.
  • --target i386-pc — просто на всякий случай, чтобы с UEFI не попутал.
  • /dev/mapper/sm-sm_voidlinux — самое главное. Grub должен увидеть, что он на LVM, и сгенерировать core.img, пригодный для старта с LVM.

Теперь основная магия. Открываем конфиг того grub, который у нас живёт на загрузочном разделе и пишем:

insmod lvm

menuentry "Voidlinux" {
    multiboot (lvm/sm-sm_voidlinux)/boot/grub/i386-pc/core.img
}

Получается следующая последовательность загрузки: * BIOS грузит бутсектор. * Бутсектор грузит grub с sda1. * Grub читает конфиг и показывает меню. * Когда мы выбираем пункт Voidlinux, grub по протоколу multiboot грузит другой grub из образа core.img. * Этот второй grub показывает нам меню, сгенерированное конкретной операционной системой. (Разные ядра, загрузка в fallback-режиме и т.п.)

Так можно установить и грузить любое количество Linux-ов внутри LVM без плясок с бубном.

Три месяца назад я писал про покупку б/у Irbis NB31. Что касается попытки запустить на нём Linux, об этом я напишу пост чуть позже. (Забегая вперёд: в целом всё работает.) А сейчас немного на другую тему.


Скорость работы встроенного SSD и microSD-контроллера

Результаты теста встроенного накопителя на 32ГБ:

Irbis-nb32-internal-storage.png (402x367)

На мой взгляд, хороший результат для бюджетного китайца. В том, что касается производительности, Windows 10 работает на этом устройстве безупречно.

Поскольку Windows занимает почти весь накопитель, для пользовательских данных была установлена microSD карта. Мы с женой долго читали отзывы, которые не отличаются разнообразием: "перестала определяться", "сдохла через 3 месяца", "перешла в режим только-чтение на 2-й день и сдана по гарантии" и т.п. В итоге купили карточку Samsung Evo Plus на 32 ГБ за 1300 рублей, которая по отзывам точно такое же говно, как и её конкуренты, но стоила на 100 р. дешевле и была в наличии в ближайшем магазине. Я в первый раз услышал, что под брендом Samsung у нас продают SD-карты. Производитель обещает 95 MB/s на чтении и 20 MB/s на записи, но это в идеальных сферических условиях при наличии высокоскоростного контроллера. В нашем случае всё упирается как раз в производительность контроллера:

Samsung-Evo-Plus.png (402x367)

При неупорядоченном доступе показатели хорошие — показывают, что накопитель еще может раскрыть свой потенциал в другой железке.

Флешки

Согласно наклейке на корпусе нетбука, у нас имеется 2 порта USB 2.0. Никакого вам 3.0. Так что на скоростных флешках мы упираемся в производительность контроллера, а не накопителя. Тем не менее, даже достаточно дорогие флешки не умеют быстро писать данные при неупорядоченном доступе, и в этом случае производительность больше зависит от конкретной флешки, чем от версии USB.

Когда я экспериментировал с запуском Linux, мы как раз были за городом, так что купить скоростную флешку возможности не было. У жены была флешка, на которой не хранилось ничего важного, и я отформатировал её в GPT, разбил на FAT32 + ext4, как требуется для загрузки с UEFI, и засунул туда Void Linux. Это была ADATA UV100 на 16 ГБ. Дешевая флешка в ненадежном пластиковом корпусе, которая постоянно греется при работе. Вот результаты теста производительности (на скриншоте виден малый объем накопителя, это как раз раздел FAT32) :

ADATA-UV100.png (402x367)

Её производительности хватает, чтобы вполне бодро загружать систему и запускать приложения. В очередной раз это доказывает, что Linux способен работать с любого утюга, если там в принципе есть процессор, память и доступ в сеть. Но как только в кэше скапливается достаточно много dirty страниц, и система пытается сбросить их на устройство, случается глобальный фриз всех приложений. Здесь особенности крайне медленной неупорядоченной записи у дешевой флеш-памяти выходят на передний план, и из софта с ними ничего не сделать. Такой глобальный лаг обычно длится от 10 секунд до 2-3 минут, впрочем, если у вас много ОЗУ и либеральные настройки vm.dirty_bytes, вы можете столкнуться с ситуацией, когда ядро внезапно решит выгрузить на диск 3-4 гигабайта, и время IO будет измеряться уже десятками или сотнями минут. У меня эти параметры были уже подкручены, так что система в целом сохраняла управляемость. Тем не менее, операции установки пакетов идут очень долго; а бразеры с настройками по умолчанию работают с длительными лагами, поскольку рассчитывают на достаточно быстрый кэш на диске, а вместо быстрого кэша получают постоянный D-state.

Также у меня была купленная по случаю Kingston DataTraveler SE9 G2 на 32 ГБ. Как-то раз мне срочно нужна была флешка, и по пути, увидев в магазине флешку в стильном цельнометаллическом корпусе от известного производителя, я просто купил её без раздумий и чтений обзоров. Обошлась она мне что-то около 1300 р., точно уже не помню.

Эта флешка отлично справляется с хранением фотографий и документов, но тестирование в CrystalDiskMark ставит крест на идее использовать её в качестве системной. Как видно, при неупорядоченной записи этот Kingston ничем не отличается от любого no name:

Kingston-dtse9-g2.png (402x367)

Точно такие же значения 0.00x показывают любые дешевые флешки, независимо от бренда, или же продающиеся вовсе без всякого бренда.

Так что при возвращении в город мы решили купить действительно быструю флешку из бюджетных, если такие существуют. Покупать что-то ультимативное типа Sandisk Extreme задачи не было. К тому же, хотелось купить достаточно компактное устройство, чтобы можно было с него загружаться, и при этом из компьютера не торчала 7-сантиметровая шишка.

Я долго гуглил и читал обзоры. В итоге решил брать что-нибудь из линейки Sandisk Ultra, но не был уверен, есть ли между флешками линейки какая-то разница, кроме дизайна корпуса. Потом наткнулся на очень информативный сайт usb.userbenchmark.com. Если там вбить в поиске 16GB (ну или 32GB), а потом отсортировать результаты по колонке Peak 4k-W, то получает интересная картина.

Первым идёт давно снятый с производства в этом объёме, но оставшийся непобеждённым Kingston DT Ultimate 16GB — живое доказательство того, что для быстрой флешки не требуется USB 3.0. Заслуженное второе место занимает SanDisk Extreme USB 3.0 16GB. Потом чего-то непонятное с неизвестными мне названиями, и наконец на 6-й позиции — SanDisk Ultra Flair USB 3.0 16GB. Прочие представители линейки Ultra почему-то отстали — значит, всё же отличаются не только дизайном, но и внутренностями.

Этот SanDisk Ultra Flair USB 3.0 16GB был в наличии в том самом «ближайшем магазине», в котором покупалась карточка Samsung, и стоил 800 рублей, поэтому и был куплен по дороге домой. Вот результаты тестов:

Sandisk-Ultra-Flair.png (402x367)

На всякий случай переставил флешку в другой порт USB и протестировал повторно:

Sandisk-Ultra-Flair-t2.png (402x367)

К сожалению, слабое железо с USB 2.0 не даёт возможности полностью раскрыться этой флешке.

Внешне SanDisk Ultra Flair и Kingston DataTraveler SE9 G2 очень похожи — одинаково узкий металлический корпус, схожая длина. Неизвестно, кто у кого спёр дизайн, однако начинка этих устройств отличается кардинально. В версии на 32 ГБ Ultra Flair на данный момент стоит 1350 рублей, примерно за эти деньги я брал и DataTraveler. Если бы я видел результаты тестов на момент покупки, я бы, разумеется, предпочел Ultra Flair.

Стоит еще добавить, что из всех перечисленных устройств, Ultra Flair единственный оставался в тесте чуть теплым. Не знаю, сохранится ли это при реальной эксплуатации, поскольку в отзывах упоминали достаточно высокую температуру. Остальные же флешки ощутимо разогреваются и на тесте, и в эксплуатации.

Когда я писал этот обзор, чисто ради интереса решил протестировать лежащий дома Smartbuy на 32 ГБ неустановленной модели, купленный, предположительно, в прошлом году. Не смотря на в целом провальные результаты последовательной записи, скорость неупорядоченной записи оказалась не совсем мёртвой:

Smartbuy.png (402x367)

Эх, если бы такие 0.2 МБ/с выдал DataTraveler, чтобы хоть символические показать своё превосходство над китайским ноунеймом из ларька. Но увы.

usb-sticks.jpg (438x254)

Теперь осталось перенести Linux на SanDisk Ultra Flair и протестировать накопитель в боевых условиях.