Использую WindowMaker.
Удинственное, что не нравилось, это то, что он хранит настройки в GNUstep директории. Прямо в хомовике. нет, без точки, просто создает директорию
Всегда не нравилось.
Ну почему не .GNUstep? один симвлол - точка спереди - и какая разница в лс, файловых менеджерах.
Сегодня настраивал систему, собрался с духом - и поправил все упомения GNUstep в .c .h исходников. сделал патчец, чтообы потом в генте по обновлению вмейкера не слетали эти настройки.
И задумался
Как часто обновляется этот идеальный оконной менеджер?
Нужен ли патч?
ведь код идеален.
Человечество создало два редактора текста, все никак второй не изучу, видать и не слезу с вима никогда. Человечество создало один оконный менеджер.  Ну и запустило человека в космос.
Не за горами достижение идеала и в других областях ПО. Практически сразу, после автоматизации разработки. Лет за пять ПО будет вылизано. В индустрии останутся лишь аналитики, продукт-менеджеры, бариста и пол-дансинг-танцовщицы с охранниками.

совершенно не знал про такой милый ресурсец
https://www.linuxatemyram.com/

How do I see how much free ram I really have?

To see how much ram your applications could use without swapping, run free -m and look at the "available" column:

  $ free -m
                total        used        free      shared  buff/cache   available
  Mem:           1504        1491          13           0         855      792
  Swap:          2047           6        2041

(On installations from before 2016, look at "free" column in the "-/+ buffers/cache" row instead.)
This is your answer in MiB. If you just naively look at "used" and "free", you'll think your ram is 99% full when it's really just 47%!
For a more detailed and technical description of what Linux counts as "available", see the commit that added the field.

When should I start to worry?

A healthy Linux system with more than enough memory will, after running for a while, show the following expected and harmless behavior:

