1
2
3
4
5
6
7
8
9
10
11
12

[Desktop Entry]
Type=Application
Name=JetBrains WebStorm
GenericName=JetBrains WebStorm 223
X-GNOME-FullName=JetBrains WebStorm 223
Exec=/home/sy/program/WebStorm-223.8214.51/bin/webstorm.sh
Icon=/home/sy/program/WebStorm-223.8214.51/bin/webstorm.png
Comment=JetBrains WebStorm 223
Categories=Development;
Terminal=false
StartupNotify=true
StartupWMClass=jetbrains-webstorm

строка 1: указывает что это конфигурация нового пункта меню
строка 2: тип пункта - запуск приложения
строка 3,4,5: название приложения сделал по аналогии с другими пунктами меню
строка 6: полный путь до исполняемого файла приложения, в моем случае это путь до скрипта bash
строка 7: полный путь до иконки приложения (необязательно, но лучше с иконкой)
строка 8: комментарий, который будет появляться при наведении курсора мышки на наш пункт меню
строка 9: это раздел, в который мы хотим добавить наш пункт, через точку с запятой можно указать несколько разделов и тогда наш пункт меню будет во всех этих разделах
строка 10: признак запуска в терминале - у нас оконное приложение, поэтому false
строка 11: просто скопировал )
строка 12: имя окна которое будет запущено (не уверен, что это обязательный параметр, но названием легко получить
для этого запускаем WebStorm, и в терминале команду
sy@nitro:~/program/WebStorm-223.8214.51/bin$ xprop WM_CLASS
и кликаем на заголовок окна WebStorm'a
WM_CLASS(STRING) = "jetbrains-webstorm", "jetbrains-webstorm"
выводом будет название окна, которое мы и вписываем в качестве значения параметра StartupWMClass
)
4. Сохраняем файл jetbrains-webstorm.desktop и наслаждаемся новым пунктом меню

Приятного обрезания!

1. Обновляем информацию о новых версиях установленного ПО в нашем локальном хранилище
sudo apt-get update
2. Обновляем ПО до последних версий (это не обязательный шаг, но рекомендуется его сделать, т.к. новые версии ПО могут содержать исправления багов и проблем с безопасностью)
sudo apt-get upgrade
3. Добавляем ключ репозитория для установки Grafana
wget -q -O - https://packages.grafana.com/gpg.key | sudo apt-key add -
4. Добавляем репозиторий, из которого будем ставить Grafana ( стабильная версия )
wget -q -O - https://packages.grafana.com/gpg.key | sudo apt-key add -
5. Повторяем пункт 1, чтобы подтянулись данные о новом репозитории
6. Ставим Grafana
sudo apt-get install grafana
7. В процессе, скрипт установки Grafana любезно предложит поставить Grafana в автозапуск - это опция для серверов, для которых жизненно необходимо чтобы Grafana сама поднималась после перезапуска сервера (в том числе и нештатного).
8. Запускаем Grafana и проверяем статус.

sudo /bin/systemctl start grafana-server
sudo /bin/systemctl status grafana-server

вы должны увидеть что-то вроде этого

