The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 , opennews (??), 20-Окт-18, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


3. "Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 "  +7 +/–
Сообщение от Megabit (ok), 20-Окт-18, 00:39 
Не могу понять, чем такие как Вы недовольны?!? Процесс разработки идёт! Вносятся очень много исправлениий-новшевств, люди работают для себя и Вас - а Вы всё не довольны... ( Может пора что-либо от себя вложить - дабы словопоносом потом не гадить?!?.. Блин!.... Простите, наболело... (((
Ответить | Правка | Наверх | Cообщить модератору

37. "Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 "  +2 +/–
Сообщение от Акакжев (?), 20-Окт-18, 13:45 
Они и сами не понимают, что делают. Когда-то увидели подобную "критику", а дурной пример заразителен.
Ответить | Правка | Наверх | Cообщить модератору

74. "Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 "  –2 +/–
Сообщение от BABUTemail (??), 22-Окт-18, 09:50 
не понимаю, чем такие как ты, которые опёнок в глаза не видели, всегда довольны :\ я его пользую лет пятнадцать, и непонаслышке знаю, насколько это уб_людочная система, пригодная только для роутера, но и в этом случае с большими оговорками. да, по сравнению с рукожопыми иптаблесами, пф- это космический корабль, а не китайская петарда, но и в нём многого недостаёт, функционал его слаб и никак не развивается. хотя, казалось бы, можно было полезное портануть с нетки. файловая система до первого обрыва питания, хотя, казалось бы, можно было портануть полезное со стрекозы. поддержки вифи, на том уровне, когда это можно использовать, нет, хотя, казалось бы, дрова существуют, надо лишь портануть.
я только сейчас понял почему пнули тео, и полностью одобряю такое решение. ведь он не созидатель, он разрушитель, он ведёт этот форк, последовательно вырезая из него подсистемы, да, пусть неидеальные, но работающие- как тот же блютуз, к виду "hello, world" с двумя remote holes
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

111. "Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 "  +/–
Сообщение от PereresusNeVlezaetBuggy (ok), 23-Окт-18, 11:20 
> не понимаю, чем такие как ты, которые опёнок в глаза не видели,
> всегда довольны :\ я его пользую лет пятнадцать, и непонаслышке знаю,
> насколько это уб_людочная система, пригодная только для роутера, но и в
> этом случае с большими оговорками. да, по сравнению с рукожопыми иптаблесами,
> пф- это космический корабль, а не китайская петарда, но и в
> нём многого недостаёт, функционал его слаб и никак не развивается. хотя,
> казалось бы, можно было полезное портануть с нетки.

Портаните, раз это так легко. Patches are welcome.

> файловая система до первого обрыва питания,

За всю мою практику видел всего лишь одно капитальное разрушение FFS, когда пришлось форматировать раздел. NTFS — по пальцам двух рук. ext2/3/4 — считать давно надоело.

Если же вы про то, что там нет журнала и восстановление, особенно не на SSD, занимает много времени — тут да, patches are welcome.

> хотя, казалось бы, можно было портануть полезное со
> стрекозы.

Портирование Hammer было в том числе в GSoC. Да и сам я интересовался этим вопросом... Patches are welcome.

> поддержки вифи, на том уровне, когда это можно использовать, нет,

Странно, и как только другие люди им пользуются. Впрочем, если вы знаете, как сделать лучше — patches are welcome.

> хотя, казалось бы, дрова существуют, надо лишь портануть.

Действительно, внутри себя ядра всех ОС ведь одинаковые, лицензии на код не имеют значения, наличие документации не имеет значения... Ну так тогда patches are welcome, где они?

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

Стек Bluetooth выкинули потому что его никто не поддерживал. Всё просто. Если хотите Bluetooth — ну, вы поняли, да?

> к виду "hello, world" с двумя remote holes

То есть вы 15 лет пользуетесь системой, которую для вас не просто бесплатно, но ещё и без каких-либо серьёзных ограничений, делают другие люди, рассказываете про её ужасы и какая она отвратительная, но при этом продолжаете ей пользоваться? Как-то лицемерно, не находите? Если есть другие ОС, в которых вам всё нравится, зачем вы 15 лет кушаете кактус? Понять хочется именно это. Или вы живёте в маленьком городе, где единственная местная ИТ-фирма работает только на OpenBSD? Что это за город, не подскажете, мне даже интересно. :)

Ответить | Правка | Наверх | Cообщить модератору

114. "Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 "  –1 +/–
Сообщение от myhand (ok), 23-Окт-18, 16:45 
> Портаните, раз это так легко. Patches are welcome.

Beware CVS.  Шел 2018 год.

Ответить | Правка | Наверх | Cообщить модератору

118. "Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 "  +/–
Сообщение от PereresusNeVlezaetBuggy (ok), 24-Окт-18, 22:52 
>> Портаните, раз это так легко. Patches are welcome.
> Beware CVS.  Шел 2018 год.

А что, «cvs diff» чем-то сильно отличается от «git diff» (ну, кроме дурной привычки последнего добавлять «a/» и «b/»)? Или patch(1) как-то иначе работает? Или исходники, полученные из CVS, работают как-то иначе? Или cvsync запретили?..

Ответить | Правка | Наверх | Cообщить модератору

119. "Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 "  +/–
Сообщение от myhand (ok), 24-Окт-18, 23:33 
>>> Портаните, раз это так легко. Patches are welcome.
>> Beware CVS.  Шел 2018 год.
> А что, «cvs diff» чем-то сильно отличается от «git diff»

Не самая часто используемая команда, прямо скажем.

> Или исходники, полученные из CVS, работают как-то иначе? Или
> cvsync запретили?..

Да, наверно, можно жить вовсе без системы контроля версий.  Но лично я бы в XXI веке жить без команд branch, merge, checkout (c -b) и bisect - не захотел бы категорически.

Ответить | Правка | Наверх | Cообщить модератору

120. "Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 "  +/–
Сообщение от PereresusNeVlezaetBuggy (ok), 26-Окт-18, 15:32 
>>>> Портаните, раз это так легко. Patches are welcome.
>>> Beware CVS.  Шел 2018 год.
>> А что, «cvs diff» чем-то сильно отличается от «git diff»
> Не самая часто используемая команда, прямо скажем.

«Bentley» тоже встречаются реже, чем «Калина», но... ;) Так что частота использования — не очень удачный аргумент.

>> Или исходники, полученные из CVS, работают как-то иначе? Или
>> cvsync запретили?..
> Да, наверно, можно жить вовсе без системы контроля версий.  Но лично
> я бы в XXI веке жить без команд branch, merge, checkout
> (c -b) и bisect - не захотел бы категорически.

Ветки в CVS имеются, если уж на то пошло. ;)

Главное же, о чём я говорю — чтобы подготовить и отправить патч в OpenBSD, merge и branch как бы и не нужны. Это уже проблемы комиттеров будут. Ну а чтобы стать комиттером, надо какой-то авторитет сначала заработать, сами понимаете... Да, впрочем, в ядре Linux всё то же самое. :)