• free memory is close to 0
• used memory is close to total
• available memory (or "free + buffers/cache") has enough room (let's say, 20%+ of total)
• swap used does not change

Warning signs of a genuine low memory situation that you may want to look into:

• available memory (or "free + buffers/cache") is close to zero
• swap used increases or fluctuates
• dmesg | grep oom-killer shows the OutOfMemory-killer at work

отлично сформулировано: http://www.opennet.ru/openforum/vsluhforumID3/115824.html#11   3.11, Аноним (11), 22:36, 13/11/2018 [^] [ответить]    [к модератору]

+1

> > Для десктопа не подходит из-за отсутствия systemd > Чего это? Это некий "системный менеджер". Почитал бегло описание: содержит в одном проекте упрощённые реализации множества стандартных утилит, написанные (и пишущиеся в данный момент) с нуля двумя людьми под влиянием того, как аналогичные задачи решаются в windows и macos. По сути, похоже на бизибокс, только если там есть определённая цель - embedded и среды с ограниченным объёмом ресурсов, то здесь - проект пишется для души, не преследуя никакой конкретной цели. Утилиты реализованы особым образом, и, чтобы они работали, требуются изменения в базовых принципах работы современных юниксов. В результате ребятам пришлось реализовать свой инит, свой способ работы с логами, свой менеджер сеансов, свой способ монтирования разделов (временно с целью поддержки софта, аналоги которого ещё не реализованы в рамках systemd, традиционный fstab генерируется автоматически), даже отдельный демон для работы с /etc/localtime. Подробностей, к сожалению, не знаю, так как прочитал описание лишь бегло, но, судя по всему, многие задачи, типично решаемые в никсах запуском утилиты или установкой переменной окружения, здесь решаются просто отдельным демоном. То есть традиционное никсовое "всё есть файл" тут пытаются заменить на "всё есть демон". Проект является "домашним проектом" двоих вышеупомянутых, поэтому если им требуется какая-то возможность, то они просто берут и реализовывают её, а если что-то становится им ненужным, то могут удалить. Кроме того, поддерживается только работа в Линукс, причём достаточно свежих версий, и требует, чтобы ядро было собрано с некоторыми экзотическими опциями (как минимум, cgroups). РедХэт седьмую центось (и рхел вроде тоже) реализовала на базе этого "системного менеджера". Лидеру технического комитета Дебиана тоже так понравился этот systemd, что он устроил несколько голосований по вопросу внедрения его в дебиан и переделки всего на работу именно с ним вместо традиционных аналогов. Однако после трёх голосований желающих переходить на systemd всё ещё было не слишком много, так что решение мигрировать Дебиан на systemd ему пришлось принимать самостоятельно. Части голосовавших это не понравилось, и они создали ветку Дебиана в классическом исполнении - devuan.

ntpdate при невозможности синхронизировать время с сервером NTP весьма неинформативно об этом рапортует, что на самом деле не только снижает потенциальный интерес к утилите, но и фактически мешает работать.   Утилита при стандартном запуске вида
  ntpdate 10.20.30.40
не даст отличить  ситуации "нет доступа к сетевому узлу 10.20.30.40" от ситуации "на хосте 10.20.30.40 не запущен NTP сервер" не говоря уже об новой для меня ситуации "NTP сервер запущен, но его stratum/leap - это параметры [не]достоверности времени сервера -  слишком велики.
Для более подробного разбора полётов -ожидаемого на самом деле поведения - необходимо запускать nptdate с ключом -d.
Вчера на gentoo настраивал NTP сервер без доступа к внешним источникам. В генте 3 варианта NTP серверов, это

• net-misc/openntpd
• net-misc/ntp
• net-misc/chrony

Мне был привычен традиционный ntp от www.ntp.org но решил попробовать openntpd.
Дать шанс. Указал адрес прослушивания, вроде бы что-то поднялось, попробовал синхронизироваться, не получилось - забил. Думаю, надо использовать старых друзей.
И как выяснилось, привычный ntpd  тоже не отдаст время с ожидаемой точностью для ntpdate.
Запустил
   <client>#ntpdate192.168.0.1

получил ожидаемое
20 Sep 05:54:30 ntpdate[1890]: no server suitable for synchronization found

далее с ключом  -d
  <client># ntpdate -d  192.168.0.1 ...
 20 Sep 05:57:03 ntpdate[5580]: ntpdate 4.2.6p5@1.2349-o Mon Nov 14 18:25:09 UTC 2016 (1)
Looking for host 192.168.0.1 and service ntp
host found : 192.168.0.1
transmit(192.168.0.1)
receive(192.168.0.1)
...
receive(192.168.0.1)
192.168.0.1: Server dropped: strata too high
server 192.168.0.1, port 123
stratum 16, precision -24, leap 11, trust 000

...
20 Sep 05:57:09 ntpdate[5580]: no server suitable for synchronization found


Решил немного покопать, может получится быстро исправить ситуацию - не получилось быстро найти требуемые опции.

 В сердцах 

подправил в сорцах

в  ntpd/ntp_proto.c задал при отправке  stratum = 2;

немногое изменилось:
 <client># ntpdate -d  192.168.0.1
20 Sep 05:59:26 ntpdate[8858]: ntpdate 4.2.6p5@1.2349-o Mon Nov 14 18:25:09 UTC 2016 (1)
Looking for host 192.168.0.1 and service ntp
host found : 192.168.0.1
transmit(192.168.0.1)leap 11
...
...
192.168.0.1: Server dropped: Leap not in sync
server 192.168.0.1, port 123
stratum 2, precision -24, leap 11, trust 000




решил, что это уже перебор. Надо дать шанс chrony, перед дальнейшей ломкой кода.
<server>#emerge chrony
<server>#cat /etc/chrony/chrony.conf
driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsync
clientloglimit 100000000
local stratum 10
leapsectz right/UTC
allow  192.168.0.100
bindaddress 192.168.0.1

<server>#/etc/init.d/chronyd start

на клиентской тачке
 <client># ntpdate  -d 192.168.0.1
...
...
server 192.168.0.1, port 123
stratum 10, precision -25, leap 00, trust 000
refid [192.168.0.1], delay 0.02576, dispersion 0.00182
...
20 Sep 06:05:10 ntpdate[16530]: adjust time server 192.168.0.1 offset 0.434906 sec

отлично

куда детей Уганды дели со стартовой вима?  только обратил внимание #эстония
#философское #vim #best_editor

как просить поддержку о логах картинками.

Openssl и многопоточка.

Всё меняется, растёт, развивается - в OpenSSL более не требуется настраивать набор локов при использовании в многопоточном приложении!

УРА!!!

Натыкался на это, примерно лет 10 назад.
Было забавно.
Заходит глава саппорта, фанат альтернативного решения, развиваемого в той же конторе, и говорит так по отечески, с легкой болью общения с непрофессионалами, окончившими учебные заведения с главным зданием слишком маленькой высоты  - "там Серёга с багом в опенссл столкнулся, вы тоже на это напоретесь, идите и посмотрите. Вот идите." Мы всегда рады расти. Ведь у нас невысокие здания в наших университетах. Во всех, кроме одного, где и готовят Специалистов. Не комплексуем, но почему-то терпим это отеческое псевдокомпетентное. Ну может действительно чему-то научили ребят, в отличие от нас, кто знает?
Ну  и захожу к соседям, и там мне "Вован, тут такая тема, надо ссл_аццепт локом обрамлять, при использовании в нескольких потоках" и я так сходу - "man threads не помог?" и мне "что-что?" и уже как-то сразу ясно стало, почему мы не столкнулись с этим, а вот альтернатива, так скажем, влетела, при всём своём несомненном опыте. Сколько таких моментов было, и всё мы скромно терпели, и зря. Надо было драться с напыщенными саппортерами.  Вообще такие случаи отличный маркер нездорового отношения, должен был аларм завыть у менеджмента, это кристально ясно через десяток лет. Ну что было, то стало.