$ sudo systemctl status grafana-server
● grafana-server.service - Grafana instance
Loaded: loaded (/usr/lib/systemd/system/grafana-server.service; disabled; vendor preset: enabled)
Active: active (running) since Tue 2020-01-07 21:29:19 MSK; 5s ago
Docs: http://docs.grafana.org
Main PID: 13788 (grafana-server)
Tasks: 22 (limit: 4915)
CGroup: /system.slice/grafana-server.service
└─13788 /usr/sbin/grafana-server --config=/etc/grafana/grafana.ini --pidfile=/var/run/grafana/grafana-server.pid --packaging=deb cfg:default.paths.logs=/var/log/grafana cfg:default.paths.data=/var/lib/grafana
янв 07 21:29:19 nitro grafana-server[13788]: t=2020-01-07T21:29:19+0300 lvl=info msg="Initializing InternalMetricsService" logger=server
янв 07 21:29:19 nitro grafana-server[13788]: t=2020-01-07T21:29:19+0300 lvl=info msg="Initializing TracingService" logger=server
янв 07 21:29:19 nitro grafana-server[13788]: t=2020-01-07T21:29:19+0300 lvl=info msg="Initializing UsageStatsService" logger=server
янв 07 21:29:19 nitro grafana-server[13788]: t=2020-01-07T21:29:19+0300 lvl=info msg="Initializing CleanUpService" logger=server
янв 07 21:29:19 nitro grafana-server[13788]: t=2020-01-07T21:29:19+0300 lvl=info msg="Initializing NotificationService" logger=server
янв 07 21:29:19 nitro grafana-server[13788]: t=2020-01-07T21:29:19+0300 lvl=info msg="Initializing provisioningServiceImpl" logger=server
янв 07 21:29:19 nitro grafana-server[13788]: t=2020-01-07T21:29:19+0300 lvl=info msg="Backend rendering via phantomJS" logger=rendering
янв 07 21:29:19 nitro grafana-server[13788]: t=2020-01-07T21:29:19+0300 lvl=warn msg="phantomJS is deprecated and will be removed in a future release. You should consider migrating from phantomJS to grafana-image-renderer plugin." logger=
янв 07 21:29:19 nitro grafana-server[13788]: t=2020-01-07T21:29:19+0300 lvl=info msg="Initializing Stream Manager"
янв 07 21:29:19 nitro grafana-server[13788]: t=2020-01-07T21:29:19+0300 lvl=info msg="HTTP Server Listen" logger=http.server address=[::]:3000 protocol=http subUrl= socket=

9. Проверяем что работает UI, для этого заходим в localhost:3000
Login: admin
Password: admin
10. После авторизации, ui предложит сменить пароль.

Поздравляю, Grafana установлена!

Проверено на Linux Mint 19

Вход по логину и паролю на локальной машине разработчика не обеспечивает никакой безопасности, но сильно раздражает, т.к. периодически требует авторизоваться заново. Поэтому будет удобно входить в Jenkins без пароля. Для этого необходимо найти файл c настройками:

sudo nano /var/lib/jenkins/config.xml
и заменить строку
<useSecurity>True</useSecurity>
на
<useSecurity>False</useSecurity>

и перезагрузить Jenkins (если вы его просто скачали то остановить и запустить снова)
если Jenkins устанавливался через менеджер пакетов, то выполнить
sudo service jenkins restart

теперь Jenkins не будет надоедать вам требованием авторизоваться!

ffmpeg -i concat:"VTS_02_1.VOB|VTS_02_2.VOB|VTS_02_3.VOB|VTS_02_4.VOB|VTS_02_5.VOB" -acodec aac -strict experimental -ac 2 -ab 128k -vcodec libx264 -crf 24 -threads 0 d1.mp4;

На выходе будет файл d1.mp4

Предварительно необходимо установить ffmpeg, если он еще не установлен.

sudo add-apt-repository ppa:mc3man/trusty-media && sudo apt-get update 
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 8E51A6D660CD88D67D65221D90BD7EACED8E640A
sudo apt-get install ffmpeg

Подробнее о ffmpeg

1. Программное обеспечение использующее СВ должно иметь публичный API (в виде документации или набора интерфейсов).

2. Стандартный номер версии должен иметь вид X.Y.Z - где X,Y и Z целые неотрицательные числа и не содержать ведущих нулей (т.е. не допускаются версии вида, например 1.01.0 - правильно 1.1.0). При внесении изменений в ПО должен изменяться один или несколько компонентов версии X, Y или Z.

3. После выпуска новой версии ПО, его содержимое для этой версии не должно меняться.

4. В начале разработки MAJOR версия равно 0, версия имеет вид 0.Y.Z. Публичное API нестабильно. Все изменения API считаются обратно-совместимым, т.е при любом изменении API увеличивается Y компонент.

5. Версия 1.0.0 присваивается публичному API в стабильном состоянии. Фактически в этот момент происходит первый релиз ПО.

6. Z компонент версии (патч-номер версии) должен быть увеличен, только если внесены обратно-совместимые исправления ошибок. Исправление ошибки - это внутреннее изменение, исправляющее некорректное поведение без изменения публичного API. Также он МОЖЕТ увеличиваться при незначительных функциональных улучшениях кода без изменения публичного API.