Ответить | Правка | Наверх | Cообщить модератору

121. "Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 "  +/–
Сообщение от myhand (ok), 26-Окт-18, 20:27 
>>> Или исходники, полученные из CVS, работают как-то иначе? Или
>>> cvsync запретили?..
>> Да, наверно, можно жить вовсе без системы контроля версий.  Но лично
>> я бы в XXI веке жить без команд branch, merge, checkout
>> (c -b) и bisect - не захотел бы категорически.
> Ветки в CVS имеются, если уж на то пошло. ;)

Главное - никому не говорите.  Я хороший, умный, добрый и скромный.  А другие могут и ногами побить.

> Главное же, о чём я говорю — чтобы подготовить и отправить патч
> в OpenBSD, merge и branch как бы и не нужны.

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

> Да, впрочем, в ядре Linux всё то же самое. :)

Категорически уверен, что в ядре Linux таки используют ветки и разработчикам приходится мержить
изменения из апстрима (или других веток).  В общем, как бы нужны.

Ответить | Правка | Наверх | Cообщить модератору

123. "Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 "  +/–
Сообщение от PereresusNeVlezaetBuggy (ok), 26-Окт-18, 23:21 
>>>> Или исходники, полученные из CVS, работают как-то иначе? Или
>>>> cvsync запретили?..
>>> Да, наверно, можно жить вовсе без системы контроля версий.  Но лично
>>> я бы в XXI веке жить без команд branch, merge, checkout
>>> (c -b) и bisect - не захотел бы категорически.
>> Ветки в CVS имеются, если уж на то пошло. ;)
> Главное - никому не говорите.  Я хороший, умный, добрый и скромный.
>  А другие могут и ногами побить.

Хм. Я понимаю, если бы такое про Subversion сказали, там действительно... оригинальный подход. А в CVS всё достаточно привычно должно быть для современного разработчика.

>> Главное же, о чём я говорю — чтобы подготовить и отправить патч
>> в OpenBSD, merge и branch как бы и не нужны.
> Все может быть.  Но обычно они в есть гайде для разработчиков
> на всяких гитхабах.

А причём тут гитхабы? Никто CVS туда и не пытается впихнуть...

>> Да, впрочем, в ядре Linux всё то же самое. :)
> Категорически уверен, что в ядре Linux таки используют ветки и разработчикам приходится
> мержить
> изменения из апстрима  (или других веток).  В общем, как бы нужны.

Ещё раз: вот я нашёл баг в Linux, взял исходники, поправил, сделал diff, отправил этот патч. Если меня не обматерили, и нашёлся ревьюер, а потом ещё и комиттер, то мой патч ушёл в mainline ядро, или что-то по соседству (возможно, не с первой итерации, не суть). Merge между mainline и прочими ядрами — это уже не моя головная боль, или я ошибаюсь?

Ответить | Правка | Наверх | Cообщить модератору

124. "Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 "  +/–
Сообщение от myhand (ok), 27-Окт-18, 11:04 
>>> Главное же, о чём я говорю — чтобы подготовить и отправить патч
>>> в OpenBSD, merge и branch как бы и не нужны.
>> Все может быть.  Но обычно они в есть гайде для разработчиков
>> на всяких гитхабах.
> А причём тут гитхабы?

Притом, что им merge и branch - во как нужны.

> Merge между mainline и прочими ядрами — это уже не
> моя головная боль, или я ошибаюсь?

Не ошибаетесь, пока кто-то не пришел в mainline с рефакторингом или еще как поковырялся в той части,
что затрагивают ваши изменения.

Ответить | Правка | Наверх | Cообщить модератору

126. "Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 "  +/–
Сообщение от PereresusNeVlezaetBuggy (ok), 27-Окт-18, 15:51 
>[оверквотинг удален]
>>>> в OpenBSD, merge и branch как бы и не нужны.
>>> Все может быть.  Но обычно они в есть гайде для разработчиков
>>> на всяких гитхабах.
>> А причём тут гитхабы?
> Притом, что им merge и branch - во как нужны.
>> Merge между mainline и прочими ядрами — это уже не
>> моя головная боль, или я ошибаюсь?
> Не ошибаетесь, пока кто-то не пришел в mainline с рефакторингом или еще
> как поковырялся в той части,
> что затрагивают ваши изменения.

Во-о-от. То есть, ещё раз, «продвинутые» средства управлениями ветками нужны для мейнтейнеров, а не для, скажем так, «одноразовых» источников патчей.

Понятно, что если я добавляю какую-то подсистему, например, то дальше мне её, видимо, и поддерживать.

Ответить | Правка | Наверх | Cообщить модератору

127. "Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 "  +/–
Сообщение от myhand (ok), 27-Окт-18, 21:23 
> Во-о-от. То есть, ещё раз, «продвинутые» средства управлениями ветками нужны
> для мейнтейнеров, а не для, скажем так, «одноразовых» источников патчей.

Да нет же.  Пока ваш одноразовый патч отрецензируют - придут другие очумелые ручки и модифицируют часть кода, что вы трогали.  Потому периодический мерж, а то и git rebase.  На вашей стороне - мейнтейнеры же не нанимались фиксить конфликты в вашем патче.

Ответить | Правка | Наверх | Cообщить модератору

