| 1.1, EuPhobos (ok), 09:06, 06/05/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –30 +/– |
 > возможность использования NVDIMM в качестве ОЗУ
Хмм-хмм, интересненько, оно только с Nouveau наверное будет работать?
| | |
| |
| |
| 3.6, Аноним (6), 09:55, 06/05/2019 [^] [^^] [^^^] [ответить]
| +10 +/– |
Получается так, Николай Владимирович. Все мы так понемногу...
| | |
|
| |
| 3.120, Аноним (120), 14:37, 08/05/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
у первопостера нет времени разбираться в вопросе, нужно поскорее что то ляпнуть.
| | |
|
|
| 1.7, Аноним (7), 10:11, 06/05/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– | |
>Добавлена поддержка ускорителей для систем машинного обеспечения Habana AI;
ЩИТО?
| | |
| 1.8, ффф (?), 10:54, 06/05/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– | |
>Во встроенную релизацию протокола TLS
- зачем оно там? и зачем тогда опен/либра_ssl?
| | |
| |
| 2.17, zanswer CCNA RS and S (?), 11:36, 06/05/2019 [^] [^^] [^^^] [ответить]
| +5 +/– | |
«The idea is for the kernel to handle the symmetric encryption and decryption, while leaving the handshake processing to user space. The feature uses the user-space API to the kernel's crypto subsystem, which is accessed via sockets created using the AF_ALG address family.»
https://lwn.net/Articles/666509/
Суть идеи в том, что таким образом выполняется offloading функций Record Layer TLS, он отвечает за передачу фактических данных, всё остальное остаётся в userspace, более того libressl и openssl взаимодействуют с KTLS.
| | |
| |
| 3.37, КО (?), 13:21, 06/05/2019 [^] [^^] [^^^] [ответить]
| –4 +/– | |
>Суть идеи в том, что
теперь при атаке человек по средине, если кто-то додумается отправить в ответ 4T пакет, то упадет не Ваш любимый Appache/Nginx/Chrome/FF/нужное подставить, а сразу йадро.
| | |
| |
| 4.46, Аноним (24), 15:06, 06/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
Поле Total Length в заголовке IP имеет размер, всего лишь, 16 бит, если что.
| | |
| 4.92, zanswer CCNA RS and S (?), 09:33, 07/05/2019 [^] [^^] [^^^] [ответить]
| +6 +/– | |
Вы ошибаетесь, когда думаете, что для ядра есть разница, какой размер имеют передаваемые данные между приложениями.
RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 содержит исчерпывающие требования к реализации TLS протокола и в частности Record Layer:
«5. Record Protocol
The TLS record protocol takes messages to be transmitted, fragments the data into manageable blocks, protects the records, and transmits the result. Received data is verified, decrypted, reassembled, and then delivered to higher-level clients.
TLS records are typed, which allows multiple higher-level protocols to be multiplexed over the same record layer. This document specifies four content types: handshake, application_data, alert, and change_cipher_spec.
~~~
5.1. Record Layer
The record layer fragments information blocks into TLSPlaintext records carrying data in chunks of 2^14 bytes or less. Message boundaries are handled differently depending on the underlying ContentType. Any future content types MUST specify appropriate rules.
~~~
Application Data messages contain data that is opaque to TLS. Application Data messages are always protected. Zero-length fragments of Application Data MAY be sent, as they are potentially useful as a traffic analysis countermeasure. Application Data fragments MAY be split across multiple records or coalesced into a single record.
~~~
enum {
invalid(0),
change_cipher_spec(20),
alert(21),
handshake(22),
application_data(23),
(255)
} ContentType;
struct {
ContentType type;
ProtocolVersion legacy_record_version;
uint16 length;
opaque fragment[TLSPlaintext.length];
} TLSPlaintext;
type: The higher-level protocol used to process the enclosed fragment.
~~~
length: The length (in bytes) of the following TLSPlaintext.fragment. The length MUST NOT exceed 2^14 bytes. An endpoint that receives a record that exceeds this length MUST terminate the connection with a "record_overflow" alert.
fragment: The data being transmitted. This value is transparent and is treated as an independent block to be dealt with by the higher-level protocol specified by the type field.»
С точки зрения KTLS нет не какой разницы где начинается или заканчивается конкретное сообщение вышестоящего протокола, например HTTP. Ядро лишь разделает поток байт на блоки размером не превышающем 2^14, при превышении соединение разрывается; выполняет над ними криптографические операции и передаёт далее по стеку для отправки через сеть. Когда ядро получает данные по стеку, то выполняет над полученными данными криптографические операции, после чего объединяет полученные блоки в последовательный поток байт, снова не заботясь не о каких границах сообщений, вышестоящего протокола.
Поскольку в классическом случае TLS работает поверх TCP, то ему нет не какой нужды заботиться о порядке получения блоков или их количестве. С точки зрения TLS, всё блоки получены в том порядке и в том количестве, котором они были сформированными на передающей стороне. И теперь нужно лишь снова их преобразовать в последовательный поток байт, который прочитает наше приложение, например Apache.
P/S/ Если у кого-то есть замечания или указания на ошибки в изложенном, буду рад комментариям. :)
| | |
|
|
| |
| 3.58, Аноним (55), 16:30, 06/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
Скомпрометированное ядро и так имеет доступ к памяти всех пользовательских процессов
| | |
|
|
| 1.10, Аноним (10), 11:06, 06/05/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– | |
> В XFS реализован режим always_cow, при котором вместо замены данных в блоках по месту применяется модель COW
А что, так можно было??
COW там только для данных или для метаданных тоже можно?
> В файловой системе Btrfs добавлена возможность настройки уровня сжатия для алгоритма zstd
несколько не по адресу, конечно, но лучше бы в zfs уже zstd добавили, пару лет уже висит https://github.com/zfsonlinux/zfs/issues/6247 и давным-давно патчи готовы, но нет, чем довести это до ума и получить zstd в рабочей и стабильной ФС, некие странные люди предпочитают ковырять далекий от продакшена btrfs.
| | |
| |
| 2.14, Fracta1L (ok), 11:22, 06/05/2019 [^] [^^] [^^^] [ответить]
| +4 +/– |
 Классический пример zfs-фанбоя - возмущается, что люди предпочитают пилить Btrfs, а не полумёртвую zfs, примотанную к ядру сбоку скотчем.