7. Y компонент версии (минорный номер версии) должен быть увеличен, если добавлена новая обратно-совместимая функциональность в публичный API. Также Y должен быть увеличен если какие-либо функции публичного API помечены как устаревшие. Компонент Y МОЖЕТ увеличиваться, если внесены значительные функциональные улучшения кода без изменения публичного API, при этом Z компонент версии (патч-номер) должен быть сброшен в 0. Если одновременно с улучшениями производились исправления ошибок, то Z компонент версии можно не менять.

8. X компонент версии должен увеличиваться при внесении обратно-несовместимых изменений в публичный API. Если одновременно с этим были обратно-совместимые изменения API и исправление ошибок не меняющих API, то компоненты Y и Z можно не менять. При изменении X компонента, компоненты Y и Z должны быть сброшены в 0.

9. Предрелизные версии могут быть обозначены путем добавления дефиса и идентификаторов, разделенных точкой, сразу после версии патча. Идентификаторы могут содержать только символы из набора [0-9A-Za-z]. Числовые идентификаторы не должны содержать ведущий ноль. Предрелизная версия указывает на то, что соответствующая версия публичного API еще не стабильна. Примеры нумерации: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92

10. Метаданные сборки могут быть добавлены в конец релизной или предрелизной версии после знака "+". Метаданные сборки - это один или несколько непустых идентификаторов разделенных точкой. Идентификаторы могут содержать только символы из набора [0-9A-Za-z]. При определении старшинства версии метаданные сборки не учитываются, т.е. если 2 версии отличаются только метаданными сборки - эти версии имеют одинаковый приоритет. Пример: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.

11. Старшинство версий должно рассчитываться путем сравнения X, Y, Z. При определении очередности слева направо сравниваются соответствующие компоненты версий. Например: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1. Когда X, Y и Z версий соответственно равны - смотрим какая из версий является предрелизной, релизная версия всегда старше. Например: 1.0.0-alpha < 1.0.0. Сравнение предрелизных версий производится слева направо, числовые идентификаторы сравниваются как число, а символьные - лексически. Числовые идентификаторы имеют меньший приоритет, чем лексические. Набор из большего количества идентификаторов имеет больший приоритет, чем набор из меньшего количества идентификаторов, при условии что все идентификаторы меньшего набора расположены в том же порядке, что и большего. Например: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.

СВ не является новой или революционной идеей и вы, наверняка, использовали что-то похоже. Достаточно ли хорошо это "похожее" работает? Проблема заключается в том, что без формальной спецификации правил, сама идея версионирования, как инструмент управления зависимостями, бесполезна. Определяя четкие правила назначения версий, становится легче доносить до пользователей вашего ПО - как изменилось ПО и что нужно предпринять для эффективного управления зависимостями.

Рассмотрим пример в котором есть приложение "Пожарная машина", которое зависит от библиотеки "Лестница". Библиотека "Лестница" использует семантическое версионирование. Приложение "Пожарная машина" использует библиотеку "Лестница" версии 3.1.0, т.к именно в этой версии были добавлены необходимые приложению функции. Это означает, что мы можем указать для приложения "Пожарная машина" диапазон совместимых версий библиотеки "Лестница" [3.1.0, 4.0.0). Это означает, что если в системе будет библиотека "Лестница" версии 3.1.1 или 3.2.5, то приложение "Пожарная машина" будет работать так же хорошо как и с версией 3.1.0
Однако с версией 4.0.0 и выше приложение может быть уже несовместимо.

Как ответственный разработчик вы хотели бы быть уверены, что в новой версии ПО именно те изменения, которые декларируются версией... Однако реальный мир несовершенен, и вы ничего не можете с этим поделать, поэтому просто будьте бдительны. Что в ваших силах сделать, так это позволить Семантическому Версионированию дать Вам разумный способ выпускать и обновлять ПО без необходимости обновления всех зависимостей, экономя ваши нервы и время.

Если все это выглядит привлекательно - все что вам нужно сделать - это объявить что вы используете Семантическое Версионирование и начать следовать правилам! Делайте ссылку на этот пост или на оригинальный текст в Вашем README, чтобы пользователи Вашего ПО понимали Вас лучше.

FAQ

→ Как менять версии формата 0.Y.Z на стадии разработки?
↑Самое простое - это начать с версии 0.1.0, а затем увеличивать Y при каждом новом выпуске, т.е. использовать 0.Y.0 (если вам не принципиально что вошло в новую версию, улучшения или исправления ошибок).

