https://opennet.ru/openforum/vsluhforumID3/115614.html В соответствии с релизным циклом вышла (http://lists.mindrot.org/pipermail/openssh-unix-dev/2018-October/037272.html) новая версия операционной системы общего назначения OpenBSD 6.4 (https://www.openbsd.org/). Самые примечательные изменения (https://www.openbsd.org/64.html) в новой версии:<br><br><br>- Множество добавлений для платформы arm64;<br>- Улучшения в удобстве использования Wi-Fi;<br>- Продолжение работы над избавлением сетевого стека от использования глобальной блокировки ядра;<br>- Cистемный вызов unveil() (https://www.opennet.ru/opennews/art.shtml?num=49042), который предоставляет новый способ изоляции доступа к файловой системе;<br>- Механизм защиты RETGUARD (https://www.opennet.ru/opennews/art.shtml?num=48730), нацеленный на усложнение выполнения эксплоитов, построенных с использованием заимствования кусков кода и приёмов возвратно-ориентированного программирования; <br>- Переработка синтаксиса OpenSMTPD для значительного увеличения гибкости не в ущерб удобству;<br><br><br><br><br><br>К сожалению, полагающаяся песня к https://opennet.ru/openforum/vsluhforumID3/115614.html#149 Sun, 01 Mar 2020 15:29:56 GMT я- простой юзер, всех моих навыков программирования: ассемблер- лет тридцать назад, да паскаль- лет пять спустя, а вершиной моего любительского творчества стала библиотека для мышки, со встроенным графическим редактором курсоров под дос. так что напиши- это не ко мне. дурак я, ферштейн? но я такой не один. при этом прекрасно понимаю чего мне от оси надо, бо только юзеры, с их широкими низменными запросами, и знают какой должна быть ось. а вот уровень этих юзеров к делу не относится. так что я могу принять аргументом только "она не для широкой публики- в целом, и не для тебя- в частности". и тут мне останется пожелать удачи вам на этом трудном и, в конце концов, тупиковым пути- найти свою нишу под такие вводные как у опёнка.<br><br>почему я продолжаю ей пользоваться? лет пятнадцать назад надо было сделать себе роутер. уже не помню по какой причине именно сделать, а не просто купить готовую мыльницу(возможно их тогда не существовало. склероз). я купил(так как жил с полярными медведями) три бсдехи- опёнок37, фрю и н https://opennet.ru/openforum/vsluhforumID3/115614.html#148 Sat, 03 Nov 2018 08:17:51 GMT &gt; :)) Видел я таких разработчиков... &#171;Пушать&#187; на GitHub они умеют, да.<br><br>Ну вот чтобы начать что-то "делать" - вам предварительно от этих элементарных навыков<br>их нужно будет отучить.<br><br>&gt; В том, что они обычно есть. Может, это только мой личный опыт, конечно.<br><br>Тогда конфликты надо будет править, я описал как. Можно pull сделать в самом начале,<br>как для cvs. Хотя все-равно будет шанс нарваться на необходимость сделать pull еще<br>раз, перед push. Как, впрочем, и в случае cvs.<br><br>&gt; Workflow, конечно, с DVCS куда богаче вариантами. Но &#171;больше возможностей&#187; &#8212; <br>&gt; опять же, не всегда означает &#171;лучше&#187;.<br><br>Мы опять ушли в сторону. Речь шла о том, что де с git - это сложнее. Выяснилось, как минимум - не<br>сложнее (если считать количество команд).<br><br>&gt; К списку CVS и Subversion добавьте ещё все остальные VCS, кроме Гитля Д'Артаньяна.<br><br>В ртути так, да (полагаю, с оглядкой на svn). Про другие - я не был бы так уверен. Как в arch - я, например, не помню. Да и не важно, техническ https://opennet.ru/openforum/vsluhforumID3/115614.html#147 Fri, 02 Nov 2018 16:54:17 GMT &gt;&gt;&gt; Да не надо ничего дорабатывать, максимум - выучиться командам.<br>&gt;&gt; Тогда вы сами себе противоречите словами &#171;если надо &#8212; сделаем&#187;.<br>&gt; Нет, команды _уже_ сделаны. Максимум - их надо выучить. И, <br>&gt; кстати, современный мир таков, что учить их <br>&gt; даже не надо - разработчики уже рождаются с встроенными навыками работы в <br>&gt; git.<br><br>:)) Видел я таких разработчиков... &#171;Пушать&#187; на GitHub они умеют, да. А вот о том, что можно обходиться и без GitHub знают уже далеко не все.<br><br>&gt;&gt; Править исходники, не обновив их, обычно плохая идея &#8212; сводить больше и <br>&gt;&gt; больнее придётся.<br>&gt; Если конфликтов нет - в чем проблема? Описанный workflow вообще кривой <br>&gt; - но это <br>&gt; именно то, что вы предложили для cvs.<br><br>В том, что они обычно есть. Может, это только мой личный опыт, конечно.<br><br>Workflow, конечно, с DVCS куда богаче вариантами. Но &#171;больше возможностей&#187; &#8212; опять же, не всегда означает &#171;лучше&#187;. На какой-нибудь АЭС регламент очень чётко требует выполнять даже с https://opennet.ru/openforum/vsluhforumID3/115614.html#146 Fri, 02 Nov 2018 09:40:30 GMT &gt;&gt; Да не надо ничего дорабатывать, максимум - выучиться командам.<br>&gt; Тогда вы сами себе противоречите словами &#171;если надо &#8212; сделаем&#187;.<br><br>Нет, команды _уже_ сделаны. Максимум - их надо выучить. И, кстати, современный мир таков, что учить их<br>даже не надо - разработчики уже рождаются с встроенными навыками работы в git.<br><br>&gt; Править исходники, не обновив их, обычно плохая идея &#8212; сводить больше и <br>&gt; больнее придётся.<br><br>Если конфликтов нет - в чем проблема? Описанный workflow вообще кривой - но это<br>именно то, что вы предложили для cvs.<br><br>&gt; Одна только загадочная логика, когда <br>&gt; с помощью branch можно сделать угодно, кроме собственно переключения веток, чего стоит.<br><br>Так оно не для переключения веток. Оно для управления ветками. Непривычно для<br>изнасилованных cvs/svn - возможно. Но нелогично - нет, конечно.<br><br>&gt;&gt;&gt; И когда задачи в основном вида <br>&gt;&gt;&gt; &#171;поправить вот эту мелочь&#187; и &#171;добавить вот такую фичу на двести <br>&gt;&gt;&gt; строчек&#187;, подойдёт любая VCS, вообще любая.<br> https://opennet.ru/openforum/vsluhforumID3/115614.html#145 Fri, 02 Nov 2018 09:00:28 GMT &gt;&gt;&gt; Тогда git (да и hg тем более) - как раз отвертка валшебная.<br>&gt;&gt;&gt; Если надо тоньше - сделаем тоньше, если еще как-то удобнее <br>&gt;&gt;&gt; сделать - будет. Это в cvs насадка навсегда одна и <br>&gt;&gt;&gt; еще стержень кривой.<br>&gt;&gt; Да можно, можно всё это в случае с Git, кто ж спорит.<br>&gt;&gt; Только вы же сами говорите &#8212; &#171;если надо &#8212; сделаем&#187;.<br>&gt; Да не надо ничего дорабатывать, максимум - выучиться командам.<br><br>Тогда вы сами себе противоречите словами &#171;если надо &#8212; сделаем&#187;.<br><br>&gt;[оверквотинг удален]<br>&gt;&gt; git ci ...<br>&gt;&gt; git push <br>&gt; Нет, это делают не так (начиная с того, что git up - <br>&gt; это какой-то ваш алиас, вероятно.<br>&gt; Делают проще: <br>&gt; emacs ...<br>&gt; git commit ..<br>&gt; git push ...<br>&gt; Если git push заругался на наличие в основном репе изменений, отсутствующих локально <br>&gt; - делаем git pull --rebase и уже потом push.<br><br>Править исходники, не обновив их, обычно плохая идея &#8212; сводить больше и больнее придётся.<br><br>&gt;&gt; Можно избавиться от отдельного &#171;git up&#187;, поправив конфиг.<br>&gt; https://opennet.ru/openforum/vsluhforumID3/115614.html#144 Fri, 02 Nov 2018 08:35:34 GMT &gt;[оверквотинг удален]<br>&gt;&gt; cvs ci <br>&gt;&gt; git up <br>&gt;&gt; git ci ...<br>&gt; Ой, страшно. Страшно оригинально и нОво. Ой, ой.<br>&gt;&gt; Можно избавиться от отдельного &#171;git up&#187;, поправив конфиг. Можно избавиться от <br>&gt;&gt; отдельного &#171;git push&#187;, добавив commit hook или какую-то ещё свою обёртку.<br>&gt;&gt; Но и то, и другое &#8212; дополнительные усилия, которые не требуются <br>&gt;&gt; в случае CVS. Никакого волшебства тут нет, только потраченные (или сэкономленные) <br>&gt;&gt; разработчиком время и усилия.<br>&gt; Ты главное не перенапрягись, выдумывая команды git.<br><br>Переклинило. Rebase там, конечно же. Писал, пользуясь в этот момент Mercurial и Subversion, вот оно и. Прошу прощения.<br> https://opennet.ru/openforum/vsluhforumID3/115614.html#143 Thu, 01 Nov 2018 16:03:12 GMT &gt;&gt; Тогда git (да и hg тем более) - как раз отвертка валшебная.<br>&gt;&gt; Если надо тоньше - сделаем тоньше, если еще как-то удобнее <br>&gt;&gt; сделать - будет. Это в cvs насадка навсегда одна и <br>&gt;&gt; еще стержень кривой.<br>&gt; Да можно, можно всё это в случае с Git, кто ж спорит. <br>&gt; Только вы же сами говорите &#8212; &#171;если надо &#8212; сделаем&#187;.<br><br>Да не надо ничего дорабатывать, максимум - выучиться командам.<br><br>&gt; Как это делают в CVS: <br><br>Задача, как я понял, обновить рабочее дерево, что-то поредактировать и закоммитить?<br><br>&gt; Как это делают в Git: <br>&gt; git pull <br>&gt; git up <br>&gt; vi ...<br>&gt; git ci ...<br>&gt; git push <br><br>Нет, это делают не так (начиная с того, что git up - это какой-то ваш алиас, вероятно.<br><br>Делают проще:<br>emacs ...<br>git commit ..<br>git push ...<br><br>Если git push заругался на наличие в основном репе изменений, отсутствующих локально - делаем git pull --rebase и уже потом push.<br><br>&gt; Можно избавиться от отдельного &#171;git up&#187;, поправив конфиг.<br><br>Из коробки избавились:<br>$ git up --help<br>git: 'up' is not https://opennet.ru/openforum/vsluhforumID3/115614.html#142 Thu, 01 Nov 2018 12:49:40 GMT &gt;[оверквотинг удален]<br>&gt;&gt; еще стержень кривой.<br>&gt; Да можно, можно всё это в случае с Git, кто ж спорит. <br>&gt; Только вы же сами говорите &#8212; &#171;если надо &#8212; сделаем&#187;. То <br>&gt; есть &#8212; дорабатывать надо. Самый очевидный пример &#8212; ниже.<br>&gt; Как это делают в CVS: <br>&gt; cvs up <br>&gt; vi ...<br>&gt; cvs ci <br>&gt; git up <br>&gt; git ci ...<br><br>Ой, страшно. Страшно оригинально и нОво. Ой, ой.<br><br>&gt; Можно избавиться от отдельного &#171;git up&#187;, поправив конфиг. Можно избавиться от <br>&gt; отдельного &#171;git push&#187;, добавив commit hook или какую-то ещё свою обёртку. <br>&gt; Но и то, и другое &#8212; дополнительные усилия, которые не требуются <br>&gt; в случае CVS. Никакого волшебства тут нет, только потраченные (или сэкономленные) <br>&gt; разработчиком время и усилия.<br><br>Ты главное не перенапрягись, выдумывая команды git.<br> https://opennet.ru/openforum/vsluhforumID3/115614.html#141 Thu, 01 Nov 2018 12:18:17 GMT &gt; Тогда git (да и hg тем более) - как раз отвертка валшебная. <br>&gt; Если надо тоньше - сделаем тоньше, если еще как-то удобнее <br>&gt; сделать - будет. Это в cvs насадка навсегда одна и <br>&gt; еще стержень кривой.<br><br>Да можно, можно всё это в случае с Git, кто ж спорит. Только вы же сами говорите &#8212; &#171;если надо &#8212; сделаем&#187;. То есть &#8212; дорабатывать надо. Самый очевидный пример &#8212; ниже.<br><br>Как это делают в CVS:<br><br>cvs up<br>vi ...<br>cvs ci<br><br>Как это делают в Git:<br><br>git pull<br>git up<br>vi ...<br>git ci ...<br>git push<br><br>Можно избавиться от отдельного &#171;git up&#187;, поправив конфиг. Можно избавиться от отдельного &#171;git push&#187;, добавив commit hook или какую-то ещё свою обёртку. Но и то, и другое &#8212; дополнительные усилия, которые не требуются в случае CVS. Никакого волшебства тут нет, только потраченные (или сэкономленные) разработчиком время и усилия.<br><br>Если уж за что и хвалить Git из коробки, так это, например, за &#171;add -p&#187; &#8212; в случае с CVS я (и не только я) как ра