| | |
| |
| 3.18, Аноним (10), 11:42, 06/05/2019 [^] [^^] [^^^] [ответить]
| +8 +/– |
zfs я готов использовать в продакшене хоть сейчас в любой момент. Да, там есть нюансы (связанные как с тем, что это модуль вне ядра, так и прикрученным сбоку к ядру управлением памятью / spl), но тем не менее. Я точно знаю, какой прирост производительности я получу из-за ARC, какую надежность я получу из-за COW, контрольных сумм и прочего. В других задачах - какой объем я получу из-за raidz при отсутствии рисков типичного рейда. И так далее.
А вот кто возьмет btrfs, над тем буду долго смеяться. Вы не видели, как она бьется с потерей данных пользователя? Я видел. Очень по-глупому она может умирать. И не спроста, повисев несколько лет в статусе экспериментальной в RHEL ее в итоге выкинули в статус прекращения поддержки. До лучших времен, которые не факт что наступят.
Проблема btrfs в том, что так и не достигнув стабильности, она оказалась не нужна никому. Даже создатели от нее отказались. Стал доступным рабочий, проверенный годами zfs, к тому же не обладающий некоторыми косяками btrfs. И в своей нише zfs сидит плотно, btfs туда толком войти не может. А в нишу xfs/ext4 btrfs тоже не потянул, принципиальные проблемы как со скоростью, так и со стабильностью. Для обхода проблем с производительностью предлагают атрибут для отключения COW - это же курам на смех. Типа "ну да, так вы теряете почти все преимущества, зато формально все еще можете хвастаться знакомым админам, что используете btrfs, ура-ура!"
| | |
| |
| 4.19, Fracta1L (ok), 11:44, 06/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
Твои мысли и переживания на этот счёт крайне важны, я думаю что ты должен их написать в письме разработчикам ядра, чтобы они перестали заниматься Btrfs и засели за ZFS.
| | |
| |
| 5.31, Аноним (31), 12:40, 06/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
Btrfs лучше работает с зоопарком дисков. Разные размеры, добавление по одному, можно даже убрать диск и не заменять. В датацентрах это не нужно, а дома нужно.
| | |
| |
| 6.40, Stax (ok), 14:05, 06/05/2019 [^] [^^] [^^^] [ответить] | +2 +/– |  А можно подробнее Я так понимаю, полноценного и рекомендованного к использовани... большой текст свёрнут, показать | | |
| |
| 7.53, Имя (?), 15:53, 06/05/2019 [^] [^^] [^^^] [ответить]
| +/– | |
>диска меньшего размера
равное количество ТБ у разных моделей не гарантирует совпадение до байта
>Большего размера, кстати, без проблем можно.
с проблемами, место пропадает
| | |
| |
| 8.68, Аноним (10), 20:27, 06/05/2019 [^] [^^] [^^^] [ответить] | +1 +/– | ё-мае, ну zfs не идиоты же писали, в самом деле Там заложено небольшое но дост... текст свёрнут, показать | | |
|
| 7.98, нах (?), 10:53, 07/05/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> Я так понимаю, полноценного и рекомендованного к использованию аналога raid-z/2/3 в btrfs нет.
есть, но он не работает ;-)
к тому же там, по беглому погляду, write hole, как в "лучших" домах, zfs даже на raidz3 будет быстрее.
а для дома я бы ни на той, ни на другой не рисковал ползучими апгрейдами дисков - учитывая, как оно все работает, единственно-правильный апгрейд - zfs send на новую пару или новый raidz. Можно изначально degraded - на первых порах старая поработает архивом.
| | |
|
|
|
| 4.27, Аноним (-), 12:03, 06/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
Она не нужна никому не из-за плохой стабильности, а потому что это фс для сверх быстрых снепшотов, которые реализованы в угоду общей производительности. Снепшоты, разумеется, нужны не всем. Базу на ней не покрутишь, и систему ставить тоже никто не будет. А вот для файлопомойки она самое то. Проще говоря, у нее просто узкая специализация.
| | |
| |
| 5.41, Stax (ok), 14:16, 06/05/2019 [^] [^^] [^^^] [ответить] | +2 +/– | Угумс Но вот на той же zfs база обычно сильно, нет вот прямо СИЛЬНО быстрее и л... большой текст свёрнут, показать | | |
| |
| 6.50, Аноним (-), 15:28, 06/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
На сколько мне известно, в ZFS реализация COW сильно отличается от BTRFS. Она не захлёбывается на виртуалках или бд, но при этом использует агрессивное кеширование в память. И памяти ей нужно много.
| | |
| |
| 7.54, Ktoto (?), 16:11, 06/05/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
в ZFS COW на уровне блоков, в brfs на уровне файлов. В каком подходе больше оверхеда, в каком то больше возможностей.
| | |
| |
| |
| |
| 10.62, Ktoto (?), 18:06, 06/05/2019 [^] [^^] [^^^] [ответить] | –1 +/– | Архитектура ZFS https storagegaga wordpress com tag redirect-on-write сравне... текст свёрнут, показать | | |
|
|
|
|
| 6.56, Fracta1L (ok), 16:24, 06/05/2019 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>Но вот на той же zfs база обычно сильно, нет вот прямо СИЛЬНО быстрее и лучше работает, чем на ext4/zfs
Отменный доширак на уши.
| | |
| |
| 7.70, Аноним (70), 20:32, 06/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
У ZFS 2 вида кеша, часто используемые блоки вымываются хуже. На некоторых особых сценариях работы базы это может выстрелить.
| | |
|
| 6.69, Аноним (70), 20:30, 06/05/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
Нельзя использовать zfs под постгрес с блоком 32к, на каждую загрузку одного блока базой с диска поднимается информация из 4-х и 3 из них засоряют кеш. Пишется тоже много лишнего... Блок ФС должен быть равен рабочему блоку базы (8к). Кеш данных нужно выключать. Можно врубить L2ARС, возможно от него будет прок, от журнала на SSD явно прок будет, но ARC для ФС с данным базы нужно отключить и дать больше шареной памяти, постгря сама придумает, что с этой памятью делать. Ну если это сервер БД, а не БД на домашнем сервере с ещё десятком сервисов... Это всё ИМХО конечно, но всё же...
| | |
| |
| 7.71, xm (ok), 20:43, 06/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
 > Блок ФС должен быть равен рабочему блоку базы (8к)