128. "Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 "  +/–
Сообщение от PereresusNeVlezaetBuggy (ok), 27-Окт-18, 21:34 
>> Во-о-от. То есть, ещё раз, «продвинутые» средства управлениями ветками нужны
>> для мейнтейнеров, а не для, скажем так, «одноразовых» источников патчей.
> Да нет же.  Пока ваш одноразовый патч отрецензируют - придут другие
> очумелые ручки и модифицируют часть кода, что вы трогали.  Потому
> периодический мерж, а то и git rebase.  На вашей стороне
> - мейнтейнеры же не нанимались фиксить конфликты в вашем патче.

rebase в не-DVCS как бы отсутствует по определению... ;)

Ответить | Правка | К родителю #127 | Наверх | Cообщить модератору

129. "Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 "  +/–
Сообщение от myhand (ok), 28-Окт-18, 13:43 
Ну как бы речь и шла о git.

Таки нужны "продвинутые средства управления ветками" (тм) кому-то кроме мейнтейнеров или запишем всех GSoC студентов на гитхабчике сразу в мейнтейнеры?)

Ответить | Правка | К родителю #128 | Наверх | Cообщить модератору

130. "Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 "  +/–
Сообщение от PereresusNeVlezaetBuggy (ok), 28-Окт-18, 14:16 
> Ну как бы речь и шла о git.

Речь изначально шла о patches are welcome. Чтобы подготовить (или обновить) патч для OpenBSD достаточно cvs diff — ничем не отличающегося по сути от git diff, hg diff и прочих.

> Таки нужны "продвинутые средства управления ветками" (тм) кому-то кроме мейнтейнеров или
> запишем всех GSoC студентов на гитхабчике сразу в мейнтейнеры?)

Открою страшный секрет: ряд разработчиков OpenBSD использует в работе, в том числе, и git, ведя локальную разработку. На Github есть даже зеркало исходников OpenBSD. Но центральный репозиторий остаётся на CVS, по ряду причин, как то:

* наличие большого количества правок напрямую в репозитории, особенно в старых коммитах (1990-е) ,приводящих к неточностям при миграции.
* в случае повреждения репозитория, починить его можно ручками ­— формат RCS куда удобнее в этом плане, чем бинарные форматы (почти?) всех остальных современных VCS.
* философия централизованного репозитория больше мотивирует не затягивать с коммитами.
* отсутствие желающих реально решать проблемы, связанные с миграцией — это обычному разработчику просто поменять «cvs» на что-то ещё, а Тео и ответственным за отдельные архитектуры и сборку пакетов — переписывать инструментарий, причём так, чтобы у остальных ничего не ломалось.

Я сейчас по разным поводам пользуюсь и CVS, и Subversion, и Git, и Mercurial — и могу точно сказать, что CVS далеко не так плох, как это может казаться. Но таки да — это когда к нему прилагаются cvsutils, cvsync и anoncvs.

Ответить | Правка | К родителю #129 | Наверх | Cообщить модератору

131. "Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 "  –1 +/–
Сообщение от myhand (ok), 28-Окт-18, 18:28 
>> Ну как бы речь и шла о git.
> Речь изначально шла о patches are welcome. Чтобы подготовить (или обновить) патч
> для OpenBSD достаточно cvs diff — ничем не отличающегося по сути
> от git diff, hg diff и прочих.

Ну, может вам везет)  В других проектах - diff'а категорически будет не хватать, по
изложенным выше причинам.

>> Таки нужны "продвинутые средства управления ветками" (тм) кому-то кроме мейнтейнеров или
>> запишем всех GSoC студентов на гитхабчике сразу в мейнтейнеры?)
> Открою страшный секрет: ряд разработчиков OpenBSD использует в работе, в том числе,
> и git, ведя локальную разработку.

Пожалуй и я спалюсь: вообще-то я немножко ерничал, указывая на cvs проекта.  Но таких как-бы сильно немного, учитывая что cvs скорее мертв, чем хоть как-то жив.  Впрочем, вон FreeBDSM - на SVN.

>  * наличие большого количества правок напрямую в репозитории, особенно в старых
> коммитах (1990-е) ,приводящих к неточностям при миграции.
>  * в случае повреждения репозитория, починить его можно ручками — формат
> RCS куда удобнее в этом плане, чем бинарные форматы (почти?) всех
> остальных современных VCS.

Так-так.  Может ну его, такой удобный формат, а завести вместо журналируемую файловую систему и бесперебойник?)  Кстати, сама по себе CVS (где критические операции не атомарны) - вероятно и стала причиной большей части "правок напрямую", не?  И что куда хуже - станет снова.

>  * философия централизованного репозитория больше мотивирует не затягивать с коммитами.

А какая религия запрещает сделать централизованный репозиторий в git?

>  * отсутствие желающих реально решать проблемы, связанные с миграцией

Ну, это может только приемуществами от использования чего-то более нормального.  Помимо упомянутого выше - наверно еще производительность при некоторых операциях.

Ах, да.   Bus factor еще.  CVS-гуру теперь надо разводить специально.

Ответить | Правка | К родителю #130 | Наверх | Cообщить модератору

132. "Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 "  +/–
Сообщение от Аноним (132), 28-Окт-18, 21:16 
> Впрочем, вон FreeBDSM - на SVN.

Нет. TL;DR:
> get the FreeBSD source code using your favorite version control system:
> git clone git://github.com/freebsd/freebsd.git src
> svn checkout svn://svn.freebsd.org/base/head src

Vнога букав:
https://wiki.freebsd.org/GitDrawbacks
> In particular, git is optimized for patch pulling, not so for pushing to a shared repo.
> The costs of the workflow change are offset by benefits of making the change.
> But it has huge downstream impact to get the full benefit.

Это раз.

https://wiki.freebsd.org/GitHub
> Pull requests submitted to GitHub are an experimental feature of the project. While efforts are made to resolve them, the project's normal work flow documented in the FreeBSD Handbook is more reliable.

Это два.


https://wiki.freebsd.org/Git
Причем уже много лет как. Зеркалу вообще лет 8 будет. Это три.

https://wiki.freebsd.org/GitWorkflow/TriangularWorkflow
> Develop changes on top of FreeBSD release branch, e.g. releng/X.Y
> Publish these changes in a personal/corporate git repository for testing and use in production
> Once these changes have been tested and have matured enough, up-port them on top of HEAD for review
> Once review accepted, push them in HEAD
>