→ Как определить что пора выпускать версию 1.0.0?
↑Как только от Вашего ПО начинает зависеть стороннее ПО или пользователи - смело ставьте версию 1.0.0

→ Если даже при малейшем изменении обратной совместимости в публичном API надо увеличивать X компонент версии, не получится ли так что он быстро вырастет до больших значений, например, 42.0.0?
↑Это вопрос планирования и предвидения развития Вашего ПО. При изменении публичного API следует помнить, что это влечет изменение зависимого ПО, что может быть очень затратно с экономической точки зрения.

→ Как удалять из публичного API устаревшие части?
↑Устаревание кода является неотъемлемой частью разработки ПО и часто необходимо для успешного развития. Когда вы помечаете часть публичного ПО, как устаревшее, вам необходимо выпустить минимум один минорный релиз, чтобы переход на новый код был плавным, и подробно описать в документации произведенные изменения.

→ Есть ли ограничение на длину строки версии?
↑Данная спецификация не накладывает никаких ограничений. Просто используйте здравый смысл.

Вольный перевод с дополнениями для Оригинал

Оказалось все вернуть - довольно легко. За отображение в нижней полосе запущенных окошек отвечает апплет Window-List. После apt-get upgrade он почему-то был отключен. Чтобы его вернуть на место надо нажать Alt и кликнуть правой клавишей мыши по нижней полоске - откроется контекстное меню! Выбираем "Добавить на панель", находим в окне со списком апплетов апплет Window-List, выбираем его и нажимаем на кнопку добавить и вуаля! Теперь между окошками можно переключаться с помощью мышки!

Способ почерпнул тут.

В очередной раз вместо того чтобы поработать над сайтом, приходится лезть в глубины убунты и ковыряться, ковыряться и ковыряться...

Сегодня мне понадобилась программулина из раздела "Прочие" Главного меню. Я по-привычке нажал в левом верхнем углу экрана на "Приложения", начал глазами искать раздел "Прочие" и... не нашел. Естественно я открыл редактор Главного меню и увидел, что меню "Прочие" должно отображаться, но его почему-то не было. Вообще логика работы конфигуратора Главного меню такая: если у пункта меню нет активных (с установленной галочкой) подпунктов, то данный пункт не отображается. В моем случае была целая куча активных подпунктов, но сам пункт не отображался.

Странно подумал я и закрыл редактор. Это было ошибкой, ибо меню "Приложения" перестало открываться целиком. Полазив по интернетам я нашел, что окно для конфигурирования Главного меню запускается командой alacarte:

[moon:~] % alacarte                                                                                                                            [0:05]
 
(alacarte:443): Gtk-CRITICAL **: gtk_accel_label_set_accel_closure: assertion 'gtk_accel_group_from_accel_closure (accel_closure) != NULL' failed
 
(alacarte:443): Gtk-CRITICAL **: gtk_accel_label_set_accel_closure: assertion 'gtk_accel_group_from_accel_closure (accel_closure) != NULL' failed
Traceback (most recent call last):
  File "/usr/bin/alacarte", line 26, in <module>
    main()
  File "/usr/share/alacarte/Alacarte/MainWindow.py", line 471, in main
    app.setMenuBasename(basename)
  File "/usr/share/alacarte/Alacarte/MainWindow.py", line 66, in setMenuBasename
    self.editor = MenuEditor(menu_basename)
  File "/usr/share/alacarte/Alacarte/MenuEditor.py", line 36, in __init__
    self.load()
  File "/usr/share/alacarte/Alacarte/MenuEditor.py", line 49, in load
    if not self.tree.load_sync():
gi._glib.GError: Ошибка в строке 1 на символе 1: Документ был пуст или содержал только пробелы

А ошибка эта означает что все данные о меню были стерты. Сам файлик с настройками должен называться

[moon:~] % ll ~/.config/menus/gnome-applications.menu

но у меня был только этот

[moon:~] % ll ~/.config/menus/gnome-flashback-applications.menu

я удалил его (он все равно был пуст) и запустил alacarte повторно. И о чудо! Конфигуратор Главного меню заработал!
Он заработал, но редактирование пунктов меню не давало результатов. Чем хорош линукс так это наличием альтернативных вариантов. В качестве альтернативы alacarte был выбран menulibre.

[moon:~] % sudo apt-get install menulibre