Всё верно. А для MySQL 16Kb для данных InnoDB и 128Kb для журналов.
| | |
| 7.88, Stax (ok), 08:13, 07/05/2019 [^] [^^] [^^^] [ответить]
| +10 +/– | |
> Нельзя использовать zfs под постгрес с блоком 32к, на каждую загрузку одного блока базой с диска поднимается информация из 4-х и 3 из них засоряют кеш
Эээ нет. Я знаю методичку, в которой вы это прочли. Но в жизни оно не так. Я пробовал и 8к, конечно же. Но 32 или даже 64 лучше (по всем реальным бенчмаркам в моих ситуациях 64 еще лучше, но тут уж я испугался и "сконсервативничал"). Во всяком случае, для SSD это точно так.
Во-первых, на засорение кэша в памяти - по фигу. В моих шаблонах, к примеру, 128 ГБ машины (где примерно 80 под ARC) достаточно для хорошо нагруженной базы на пару-тройку терабайт. Никаких эффектов нехватки кэша не наблюдается. Хотя для еще больших баз и сверхбольших нагрузок, вероятно, лучше еще памяти.
Во-вторых критичное тут IO. Я писал, что база получает огромный прирост скорости от сжатия, т.к. получается за то же время вытянуть больше данных. Но на маленьких блоках сжатие перестает работать. Вот пример цифр как раз для постгри: https://www.2ndquadrant.com/en/blog/pg-phriday-postgres-zfs/
Коэффициент сжатия 1.71 при 8к блоках против 7.59 при 128к. Или можно так представить: тратя в 4.4 раза больше времени, мы прочитываем в 16 раз больше данных (временем разжатия можно пренебречь). Но нагрузки от БД по чтению не являются случайными! Даже в OLTP процент чисто случайных выборок, когда каждый следующий блок не имеет отношения к предыдущему не такой большой. А в других нагрузках так постоянно БД приходится считывать последовательные куски - таблиц или индексов. И это как бы правда, что при считывании истинно случайных блоков мы будем тупо тратить в несколько раз больше времени. Но каждый раз, когда требуются последовательные блоки, мы за то же время считываем в разы больше информации.
Ну и в-третьих, помимо сжатия считать более крупный блок эффективнее, чем два мелких последовательно. А в базе последовательной нагрузки не так мало, как писал выше (даже если кажется, что это не так!).
Но надо заметить, что recordsize в zfs это не фиксация, а ограничение сверху. Поэтому если база будет активно писать или изменять случайные 8K блоки (в противоположность последовательной записи), то эти измененные блоки будут сохранться по 8K, что бы там в recordsize не стояло. Ну и оверхед будет при изменениях. Поэтому эффект от регулярного pg_repack для переписывания таблиц и индексов для постгри на zfs даже больше, чем в других ситуациях (в целом-то это много когда улучшает производительность). Прямо видно, как уменьшаются размеры на диске и увеличивается коэффициент сжатия и производительность - пишет-то постгрес своими блоками, но zfs последовательные записи (даже в несколько потоков) агрегирует и пишет своим recordsize.
Цифр по постгресу, показывающих это на практике в каком-нибудь pgbench я в сети сейчас не вижу, а вот по mysql вполне находятся (где ситуация похожая): https://charlesnagy.info/it/mysql/how-to-decrease-iops-when-running-mysql-on-z 16k лучше, чем 8, а 32k еще лучше.
В общем, те люди, которые писали ту методичку скорее всего не учитывали, что придут SSD, не оценивали эффект от сжатия и в целом не пробовали гонять ни реальную нагрузку, ни хотя бы pgbench в современных реалиях ) Потому что методичка с советом брать recordsize=8k для постгри родом где-то из 2012 или 13 года, с тех пор многими бездумно копировалась, да и вообще не факт что авторы реально проверяли это все для постгри, а не скопировали с оракала по аналогии (а там ситуация немного другая, т.к. во-первых он не MVCC, а во-вторых там свое кэширование, а не системное).
> Кеш данных нужно выключать
)) попробуйте как-нибудь на досуге, будет очень смешно. Сейчас не готов показать цифры, но по памяти как-то так: когда работают несколько очень тяжелых запросов, надолго прогружающих диски, с включенным кэшем имеем 20 МБ/с случайных чтений на диск (NVMe дисков тогда возможности поставить не было, а это где-то предел энтерпрайзных SATA SSD'шников типа DC 3700 под долговременной нагрузкой). Видно, как дискам плохо, задержки (await) немаленькие. Ставим primarycache=metadata. О! У дисков открывается второе дыхание, ввод-вывод становится более-менее последовательным, они фигачат под 120 МБ/с. Задержки уменьшаются, все счастливы. Кроме пользователей: запросы начинают выполняться в несколько раз дольше. Опаньки.
С другой стороны, та база была реальный хардкор. На более приличных экземплярах переход на ZFS и эффект от умного ARC + сжатия обычно настолько делает все легче, что выключайте что угодно, все равно скорее всего будет лучше, чем было до zfs.
> Можно врубить L2ARС
В базах, где я вынужден был перейти на zfs этап L2ARC давно пройден, т.к. хотсет превышает разумный объем SSD под L2ARC, они давно all-SSD. Хотя на начальных этапах в некоторых из них это работало. Но когда база на много терабайт и это не разу ни холодные данные, все это постоянно читается и пишется, L2ARC не работает.
| | |
| |
| 8.96, нах (?), 10:42, 07/05/2019 [^] [^^] [^^^] [ответить] | +/– | ну хоть один понимает, что делает, а не методички безграмотные перепевает P S... текст свёрнут, показать | | |
|
|
|
|
| 4.63, livelace (?), 18:35, 06/05/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Поддержку. На днях умерла btrfs после нештатного выключения. Умерла полностью. Самое интересное, что данные на данном томе вообще не использовались в тот момент. ФС на сервере: ext4 под систему, xfs под openstack swift, zfs под виртуальные машины. Выжили все, кроме btrfs.
| | |
| |
| 5.97, нах (?), 10:47, 07/05/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
не надо выдавать ваше случайное везение за общее правило.
И да, что такое "умерла полностью" - что говорит mount и что показывает check ? (про dump-tree лучше не буду, все равно не разберетесь)
| | |
| |
| 6.113, Ktoto (?), 14:35, 07/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
сейчас он вспомнит что там использовался RAID 5/6 ... точнее не . не вспомнит :-)
| | |
| |
| 7.115, нах (?), 16:02, 07/05/2019 [^] [^^] [^^^] [ответить]
| +/– | |
насколько я помню (давно уже не слышал новостей от пользователей подобного) - там не при выключении умирало, а прямо на ходу разваливалось. С panic и прилетами в том числе и по соседним fs ;-)
так что, вероятнее всего - не использовался.
| | |
|
|
|
| 4.95, нах (?), 10:38, 07/05/2019 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Вы не видели, как она бьется с потерей данных пользователя? Я видел.
вы не видели как zfs pool превращается в тыкву с kernel panic при попытке его импорта/отрытия уже импортированного, похоронив ВСЕ данные вообще?
Я вас огорчу, но вы ничерта, похоже, не знаете о предмете своего фетишизирования.
> Проблема btrfs в том, что так и не достигнув стабильности, она оказалась не нужна никому.
проблема zfs в том, что потеряв сановского тимлида с большой дубиной, она оказалась "нужна" массе торопыжных обезьянков, пильщиков грантов, которые сломали все что можно и нельзя, под предлогом мелкого улучшизма, и не сделали ничего из того что действительно надо было сделать - под предлогом "а у сана такого нет!".
| | |
| |
| 5.100, Stax (ok), 11:01, 07/05/2019 [^] [^^] [^^^] [ответить] | +/– | Нет В солярке оракловой или одной из открытых Или это в линуксе В целом я вид... большой текст свёрнут, показать | | |
| |
| 6.105, нах (?), 11:29, 07/05/2019 [^] [^^] [^^^] [ответить] | +/– | и в линуксе, и в freebsd, результаты примерно одинаковые - и починить не получит... большой текст свёрнут, показать | | |
|
|
|
|
|
| 1.13, InuYasha (?), 11:21, 06/05/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –5 +/– | |
>>проблемы 2038 года
Никогда не понимал: при создании какого-то типа или структуры так трудно просчитать, какие числа она может хранить?? Очередной детский сад из 1980-ых, наверное... (-_-)
| | |
| |
| 2.16, Аноним (16), 11:33, 06/05/2019 [^] [^^] [^^^] [ответить]
| +4 +/– |
Вообще-то 1 января 1970 года. Так и представляю, как в 70х (да хоть и в 80х) годах процессор использует 64х битные числа для хранения UNIX-time.
| | |
| |
| 3.26, InuYasha (?), 12:00, 06/05/2019 [^] [^^] [^^^] [ответить]
| –2 +/– |
А не обязательно. Достаточно структуры с двумя 32-битными числами, обрабатываемыми по необходимости. Проблема в том, что хотели unix time использовать "лишь" для часов, но - увы и ах! - оно влезло всюду. О том, что в unix time не запишешь дату падения Российской Империи, думаю, разработчики догадывались. Верили, наверное, что выхлопные газы и ГМО не дадут им дожить до конца unix time, но вот уже не за горами :D
| | |
| |
| 4.33, Аноним (33), 12:57, 06/05/2019 [^] [^^] [^^^] [ответить]
| +3 +/– |
Проблема не в хранении, а в вычислении. Накладные расходы сильно возрастают.
| | |
| |
| 5.36, Аноним (16), 13:20, 06/05/2019 [^] [^^] [^^^] [ответить]
| +3 +/– |
И в хранении проблема. В те времена память исчислялась килобайтами.
| | |
|
| 4.59, Аноним (55), 16:38, 06/05/2019 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Unix time это формат _кодирования_ времени, а не формат хранения.
> О том, что в unix time не запишешь дату падения Российской Империи, думаю, разработчики догадывались
В unix time вполне можно закодировать дату падения Российской Империи, достаточно использовать отрицательные числа и например double для хранения.
| | |
| |
| 5.82, Аноним (82), 23:38, 06/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
double -- это уже 8 байт, да и польза от плавающей точки тут сомнительная.
| | |
|
| 4.93, Совершенно другой аноним (?), 10:05, 07/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
Вряд-ли у Вас будут файлы созданные, модифицированные или имевшие последний доступ во времена падения Российской Империи. Кстати, а почему не Римской, а то и не Египетских и разных Вавилонских царств?
| | |
|
|
| 2.90, Совершенно другой аноним (?), 09:30, 07/05/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
Умный Microsoft, например, думал, думал, и придумал: у них один из форматов хранения времени количество единиц по 100 наносекунд с 1 января 1601 года UTC в хранящееся 64-х разрядном числе. Просто у Microsoft был опыт того-же Unix и плюс к этому гораздо подросшие вычислительные способности и объёмы памяти - самые первые Unix были 16-ти разрядные, если не путаю, с максимальным количеством памяти 144К, а реальным, насколько я понимаю - 9К - как Вы думаете, в таких условиях можно было для хранения времени выделять 8 байт? Удивительно, что они вообще до 32-х битного времени догадались.
| | |
| 2.99, нах (?), 10:56, 07/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
"разумеется, никто не думает, что юникс будет использоваться так долго".
Из книжки кого-то из основоположников, середина 80х.
| | |
|
| 1.28, Нанобот (ok), 12:04, 06/05/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
 > Реализована безопасная доставка сигналов, учитывающая возможность повторного использования PID