Ответить | Правка | К родителю #131 | Наверх | Cообщить модератору

133. "Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 "  +/–
Сообщение от PereresusNeVlezaetBuggy (ok), 28-Окт-18, 21:42 
>> Впрочем, вон FreeBDSM - на SVN.
> Нет. TL;DR:
>> get the FreeBSD source code using your favorite version control system:
>> git clone git://github.com/freebsd/freebsd.git src
>> svn checkout svn://svn.freebsd.org/base/head src

Это зеркала, они вообще не в счёт: в зеркало закоммитить нельзя. Сам репозиторий — по-прежнему, Subversion, и workflow для внесения изменений определяется именно там.

Ответить | Правка | К родителю #132 | Наверх | Cообщить модератору

135. "Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 "  +/–
Сообщение от Аноним (132), 28-Окт-18, 22:12 
>>> Впрочем, вон FreeBDSM - на SVN.
>> Нет. TL;DR:
>>> get the FreeBSD source code using your favorite version control system:
>>> git clone git://github.com/freebsd/freebsd.git src
>>> svn checkout svn://svn.freebsd.org/base/head src
> Это зеркала, они вообще не в счёт: в зеркало закоммитить нельзя. Сам
> репозиторий — по-прежнему, Subversion, и workflow для внесения изменений определяется именно там.

Я же специально цитировал:
> https://wiki.freebsd.org/GitHub
> Pull requests submitted to GitHub are an experimental feature of the project.

И

> The official endorsed way of using git to hack on FreeBSD is documented here: GitWorkflow.
> This page describes the official git repositories of the FreeBSD project that can be used as common repositories to base other work on.
> Using git to commit changes to these repositories is not officially supported (but doable). Instead it aims to serve as a collaboration point by using additional tools like Github, Gitorious, or Gerrit, etc.
>

Часть проектов (pkg) вообще разрабатывается только в гит.


Ответить | Правка | К родителю #133 | Наверх | Cообщить модератору

134. "Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 "  +/–
Сообщение от PereresusNeVlezaetBuggy (ok), 28-Окт-18, 21:51 
>>> Ну как бы речь и шла о git.
>> Речь изначально шла о patches are welcome. Чтобы подготовить (или обновить) патч
>> для OpenBSD достаточно cvs diff — ничем не отличающегося по сути
>> от git diff, hg diff и прочих.
> Ну, может вам везет)  В других проектах - diff'а категорически будет
> не хватать, по
> изложенным выше причинам.

Я пока что натыкался на проекты с замороченным порядком внесения изменений, с отдельными ветками, которые сначала вносятся в staging, а оттуда в основную ветку (и так далее) всего пару раз, да. Кажется, это были CMake и Qt...

>>> Таки нужны "продвинутые средства управления ветками" (тм) кому-то кроме мейнтейнеров или
>>> запишем всех GSoC студентов на гитхабчике сразу в мейнтейнеры?)
>> Открою страшный секрет: ряд разработчиков OpenBSD использует в работе, в том числе,
>> и git, ведя локальную разработку.
> Пожалуй и я спалюсь: вообще-то я немножко ерничал, указывая на cvs проекта.
>  Но таких как-бы сильно немного, учитывая что cvs скорее мертв,
> чем хоть как-то жив.  Впрочем, вон FreeBDSM - на SVN.

:)

>>  * наличие большого количества правок напрямую в репозитории, особенно в старых
>> коммитах (1990-е) ,приводящих к неточностям при миграции.
>>  * в случае повреждения репозитория, починить его можно ручками — формат
>> RCS куда удобнее в этом плане, чем бинарные форматы (почти?) всех
>> остальных современных VCS.
> Так-так.  Может ну его, такой удобный формат, а завести вместо журналируемую
> файловую систему и бесперебойник?)  Кстати, сама по себе CVS (где
> критические операции не атомарны) - вероятно и стала причиной большей части
> "правок напрямую", не?  И что куда хуже - станет снова.

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

>>  * философия централизованного репозитория больше мотивирует не затягивать с коммитами.
> А какая религия запрещает сделать централизованный репозиторий в git?

Наверное, я не совсем корректно выразился. Попробую переформулировать: концепция централизованной VCS способствует тому, что разработчик не «сидит на патчах», а старается их внедрять как можно быстрее, чтобы потом меньше надо было сводить после update.

Хороший пример, кстати — KDE: в то время как репозитории с кодом на Git, инфраструктура i18n/l10n использует по-прежнему Subversion, это было осознанное решение данных людей — им действительно так удобнее.

На моей текущей работе, например, я тоже вижу, что внедрение DVCS, скорее, ухудшит workflow, поэтому даже не пытаюсь их продвигать. Специфика работы без интернета, так сказать.

>>  * отсутствие желающих реально решать проблемы, связанные с миграцией
> Ну, это может только приемуществами от использования чего-то более нормального.  Помимо
> упомянутого выше - наверно еще производительность при некоторых операциях.
> Ах, да.   Bus factor еще.  CVS-гуру теперь надо разводить
> специально.

Справедливости ради, разобраться в нутре CVS куда проще, чем в нутре любой другой популярной VCS. Так что выращивание не является такой серьёзной проблемой. :)

Ответить | Правка | К родителю #131 | Наверх | Cообщить модератору

136. "Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 "  +/–
Сообщение от myhand (ok), 29-Окт-18, 10:48 
> Причины были разные, в том числе — кривые руки первых коммитеров. Просто
> я не случайно указал даты: гитами и прочими жидкими металлами тогда и не пахло.

Во всяком случае, думаю что это, в принципе, решаемо.  OpenBSD - большой и старый проект,
использующий CVS, но вряд-ли он был таким ранее.

> Попробую переформулировать: концепция централизованной
> VCS способствует тому, что разработчик не «сидит на патчах», а старается
> их внедрять как можно быстрее, чтобы потом меньше надо было сводить
> после update.

Хотелки уменьшить количество конфликтов - параллельны концепции централизованной
VCS.  (A propos, на мой вкус и цвет - в git/hg это делать куда удобнее).  Дело в возможностях
рецензирования кода и т.п.

> Хороший пример, кстати — KDE: в то время как репозитории с кодом
> на Git, инфраструктура i18n/l10n использует по-прежнему Subversion, это было осознанное
> решение данных людей — им действительно так удобнее.

