• Киллер фича Vim
    –1
    Про блокнот, видно что 3 страницы текста по ссылке вы осилить не способны, чтобы дочитать до понятия квазирежимов, например, позволяющих сохранять файлы через Ctrl+S, которое есть хоть в блокноте, хоть в саблайме, а в куче редакторов вообще автосохранение.
    Автосохранение с автопридумываением имена файла, я так понял? Речь идёт о том, что выполняя определённое действие вы попадает в другое окно, в котором у вас другой мир и старые команды не работают. Работает только… барабанная дробь клавиша ESC. А иногда, кстати, и она не работает.

    Так чем эти режимы (коих десятки в так восхваляемом вами Sublime) лучше того, что в VIM'е? Тем что там нет отдельного режима редактирования и ввобда текста? Но есть отдельные режимы (без всяких «квази», я статью прочитал, не беспокойтесь) для ввода имени нового класса, строки для поиска и прочих интересных вещей? Чем режим поиска текста в Sublime лучше командного режима в VIM'е? Тем что Sublime вам нравится, а VIM — нет?
  • Киллер фича Vim
    +1
    Как это может быть удобно — непонятно.
    Тут вопрос не «как», а «кому». Тому, кто не путает вторую и четвёртые передачи, однако.

    А профессионалов (причём не только у автогонщиков, но и у дальнобоев, коих несравнимо больше) этих передач может быть и два десятка, представляете?

    Это не в упрёк вам — просто люди разные, кто-то в четырёх-пяти передачах путается, а кто-то и в 4-5 режимах VIM'а чувствует себя как «рыба в воде».
  • Киллер фича Vim
    0
    Ну люди же работаю как-то на Mac'е где нужно помнить в какой программе это Ctrl-C/V, а в какой — Command-C/V и ничего.

    Наоборот, когда шорткаты отличаются настолько сильно это вызывает меньше когнитивного диссонанса, чем когда отличие минимально — но таки есть…
  • Киллер фича Vim
    0
    Ничего не понял. Мы вроде о текстовом режиме говорим — какой-такой «буффер обмена вне редактора» вы нашли в этом режиме???
  • C++17
    0
    Ого. Не ожидал. Clang тоже сьедает, кстати — но по крайней мере warning'и выдаёт.

    Это GNU'сное расширение, которое в стандарт C99 (а теперь и C++20) решили не вносить. Было принято решение использовать другой синтаксис, никакого отношения к JavaScript'у не имеющий.

    То есть в GCC реализовали инициализаторы с одной стороны криво и не полностью, а с другой — со своими собственными расширениями.

    Прэлестно, просто прэлестно.
  • C++17
    0
    Я могу предположить, что это самодеятельность разработчиков компилятора, но как минимум gcc 6 съедает такой код и не давится.
    Прекрасно. В таком случае дать ссылку на https://godbolt.org/ вас, разумеется не затруднит. Дополните ваш пример до компилируемого кода — и можно будет что-то обсуждать.
  • Киллер фича Vim
    0
    все равно размер и ограниченность в сроках не позволяет сначала досконально понять приложение, а уже только потом что-то в нем дорабатывать.
    А не является ли это типичным случаем феномена «мне некогда точить топор, мне надо рубить лес»?

    Если у вас нет хорошего представления о том что это за код и что он делает — то вы точно уверены, что его «дорабатывания» пойдут проекту на пользу?
  • Киллер фича Vim
    0
    Это уже детали реализации. TUI тоже может запускать фоновые процессы, общаться с демонами и прочая, прочая, прочая. В конце-концов Vi, как бы, родился во вполне себе многозадачной системе.

    А вот то, что это свойство в GUI реализовано намерено — тут вы правы на 100%. При работе с многими программами в этом даже есть какой-то смысл — действительно, не должна же моя среда тормозить из-за того, что в каком-то там браузере в фоне дизайнер навороты, грузящие одно из ядер на 100%, сделал… но почему эта беда должна наблюдаться в рамках одного процесса — мне решительно непонятно.
  • C++17
    0
    В конце концов, constexpr не гарантирует выполнения на этапе компиляции.
    В случае с описанием переменной (а также использования в качестве параметра типа, размера массива и в других местах) — гарантирует.

    Не могли бы вы объяснить по-подробнее? Почему прям нельзя?
    Потому что описать constexpr-функцию без тела — нельзя, а без constexpr-можно.

    Но реально, конечно, это всё поблажки разработчикам компиляторов: constexpr-функции ведь приходится интерпретировать — а для этого, фактически, отдельный транслятор нужен… Вот и ограничивают их. Вначале ограничения были совсем драконовскими, но сейчас потихоньку гайки отпускают.
  • C++17
    +1
    Это не валидный код в C++. Это всго лишь пропозал для C++20, причём в том виде, как вы его описали — это всё равно ошибка.

    И да — это весьма полезная фича, благо она есть в C99, активно используется во многих проектах, а в режиме C++ поддерживается, например, clang'ом.
  • C++17
    +1
    А можно познакомиться со списком удалённого?
    Приложение С в стандарте этому посвящено.

    PS по Вашим словам, похоже практики настолько мало знакомы с нововведениями, что не успевают даже заметить и прочувствовать, что что-то добавили и удалили.
    Не совсем так. В C++11 удалили какие-то фичи, которые были обьявлены как «устаревшие» в C++03, в C++17 — то, что было обьявлено устаревшим в C++11.

    export template удалили, который ни одним компилятором не поддерживался (хотя вру — вроде один экспериментальный всё же был).
  • C++17
    +1
    Если компилятор не сможет сделать constexpr, он об этом сообщит.
    К сожалению всё не так. Это происходит в любом случае в месте подстановки. Посмотрите сами — вызов printf не машает функции отрабатывать в компайл-тайме. Если он не триггерится, конечно.

    Ну так и нафига козе баян — в смысле нафига явно тут указывать, что функция constexpr? Если возможность её использовать всё равно зависит от конкретного значения?

    P.S. Кстати за счёт constexpr любой коспилятор C++ — теперь где-то ещё и инетерпретатор. clang отрабатывает раз в 8 быстрее, чем gcc…
  • C++17
    +1
    Вполне можно было вообще все функции считать constexpr по-умолчанию
    Нельзя. По историческим причинам. Функции не описанные как constexpr компилятор, в большинстве случаев, в нужном контексте просто не видит (раздельная компиляция, всё такое). Так что constexpr таки нужен.

    Но можно было бы всё inline-функции сделать constexpr — это правда…
  • C++17
    +4
    Вообще-то образцов послужил C++98, в котором это было разрешено делать в цикле for.

    Когда эта фича в C++ появилась — ни rust'а, ни go даже в проекте не было.
  • C++17
    +3
    В случае с C++ всё просто: ничего никуда не конвертируется. В стандарте просто сказано: An identifier is an arbitrarily long sequence of letters and digits. Each universal-character-name in an identifier shall designate a character whose encoding in ISO 10646 falls into one of the ranges specified in E.1.

    И компиляторы, хотя и не все, давно позволяют называет идентификаторы по русски. Это вопрос к программистам, а не к стандарту сегодня, на самом деле.
  • C++17
    +3
    почему бы в C++ не принять эту фичу
    А это от программистов зависит, компиляторы её ужа давно поддерживают.
  • Киллер фича Vim
    +1
    Забавно, что на самом-то деле это разница между TUI и GUI.

    То есть когда я работал в каким-нибудь седом Turbo Pascal'е, то для меня не предоставляло проблемы нажать «не глядя» что-нибудь типа "<Ctrl+F7> x <Ctrl+F7> y <Ctrl+F8> <Ctrl+F9>" — всё это «не глядя», после чего я мог повернуться и что-то написать на листочке, пока комп всё это будет проделывать (у нас жётских дисков в компьютерном классе не было, а при работе с дискетки одно окно могло окрываться секунд 5). И это не вызывало ощущения «ужасающих тормозов»: думаю-то я всё равно не так быстро, так что после того, как я подал пару десятков команд могу и подумать над чем-нибудь ещё.

    А вот в Clion гораздо меньшие тормоза — раздражают ужасно. Потому что я не могу «забросить» кучку команд и глотнуть кофе. Я должен за этим монстром приcматривать… и подавать команды когда он будет готов. Возникает вопрос: кто для кого работает — я для компьютера или компьютер для меня?

    На машинке за $10'000 примерно, впрочем, тормозов почти нет и можно работать почти как в Turbo Pascal'е… потому что CLion успевает отреагировать на всё между двумя нажатиями клавиш… но есть ощущение какой-то неадкватности: неужели же вся эта моща нужна только, чтобы компенсировать тот факт, что мы используем GUI?

    Обидно как-то…
  • Киллер фича Vim
    0
    Это такой способ «застыдить»? Я вот не скажу — умею ли я печатать, не глядя на клавитуру, но таки тот факт, что на клавиатуре, на которой я набираю это сообщение нет русских букв меня не напрягает… И нет — раскладка у меня не ЯВЕРТЫ…
  • Киллер фича Vim
    0
    либо пишу, либо зажимаю особенную кнопку, чтобы выполнять особенные действия.
    Я так понимаю, что позиция сторонников VIM'а заключается в том, что «особенные действия» — это как раз «тупой» ввод текста! То есть большую часть времени вы делаете что-то другое: вставляете управляющие конструкции, двигаете что-то куда-то и так далее. И вот только тогда, когда всей мощи редактора не хватает — вы опускаетесь «на уровень машинных кодов»… и просто «вбиваете» текст!
  • Киллер фича Vim
    +6
    Проблема не в использовании мыши. Проблема в подходе.

    Вы не поверите В СКОЛЬКИХ местах IDE глотают нажатия клавиш, если кто-то набирает быстро и не глядя на экран. В VIM вы можете быть уверены, что набрав 100 команд не глядя на экран вы увидите то, на что рассчитывали. IDE (за исключением текстовых) в одном случае из 100 будет что-то глотать. Вроде бы немного, но это значит что ваши действия нужно контролировать после каждой команды. Иначе рано или поздно вы пропустите момент, когда какое-то окно не успело открыться (или закрыться), после чего уже все последующие команды пойдут «мимо контекста».

    В том-то и дело, что на самом деле режимов у IDE в 100 раз больше, чем у VIM'а (окно редактирования свойств класса — один режим, окно открытия файла — другой, окно заливки в VCS — третий и так далее… сотни их… если не тысячи...).

    Так что разница принципиальна: в IDE вы работаете с компьютером в режиме диалога, в VIM это «я сказал, компьютер сделал».
  • Такты для разработчиков
    0
    Тут явно идёт речь не про векторизацию шага внутри раунда, а про попытку раскидать сами шаги между потоками.
    Нет, тут говорится о том, что каждый раунд AES состоит из подшагов (InvShiftRows, InvSubBytes и так далее). Если в каждом такте делать только один подшаг — то количество исполнительных блоков и потребных тактов станет больше, но зато каждый такт станет меньше. Привет Pentium4, короче…
  • Root хуже Михалкова
    0
    Когда выяснилось, что слишком много всего возложено на root, то его начали «пилить».

    В результате сейчас может быть как обычный пользователь, умеющий «кое-что из того, что обычно делал root», так и root'а можно ограничить (многими способами) так, что от его «суперсилы» останутся «рожки да ножки».

    SElinux, capabilties, контейнеры и прочее.
  • Джозеф «Лик» Ликлайдер: «Симбиоз человека и компьютера» (1960), часть 1
    +1
    Тут надо, как бы, не забывать, что мы обсуждаем статью 2006 года.

    К сожалению, Энгельбарт умер в 2013.
    В 2006м он ещё был жив.

    Таким образом, как понять фразу «Энгельбарт и прочие пионеры компьютерной эры заявляют, что «информационная революция еще не началась»»?
    Ровно так, как написано: сейчас, в 2006м году, «Энгельбарт и прочие пионеры компьютерной эры заявляют, что «информационная революция еще не началась»».

    Сейчас, в 2017, революция уже началась?
    Похоже, что всё ещё нет. Если вы посмотрите на, собственно, демку, то вы увидите, что там была продемонстрирована единая среда. Где нет отдельной программы, которая позволяет вам рассчитывать платежи за кредит и другой, также отдельной, программы, которая позволяет рисовать картинки.

    В 2006м году казалось, что web — близок к тому, чтобы реализовать эту парадигму… но за прошедшие 10 лет скорее произошел откат назад: отдельные web-приложение сейчас не проще заставить работать совместно, чем 20 лет назад Window-приложения или 40 лет назад — текстовые на мэйнфреймах.

    Почему-то всё развитие компьютерых технологий — это такие качели: мы пытаемся воспроизвести парадигму oN-Line System, доходим до некоторого уровня… а потом — получаем откат. И мы снова пытаемся взобраться на эту гору — но уже с другими технологиями.

    «Перламутровые пуговицы» — мы делать умеем, а вот костюм сшить — всё никак не получается… Весь пар уходит в свисток…
  • Root хуже Михалкова
    –1
    Это единственный и основной признак классификации рамдиска.
    Тогда у вас в каждом процессе свой, индувидуальный ramdisk благодаря fmemopen. И procfs/sysfs у вас тогда — тоже RAMdisk'и.

    ramfs/tmpfs поддерживают POSIX, этого уже достаточно.
    О как? То есть у вас в Windows теперь вообще RAMdisk'ов нет — пока вы Ubuntu не поставите?

    Обратите внимание, что tmpfs только в заголовке соотвествующей статьи — в теле фигурируют NTFS, HFS, /dev/ram — но никак не tmpfs.

    Знаете почему? Потому что ссылка на tmpfs оттуда была удалёна — с комментарием tmpfs isn't a RAM drive, it's a file system that lives in virtual memory, as the hatnote indicates — it doesn't dedicate a chunk of memory for use as a fake disk partition.

    RAMdisk — это RAM + disk. И оба компонента должны присутствовать.
  • Джозеф «Лик» Ликлайдер: «Симбиоз человека и компьютера» (1960), часть 1
    +1
    Оценка, в общем-то, была дана:
    Джозеф «Lick» Ликлайдер «придумал» компьютерную эру
    Кульминацией явилась The Mother of All Demos. 1968й год. Подавляющее большинство читателей и писателей Хабра ещё не родились. UNIX в зародыше, Mac появится через полтора десятилетия, до изобретения web'а — 20 с лишним лет, до появления Skype — 35, Writely — 38.

    Демонстрация oN-Line System включала прототипы этого всего: оконный интерфейс, гипертекст, видеоконференция и совместное редактирование документов — всё это там было. Фактически после этого «циркового акта» последующие несколько десятилейтий компьютерная индустрия провела в попытках повторить это всё — но так, чтобы рабочее место не обходилось в десятки тысяч долларов в час…
  • WhatsApp, что внутри?
    0
    История по-умолчанию на Google Drive же складывается, разве нет? Это вам не LINE, где о такой возможности узнаёшь уже когда всё потеряно…
  • Root хуже Михалкова
    0
    Если же брать ваше — то в каждом конкретном случае использовать диск? почему? какой? зачем нам просто невнятное «блочное устройство»?
    Потому что «над ним» мы можем развести ту файловую систему, какая нам нужна. В Windows 2000, к примеру, не было символических ссылок, а в Windows 7 — они есть. На работу RAMdisk'а всё это не влияет никак.

    Можно snapshot'ы снимать через LVM и так далее. Весь арсенал средств, работающих с блочными устройствами — к вашим услугам.

    Всю терминологию стоит использовать с оговорками, поскольку четкое определение редко когда может охватить ВСЕ существующие реализации в силу устаревания.
    Это правда, конечно, но в данном случае польза от использования терминологии понятна, а вред — сомнителен. В то же время исскусственное помещение tmpfs в раздел дисков (пусть и виртуальных) немедленно поднимает вопрос о применимости подобной конструкции…
  • Root хуже Михалкова
    0
    Рамдиск по определению не должен хранить данные при перегрузке.
    Может и хранить. Я сам лично видел RAMdisk, который таки хранил данные при перезагрузке — так как у машинки батарейка на модуле памяти была и память при перезагрузке не очищалась.

    То есть вы докапываетесь до мелочей, а не до сути.
    А какова сущность диска в вашем случае? Чем отличаеться файловая система от диска и каковы их свойства?

    В моём мире — всё просто: диск — есть диск, он может быть гибким, оптическим и даже виртуальным, но это — блочное устройство, обращение к данным на нём происходит на уровне секторов.

    А файловая система — это более высокоуровневое понятие, тут секторов уже нет, есть файлы. Она может быть дисковой, сетевой и виртуальной. В частности tmpfs — виртуальная файловая система для хранение временных данных.

    А вашем мире что такое диск? Что такое RAMdisk? И что такое, наконец, файловая система? Почему вдруг у вас файловая система стала диском?

    Только не надо говорить что «RAMdisk — это такая хрень», а «файловая система — это такая шняга», пожалуйста… потому что неясно как вы собираетесь что-то вообще обсуждать не имея определений, а имея только «суть, которую не выразить словами».
  • Root хуже Михалкова
    0
    А кто вам сказал, что файловая система обязана размещаться на диске? Есть сетевые файловые системы — у них диск размещается бог знает где (и его может не быть вообще), есть виртуальные файловые системы.

    Это не я выдумываю — это вот прямо на страничке с описанием того, что такое файловая система написано: Some file systems are used on local data storage devices; others provide file access via a network protocol (for example, NFS, SMB, or 9P clients). Some file systems are «virtual», meaning that the supplied «files» (called virtual files) are computed on request (e.g. procfs) or are merely a mapping into a different file system used as a backing store.
  • Root хуже Михалкова
    0
    Почему каждый диск обязан быть блочным устройством?
    Потому что, чёрт побери, это определение дискового устройства.

    Почему вы считаете, что tmpfs нельзя замаунтить?
    Её можно замаунтить. И размаунтить тоже можно. Вот только после того, как вы её размаунтите все данные будут потеряны. Именно потому что диска под ней нету!

    dd — просто работает со всеми блочными устройствами, а не избирательно только с дисками.
    Она ещё и с символьными устройствами работает. Но если устройства нет (никакого — ни символьного, ни блочного), то она не работает. А раз нет устройства — то нет и RAM disk'а! Так вот в tmpfs — RAM есть, а диска — нет.

    Но это не означает, что они перестают относиться к рамдискам.
    Означает. В описании tmpfs очень чётко написано: A similar construction is a RAM disk, which appears as a virtual disk drive and hosts a disk file system.

    Simular — это не more general, это different.

    А не создают виртуальное блочное устройство для работы с dd.
    Раз они не создают устройства для работы с dd — то это не диск.

    Иначе что у вас тогда такое «диск» и чем оно от файловой системы отличается?

    Та же история, что и с сетевыми технологиями: NBD — диск, NFS — не диск.

    Они на разных уровнях абстракции работают…
  • Root хуже Михалкова
    0
    Именно в этом и суть рамдиска — использовать виртуальный диск в памяти вместо внешнего диска.
    И именно этого не происходит при использовании tmpfs. Там нет диска. Никакого. Ни физического, ни виртуального. Это файловая система, работающая без диска.
  • Root хуже Михалкова
    0
    Другими словами, под ramdisk называется диск, который эмулируется софтом в оперативной памяти компьютера.
    Диск. Блочное устройство. На котором «сверху» надстраивается файловая система. Которое можно отмонтировать и перелить (посекторно перелить!) на другое устройство.

    Ничего этого сделать с tmpfs — нельзя. Там дальше в описании RAM disk'а упоминается /dev/ram on Linux, md(4)[8] on FreeBSD, но не tmpfs — как вы думаете, почему? Да, чёрт побери, потому что в tmpfs нет диска! Это, чёрт побери, файловая система, а не блочное устройство! Одна вообще в другом ряду стоит.

    Бывают диски: гибкий, жёсткий, твёрдый, и да, ещё и RAM disk.

    А бывают — файловые система: FAT, NTFS, ext4 или, вот ещё, tmpfs. Это — не диски, это, чёрт побери, файловые системы — как и следует из названия!

    Если же вы интерпретируете текст иначе, мы можем спорить вечно.
    Ну не понимаю я о чём тут спорить! Для любого диска (в том числе для RAM disk'а — такого как /dev/ram5) я могу сделать umount, dd (в диск или в файл) — а потом, на другой машине, соответственно,dd и mount. Если, как вы утверждаете, tmpfs — это таки диск, то для неё это должно быть возможно тоже.

    Ну и? Как мне это сделать? Не подскажете?
  • Root хуже Михалкова
    0
    Так что разницы в этом плане нет никакой.
    Разница принципиальна. У вас либо есть secondary storage, либо его нет. Например если мы взяли и отобразили файл в память — скольку у нас будет копий данных? В случае с дисковой файловой системой, в том числе с файловой системой, размещённой на диске в памяти ответ — таких копий будет две: одна — где-то в недрах page cache, другая — на, собственно, блочном устройстве. Что выглядит несколько глупо (для тех целей, для которых обычно применяется tmpfs), но иногда может иметь смысл. Так как вы, немного поработав с этим устройством, сможете его размонтировать и залить «как есть» на флешку. Или переслать на другуй компьютер. Да мало ли что может захотеться сделать с диском!

    А в tmpfs никакого диска нет. Ну вот совсем нет — и всё. Cо всеми вытекающими.

    P.S. Классический ramdisk в Linux, разумеется, тоже есть. Просто он редко испоьзуется. Но бывает и такое. Скажем если вы хотите создать образ дискеты или ещё что-нибудь подобное. Но это редко случается. В большинстве случаев достаточно tmpfs.
  • На шаг ближе к С++20. Итоги встречи в Торонто
    0
    В целом то что вы написали — это примерно то же что и я пытаюсь сказать: «что вся переносимость новшеств должна достигаться не в ущерб производительность», т.е. переносимость тут не наивысший приоритет.
    Спорить о том что есть высший приоритет, а что низший можно до бесконечности. Важно, что пока нет быстрого и переносимого решания — фича в C++ не появляется, а переностися на следующий релиз.

    Microsoft со своими co_await/co_yield на это с размаху вьехал — потому его и послали в C++20 (и не факт что там примут — будет зависеть от того, насколько эффективной реализация на разных платформах окажется).

    вспомните например ./configure и autotools
    Вспоминаю. Как страшный сон. Слава богу поддержка «кривых» платформ, не поддерживающих стандарты, сегодня не актуальна (за исключением embedded, но и там потихоньку «дело движется»)
  • На шаг ближе к С++20. Итоги встречи в Торонто
    0
    Я боюсь вы путаете WORA и переносимость.

    Если вы не хотите вовлекать разработчика в процесс — то да, вам нужна виртуальная машина и запрет на использование API.

    Если же вы хотите вовлечь разработчика в этот процесс, то у вас появляется CHARS в Форте (а вдруг у вас память нибблами адресуется как на HP 48?) и множество «неопределённых поведений», которых программист должен избегать.

    Излишне и говорить что первый процесс порождает гораздо менее переносимые программы — если специально о переносимости не заботится, то и в Java её не будет (ваша программа может захотеть иметь два разных файла «Makefile» и «makefile» в одном каталоге и всё — прощай переносимость).
  • Root хуже Михалкова
    0
    И все.
    Не всё. Для тех, кто не понимает что обозначают слова «treating as if the memory were a disk drive» (со ссылками, объясняющими, что disk drive — это, оказывается, a block storage device) там же, ещё выше, написано чётко и отдельно: This article is about virtual drives emulated with software. For hardware storage devices using RAM, see solid-state drive. For filesystems without drive emulation, see tmpfs — чтоб уж совсем никакой путаницы не было.
  • Считаем до трёх: четыре
    0
    Результат сравнения двух чисел — это одно из трёх (а не одно из двух): больше, меньше, равно. Это один трит. И никаких «запрещённых комбинаций».
  • Скажи «нет» Electron! Пишем быстрое десктопное приложение на JavaFX
    0
    Вот прямо у них на страничке Development/Java. Она, собственно, с этого тезиса начинается. А закачивается разделом «Suggestion to Remove Java Components».

    На что меняют? На то, что и было: C/C++. Но Sun успел изрядно засрать кодовую базу компонентами на Java, работы много.
  • Скажи «нет» Electron! Пишем быстрое десктопное приложение на JavaFX
    0
    Ну дык эта: архитектурная астронавтика и C#, чего вы хотите? Как я уже сказал: Visual Studio на C++ — это история. Это из LibreOffice выпиливают Java'у (и последние версии пошустрее работают), в Visual Studio — наоборот…
  • Root хуже Михалкова
    0
    эта проблема просто не существует для устройств, у которых нет движущихся частей — то есть у которых скорость к случайным секторам такая же, как к последовательным.
    Ферритовые кольца в наше время не актуальны. И даже если использовать что-то подобное — то будут накладные расходы на поиск следующего блока. На фрагментированном диске у вас тупо будет больше экстентов и на работу с ними уйдёт больше времени.
    А это как раз флешки, ssd
    Вы сейчас серьёзно говорите, не шутите? Да посмотрите же, блин, на тесты. Вот — первый попавшийся в гугле: последовательное чтение — 529Мб/сек, случайное — 38МБ/сек. Разница — больше, чем на порядок.

    и конечно рамдиски.
    В случае с рамдисками разница тоже будет — хотя и не такая разительная.

    Определение рамдиска это не «потому что он не тормозит при заполнении», а потому что он расположен в памяти (в ram).
    Опять 25. Смотрю в книгу — вижу фигу. Ramdisk — это RAM + disk. Или, говоря формально, программная технология, позволяющая хранить данные в быстродействующей оперативной памяти как на блочном устройстве.

    Так вот в tmpfs RAM-таки да, а disk (блочное устройство) — таки нет. Потому tmpfs и не ramdisk.

    Обратите внимание что в статье про RAM-disk прямо наверху идёт отсылка на solid-state drive и tmpfs отдельно — это три похожих, но разных технологии!

    На настоящем ramdisk'е при 100% заполнении тормоза таки возникнут — хотя и не такие ужасные, как на SSD или, тем более, HDD.

    Просто в Linux есть поддержка рамдиска из коробки, в виде ramfs и tmpfs, которые внутри — одно и тоже, с разницей которую я пояснил выше.
    Нет — ramfs и tmpfs не являются ramdisk'ом. Даже initrd уже изжит (initrmfs — это не ramdisk, там тоже нет блочного устройства).

    Кроме того, под линукс хватает сторонних программ для организации виртуального рам-диска, который вы можете отформатировать в любую любимую ext2, zfs и т.д.
    И вот там — вы можете получить разные забавные эффекты при заполнении оного. Но для большинства систем — это не актуально…