хорошо, конечно, давно нужно было сделать. мне бы эта функция пригодилась ещё где-то лет пятнадцать назад
| | |
| |
| 2.72, Аноним (72), 20:58, 06/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
А почему не использовать в этом случае просто UUID для процессов?
| | |
| |
| 3.89, Нанобот (ok), 08:56, 07/05/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> А почему не использовать в этом случае просто UUID для процессов?
по причине его отсутствия
| | |
|
|
| 1.30, Анимайзер (?), 12:32, 06/05/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> Добавлена возможность использования устройств постоянной памяти (persistent-memory, например NVDIMM) в качестве ОЗУ
Единая, быстрая память (MRAM или аналоги) без разделения на ПЗУ и ОЗУ. Это будет началом новой эпохи в развитии архитектуры ПК, а новые архитектуры потребуют и написания принципиально новых операционных систем. К этому рано или поздно все и придут. Выходит, Дмитрий Завалишин предвидел будущее и был всё-таки прав со своей Фантом ОС.
| | |
| |
| 2.38, Ууаа (?), 13:25, 06/05/2019 [^] [^^] [^^^] [ответить]
| +8 +/– | |
> Единая, быстрая память (MRAM или аналоги) без разделения на ПЗУ и ОЗУ. Это будет началом новой эпохи в развитии архитектуры ПК,
Это будет новым вызовом нам, храбрейшим и умнейшим сынам каменных джунглей!
Но мы знаем, мы уверены, что приложим все свои великие силы, будем жертвовать сном и бананами, но сможем эффективно занять и эту память одним тяжелым веб-приложением аналога калькулятора на нативном, близком к железу Браузере!
У-у-а, товарищи! У-у-а!
| | |
| 2.39, КО (?), 13:35, 06/05/2019 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>К этому рано или поздно все и придут
Или не придут. :)
А если быть точным от этого уже давно ушли. Ибо, пока, ограничения на ресурс и долговременное хранение очень сильно влияют на скорость чтения-записи и цену.
| | |
| 2.124, uis (ok), 00:00, 14/12/2020 [^] [^^] [^^^] [ответить]
| +/– |
 >без разделения на ПЗУ и ОЗУ. Это будет началом новой эпохи в развитии архитектуры ПК, а новые архитектуры потребуют и написания принципиально новых операционных систем
