Re: переключение языков в иксах
2018-012 20:06 Sohin Vyacheslaw wrote: > Может кто-нибудь из рассылки юзает более удобные сочетания? > плз поделитесь... использую LWin и Menu (RWin у меня нету), ну и аналогично scroll в качестве индикатора, никаких там индикаторов на экране и не нужно. привык настолько, что для ввода знаков препинания (запятые там, точки, вопрос, кавычки всякие, etc) переключаюсь на аглицкую и обратно - они там гораздо удобнее расположены, да и переключалка как раз рядом с ними контекстное меню (ака имитация ПКМ) работает по shift+Menu
Re: переключение языков в иксах
В Sat, 13 Jan 2018 19:32:28 +0300 Pavel Volkov пишет: > On пятница, 12 января 2018 г. 21:06:07 MSK, Sohin Vyacheslaw wrote: > > Приветствую, > > > > на данный момент у меня переключение языков настроено > > Caps/Shift+Caps: Option "XkbOptions" > > "terminate:ctrl_alt_bksp,grp:caps_toggle,grp_led:scroll" > > > > Может кто-нибудь из рассылки юзает более удобные сочетания? > > плз поделитесь... > > Не совсем в тему, но использую compose key для ввода ряда > спецсимволов: тире, градус, знак ударения, знак умножения, кавычки, > евро, копирайт и т. д. > В качестве compose key — правый Alt. > Например, правый Alt + d, чтобы поставить градус°. По-моему, стандартное использование Compose Key куда проще запоминается: когда последовательно надо нажать Compose ^ 0 для градуса Сompose ^ 2 для ² (двойка в верхнем индексе) и т.д. Compose --- для тире Compose a e для æ Compose o c для © То есть использовать слово Compose по смыслу "скомпоновать сложный символ из нескольких простых". Это есть во всех стандартных раскладках. Я, конечно, понимаю, что если у человека есть потребнность еще и хатакану с кираганой вводить, там может быть по-другому и использование правого Alt как модификатора осмысленно. Но у нас тут в Европе, как правило, символы, вводимые через компоуз используются не чаще одного-двух на строчку, поэтому мнемоничность важнее минимизации количества нажимаемых клавиш. > Это обеспечивается раскладкой typo. > > Option "XkbLayout" "jp+typo,ru:2+typo" > Option "XkbOptions" > "grp:caps_toggle,grp_led:scroll,terminate:ctrl_alt_bksp,lv3:ralt_switch" > -- Victor Wagner
Re: Снова о ZFS
>> Т.е., приложение всё-равно запишет, не поняв что была ошибка и данных на >> диске нет? >> В чём тогда разница? > > Я не понимаю про какую разницу вы спрашиваете. > > * zfs set sync=disabled -- означает что "не делать настоящую > гарантированную запись на диск во время вызова fsync", а поместить всё > в буфер и уж когда запишется, тогда и запишется. Программа после fsync > думает что на диске всё есть, но при какой-то поломке/проблеме, то, > что не записалось из буфера, будет потеряно > * вынесенный ZIL но без зеркалирования -- fsync гарантирует что до ZIL > запись дошла, на него записалась, но при поломке, то, что из ZIL не > успело перенестись на диск, будет потеряно. Аналогично sync=disabled, > с той лишь разницей что данные оказались на ZIL накопителе, а не в > памяти > Т.е., в случае sync=disabled, ZIL запишется сразу (на SSD), но на диск данные не будут сброшены? > Так как ZIL это SSD наверняка всегда, то SSD имеет очень не нулевой шанс > внезапно отказать (а не плавно деградировать как это делают HDD) и, > соответственно, шанс потерять какие-то данные после fsync. Поэтому ZIL > так сильно рекомендуется зеркалировать. > Ok, понял, докуплю вторую SSD. >> Ещё вопрос: есть SSD размером 250 ГБ на который будет установлена >> система (или два SSD), и на которые будет вынесен ZIL. >> Хочу сделать два одинаковых GPT раздела на каждой из SSD. >> На раздел под систему отвести 100 ГБ, под ZIL 150 ГБ. >> Оба раздела будут шифроваться стандартным ZFS шифрованием. >> С первого раздела (миррора) должна грузиться ОС. >> >> Эта конфигурация жизнеспособна? > > Да, проблем или каких-то особенностей тут не вижу. > Вопрос по загрузке возникает. В Linux эта проблема решается через вынесение ядра и initrd с cryptsetup на отдельный раздел. Здесь тоже самое?
Re: Снова о ZFS
10.01.2018 18:29, Sergey Matveev пишет: > *** artiom [2018-01-10 18:18]: >> И всё бы хорошо, но про OMV вы молчите. >> Что скажите насчёт ZFS+Linux? >> Доводы за и против? > > Лично я с GNU/Linux уже давно не работаю (и не хочу) и поэтому ничего не > могу сказать, так как опыта нет. Качество падает и подходы к качеству в > GNU/Linux мире меня ОЧЕНЬ удручают и поэтому я в него больше "не лазаю" :-) > Но это чисто личное мнение/опыт. Про OMV я вообще только от вас впервые и > услышал. > А что можете сказать про другие системы (NAS специфичные)? В частности, интересует NAS4Free.
Re: переключение языков в иксах
только это не compose, а 3rd level про compose Виктор в соседнем письме ответил кстати, с помощью compose можно строить всякие прикольные шаблоны, типа compose + < + a = ну или кому что надо, лишь бы в одну строку ложилось 2018-013 19:32 Pavel Volkov wrote: > Не совсем в тему, но использую compose key для ввода ряда спецсимволов: > тире, градус, знак ударения, знак умножения, кавычки, евро, копирайт и т. > д. > В качестве compose key — правый Alt. > Например, правый Alt + d, чтобы поставить градус°. > Это обеспечивается раскладкой typo. > > Option "XkbLayout" "jp+typo,ru:2+typo" > Option "XkbOptions" > "grp:caps_toggle,grp_led:scroll,terminate:ctrl_alt_bksp,lv3:ralt_switch" >
Re: переключение языков в иксах
>> Не совсем в тему, но использую compose key для ввода ряда >> спецсимволов: тире, градус, знак ударения, знак умножения, кавычки, >> евро, копирайт и т. д. >> В качестве compose key — правый Alt. >> Например, правый Alt + d, чтобы поставить градус°. >> >> Это обеспечивается раскладкой typo. >> >> Option "XkbLayout" "jp+typo,ru:2+typo" >> Option "XkbOptions" >> "grp:caps_toggle,grp_led:scroll,terminate:ctrl_alt_bksp,lv3:ralt_switch" > > По-моему, стандартное использование Compose Key куда проще запоминается: > когда последовательно надо нажать > > Compose ^ 0 для градуса > Сompose ^ 2 для ² (двойка в верхнем индексе) и т.д. > Compose --- для тире > Compose a e для æ > Compose o c для © > > То есть использовать слово Compose по смыслу "скомпоновать сложный > символ из нескольких простых". Легко заметить по конфигу, что товарищ просто оговорился: сказал про композицию (для которой, как видно, клавиша у него вовсе не назначена), когда имел в виду третий и четвертый уровни раскладки. > куда проще На вкус и цвет все люди разные. Я, к примеру, пользуюсь и тем, и другим: одиночное «menu» включает третий ряд, двойное — композицию. То есть, к примеру, «×» («на», как в «4 × 3 см») можно набрать двояко: ‘ shift-8’ или ‘ x x’ (где «x» — это латинская буква). > Это есть во всех стандартных раскладках. Механизм как таковой, кажется, вообще не зависит от раскладки. А вот же клавиша, если я помню верно, из коробки ни в одной раскладке не назначена. > Я, конечно, понимаю, что если у человека есть потребнность еще и > хатакану с кираганой вводить, там может быть по-другому и использование > правого Alt как модификатора осмысленно. > > Но у нас тут в Европе, как правило, символы, вводимые через компоуз > используются не чаще одного-двух на строчку, поэтому мнемоничность > важнее минимизации количества нажимаемых клавиш. Это в той самой Европе, где во всех латинских раскладках третий ряд задействован по-умолчанию? Даже в английской, да. (Другое дело, что отбирать под это «альт» — дело нехорошее, ну так это легко поправимо.) Или имеется в виду кирилловская Европа? Тут из коробки он не задействован, да. А ведь совершенно зря! А «не чаще двух раз на строчку» — это вы, конечно, лихо сказали. Под таким предлогом впору половину клавиш выкидывать. Просто же *чаще*, чем несколько уютно расположившихся в первом ряду азбучных букв, используются в русском наборе тире и кавычки. Откровенно непонятно, что в первых двух рядах по прежнему делают машинописный знак «_» и совсем уже непонятного назначения литера «\», когда есть апостроф и знак ударения. При таких поправках более высокие ряды, возможно, и станут для русской раскладки излишни. Пока мы не вспомним, что добрая половина русскоязычных в той или иной степени владеют еще одним языком, у которого письмо тоже на кириллице. И многим из них было бы удобно время от времени иметь возможность вводить тамошние буквы.
Re: Снова о ZFS
*** artiom [2018-01-14 17:14]: >Т.е., в случае sync=disabled, ZIL запишется сразу (на SSD), но на диск >данные не будут сброшены? sync=disabled даже на ZIL не запишет, насколько знаю. С sync=standard (по-умолчанию) всё как вы сказали: на ZIL точно запишет, на диск позже. >Вопрос по загрузке возникает. В Linux эта проблема решается через >вынесение ядра и initrd с cryptsetup на отдельный раздел. Здесь тоже самое? Про GNU/Linux, к сожалению, ничего не смогу сказать. В FreeBSD такое точно без проблем работает -- у меня схожая схема используется. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
*** artiom [2018-01-14 17:14]: >А что можете сказать про другие системы (NAS специфичные)? >В частности, интересует NAS4Free. Я наслышан только о FreeNAS и то что он активно используется знакомыми. Он just-works, подвохов не было. Сам руками ничего не трогал. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: Снова о ZFS
14.01.2018 22:55, Sergey Matveev пишет: > *** artiom [2018-01-14 17:14]: >> Т.е., в случае sync=disabled, ZIL запишется сразу (на SSD), но на диск >> данные не будут сброшены? > > sync=disabled даже на ZIL не запишет, насколько знаю. С sync=standard > (по-умолчанию) всё как вы сказали: на ZIL точно запишет, на диск позже. > Кстати, был вопрос "чем отличается брэндовый L2ARC от обычной SSD?". Вот это наталкивает на мысли (пусть оно и для ZIL): "After a crash, ZFS will attempt to replay the ZIL contents. SSDs themselves have a volatile write cache, so they may lose data during a bad shutdown. To ensure the ZFS write cache replay has all of your inflight writes, the SSD devices used for dedicated ZIL devices should have power protection. HGST makes a number of devices that are specifically targeted as dedicated ZFS ZIL devices." Отсюда: http://www.freenas.org/blog/a-complete-guide-to-freenas-hardware-design-part-iii-pools-performance-and-cache/ Оттуда же (насчёт производительности): "A key thing to know here is a ZFS vdev gives the IOPs performance of one device in the vdev. That means that if you create a RAIDZ2 of ten drives, it will have the capacity of 8 drives but it will have the IOPs performance of a single drive." >> Вопрос по загрузке возникает. В Linux эта проблема решается через >> вынесение ядра и initrd с cryptsetup на отдельный раздел. Здесь тоже самое? > > Про GNU/Linux, к сожалению, ничего не смогу сказать. В FreeBSD такое > точно без проблем работает -- у меня схожая схема используется. > Каким образом (FreeBSD давно был)? Нужен отдельный незашифрованный раздел?
Re: Снова о ZFS
*** artiom [2018-01-15 00:29]: >Вот это наталкивает на мысли (пусть оно и для ZIL): >"After a crash, ZFS will attempt to replay the ZIL contents. SSDs >themselves have a volatile write cache, so they may lose data during a >bad shutdown. To ensure the ZFS write cache replay has all of your >inflight writes, the SSD devices used for dedicated ZIL devices should >have power protection. HGST makes a number of devices that are >specifically targeted as dedicated ZFS ZIL devices." А, ну то бишь это как и HDD специально сделанные для NAS решений: как бы без write cache-а. Разумно. Действительно полезно. На HDD часто просто можно отключать этот write cache и нивелировать проблемы внезапного выключения. >Оттуда же (насчёт производительности): >"A key thing to know here is a ZFS vdev gives the IOPs performance of >one device in the vdev. That means that if you create a RAIDZ2 of ten >drives, it will have the capacity of 8 drives but it will have the IOPs >performance of a single drive." Для random IOPS всё верно. Sequential read будет всё же быстрее. >>> Вопрос по загрузке возникает. В Linux эта проблема решается через >>> вынесение ядра и initrd с cryptsetup на отдельный раздел. Здесь тоже самое? >Каким образом (FreeBSD давно был)? Нужен отдельный незашифрованный раздел? Да, просто отдельный раздел где будет загрузчик с ядром и модулями которые они подгружают. В самом man-е GELI есть примеры касающиеся boot: https://www.unix.com/man-page/FreeBSD/8/geli/ (/boot/loader.conf) -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