Это странно, т.к. с логической точки зрения - VCS является частным случаем
DVCS.  Т.е. при желании ничто не мешает организовать работу идентичным образом.

Ответить | Правка | К родителю #134 | Наверх | Cообщить модератору

137. "Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 "  +/–
Сообщение от PereresusNeVlezaetBuggy (ok), 31-Окт-18, 11:18 
>> Причины были разные, в том числе — кривые руки первых коммитеров. Просто
>> я не случайно указал даты: гитами и прочими жидкими металлами тогда и не пахло.
> Во всяком случае, думаю что это, в принципе, решаемо.  OpenBSD -
> большой и старый проект,
> использующий CVS, но вряд-ли он был таким ранее.

Ну как сказать. Проект OpenBSD, например, был первым проектом ОС, который вообще сделал публично доступный репозиторий (а не просто релизные архивы выкладывал), так что история в этом плане богатая.

>[оверквотинг удален]
>> после update.
> Хотелки уменьшить количество конфликтов - параллельны концепции централизованной
> VCS.  (A propos, на мой вкус и цвет - в git/hg
> это делать куда удобнее).  Дело в возможностях
> рецензирования кода и т.п.
>> Хороший пример, кстати — KDE: в то время как репозитории с кодом
>> на Git, инфраструктура i18n/l10n использует по-прежнему Subversion, это было осознанное
>> решение данных людей — им действительно так удобнее.
> Это странно, т.к. с логической точки зрения - VCS является частным случаем
> DVCS.  Т.е. при желании ничто не мешает организовать работу идентичным образом.

Конечно, реализовать можно. Но частные случаи как раз потому и интересны, что усилий для этого там прилагать надо меньше.

Ответить | Правка | К родителю #136 | Наверх | Cообщить модератору

138. "Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 "  +/–
Сообщение от myhand (ok), 31-Окт-18, 14:45 
> Конечно, реализовать можно. Но частные случаи как раз потому и интересны, что
> усилий для этого там прилагать надо меньше.

Логично.  А потому для программироваиия - только Notepad, ибо в этих ваших емаксах даже кейбиндинги гвоздями не прибиты.

Ответить | Правка | К родителю #137 | Наверх | Cообщить модератору

139. "Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 "  +/–
Сообщение от PereresusNeVlezaetBuggy (ok), 31-Окт-18, 14:54 
>> Конечно, реализовать можно. Но частные случаи как раз потому и интересны, что
>> усилий для этого там прилагать надо меньше.
> Логично.  А потому для программироваиия - только Notepad, ибо в этих
> ваших емаксах даже кейбиндинги гвоздями не прибиты.

Не-не-не.

Смотрите: можно взять «универсальную» отвёртку, с насадками на все случаи жизни: шлиц, шестигранник, звёздочка, все размеры... И, в общем-то, не знать горя.

Но если 90% времени вы работаете с одной и той же насадкой, то удобнее оказывается иметь под это дело отдельную отвёртку. Скорее всего, она будет тоньше, или легче, или ещё как-то более удобна. Да, места на столе (в мозгу) для работы с двумя отвёртками (VCS) требуется чуть больше, но это окупается экономией времени на основных операциях.

Ответить | Правка | К родителю #138 | Наверх | Cообщить модератору

140. "Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 "  +/–
Сообщение от myhand (ok), 01-Ноя-18, 10:48 
Тогда git (да и hg тем более) - как раз отвертка валшебная.  Если надо тоньше - сделаем тоньше, если еще как-то удобнее сделать - будет.  Это в cvs насадка навсегда одна и еще стержень кривой.

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

Ответить | Правка | К родителю #139 | Наверх | Cообщить модератору

141. "Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 "  +/–
Сообщение от PereresusNeVlezaetBuggy (ok), 01-Ноя-18, 15:18 
> Тогда git (да и hg тем более) - как раз отвертка валшебная.
>  Если надо тоньше - сделаем тоньше, если еще как-то удобнее
> сделать - будет.  Это в cvs насадка навсегда одна и
> еще стержень кривой.

Да можно, можно всё это в случае с Git, кто ж спорит. Только вы же сами говорите — «если надо — сделаем». То есть — дорабатывать надо. Самый очевидный пример — ниже.

Как это делают в CVS:

cvs up
vi ...
cvs ci

Как это делают в Git:

git pull
git up
vi ...
git ci ...
git push

Можно избавиться от отдельного «git up», поправив конфиг. Можно избавиться от отдельного «git push», добавив commit hook или какую-то ещё свою обёртку. Но и то, и другое — дополнительные усилия, которые не требуются в случае CVS. Никакого волшебства тут нет, только потраченные (или сэкономленные) разработчиком время и усилия.

Если уж за что и хвалить Git из коробки, так это, например, за «add -p» — в случае с CVS я (и не только я) как раз в свою очередь писал обёртку под это дело.

> Ну в самом деле, аналогичная cvs модель работы - никаких специальных усилий
> от мейнтейнера не требует.  Наверное, можно даже сказать что львиная
> доля пользователей пользуют именно ее.

Правильно, а почему они её используют? — патамушта Linux и GitHub. Если первой VCS, с которой знакомится эта самая львиная доля пользователей, становится Git, то результат как бы предсказуем (я не в претензии, просто констатирую положение дел). Но масштаб проектов и задачи в них от VCS в целом не меняются. И когда задачи в основном вида «поправить вот эту мелочь» и «добавить вот такую фичу на двести строчек», подойдёт любая VCS, вообще любая. При этом порог вхождения у CVS всё же чуточку меньше — да, в том числе из-за отсутствия каких-то фич, типа git index. Я понимаю, что в глазах многих людей сознательный отказ от фич выглядит, говоря литературным языком, ретроградством, но за ним стоит кое-что большее, чем лень и нежелание учиться. :)

Ответить | Правка | К родителю #140 | Наверх | Cообщить модератору

142. "Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 "  +/–
Сообщение от Andrey Mitrofanov (?), 01-Ноя-18, 15:49 
>[оверквотинг удален]
>> еще стержень кривой.
> Да можно, можно всё это в случае с Git, кто ж спорит.
> Только вы же сами говорите — «если надо — сделаем». То
> есть — дорабатывать надо. Самый очевидный пример — ниже.
> Как это делают в CVS:
> cvs up
> vi ...
> cvs ci
> git up
> git ci ...

