Спасибо, «вкусно» написано, сразу почему-то захотелось пойти потыкать палкой в ту сторону — а то про Go вяло почитывал, а тут вполне понятный кейс с хорошим результатом. Даже на два порядка меньшее итоговое ускорение — уже интересно :) плюс более актуальная архитектура…
Такая просьба — когда говорите про ручное обновление, имеет смысл в конец добавлять «очевидную» команду перезапуска службы (systemctl restart exim), а то кто-нибудь в пылу обновления скопипастит (хм) и успокоится на этом, забыв перезапустить :)
Что касается первого дня — всё верно, в koji пакет появляется раньше чем в стабильной ветке, тестирование ещё долго шло :)) судя по логу — https://bugzilla.redhat.com/show_bug.cgi?id=1756656 — для EPEL 7 закончилось только позавчера вечером (почти через 4 дня после начала).
Вы правы, вообще-то с точки зрения исходной проблемы
Оказывается у вас почему-то нет доступа в папочку, а у автора слайде он есть. И начинается
в таком случае если в целом доступ к репозиторию есть то сделать себе копию и исправить до отправки клиенту можно; а потом отправить merge request, если нет «доступа к папочке» (в данном случае к записи в master).
Всё-таки думается что описанная ситуация возможна, т.к. неправильно как-то если доступ есть у всех и ко всему — иначе, условно, клинеры придут и вместе с пылью код почистят) Или в прод пасхалок насуют.
Так что там где разграничение прав доступа есть, ситуация возможна.
Но это явно не уникальная проблема описываемого тут подхода, не вижу причин почему с sharepoint и пр ситуация была бы иная (бесконтрольность vs проблема отсутствия доступа к неким материалам, если доступ забыли дать).
Реально интересная штука, спасибо!
Вопрос: а мне одному там в примере «An example of a sequence diagram» не хватает стрелочек на визуализации? Конкретно в «John->Bob: How about you?» вообще не понять, откуда куда сигнал идёт. Что я упустил?..
Ситуация возможна, да. Но сразу вопрос — скажите пожалуйста, а с тем же sharepoint никогда не сталкивались с ограничением прав? Все могут всё что угодно редактировать? ;)
По идее такая ситуация возможна в большинстве подобных систем (обратная сторона медали, куда же без неё).
Тут речь о целевой аудитории, кому что ближе. Кому-то проще мышкой и визуально, а кому-то проще клавиатурой исходник написать, чтобы визуальная часть сама собралась.
Что касается последнего пункта — проблем с картинкой и стрелочкой — так тут инструмент можно сказать на коленке придуман и ещё не успел обрасти фичами полезными.
И тест на наличие картинки в нужной локации, и моментальный визуальный превью диаграмм — это же вообще не проблема.
Так же как в sharepoint нужные фичи допиливаются (у знакомых в относительно небольшой конторе целый отдел этим занят), так и тут при желании можно любую нужную обвязку вокруг накидать быстро.
Вплоть до того что условно через чат-бота в мессенджере писать/редактировать презентацию и диаграммы (!!!) :)
Думаю что Вы согласитесь что слово «невозможно» тут только раззадорить может ;) Руки так и тянутся потратить время впустую но «сделать невозможное возможным».
Варианты-то разные есть даже с закрытыми форматами — в конце концов можно перенести всё кусками, банально нарезав на скриншоты и вставив их как картинки. Неоптимально, но уже не невозможно. А раз можно руками, можно и автоматом, RPA в помощь. Ну и наверняка более оптимальные пути найдутся.
К вопросу «зачем» — не знаю, потому и говорю что бесполезно :) Но мало ли, вдруг кому-то именно powerpoint-файл. Пусть не унывают)
Про github Ваш спасибо, заходил уже туда, смотрел — всё-таки прикольно читать схему graphviz, и только потом понимать что её можно и визуально глянуть)) (на том же GraphvizOnline)
Спасибо за идею и подачу, на мой взгляд весьма изящный вышел подход, и Вы хорошо его описали — обязательно протестируем такой способ при подготовке презентации группой людей, которым код ближе чем тыканье мышкой в powerpoint :)
Должно очень хорошо зайти, всё-таки у версионирования тут будет огромный плюс по сравнению с пересылкой файлов туда-сюда.
И отдельный плюс — разделение информации и представления. Вот уж где мучение для многих программистов, имеющих своё специфическое (утилитарное) представление о красоте презентации ;) не совпадающее с тем что от них иногда требуют в оформлении.
Кстати, по идее можно на выходе не только pdf, но наверно и в powerpoint формат скомпилировать, не изучали вопрос?
Замечательно, ура!
Ранее запущенные — например, ребут.
Или остановить службу (service exim stop) и убедиться что процессы все отключатся (ps aux | grep [e]xim будет пустым). Если какие-то не отключатся, то killall -9 exim или адресно kill -9 [pid процесса], пока запущенных не останется.
Ну и тогда уже service exim start, там свежий 4.92 заведомо будет.
Согласен, но не забудьте что «Должно было завершить» и «завершило» не всегда совпадает :)… Например, посмотрите на скрипт фикса от firstvds — там killall вызывается 4 раза подряд, как думаете почему? Вот так и тут. Лучше перестраховаться, на мой взгляд.
Про ключ годичной давности — отлично, только пожалуйста убедитесь что это Ваш ключ.
Если это чей-то чужой ключ,… гм гм, я думаю от анекдота воздержусь :)
daykkin вот туда же сослался, откуда я скопипастил — только в отличие от меня он верно подметил что строка с curl к обсуждаемому там вопросу относилась, но не к Вашему :)
По остальным вопросам — daykkin так обновился, так что если у Вас та же ситуация, тоже обновитесь.
Другие службы обновлять оно не должно (т.е. если тот же curl не упомянете, его обновлять не будет)
Что касается первого дня — всё верно, в koji пакет появляется раньше чем в стабильной ветке, тестирование ещё долго шло :)) судя по логу — https://bugzilla.redhat.com/show_bug.cgi?id=1756656 — для EPEL 7 закончилось только позавчера вечером (почти через 4 дня после начала).
in testing 14 hours ago
days to stable 14
Т.е. через пару недель всё будет? ;)
Спешу однако обрадовать — 4.92.2 уже устарела / Хабр
Теперь опять Ваша очередь :)
в таком случае если в целом доступ к репозиторию есть то сделать себе копию и исправить до отправки клиенту можно; а потом отправить merge request, если нет «доступа к папочке» (в данном случае к записи в master).
Так что там где разграничение прав доступа есть, ситуация возможна.
Но это явно не уникальная проблема описываемого тут подхода, не вижу причин почему с sharepoint и пр ситуация была бы иная (бесконтрольность vs проблема отсутствия доступа к неким материалам, если доступ забыли дать).
Вопрос: а мне одному там в примере «An example of a sequence diagram» не хватает стрелочек на визуализации? Конкретно в «John->Bob: How about you?» вообще не понять, откуда куда сигнал идёт. Что я упустил?..
По идее такая ситуация возможна в большинстве подобных систем (обратная сторона медали, куда же без неё).
Но тут речь шла про выложенные на github файлы :) Конкретно — https://github.com/inponomarev/csa-hb/blob/master/src/main/asciidoc/csa.adoc
Что касается последнего пункта — проблем с картинкой и стрелочкой — так тут инструмент можно сказать на коленке придуман и ещё не успел обрасти фичами полезными.
И тест на наличие картинки в нужной локации, и моментальный визуальный превью диаграмм — это же вообще не проблема.
Так же как в sharepoint нужные фичи допиливаются (у знакомых в относительно небольшой конторе целый отдел этим занят), так и тут при желании можно любую нужную обвязку вокруг накидать быстро.
Вплоть до того что условно через чат-бота в мессенджере писать/редактировать презентацию и диаграммы (!!!) :)
Варианты-то разные есть даже с закрытыми форматами — в конце концов можно перенести всё кусками, банально нарезав на скриншоты и вставив их как картинки. Неоптимально, но уже не невозможно. А раз можно руками, можно и автоматом, RPA в помощь. Ну и наверняка более оптимальные пути найдутся.
К вопросу «зачем» — не знаю, потому и говорю что бесполезно :) Но мало ли, вдруг кому-то именно powerpoint-файл. Пусть не унывают)
Про github Ваш спасибо, заходил уже туда, смотрел — всё-таки прикольно читать схему graphviz, и только потом понимать что её можно и визуально глянуть)) (на том же GraphvizOnline)
Должно очень хорошо зайти, всё-таки у версионирования тут будет огромный плюс по сравнению с пересылкой файлов туда-сюда.
И отдельный плюс — разделение информации и представления. Вот уж где мучение для многих программистов, имеющих своё специфическое (утилитарное) представление о красоте презентации ;) не совпадающее с тем что от них иногда требуют в оформлении.
Кстати, по идее можно на выходе не только pdf, но наверно и в powerpoint формат скомпилировать, не изучали вопрос?
Кто не в курсе прикола — население 3 прибалтийских республик составляет около 6 млн человек, а в Бангладеше численность населения больше чем в России.
p.s. Историческая карта тоже крайне любопытна. Наглядно видно как что заселялось-менялось…
А спасибо не мне а daykkin за то что поднял и дожал этот вопрос :)
Ранее запущенные — например, ребут.
Или остановить службу (service exim stop) и убедиться что процессы все отключатся (ps aux | grep [e]xim будет пустым). Если какие-то не отключатся, то killall -9 exim или адресно kill -9 [pid процесса], пока запущенных не останется.
Ну и тогда уже service exim start, там свежий 4.92 заведомо будет.
Про ключ годичной давности — отлично, только пожалуйста убедитесь что это Ваш ключ.
Если это чей-то чужой ключ,… гм гм, я думаю от анекдота воздержусь :)
Как Вы уже проверили, теперь /usr/sbin/exim стал версии 4.92, всё ок.
Для спокойствия можете проверить, не запущен ли где-то exim из другой локации,
там должен быть только /usr/sbin/exim
И — не забудьте все ранее запущенные процессы exim перезапустить! Т.к. при обновлении на диске в памяти могли остаться старые дырявые.
По остальным вопросам — daykkin так обновился, так что если у Вас та же ситуация, тоже обновитесь.
Другие службы обновлять оно не должно (т.е. если тот же curl не упомянете, его обновлять не будет)