Кстати, он мне больше понравился, чем alacarte! А чем понравился? Да хотя бы тем, что отображает информацию о запускаемых программах для каждого пункта меню, а также предлагает сохранить изменения меню.
Но и после редактирования Главного меню через menulibre - меню "Приложения" не заработало, что натолкнуло на мысль о необходимости перезагрузки, хотя это очень не характерно для линукса.

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

Все манипуляции проделывались в Ubuntu 14.04
Версия Gnome - хз.

А в логах было примерно так:

17:13:50,867 | WARN | rint Extender: 1 | FeaturesServiceImpl | 27 - org.apache.karaf.features.core - 2.2.11 | Unable to add features repository mvn:com.example/artefact.deploy/1.0.0-SNAPSHOT/xml/features at startup
java.lang.RuntimeException: URL [mvn:com.example/artefact.deploy/1.0.0-SNAPSHOT/xml/features] could not be resolved.
...

Это было очень подозрительно! Надо было проверить есть ли бандл в локальном репозитарии .m2/repository

Бандл был на месте, в полной сохранности, а значит, это Servicemix почему-то перестал видеть локальный репозитарий maven. Настройки доступа к maven хранятся в директории Servicemix в файле конфигурации etc/org.ops4j.pax.url.mvn.cfg
Беглый осмотр не выявил каких-то явных косяков (правда я не особо-то и разбираюсь в этом файле конфигурации), поэтому решено было включить DEBUG уровень логов и смотреть, где же Servicemix пытается найти мою фичу. К слову сказать, настройки логирования находятся рядышком в etc/org.ops4j.pax.logging.cfg

После перезапуска микса, в логах (data/log/servicemix.log) перед RuntimeException было видно что система пытается найти эту фичу, но по очень странному пути

17:37:10,814 | DEBUG | rint Extender: 2 | Connection | 2 - org.ops4j.pax.url.mvn - 1.2.8 | Could not download [Version [1.0.0-SNAPSHOT] from URL [file:/D:/apache-servicemix-4.5.3/$%7Buser.home%7D/.m2/repository/com/example/artefact/1.0.0-SNAPSHOT/artefact-1.0.0-SNAPSHOT-features.xml]]

Какой-то непонятный локальный url...

Тут сделаем отступление!
В etc/org.ops4j.pax.url.mvn.cfg два параметра отвечают за работу с локальным репозитарием maven'a - это org.ops4j.pax.url.mvn.settings и org.ops4j.pax.url.mvn.localRepository

org.ops4j.pax.url.mvn.settings - это путь к settings.xml maven'a из которого Servicemix берет путь к локальному репозитарию и список maven репозитариев, если этот список явно не определен с помощью параметра org.ops4j.pax.url.mvn.repositories. По умолчанию setting.xml Servicemix ищет в ${user.home}/.m2/settings.xml, затем в ${maven.home}/conf/settings.xml, затем в ${M2_HOME}/conf/settings.xml

org.ops4j.pax.url.mvn.localRepository позволяет указать путь к локальному репозитарию. Значение по-умолчанию System.getProperty( "user.home" ) + "/.m2/repository". Значение по-умолчанию применяется только, если путь к локальному репозитарию не был найден в .m2/settings.xml...

Оба этих параметра у меня закомментированы, т.е. применяются значения по умолчанию.

Тут-то меня и осенило, как я мог поломать видимость локального репозитария maven'a из Servicemix! Я действительно недавно экспериментировал с настройками в .m2/settings.xml и действительно добавил туда:

<localRepository>${user.home}/.m2/repository</localRepository>

Что же сделал Servicemix после того как я добавил эту строчку в .m2/settings.xml ? Он нашел эту строчку и не стал использовать значение по-умолчанию параметра org.ops4j.pax.url.mvn.localRepository. При этом найти-то он нашел, а вот правильно распарсить не смог. Тут для меня большая загадка, почему у Servicemix не получилось вытащить путь, но проблемы как минимум 2:
1) Servicemix попытался распарсить конструкцию ${user.home} и почему-то не сумел, т.е. у него получилось $%7Buser.home%7D, вместо значения переменной окружения user.home
2) Почему-то в начало пути было добавлено значение переменной окружения SM_HOME (хотя тут я не уверен).

Проблема решилась как только я закомментировал элемент localRepository в .m2/settings.xml !