Ой, страшно.  Страшно оригинально и нОво.  Ой, ой.

> Можно избавиться от отдельного «git up», поправив конфиг. Можно избавиться от
> отдельного «git push», добавив commit hook или какую-то ещё свою обёртку.
> Но и то, и другое — дополнительные усилия, которые не требуются
> в случае CVS. Никакого волшебства тут нет, только потраченные (или сэкономленные)
> разработчиком время и усилия.

Ты главное не перенапрягись, выдумывая команды git.

Ответить | Правка | К родителю #141 | Наверх | Cообщить модератору

144. "Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 "  +1 +/–
Сообщение от PereresusNeVlezaetBuggy (ok), 02-Ноя-18, 11:35 
>[оверквотинг удален]
>> cvs ci
>> git up
>> git ci ...
> Ой, страшно.  Страшно оригинально и нОво.  Ой, ой.
>> Можно избавиться от отдельного «git up», поправив конфиг. Можно избавиться от
>> отдельного «git push», добавив commit hook или какую-то ещё свою обёртку.
>> Но и то, и другое — дополнительные усилия, которые не требуются
>> в случае CVS. Никакого волшебства тут нет, только потраченные (или сэкономленные)
>> разработчиком время и усилия.
> Ты главное не перенапрягись, выдумывая команды git.

Переклинило. Rebase там, конечно же. Писал, пользуясь в этот момент Mercurial и Subversion, вот оно и. Прошу прощения.

Ответить | Правка | К родителю #142 | Наверх | Cообщить модератору

143. "Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 "  +1 +/–
Сообщение от myhand (ok), 01-Ноя-18, 19:03 
>> Тогда git (да и hg тем более) - как раз отвертка валшебная.
>>  Если надо тоньше - сделаем тоньше, если еще как-то удобнее
>> сделать - будет.  Это в cvs насадка навсегда одна и
>> еще стержень кривой.
> Да можно, можно всё это в случае с Git, кто ж спорит.
> Только вы же сами говорите — «если надо — сделаем».

Да не надо ничего дорабатывать, максимум - выучиться командам.

> Как это делают в CVS:

Задача, как я понял, обновить рабочее дерево, что-то поредактировать и закоммитить?

> Как это делают в Git:
> git pull
> git up
> vi ...
> git ci ...
> git push

Нет, это делают не так (начиная с того, что git up - это какой-то ваш алиас, вероятно.

Делают проще:
emacs ...
git commit ..
git push ...

Если git push заругался на наличие в основном репе изменений, отсутствующих локально - делаем git pull --rebase и уже потом push.

> Можно избавиться от отдельного «git up», поправив конфиг.

Из коробки избавились:
$ git up --help
git: 'up' is not a git command. See 'git --help'.
...
$ git update
git: 'update' is not a git command. See 'git --help'.
...

:)

> Но и то, и другое — дополнительные усилия, которые не требуются
> в случае CVS.

Дополнительные усилия называются: чтение документации на уровне туториала.  Git все-таки
не является копией CVS (аллилуия!), потому команды и их аргументы - несколько другие.

Ну и, еще раз напоминаю: реалии мира таковы, что люди скорее будут вынуждены выяснять
что такое cvs update.

>> Ну в самом деле, аналогичная cvs модель работы - никаких специальных усилий
>> от мейнтейнера не требует.  Наверное, можно даже сказать что львиная
>> доля пользователей пользуют именно ее.
> Правильно, а почему они её используют? — патамушта Linux и GitHub.

Ну как бы было время, когда гитхаба - не было.  Зато CVS был давно.  Это, наверное, масоны устроили так, чтобы он на гитхабы с линуксами не попал?)

> И когда задачи в основном вида
> «поправить вот эту мелочь» и «добавить вот такую фичу на двести
> строчек», подойдёт любая VCS, вообще любая.

Я надеюсь, описанный сценарий - не для OpenBSD.

> При этом порог вхождения у CVS всё же чуточку меньше — да, в том числе из-за
> отсутствия каких-то фич, типа git index.

Знать такие вещи - как правило и не требуется для рядового пользователя.  Это как если б
я попросил вас рассказать что может поломать cvs update, если вдруг свет вырубят.

> Я понимаю, что в глазах
> многих людей сознательный отказ от фич выглядит, говоря литературным языком, ретроградством,
> но за ним стоит кое-что большее, чем лень и нежелание учиться.  :)

Кстати, а в OpenBSD как изменения тестируются?  Полазал по сайту, как-то там глубоко ссылки на ваш CI сервис закопаны.

Ответить | Правка | К родителю #141 | Наверх | Cообщить модератору

145. "Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 "  +/–
Сообщение от PereresusNeVlezaetBuggy (ok), 02-Ноя-18, 12:00 
>>> Тогда git (да и hg тем более) - как раз отвертка валшебная.
>>>  Если надо тоньше - сделаем тоньше, если еще как-то удобнее
>>> сделать - будет.  Это в cvs насадка навсегда одна и
>>> еще стержень кривой.
>> Да можно, можно всё это в случае с Git, кто ж спорит.
>> Только вы же сами говорите — «если надо — сделаем».
> Да не надо ничего дорабатывать, максимум - выучиться командам.

Тогда вы сами себе противоречите словами «если надо — сделаем».