Угу-угу. Никогда такого не было и вот опять. Яблодрочер что-ли? Те тоже любят заявлять, что придумали то, что было 100500 лет назад.
Фон Нейман негодует!
| | |
|
| 1.32, Аноним (32), 12:46, 06/05/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
> Добавлена возможность загрузки с файловой системы, размещённой на устройстве device-mapper, без применения initramfs.
Ну наконец-то!!! Всегда удивлялся отсутствию этой сверхнеобходимой фичи. LVMу уж 100 лет в обед, а ядро без костылей могло грузиться только с обычных разделов. Компиляю 5.1 и выкидываю initramfs-tools!!!
| | |
| |
| 2.42, Аноним (42), 14:17, 06/05/2019 [^] [^^] [^^^] [ответить]
| –5 +/– |
Давай, давай, компиляй ядро без патчей. Посмотрим что у тебя отвалится. Кажется в 4.14 билась файловая система.
| | |
| |
| 3.49, Ordu (ok), 15:20, 06/05/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
 > Кажется в 4.14 билась файловая система.
Это где она билась? В смысле, что за дистр?
| | |
| 3.108, Аноним (32), 12:25, 07/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Давай, давай, компиляй ядро без патчей. Посмотрим что у тебя отвалится. Кажется
> в 4.14 билась файловая система.
о каких патчах речь, если не секрет?
| | |
|
| 2.43, Аноним (43), 14:36, 06/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
Возможность не использовать initramfs была давным-давно. Просто так решил вскукарекнуть?
| | |
| |
| 3.48, Аноним (24), 15:16, 06/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
Речь шла про корневой раздел на LVM. Нужно уж хотя бы выполнить "vgchange -ay" откуда-нибудь, чтоб корень увидеть.
| | |
| |
| 4.109, Аноним (32), 12:30, 07/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Речь шла про корневой раздел на LVM. Нужно уж хотя бы выполнить
> "vgchange -ay" откуда-нибудь, чтоб корень увидеть.
Спасибо, Анон.
| | |
|
|
|
| 1.47, Пряникё (?), 15:14, 06/05/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Хватит добавлять свистоперделок в btrfs. Там от того, что уже накреативили - не продохнуть
| | |
| |
| |
| 3.84, KonstantinB (ok), 00:43, 07/05/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Ноль это io_uring_params.flags, см. io_uring.h
Я вот думаю, получится ли с этим сделать эффективную замену тред-пулу в nginx. Надо попробовать.
| | |
| 3.85, KonstantinB (ok), 00:45, 07/05/2019 [^] [^^] [^^^] [ответить]
| +4 +/– | |
Более-менее исчерпывающей доки я не нашел, все отправные точки перечислены в посте.
"Программа подробно задокументирована на языке C". Ну да не привыкать, со старым aio было еще хуже.
| | |
|
| 2.80, Аноним (80), 23:06, 06/05/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Проработанный?
> Group: System Environment/Libraries
> BuildRoot: %{_tmppath}/%{name}-root
>
> %clean
> [ "$RPM_BUILD_ROOT" != "/" ] && rm -rf $RPM_BUILD_ROOT
>
> %post -p /sbin/ldconfig
>
> %postun -p /sbin/ldconfig
Все уже лет десять как забыли про такую «проработку».
> %package devel
> Provides: liburing.so.1
WTF?
| | |
| |
| |
| 4.106, нах (?), 11:30, 07/05/2019 [^] [^^] [^^^] [ответить]
| +/– | |
devel для .so - явное не так, остальное чьи-то личные тараканы
| | |
| |
| 5.111, anonymous (??), 12:59, 07/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
ОК, ещё мне, конечно, не нравится (своей экстримальной опасностью) строка:
[ "$RPM_BUILD_ROOT" != "/" ] && rm -rf $RPM_BUILD_ROOT
А в остальных приведённых строках что не так? [если не впадлу прокомментировать :)]
| | |
|
| 4.114, Аноним (114), 15:25, 07/05/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> Для тех, кто в spec-файлах ничего не понимает (вроде меня), что тут не так?)
Тут не так то, что это всё устаревший мусор, не который при использовании актуальных версий rpm надлежит выкинуть. Но Альт и современный rpm — вещи несовместные.
А якобы предоставляемая devel-пакетом либа — какой-то бред, к тому же вредный. Я допускаю, конечно, что чего-то не знаю про Альт, но в любом другом дистрибутиве это недопустимая ошибка.
| | |
| |
| 5.117, toshische (ok), 12:27, 08/05/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Вообще, это очень странный спек для ALT. Потому, что в ALT этот устаревший мусор совершенно не нужен и уже очень давно. Если я правильно помню, то раньше, чем в upstream RPM.
И нельзя сказать, чтоб rpm-4.13.0.1-alt6 был очень уж несовременным :-D
| | |
|
|
| 3.110, Аноним (32), 12:34, 07/05/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
> WTF?
> [ "$RPM_BUILD_ROOT" != "/" ] && rm -rf $RPM_BUILD_ROOT
I'm loving it!
| | |
|
|
|