>[оверквотинг удален]
>> git ci ...
>> git push
> Нет, это делают не так (начиная с того, что git up -
> это какой-то ваш алиас, вероятно.
> Делают проще:
> emacs ...
> git commit ..
> git push ...
> Если git push заругался на наличие в основном репе изменений, отсутствующих локально
> - делаем git pull --rebase и уже потом push.

Править исходники, не обновив их, обычно плохая идея — сводить больше и больнее придётся.

>> Можно избавиться от отдельного «git up», поправив конфиг.
> Из коробки избавились:
> $ git up --help
> git: 'up' is not a git command. See 'git --help'.
> ...
> $ git update
> git: 'update' is not a git command. See 'git --help'.
> ...

(дублирую написанное Митрофанову насчёт git up)
Переклинило. git rebase там, конечно же. Писал, пользуясь в этот момент Mercurial и Subversion, вот оно и.

>> Но и то, и другое — дополнительные усилия, которые не требуются
>> в случае CVS.
> Дополнительные усилия называются: чтение документации на уровне туториала.  Git все-таки
> не является копией CVS (аллилуия!), потому команды и их аргументы - несколько
> другие.

Угу, угу. Все дураки, один Git умный. Одна только загадочная логика, когда с помощью branch можно сделать угодно, кроме собственно переключения веток, чего стоит. Учить надо, да, но в итоге всё равно регулярно путаешься (как я выше) — если, конечно, не пользоваться одним только Git.

> Ну и, еще раз напоминаю: реалии мира таковы, что люди скорее будут
> вынуждены выяснять
> что такое cvs update.

Всё может быть. Только это произойдёт в первую очередь из-за новых проектов. А не из-за миграции старых.

>>> Ну в самом деле, аналогичная cvs модель работы - никаких специальных усилий
>>> от мейнтейнера не требует.  Наверное, можно даже сказать что львиная
>>> доля пользователей пользуют именно ее.
>> Правильно, а почему они её используют? — патамушта Linux и GitHub.
> Ну как бы было время, когда гитхаба - не было.  Зато
> CVS был давно.  Это, наверное, масоны устроили так, чтобы он
> на гитхабы с линуксами не попал?)

Да я же писал, что не в претензии. Причины понятны. Но не гитхабом единым живы программисты.

>> И когда задачи в основном вида
>> «поправить вот эту мелочь» и «добавить вот такую фичу на двести
>> строчек», подойдёт любая VCS, вообще любая.
> Я надеюсь, описанный сценарий - не для OpenBSD.

Не понял, что вы имели в виду. Что в OpenBSD не должно быть маленьких правок? Или что?

>> При этом порог вхождения у CVS всё же чуточку меньше — да, в том числе из-за
>> отсутствия каких-то фич, типа git index.
> Знать такие вещи - как правило и не требуется для рядового пользователя.
>  Это как если б
> я попросил вас рассказать что может поломать cvs update, если вдруг свет
> вырубят.

Не соглашусь. Пока не сел и спокойно не разобрался с git index (и в целом с Git) в своё время, постоянно матерился на непонятное поведение при add и commit.

>> Я понимаю, что в глазах
>> многих людей сознательный отказ от фич выглядит, говоря литературным языком, ретроградством,
>> но за ним стоит кое-что большее, чем лень и нежелание учиться.  :)
> Кстати, а в OpenBSD как изменения тестируются?  Полазал по сайту, как-то
> там глубоко ссылки на ваш CI сервис закопаны.

Кто хочет сам прогнать тесты — идёт и делает make regress.

На регулярной же основе bluhm@ регулярно прогоняет это дело на отдельном кластере, результаты доступны прогонов доступны разработчикам для анализа в удобном виде.

Ответить | Правка | К родителю #143 | Наверх | Cообщить модератору

146. "Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 "  +/–
Сообщение от myhand (ok), 02-Ноя-18, 12:40 
>> Да не надо ничего дорабатывать, максимум - выучиться командам.
> Тогда вы сами себе противоречите словами «если надо — сделаем».

Нет, команды _уже_ сделаны.  Максимум - их надо выучить.  И, кстати, современный мир таков, что учить их
даже не надо - разработчики уже рождаются с встроенными навыками работы в git.

> Править исходники, не обновив их, обычно плохая идея — сводить больше и
> больнее придётся.

Если конфликтов нет - в чем проблема?  Описанный workflow вообще кривой - но это
именно то, что вы предложили для cvs.

> Одна только загадочная логика, когда
> с помощью branch можно сделать угодно, кроме собственно переключения веток, чего стоит.

Так оно не для переключения веток.  Оно для управления ветками.  Непривычно для
изнасилованных cvs/svn - возможно.  Но нелогично - нет, конечно.

>>> И когда задачи в основном вида
>>> «поправить вот эту мелочь» и «добавить вот такую фичу на двести
>>> строчек», подойдёт любая VCS, вообще любая.
>> Я надеюсь, описанный сценарий - не для OpenBSD.
> Не понял, что вы имели в виду. Что в OpenBSD не должно
> быть маленьких правок? Или что?

Что в OpenBSD дело не заканчивается маленькими правками.

Ответить | Правка | К родителю #145 | Наверх | Cообщить модератору

147. "Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 "  +/–
Сообщение от PereresusNeVlezaetBuggy (ok), 02-Ноя-18, 19:54 
>>> Да не надо ничего дорабатывать, максимум - выучиться командам.
>> Тогда вы сами себе противоречите словами «если надо — сделаем».
> Нет, команды _уже_ сделаны.  Максимум - их надо выучить.  И,
> кстати, современный мир таков, что учить их
> даже не надо - разработчики уже рождаются с встроенными навыками работы в
> git.

:)) Видел я таких разработчиков... «Пушать» на GitHub они умеют, да. А вот о том, что можно обходиться и без GitHub знают уже далеко не все.

>> Править исходники, не обновив их, обычно плохая идея — сводить больше и
>> больнее придётся.
> Если конфликтов нет - в чем проблема?  Описанный workflow вообще кривой
> - но это
> именно то, что вы предложили для cvs.

В том, что они обычно есть. Может, это только мой личный опыт, конечно.

Workflow, конечно, с DVCS куда богаче вариантами. Но «больше возможностей» — опять же, не всегда означает «лучше». На какой-нибудь АЭС регламент очень чётко требует выполнять даже самые безопасные, казалось бы, операции, что кстати, многих бесит. Зачем так делается? — Да затем, чтобы в случае чего было известно, кто как себя будет вести и что будет делать. То есть при всём богатстве вариантов workflow, в любом сколько-то серьёзном проекте он фиксирован. И если этот workflow ложится на централизованную VCS, то... почему бы и нет?

>> Одна только загадочная логика, когда
>> с помощью branch можно сделать угодно, кроме собственно переключения веток, чего стоит.
> Так оно не для переключения веток.  Оно для управления ветками.  
> Непривычно для
> изнасилованных cvs/svn - возможно.  Но нелогично - нет, конечно.

К списку CVS и Subversion добавьте ещё все остальные VCS, кроме Гитля Д'Артаньяна.

>>>> И когда задачи в основном вида
>>>> «поправить вот эту мелочь» и «добавить вот такую фичу на двести
>>>> строчек», подойдёт любая VCS, вообще любая.
>>> Я надеюсь, описанный сценарий - не для OpenBSD.
>> Не понял, что вы имели в виду. Что в OpenBSD не должно
>> быть маленьких правок? Или что?
> Что в OpenBSD дело не заканчивается маленькими правками.

Не заканчивается, разумеется. И мы возвращаемся к исходной диспозиции: кто-то использует cvsync, кто-то — cvs2gitdump... И это ровно то, о чём шла речь выше: доработки для тех, кто хочет использовать DVCS.

Ещё раз: я не говорю, то Git — это плохо. И точно знаю, что ряд разработчиков OpenBSD с удовольствием бы на него переехали (лично я вообще предпочитаю Mercurial, к слову). Но цена переезда довольно высока, и как минимум Тео её (пока) не хочет платить.

На этом и предлагаю закругляться, а то у нас уже сказка про белого бычка начинается. :)

Ответить | Правка | К родителю #146 | Наверх | Cообщить модератору

148. "Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 "  +1 +/–
Сообщение от myhand (ok), 03-Ноя-18, 11:17 
> :)) Видел я таких разработчиков... «Пушать» на GitHub они умеют, да.

Ну вот чтобы начать что-то "делать" - вам предварительно от этих элементарных навыков
их нужно будет отучить.

> В том, что они обычно есть. Может, это только мой личный опыт, конечно.

Тогда конфликты надо будет править, я описал как.  Можно pull сделать в самом начале,
как для cvs.  Хотя все-равно будет шанс нарваться на необходимость сделать pull еще
раз, перед push.  Как, впрочем, и в случае cvs.

> Workflow, конечно, с DVCS куда богаче вариантами. Но «больше возможностей» —
> опять же, не всегда означает «лучше».

Мы опять ушли в сторону.  Речь шла о том, что де с git - это сложнее.  Выяснилось, как минимум - не
сложнее (если считать количество команд).

> К списку CVS и Subversion добавьте ещё все остальные VCS, кроме Гитля Д'Артаньяна.

В ртути так, да (полагаю, с оглядкой на svn).  Про другие - я не был бы так уверен.  Как в arch - я, например, не помню.  Да и не важно, технические вопросы не решаются же голосованием.

> Ещё раз: я не говорю, то Git — это плохо. И точно
> знаю, что ряд разработчиков OpenBSD с удовольствием бы на него переехали
> (лично я вообще предпочитаю Mercurial, к слову). Но цена переезда довольно
> высока, и как минимум Тео её (пока) не хочет платить.

Git определенно удобнее локально.  Но штука в том, что он также удобнее и для центрального
репозитория (впрочем, то же справедливо относительно всех современных DVCS).  Хотя бы
надежностью хранилища.  Плюс - cvs официально дохлый, приходящих разработчиков
ему придется учить, тем более - тех кто непосредственно будет заниматься основным репом,
поддержкой необходимых обвязок над cvs и т.п.  Учить сурово: как хранятся данные,
что может в хранилище поломаться при штатных операциях и т.п.  Не просто документации,
как в менее кривых современных DVCS.

В общем, предсказываю, что опенок таки с cvs однажды свалит.  Если, конечно, не помрет в
самое ближайшее время (да не дождетесь!).  Хотя со временем цена этого гемороя определенно будет расти.  

> На этом и предлагаю закругляться, а то у нас уже сказка про
> белого бычка начинается. :)

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

Ответить | Правка | К родителю #147 | Наверх | Cообщить модератору

149. "Релиз OpenBSD 6.4, OpenSSH 7.9 и LibreSSL 2.8.2 "  +/–
Сообщение от BABUTemail (??), 01-Мрт-20, 18:29 
я- простой юзер, всех моих навыков программирования: ассемблер- лет тридцать назад, да паскаль- лет пять спустя, а вершиной моего любительского творчества стала библиотека для мышки, со встроенным графическим редактором курсоров под дос. так что напиши- это не ко мне. дурак я, ферштейн? но я такой не один. при этом прекрасно понимаю чего мне от оси надо, бо только юзеры, с их широкими низменными запросами, и знают какой должна быть ось. а вот уровень этих юзеров к делу не относится. так что я могу принять аргументом только "она не для широкой публики- в целом, и не для тебя- в частности". и тут мне останется пожелать удачи вам на этом трудном и, в конце концов, тупиковым пути- найти свою нишу под такие вводные как у опёнка.

почему я продолжаю ей пользоваться? лет пятнадцать назад надо было сделать себе роутер. уже не помню по какой причине именно сделать, а не просто купить готовую мыльницу(возможно их тогда не существовало. склероз). я купил(так как жил с полярными медведями) три бсдехи- опёнок37, фрю и нетку. почему это не был линь- не помню, но уже тогда у меня была давняя глубокая ненависть к "обезьяньему стилю", сформировавшаяся в протипоставлении тасма и масма, так что у линя шансов не было в любом случае. никакого опыта общения с никсами я не имел(лины если и видел, то не у себя). начал с фряхи, но не осилил её поставить так, как хотел: этот слишком умный псевдографический интерфейс не позволил поставить систему полностью на один раздел(за исключением свопа) и исключить графику- постоянно автоматически подтягивались зависимости, и в итоге я получал тостер. следующей была опёнок, которая оказалась проста, интуитивна и юзер-френдли, сразу позволив реализовать все мои хотелки. такая она, в некотором роде(полезный функционал удаляется, вредный добавляется :\), и осталась до сих пор. до нетки же дело просто не дошло. а дальше дело было в инерции.
надо заметить, что в те времена опёнок поддерживала всё моё железо, ни с чем не было проблем, даже с вифи(нынче это немыслимо). если бы тот выбор стоял сейчас перед мною, то она отправилась бы в ведро, бо проблемы с поддержкой железа дико з@ёбывают.

зы: а, вспомнил почему именно сделать- связь с провайдером была по вифи, через aironet 350

Ответить | Правка | К родителю #111 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру