The OpenNET Project / Index page

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

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


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

Оглавление

GitHub переходит на использование обязательной двухфакторной аутентификации, opennews (??), 05-Май-22, (0) [смотреть все]

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


4. "GitHub переходит на использование обязательной двухфакторной..."  +7 +/–
Сообщение от Аноним (4), 05-Май-22, 10:31 
Можно чуть проще: "GitHub переходит на..."
Ответить | Правка | Наверх | Cообщить модератору

6. "GitHub переходит на использование обязательной двухфакторной..."  +28 +/–
Сообщение от YetAnotherOnanym (ok), 05-Май-22, 10:40 
> "GitHub идёт на..."

Можешь не благодарить.

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

27. "GitHub переходит на использование обязательной двухфакторной..."  –6 +/–
Сообщение от Ooiiii (?), 05-Май-22, 12:28 
А можно было просто уйти из гитхаба на скрепный сервис анало-гов-нет, а не сквернословить и минусить новость
Ответить | Правка | Наверх | Cообщить модератору

30. "GitHub переходит на использование обязательной двухфакторной..."  +4 +/–
Сообщение от Аноним (30), 05-Май-22, 12:34 
Если не смузихлёбствовать, то можно найти кучу других публичных нескрепных гитов.
Ответить | Правка | Наверх | Cообщить модератору

61. "GitHub переходит на использование обязательной двухфакторной..."  +2 +/–
Сообщение от пох. (?), 05-Май-22, 14:27 
гит - ненужно. Нужно общение разработчиков между собой. Гитхаб - это такая социалочка для них.

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

81. "GitHub переходит на использование обязательной двухфакторной..."  +12 +/–
Сообщение от Аноним (-), 05-Май-22, 15:38 
с цензуркой, dcma, неадекватными зомбями. и help ukraine на каждой страничке ^_^
Ответить | Правка | Наверх | Cообщить модератору

181. "GitHub переходит на использование обязательной двухфакторной..."  +/–
Сообщение от nvidiaamd (?), 06-Май-22, 12:25 
Ща поха порвет
Ответить | Правка | Наверх | Cообщить модератору

193. "GitHub переходит на использование обязательной двухфакторной..."  +/–
Сообщение от torvn77 (ok), 06-Май-22, 13:56 
>Нужно общение разработчиков между собой.  

Если внимательно прочитать новость то именно общение не ограничивается, ограничена только отправка кода.

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

272. "GitHub переходит на использование обязательной двухфакторной..."  +/–
Сообщение от пох. (?), 07-Май-22, 09:44 
Как ты понимаешь, если общаться надо в одном месте, а код отправлять какими-то череззадничными способами через совсем другое отверстие - это несколько уменьшает желание окружающих с тобой общаться ни о чем.

А поддерживать issues/pull req/прочую сосальную активность на шитхабе - и при этом героически копипастить все вручную в личный суперсекретный репо - желающих найдется крайне мало.

То есть так как раз устроены некоторые корпоративные разработки, и у них в общем все плохо с фидбэком и комьюнити - именно по этой причине.

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

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

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

216. "GitHub переходит на использование обязательной двухфакторной..."  +/–
Сообщение от Аноним (-), 06-Май-22, 17:03 
> гит - ненужно.

А что нужно то, лол?

> Нужно общение разработчиков между собой. Гитхаб - это такая социалочка для них.

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

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

220. "GitHub переходит на использование обязательной двухфакторной..."  +2 +/–
Сообщение от Аноним (220), 06-Май-22, 17:23 
> От того что ты потрындишь в чатике программа не улучшится, внезапно.

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

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

227. "GitHub переходит на использование обязательной двухфакторной..."  +/–
Сообщение от Аноним (-), 06-Май-22, 17:50 
> Внезапно может оказаться, что отказаться от очередного "улучшения" - лучший вариант для всех.

Ну, у меня для этого git revert есть.

> "Улучшатели" бывают весьма странными типами.

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

Прикинь, тупица, если мне не хочется иметь дело с гитхабом я спишусь с вон тем девом в частном порядке и попрошу его pull request сделать на мой патч :). Дальше он может пушить это в гитхаб, может пушить в шитфаб, нотабуг, кодберг, марсианское хранилище в вечной мерзлоте или что там еще - мне уже похрен, я свое дело сделал. А вот именно гитхаб как точка обмена стал неудобным и назойливым. Там еще вебмакаки мудасофта что-то поменяли и он стал дичайше грузить проц браузером по поводу и без, как будто майнит коины все время. И это случилось после покупки мудасофтом. До этого все отлично было. Эти люди еще будут мне тут про мутный код лечить, ага.

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

234. "GitHub переходит на использование обязательной двухфакторной..."  +/–
Сообщение от Аноним (220), 06-Май-22, 18:09 
Собственно к чему я предыдущий комментарий написал, а ктому, что смысл от гитхаба как от соцсетки всё-таки есть - и разработчикам, и пользователям он знаком.
Понятно, что есть и другие соцсетки, но популярность их в таргет-группе не очень высока.
Опенсорс - это факту не только код, но и в определённом смысле общественное движение, если разработчики программ не будут это учитывать, то крупные компании в итоге победят и задушат опенсорс, у них есть понимание как работать с обществом.
Ответить | Правка | Наверх | Cообщить модератору

238. "GitHub переходит на использование обязательной двухфакторной..."  +/–
Сообщение от Аноним (-), 06-Май-22, 18:26 
> Собственно к чему я предыдущий комментарий написал, а ктому, что смысл от
> гитхаба как от соцсетки всё-таки есть - и разработчикам, и пользователям он знаком.

Актуально в основном всяким корпоменеджерам. Ну их пусть и строят. Только разработчики покажут им факи и либо не будут пользоваться гитхабом, либо будут туда раз в полгода пушить мега-релиз, а вы там разбирайтесь. А чтоб больше програмить и меньше развлекаться с всякими 2FA и прочим мешающим булшитом.

> Понятно, что есть и другие соцсетки, но популярность их в таргет-группе не очень высока.

У таргет группы, если мы вообще о кодинге проектов, цель так то сделать проект. Потрындеть можно и в вон той ирке, как те 50К юзерей в фриноде. А обмен кодом - это обмен кодом.

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

Если какое-то сообщество решило что ему гитхаб мастхэв, для начала, из них очень условные опенсорсники получаются. Ибо лочатся на наглый проприетарный сервис. Большая часть опенсорсников вполне способны к пониманию таких вещей кстати.

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

Оно и видно на примере гитхаба. И оглушительного успеха codeplex'а. Знаете что, так называемое опенсорсное сообщество, если для вашей победы надо заглот майкрософту делать, от вашего исчезновения лично я не расстроюсь. Я уважаю сильных и самодостаточных, а не видал-сасунов отлизывающих мегакорпу. Такая пародия на опенсорц даром не упала - не достигает основных целей опенсорца, той же страховки от резких внезапных непопулярных решений. Ну вот как в этой новостии например.

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

255. "GitHub переходит на использование обязательной двухфакторной..."  +/–
Сообщение от Аноним (-), 07-Май-22, 04:13 
upd: мы говорим фринода подразумеваем libera. Корейский принц может всем известным курсом...
Ответить | Правка | Наверх | Cообщить модератору

225. "GitHub переходит на использование обязательной..."  +/–
Сообщение от arisu (ok), 06-Май-22, 17:37 
>> гит - ненужно.
> А что нужно то, лол?

Fossil же. в коробке имеет вики, форум, тикеты и даже чятег. всё кроме последнего — лежит в репозитории, и клонируется вместе с ним. в отличие от шитхаба, где ни тикеты толком не забрать, ни вику, ни потом это нормально не встроить в другое место.

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

228. "GitHub переходит на использование обязательной..."  +/–
Сообщение от Аноним (-), 06-Май-22, 17:54 
> Fossil же.

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

> в коробке имеет вики, форум, тикеты и даже чятег.

Зачем мне куча третьесортных тулов? Если они мне реально нужны будут - я первосортные возьму. Ну там токс какой в качестве чатика куда как прикольнее :). Я на нем даже ботиков научился слегоница. Ну они и спамят меня всякими интересностями. А могут и вон той релюшкой клацнуть прям по команде в чатик от меня, врубив что-нить мощное. Апи кстати клевое если на сях прогать.

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

А для гита кто-то тоже довесок подобного плана сколхозил. Правда на игогошке. Хранит баги в объектах гита. Но как-то сложно слишком получилось.

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

232. "GitHub переходит на использование обязательной..."  +/–
Сообщение от arisu (ok), 06-Май-22, 18:04 
>> Fossil же.
> У гита преимущество в том что через него можно с окружающими перекидываться,
> врядли им придется учить что-то новое.

если человек не в состоянии освоить фоссил — я лично с ним не стану ничем перекидываться. это инвалид мозга.

>> в коробке имеет вики, форум, тикеты и даже чятег.
> Зачем мне куча третьесортных тулов? Если они мне реально нужны будут -
> я первосортные возьму.

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

>> всё кроме последнего — лежит в репозитории, и клонируется вместе с ним.
>> в отличие от шитхаба, где ни тикеты толком не забрать, ни
>> вику, ни потом это нормально не встроить в другое место.
> А для гита кто-то тоже довесок подобного плана сколхозил. Правда на игогошке.
> Хранит баги в объектах гита. Но как-то сложно слишком получилось.

а в фоссиле просто. оно Просто Работает. из коробки. без проблем. хочешь — локально, хочешь — в интернеты вывешивай, тем же фоссилом. на всё про всё — один бинарь. автор SQLite, однако, имеет мозг и руки из нужного места потому что. да, Fossil — это от него.

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

239. "GitHub переходит на использование обязательной..."  +/–
Сообщение от Аноним (-), 06-Май-22, 18:42 
> если человек не в состоянии освоить фоссил — я лично с ним
> не стану ничем перекидываться. это инвалид мозга.

Ну, я просто поленюсь тратить мое время на "освоение" непонятно чего и зачем. Не потому что инвалид мозга а потому что предпочту это время потратить на проект который считаю интересным, например. У меня довольно длинная очередь того что я бы хотел (попытаться) накодить, на пределе возможностей, поэтому изучать хз что и зачем я таки не буду. Так и накроется взаимодействие.

> и пойдёшь плясать по граблям, пытаясь это всё как-то заставить вместе работать.

А таки модуляризация и деление на части штука полезная. Особенно в софтострое.

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

Я бы сказал что вика нужна далеко не каждому первому проекту. А единственной викой которую я всерьез редактил была википедия.

> а в фоссиле просто. оно Просто Работает. из коробки. без проблем.

Мне не надо решение для конченых юзеров, мне юниксвэй нравится, с модульностью и гибкостью. Гит в это неплохо вписывается. Да, я работаю с ним из командлайна сугубо. И уж точно не из-за вики с багтрекингом. Так что все это для меня очень такой условный плюс в vcs, уж точно не определяющий.

> хочешь — локально, хочешь — в интернеты вывешивай, тем же фоссилом. на
> всё про всё — один бинарь. автор SQLite, однако, имеет мозг
> и руки из нужного места потому что. да, Fossil — это от него.

Может быть. Но mindset торвальдса хорошо маппится на мой - меня устраивает. А вики и багтреки для меня - довольно пофигистичны, если честно. Лучше пусть does one thing (version control) and does it well. А вот это не отнять.

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

252. "GitHub переходит на использование обязательной..."  +/–
Сообщение от arisu (ok), 07-Май-22, 02:46 
>> если человек не в состоянии освоить фоссил — я лично с ним
>> не стану ничем перекидываться. это инвалид мозга.
> Ну, я просто поленюсь тратить мое время на "освоение" непонятно чего и
> зачем. Не потому что инвалид мозга а потому что предпочту это
> время потратить на проект который считаю интересным, например.

собственно, предполагалось, что тебе уже интересно — иначе зачем ты вообще захотел что-то для проекта сделать. это отлично, но я хочу видеть ещё и минимальные шаги навстречу со сторны контрибутора. потому что лично я рассматриваю возможность что-то сделать в моём проекте как привилегию, которую я даю другим: так-то мой проект отлично без них жил до этого — проживёт и дальше. а если хочется в нём Странного… ну, show me your dedication. вот отсюда и моя фраза про инвалида мозга.

> Так и накроется взаимодействие.

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

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

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

> Я бы сказал что вика нужна далеко не каждому первому проекту.

это ты говоришь потому, что в гите её нет встроеной. я тоже так говорил. а потом оказалось — это просто таки офигительно удобно. особенно с учётом того, что фоссил позволяет привязывать вики-странички даже к отдельным коммитам (да, явно) — где можно подробно расписать, например, неочевидное изменение, не захламляя код и commit message. и это описание никуда не потеряется, его будет сразу видно, оно легко доступно. ты просто не представляешь, насколько это удобно — потому что в гите нет ничего даже отдалённо похожего, и ты не пробовал.

>> а в фоссиле просто. оно Просто Работает. из коробки. без проблем.
> Мне не надо решение для конченых юзеров, мне юниксвэй нравится, с модульностью
> и гибкостью.

да на здоровье. фоссил отлично работает из командной строки, там тоже масса всяких команд для всего. собственно, командная строка и есть основной режим, веб-гуй — это бонус. а ещё есть libfossil — реализация не от авторов фоссила, что помогает находить и устранять расхождения между спецификациями и реализацией.

> Может быть. Но mindset торвальдса хорошо маппится на мой - меня устраивает.
> А вики и багтреки для меня - довольно пофигистичны, если честно.
> Лучше пусть does one thing (version control) and does it well.
> А вот это не отнять.

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

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

257. "GitHub переходит на использование обязательной..."  +/–
Сообщение от Аноним (-), 07-Май-22, 05:19 
> собственно, предполагалось, что тебе уже интересно — иначе зачем ты вообще захотел
> что-то для проекта сделать. это отлично, но я хочу видеть ещё
> и минимальные шаги навстречу со сторны контрибутора.

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

> потому что лично я рассматриваю возможность что-то сделать в моём проекте
> как привилегию, которую я даю другим: так-то мой проект отлично без них жил
> до этого — проживёт и дальше. а если хочется в нём Странного… ну,
> show me your dedication. вот отсюда и моя фраза про инвалида мозга.

А с моей стороны - я могу проявить немного альтруизма, но мазохистом точно не являюсь, доказывать кому-то что не верблюд, убивая на это мое время на разучивание ненужных мне по жизни тулов. И так то если мне ну вот реально надо - я так то познал прелести _D_VCS-а и могу и форкануть. В том числе вывесив не только свои улучшения но и более привычный VCS народу. Так уже и до takeover разработки недалеко.

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

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

Консенсус - я вижу что проект явно не будет удобен мне и просто потрачу время на другие вещи. А если это что-то позарез нужное мне я таки и форкануть не обломаюсь, я так то умею плюсами опенсорса пользоваться. У меня есть эн проектов отфорканых от апстримов, некоторые довольно сильно перепаханы и иногда я cherri-pick'аю из апстрима некоторые фичи, но де факто это весьма отдельные ветки, где главной ауторити я и некоторые вещи относительно апстрима пересмотрены. Это такой гибридный метод - можно ресурсами апстрима пользоваться частично, но будет все же по моему. Опенсорс как-то так и должен быть :)

> таки кто тебе запрещает добывать из фоссил-репы (которая просто SQLite база) нужные
> данные, и рисовать их чем угодно?

Я не DBA и не особый фан сиквеля. И если я этим займусь, то почти наверняка влеплю веселых вулнов, что для проекта оперирующего внешними данными достаточно фатально. Поэтому все это счастье я предоставлю кому-нибудь другому, имхо. Особенно с сиквелем.

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

А для гита так то люди накодили libgit всякие. Если мне ну вот реально станет надо что-то кастомное на основе тех технологий - для меня это будет намного более удачный интерфейс чем сиквельная база и все такое. И я скоорее сделаю что хотел через такой программный интерфейс.

А сиквель ни два ни полтора. Это уже не юниксвэй но еще не api либы в нормальном виде.

> сам по себе фоссил не трактует всё это как-то особенно: текст везде текст,
> версионируется и складывается в репозиторий.

Ага, в сиквеле текст везде текст но, таки, имеющий местами специальные значения - и если этим плотно не заниматься и не знать все грабли - гамна имени Bobby Tables'а там на внешних данных можно откушать более чем. Я об этом догадываюсь и не рвусь что-то делать с сиквельными базами лишний раз.

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

Это я говорю потому что прогеры ненавидят писать доки, минимизируя это занятие как неизбежное зло :). И врядли ты сделаешь там именно привычный мне медиавики, с 100% compat-ом синтаксиса и фич, это довольно дохрена кодить так то. Значит мне будет постоянно икаться. А инструмент постоянно отвешивающий мне оплеухи в задаче которой я вообще не очень хочу заниматься очень так себе, если честно. Да, медиавики большой монстр. Но если вика всерьез нужна, он таки крут, мощен и удобен. А мелкие пародии на него после него уже не то. Особенно когда я не ярый фанат докописательства чтобы получать пинки лишний раз когда оно привычный мне синтаксис не сожрет.

> а потом оказалось — это просто таки офигительно удобно.

Может быть, но см. выше.

> особенно с учётом того, что фоссил позволяет привязывать вики-странички даже к
> отдельным коммитам (да, явно) — где можно подробно расписать, например, неочевидное
> изменение, не захламляя код и commit message.

А я таки вкатываю это в commit message, если надо, commit -F <file>. Так если кого-то коммит заинтересует, он сразу же именно там и найдет ответ, сразу гитом. А, еще я неочевидные места кода таки коментирую. И именно inline в релевантных местах. Это логичнее чем какая-то вика, где-то сбоку. Описание как что и почему делает код уместнее всего в этом коде.

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

Наверное я просто не настолько фанат вик, пользующийся ими эпизодически и уж точно не в контексте кодинга чего-то. ИМХО вики для долговременного стабильного знания, привязка к комитам и что там еще - как-то ортогональна этой идее.

А актуальные доки для кодеров на проект лучше имхо как txt или как максимум .md, чтобы они могли это в любимом текстовом эдиторе открыть. Синтаксис вик для такого - ну, так себе. Штуки типа .md лучше в такое применение вписались.

> да на здоровье. фоссил отлично работает из командной строки, там тоже масса
> всяких команд для всего. собственно, командная строка и есть основной режим,

А как с этим соотносится всякая реклама багтрекеров и вик? Я вообще по умолчанию не хочу никакие сетевые сервисы на моих системах - покуда я явно не захотел обратного и не сконфигурил это самолично. Упомянутый шаг все-равно неизбежен из-за кастомной сетевой конфигурации, искаропки оно вообще никуда не попадет по сети.

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

Так то и для гита есть libgit всякие. Не от авторов гита вроде, но какая мне нафиг разница. А конкретно скулайт когда я с ним возился что-то не порадовал меня особым перфомансом, а заодно вымахал в немелкую либу и не то чтобы я сильный фанат этого. Ну да, конкурентов с именно SQL особо и нет, но для себя я предпочитаю более простые вещи типа key-value просто.

> так в том-то и дело, что гит это делает очень плохо.

Я этого на себе совершенно не ощутил.

> там даже нормального поиска по времени коммитов назад нет. поиска по связаным
> коммитам нет. визуализации нормальной нет.

А это все, внезапно, уже не контроль версий и я не понимаю при чем тут vcs, звучит как занятие для внешних тулзов если мы про юниксвей. Да и ходить туда не знаю куда, ища то не знаю что у меня лучше всего получается git bisect'ом, заодно сразу code fix причастному прилетает.

> там ничего, собственно, нет из удобных инструментов работы с таймлайном.

А какое практическое применение это все несет? Я ж не как цифровой археолог проекты клонирую и вот это знание мне в общем случае похрен, меня интересует кто что и когда сломал, либо кто фичу накодил, или как она эволюционировала. С этим никаких проблем нет а bisect еще и просто приколен. Позволяет гасить баги даже в коде в котором я ни в зуб ногой изначально и вообще понятия не имел что ищу. А treewalk бинарным деревом в целом эффективнее тыкания по датам наугад. С точностью до комита скажет где факап. У культурных людей я сразу вижу где лажа вплоть до того что могу code fix тут же выкатить.

> там даже несчастных тикетов встроеных нет — а тикеты очень многофункциональная вещь.

Кроме того что это - система тикетинга а не VCS. С фига ли это в VCS должно быть для меня вообще загадка.

> всё, что гит делает — он делает очень, очень плохо.

У меня другие идеи на этот счет. Вот именно по версиям, именно исходников, он меня очень эффективно двигает. И никакие тикеты в эту хотелку уж точно не входят.

> но это можно понять только когда реально поработаешь с DVCS, которая делает это хорошо.

Я вообще не понимаю на самом концептуальном уровне почему это занятие для именно DVCS. И ты уж извини но даже тот же мантис как выделеный бактрекер не особо жирный, но при этом - все по делу. Вплоть до того что первая же страница встречает тебя не чем попало а вполне релеватным багтрекингу вью - показывающим именно то что может интересовать тех кто по части багов пришел. А вот всякие встроенные самопалы в этом плане - дикий ужас. Они багтрак делают до кучи и не парятся "do it well". Туда же и гитхаб идет - багтрекер там реально для галочки. В нем даже понимание актуальных самых жмущих проекту багов хрен получишь с наскока, за 5 минут - ну и какой это нафиг "багтрекер" вот так? Фича для галочки.

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

258. "GitHub переходит на использование обязательной..."  +/–
Сообщение от arisu (ok), 07-Май-22, 05:45 
я сначала начал писать большой ответ — а потом мне стало лень, извини. это по сложности и эффективности — примерно как пытаться пояснить, что такое «сладко», человеку, который в жизни пробовал только «солёно» и «горько». большинство твоих непоняток именно от того, что гит нихрена вообще не умеет — и ты считаешь, что так и должно быть. ну, примерно как: «а зачем в редакторе поддержка регулярок? у меня grep и sed есть, а редактор должен делать только своё дело: добавлять и убирать буковки.» так-то вариант, и SAM даже как-то так примерно написан, но… после того, как с нормальным редактором поработал — не очень удобно.

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

p.s.: а SQLite, кстати — в том числе очень удобный кейвалуй. фоссил его и использует как кейвалуй для хранения манифестов и дифов — и оные манифесты с дифами можно в любом другом хранилище держать, оно не так важно. поверх этого там строится куча дополнительных таблиц для удобства — но это уже сервис, все эти таблицы создаются на основе манифестов, их можно выкинуть и построить заново в любой момент. и использовать их совершенно необязательно.

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

263. "GitHub переходит на использование обязательной..."  +/–
Сообщение от Аноним (-), 07-Май-22, 08:05 
> что такое «сладко», человеку, который в жизни пробовал только «солёно»
> и «горько». большинство твоих непоняток именно от того, что гит нихрена
> вообще не умеет — и ты считаешь, что так и должно быть.

Да вообще офигеть, мне от системы контроля версий надо контроль версий и чтобы типовые и частые операции удобно, быстро и интуитивно для меня - ну и потом с другими комитами перекидываться. Остальное в контексте VCS мне похрен.

А раскладывание по дирам - ну вот у меня несколько кернелов лежит. Это divirgent copy of одной и той же базы. Reflink сделал так что копии весом около 2 гигз каждая делались полсекунды и не занимали места (кроме фактических изменений). Но вот логика раскладки внезапно не "версии" а "архитектуры проца" вообще. У вас в ваших концепциях так не предусмотрано? А у меня и вот такая раскладка дико эффективна. Я не уверен но возможно оно даже блочный кеш юзает 1 раз на всю ораву (это продвинутый топик системной механики, я могу и не угадать, но было бы логично).

Я понимаю какие проблемы решает гит. А какие проблемы решают недо-вики и недо-багтреки - не очень, и это не специфично для фоссила. Я то же самое сказал и про (предсказуемо пустые)  вики в шарпойнте. Оно либо медиавики, либо фан этого сам в 1 рыло все редактит. Так получилось. Пойнт мультиплеерного нотпада с 1 плеером мне не понятен.

> ну, примерно как: «а зачем в редакторе поддержка регулярок? у
> меня grep и sed есть, а редактор должен делать только своё
> дело: добавлять и убирать буковки.» так-то вариант,

Типа того. Я совершенно не стесняюсь использовать *никсный шелл и у меня он всегда под рукой, как раз чтобы в него при случае oneliner вбить. Но вот редактирование буковок должно быть хорошим. Ну вот например блочное редактирование в geany - прикольно. Как именно редактирование. Когда поставить 4 пробела за присест можно сразу на 20 линиях, визуально выделив куда попадет. Или селекшн скопировать "квадратиком" из "региона" а не "строками". Регулярки этому не очень помогут и я бы совсем не хотел кодить или скриптить такое сам, особенно с привязкой к визуализации и UI.

> и SAM даже как-то так примерно написан, но… после того, как с нормальным
> редактором поработал — не очень удобно.

Может быть. Но опять же - мне от редактора надо редактирование прежде всего. От програмерского - еще раскрас синтаксиса и быстрое оформление типовых конструкций. Бонус для относительно крупных проектов - навигация по всяким спискам определений, перехода к объявлениям и прочее. А всякие регулярки и прочие вещи я так то и сам скрою в шелле. Насколько это вообще часто надо и зачем бы это делать часто? Оптимизить имеет смысл частые операции а не заподвыподверты.

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

Ну оно как бы да. Однако вики и багтреки для меня не особо понятный бенефит.

> p.s.: а SQLite, кстати — в том числе очень удобный кейвалуй.

Он довольно жирный, тормозной и безблагодатный кейвалуй, прущий с собой огромный скуль-парсер. Если хотелось именно это - даже какой-нибудь токийский кабинет будет поприятнее имхо.

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

Я все же не уверен что это удачное решение дизайна. Не, я понимаю что когда в руках молоток, все кажется гвоздями, а если кто автор скулайта, он его всюду и впихнет. Но что делать если я довольно среднего мнения о низкоуровневой части этого двигла бд?

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

271. "GitHub переходит на использование обязательной..."  +/–
Сообщение от arisu (ok), 07-Май-22, 08:59 
> А всякие регулярки и прочие
> вещи я так то и сам скрою в шелле. Насколько это
> вообще часто надо и зачем бы это делать часто? Оптимизить имеет
> смысл частые операции а не заподвыподверты.

то есть, нормальной поддержки регулярок в твоём редакторе тоже нет. да что ж такое то: за что ни хватишься — ничего нету?!

>> p.s.: а SQLite, кстати — в том числе очень удобный кейвалуй.
> Он довольно жирный, тормозной и безблагодатный кейвалуй, прущий с собой огромный скуль-парсер.
> Если хотелось именно это - даже какой-нибудь токийский кабинет будет поприятнее
> имхо.

можно увидеть документальное подтверждение этих слов? тормозит по сравнению с *чем*? где бенчмарки, где юскейсы? потому что у меня картина несколько иная, и я поубирал из своих проектов как доморощеные кейвалуи, так и другие. и заменил на скулит.

> Но что делать
> если я довольно среднего мнения о низкоуровневой части этого двигла бд?

рассказывать юзкейсы и показывать тесты, не? а то у меня создаётся впечатление, что твоё мнение основано на аллергии на буквы «SQL» (что тоже зря, кстати, потому что SQL крутой).

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

275. "GitHub переходит на использование обязательной..."  +/–
Сообщение от Аноним (-), 07-Май-22, 10:56 
> то есть, нормальной поддержки регулярок в твоём редакторе тоже нет. да что
> ж такое то: за что ни хватишься — ничего нету?!

Как я уже сказал - оптимизировать надо часто нужные вещи. А нужные раз в черти сколько я и oneliner'ом в консоли оформлю. В отличие от продвинутой блочной копипасты какой.

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

Ну если подашь идею что забенчить реалистичного - могу попробовать. Только чуть позже и без жестких гарантий. Просто сколько я не смотрел на скулайт - он при профайлинге всегда светился и это меня анноило.

> рассказывать юзкейсы и показывать тесты, не? а то у меня создаётся впечатление,
> что твоё мнение основано на аллергии на буквы «SQL» (что тоже

А также на тормозняках того что я с скулайтом пробовал делать :\

> зря, кстати, потому что SQL крутой).

Не люблю я бобби тэйблса, извини.

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

277. "GitHub переходит на использование обязательной..."  +/–
Сообщение от arisu (ok), 07-Май-22, 11:13 
> Ну если подашь идею что забенчить реалистичного - могу попробовать.

эм… я предполагал, что раз ты говоришь про тормоза — то ты сравнивал с чем-то. «светится в профайлинге» — это, извини, не критерий. особенно с учётом того, что скулит можно довольно гибко настраивать под разные применения, но почти никто этого делать не желает, потому что в документации многабукав.

> А также на тормозняках того что я с скулайтом пробовал делать :\

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

p.s.: я, к примеру, местами даже доморощеные хэш-таблички в некоторых сишных проектах повыкидывал, потому что скулит справляется достаточно быстро. мой почтовик, например, вообще ничего не кэширует, а просто на каждую перерисовку экрана ходит в базу. и то, что я забыл отключить полную перерисовку экрана при любом движении мыши я заметил очень не сразу, потому что не тормозит (а тормоза были бы видны, потому что я рисую мышиный курсор битмапом в виртуальный экран, а не использую аппаратный). да, на базе под гигабайт. а ботоотсекалка, которая сидит перед моим веб-сервером, спокоино в состоянии обработать десятки тысяч коннектов с секунду — а она тоже активно ходит в базу, каждый раз читает оттуда кучу всего, и пишет туда логи на каждый чих почти. так что я слабо себе представляю, что у тебя за особенные задачи такие, где скулит тормозит — и мне неиронично интересно.

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

355. "GitHub переходит на использование обязательной..."  +/–
Сообщение от Аноним (-), 09-Май-22, 22:32 
> эм… я предполагал, что раз ты говоришь про тормоза — то ты
> сравнивал с чем-то. «светится в профайлинге» — это, извини, не критерий.

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

> особенно с учётом того, что скулит можно довольно гибко настраивать под разные применения,

Между нами, я очень не хочу крутить кучу tunables и становиться чем-то типа DBA - я хочу решить те или иные задачи и DB там лишь одно из звеньев. Чем меньше оно внимания к себе требует, при более забористом перфомансе и мизерном жраче ресурсов, тем я довольнее жизнью. При этом очень кстати если первая попытка знакомства покажет что-то клевое, а не унылый булшит.

И таки я не против накодить какойнить бенч ради лулзов - есть прикольные примеры юзежа скулайта как именно key-value? Желательно с произвольным ключом и значением, токийский кабинет приколен тем что жрет любое бинарное нечто как таковые с минимальными constraints на это все. Так что бобби тэйблс может любой ник брать а мне ничего не будет за юзеж оного как key, например. Мне нравятся такие апи.

> но почти никто этого делать не желает, потому что в документации многабукав.

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

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

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

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

> p.s.: я, к примеру, местами даже доморощеные хэш-таблички в некоторых сишных проектах
> повыкидывал, потому что скулит справляется достаточно быстро.

У скулитовского бэка насколько я помню есть проблемы с масштабированием (файлы более 20 гигз ему вообще категорически противопоказаны) - и это, там есть что-то глядя на что я бы сказал вау? Допустим что SQL меня не интересует - а как key value он таки на первый взгляд нечто странное. Есть какие-то "эпичные" примеры как его в режиме key-value, без всякого скуля?

> мой почтовик, например, вообще ничего не кэширует, а просто на каждую перерисовку
> экрана ходит в базу.

А будет ли он адекватно себя вести если у меня например почтовая база под 80 Гб с сотнями тысяч сообщений? Многим key-value сам по себе размер или число item'ов относительно пофиг, а у скулайта после ~20 гигз начинают тупить внутренние операции их двигуна с страницами и деревьями как я понял.

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

Странный ты тип, рисовать курсор самому битмапом но при этом скулем ворочать...

Лично мне нравится когда запросы к бд прямые, быстрые, и без ограничений на то что в ключе и значении, как бинарные данные, без преобразований.

> да, на базе под гигабайт.

Это, типа, много? И каком числе записей в базе?

> а ботоотсекалка, которая сидит перед моим веб-сервером, спокоино в состоянии
> обработать десятки тысяч коннектов с секунду — а она тоже активно ходит в базу,

Оно как бы здорово - но опять же без хотя-бы данных профайлинга не говорит мне чуть менее чем ничего. Ибо сами по себе десятки тыщ конектов в секунду на современнном железе не есть что-то этакое.

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

Да даже просто bulk insert записей в солидном объеме мне хтонически не понравился. В том плане что вот это вот на key value имеет свойство быть сильно резвее. Да, конечно, можно порассуждать про фичи, гарантии и проч - но будем честны, я не люблю SQL и не намерен им пользоваться. А вот базы key-value иногда юзаю.

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

358. "GitHub переходит на использование обязательной..."  +/–
Сообщение от arisu (ok), 10-Май-22, 05:23 
>> эм… я предполагал, что раз ты говоришь про тормоза — то ты
>> сравнивал с чем-то. «светится в профайлинге» — это, извини, не критерий.
> Для меня это как раз таки критерий. О его идеальности можно заспорить,
> но все же, это позволяет осмысленно наседать на проблемы перфоманса -
> понимая во что уперлось и в какую сторону копать.

всё-таки в сторону чтения документации прежде всего.

>> особенно с учётом того, что скулит можно довольно гибко настраивать под разные применения,
> Между нами, я очень не хочу крутить кучу tunables и становиться чем-то
> типа DBA

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

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

у каждого своё понятие «клёвого».

> И таки я не против накодить какоинить бенч ради лулзов - есть
> прикольные примеры юзежа скулайта как именно key-value?

ну что значит «прикольные»-то?

> Желательно с произвольным ключом
> и значением, токийский кабинет приколен тем что жрет любое бинарное нечто
> как таковые с минимальными constraints на это все.

ограничение скулита — 2^31 на одно значение в базе (будь то ключ, или блоб-валуй). потому что API использует инты; 64-бит апи тоже есть, но его добавили — по меркам SQLite — не так давно. впрочем, я не думаю, что кто-то тестировал его на ключах такого размера, так что полагаю, что более реальная мера — это где-то мегабайт для ключа. для валуя без разницы, там есть file-like API к ним. да, нули внутри этого никто не запрещает, и SQLite не поперхнётся.

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

ты же понимаешь, что этой фразой определяешь себя в ту же категорию, что и юзеры, которые хотят, чтобы им дали кнопку «сделай хорошо!»?

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

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

> Я что-то пропустил? Ну, дай какие-нибудь интересные примеры
> чего-то низкоуровневого и быстрого на нем?

чего?

> Скуль мне не интересен как категория.

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

> Ну, я 100К и 1М записей добавлял в скулайт базы.

я же не зря просил юзкейсы. у тебя задача, у которой это основной режим работы? потому что если это было начальное заселение базы — никто не мешал тебе отключить к чёрту весь ACID и остальные «тяжёлые» механизмы на время заселения.

> У скулитовского бэка насколько я помню есть проблемы с масштабированием (файлы более
> 20 гигз ему вообще категорически противопоказаны)

откуда дровишки? потому что мой *практический* опыт такого не демонстрирует.

> и это, там есть что-то глядя на что я бы сказал вау?

откуда я знаю, что для тебя «вау»?

>> мой почтовик, например, вообще ничего не кэширует, а просто на каждую перерисовку
>> экрана ходит в базу.
> А будет ли он адекватно себя вести если у меня например почтовая
> база под 80 Гб с сотнями тысяч сообщений?

будет. ему абсолютно всё равно.

> Многим key-value сам
> по себе размер или число item'ов относительно пофиг, а у скулайта
> после ~20 гигз начинают тупить внутренние операции их двигуна с страницами
> и деревьями как я понял.

не начинают. это раз. и два: а как у кейвалуев с выборкой типа: «хочу письма с тэгами abc и def, за период 'последний месяц', где в заголовке есть слово 'ЩАСТЕ', сортированые по дате, флажку 'important', и принадлежности к тредам»? мне вот это вот надо кодировать руками на каждый чих, или опять же руками пилить недо-sql, чтобы делать подобные выборки? а зачем, если у меня уже есть готовый SQL, который с подобными запросами справляется играючи?

(да, пример из жизни; я часто создаю подобные «виртуальные каталоги» по запросам. это всё ещё не тормозит.)

> Странный ты тип, рисовать курсор самому битмапом но при этом скулем ворочать...

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

> Лично мне нравится когда запросы к бд прямые, быстрые, и без ограничений
> на то что в ключе и значении, как бинарные данные, без
> преобразований.

ну и отлично. если бы ты изволил почитать документацию по SQLite, ты бы с удивлением обнаружил…

>> да, на базе под гигабайт.
> Это, типа, много? И каком числе записей в базе?

это типа я намекаю, что база не игрушечно-тестовая. а что значит «число записей», и что это за метрика — я не очень понимаю. это база данных, а не кейвалуй, она умеет более чем в одну таблицу. у меня там хранилище, словари, view-ы, и ещё много прикольных удобных штучек, и всё это совершенно бессмысленно считать тупым сложением (потому что при некоторых подсчётах может получиться вообще +inf).

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

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

>> каждый раз читает оттуда кучу всего, и пишет туда логи на каждый чих почти. так что
>> я слабо себе представляю, что у тебя за особенные задачи такие,
>> где скулит тормозит — и мне неиронично интересно.
> Да даже просто bulk insert записей в солидном объеме мне хтонически не
> понравился.

см. выше про это.

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

362. "GitHub переходит на использование обязательной..."  +/–
Сообщение от Аноним (-), 10-Май-22, 12:45 
> всё-таки в сторону чтения документации прежде всего.

Ну вот не попадалось прикольных примеров для скулайта для быстрого старта. А плотно вштыривать - я не DBA и не готов на это столько сил сливать если оно решаемо иными методами.

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

В идеале - да, удобнее всего было бы запустить компилер и чтобы это был максимально компактный и быстрый код, все и сразу. Но у конкретно меня сборка софта бывает очень разнообразной. У фирмвари которая должна в 16 кил флехи влезть "хоть там что" приоритеты одни, а -10% скорости vs O2 обидно, но болт с ним: мы или успеваем в ралтайм, или нет. И если я уже тошнился в 10% от грани, я про@$#%лся на совсем других уровнях. А у вон той мегасофтины с 7-метровым бинарем исполняемого где надо максимальный перфоманс на том что есть, любой ценой, таки сильно разные приоритеты в кодогенерации. И чем ближе компилер к тому идеалу тем он лучше так то. В этом плане LTO например ацкий win: может урезать чуть не треть бинаря, ничего не теряя.

> *любой* гибкий и сложный инструмент желательно настраивать под свои нужды,

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

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

Я как бы допускаю что мои хотелки отличаются от среднестатистических. Но даже они имхо могут хотеть резвый инсерт миллиона записей в базу. А хотя-бы для импорта/конверсии чего-то уже существовавшего.

> у каждого своё понятие «клёвого».

У меня это что-нибудь маленькое, простое, быстрое, ядреное, не жрущее ресурсы и при этом делающее что-нибудь интересное и полезное.

> ну что значит «прикольные»-то?

Простые, маленькие, быстрые как п@нос. Ну как у lwan например - полстранички на си и вот у вас уже скоростной вебсерв, с кастомными хэндлерами, можно GOпникам мастеркласс на тему микросервисов показывать.

> ограничение скулита — 2^31 на одно значение в базе (будь то ключ, или блоб-валуй).

Вообще, вполне нормально так то по описанию. А ключом может быть произвольный блоб без заморочек с эспейпингом и проч? Это удобно например чтобы чейто ник в виде как есть юзать как "ключ" и единственный критерий сам ник, а что за кал они туда записали - да пофиг. Ну вот не хочу я эскейпить и фильтрить бобби таблесов.

> потому что API использует инты; 64-бит апи тоже есть, но его добавили — по
> меркам SQLite — не так давно.

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

> впрочем, я не думаю, что кто-то тестировал его на ключах такого
> размера, так что полагаю, что более реальная мера — это где-то
> мегабайт для ключа. для валуя без разницы, там есть file-like API
> к ним. да, нули внутри этого никто не запрещает, и SQLite
> не поперхнётся.

А еще я не люблю оверинженерию. Не надо мне никаких file like api, если мне будет надо это, я таки умею файловой системой пользоваться. А делать что-то типа doc-файлов в мои планы не входит.

Ну то-есть если б у скулайта был вот реально лайт, где есть мини-версия с key-value двигуном отдельно от всяких файловых апи и скуля, я бы вероятно с ним познакомился сильно плотнее. А когда мне еще кучу мусора прут, мне оно не надо. Это только делает либ жирнее, медленнее, и уменьшает мое желание видеть это в depends.

> что и юзеры, которые хотят, чтобы им дали кнопку «сделай хорошо!»?

Конечно. И как-то так люди и работают :). Можно меня и обиднее пнуть, показав питонистов. Даже все так будет, НО есть нюансы: их код обычно медленный, кривой, с периодом полураспада год, падающий без обработки ошибок на каждый пук - и в конечном итоге я знаю что разработка софта все же комплексное мероприятие если хочется те соотношения как-то поприятнее.

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

Токийский кабинет дает выбор между хэштаблицей и б-деревом и я совершенно ок с этой тупизной, будучи в состоянии выбрать параметры и тип осмысленно, там даже RTFMимть особо не надо ибо это азы CS, не зная которые считать себя прогером может только наглый веьманки. Зато небольшая либа, относительно простое апи, минимум лимитов, которые просто держать в голове. А не огромный монстр с автоматической задовытиралкой для тупиц там где мне хотелось "немного базы". Не, скуля не хотелось - я не dba и не мегаархитект баз данных, это не мое. Совсем.

> и автоматом ресайзить её не умеет.

Мне в многих моих случаях это ок.

> а если я количества записей заранее не знаю?

B-деревьям IIRC похрен. Да, там иные соотношения, O(1) vs O(log(N)). Но оно вроде и у скулайта вылезает, что они, волшебники? Или там какой-то нии...цца прорыв в CS случился заслуживающий внимания?

> ну, и будет там или куча неэффективной пустоты с page miss,

У меня разные кейсы, включая и системы с лимитированой RAM так что я на page cache и прочие огромные кеши могу и не хотеть ориентироваться.

> или оно выродится в блуждание по связаным спискам, с теми же page miss. (да, я его читал.)

Page miss вот так по максимуму беспокоит .. не всех и не всегда.

> чего?

Ну там insert и retrieve произвольного блоба-ключа и значения с минимумом допущений. Ну, кроме размера.

> обычно такое говорят люди, которые не умеют применять SQL.

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

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

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

Ну например, у юзера токса уникальнй глобальный ID это 32 байта ключа. Технически это u8[32].

С этим бывают фееричные приколы. Скажем был мускул, я хотел в скулайт попробовать перегнать. База тривиальная но заполнена реальными юзерами. Агаблин, мускуль экспортирует свой чудный текст.. а дальше скуль то типа скуль, но здесь вам не тут - после тупняков полдня испорт таки завалился. Да, юзеры ввели очень странный булшит, и где-то на i++'ной записи оно сломалось, когда мнение мускула и скулайта об эскейпинге чего-то хитрого не совпали. Нюанс в том что я вообще совсем не хочу греть мой маленький мозг ПОДОБНЫМ БУЛШИТОМ. Совсем.

> я же не зря просил юзкейсы. у тебя задача, у которой это
> основной режим работы?

Нет конечно, НО возможны burst'ы активности и кроме того - а почему это должно работать хреново, собссно?

> потому что если это было начальное заселение базы — никто не мешал тебе отключить
> к чёрту весь ACID и остальные «тяжёлые» механизмы на время заселения.

Оно как бы да. Но все это напомнит о себе и при всплеске активности. И в принципе позволяет целенаправленно валить вон тот сервис вот этими запросами. В key-value я в принципе сильно меньше грею мозги такими вещами: там тормозить особо нечему. И если мне хотелось НЕМНОГО базы это не значит что я мечтал стать профессиональным DBA/девом умеющим в оптимизацию запросов и что там еще.

> откуда дровишки? потому что мой *практический* опыт такого не демонстрирует.

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

> откуда я знаю, что для тебя «вау»?

См. выше. Ну да, сейчас это не модно. Но я люблю мелкий, шустрый, крутой, эффективный софт. Переклин на текстовом представлении в этом не помощник если что.

> будет. ему абсолютно всё равно.

Хм, может они что-то в движке переделали? Но раньше они не советовали за 20 гигз вылезать, что-то по части низкоуровневой механики как раз.

> не начинают. это раз. и два: а как у кейвалуев с выборкой типа: «хочу письма
> с тэгами abc и def, за период 'последний месяц', где в заголовке есть слово
> 'ЩАСТЕ', сортированые по дате, флажку 'important', и принадлежности к тредам»?

Так хотелки разные бывают, с вот такой я понимаю нафиг тебе скуль. На чистом key value оно конечно канительно, самому индексы строить на все и вся. Это решаемо, но изобретение вела зайжет далековато. Но у меня обычно хотелки сильно проще.

> мне вот это вот надо кодировать руками на каждый чих, или опять же руками пилить
> недо-sql, чтобы делать подобные выборки? а зачем, если у меня уже есть готовый
> SQL, который с подобными запросами справляется играючи?

Все так. Но у меня сильно более простые хотелки относительно баз.

> (да, пример из жизни; я часто создаю подобные «виртуальные каталоги» по запросам.

Оно как бы забавно но не думаю что мне сильно надо что-то такое.

> это всё ещё не тормозит.)

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

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

Спасибо кэп. Только про b-деревья еще забыл. Да, совершенно никакой черной магии. И я хочу вот что-то такое, когда мне надо НЕМНОГО базы с простой, тривиальной схемой данных.

> после чего преимущества кейвалуев резко уходят в никуда.

Кроме того что с ними не придется "ну ты ручками отключи ACID" - и вообще RTFMай в оптимизацию запросов дескать. Ух, а в мои планы точно входило стать профессиональным DBA чтобы столько RTFMать? А может я хотел простого чатбота например накодить, с тупой как дрова "схемой хранения"? Или там вебфигню тривиальную где база настройки по юзерам помнит, с идентификатором юзера который везде напихан и "primary key" по любому, а остальное в value прекрасно ложится и больше мне там ничего и не надо. А вот оптимизить запрос на скорость мне совсем не хочется.

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

Ну, мне вон те кейсы просто ни к чему. Я не пишу почтарь с поиском по 20 критериев за присест и виртуальными вью.

> ну и отлично. если бы ты изволил почитать документацию по SQLite, ты
> бы с удивлением обнаружил…

Да, она здоровенная и всю ее я ессно не читал. И фич в нем архидофига. Если мне надо вбить гвоздь, я хочу молоток. А пригнать мне компрессор и супермолот позволяющий загвоздить все вокруг - избыточно. Чтение инструкции как его запускать займет больше времени чем взять обычный простой молоток и забить гвоздь. Да, в молотке нет совсем никакой магии. Это простой инструмент для решения простых задач. Те кто планирует застроить целый квартал найдут более эффективный инструмент и чтение мана на его использование окупится.

> это типа я намекаю, что база не игрушечно-тестовая. а что значит «число
> записей», и что это за метрика — я не очень понимаю.

Ну то и значит.

> прикольных удобных штучек, и всё это совершенно бессмысленно считать тупым сложением
> (потому что при некоторых подсчётах может получиться вообще +inf).

Так я и не утверждал что скуль для этого чем-то плох. Мне просто столько не надою.

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

А все равно без данных профайлинга и знания конфиги мало что говорит.

>> Да даже просто bulk insert записей в солидном объеме мне хтонически не понравился.
> см. выше про это.

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

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

366. "GitHub переходит на использование обязательной..."  +/–
Сообщение от arisu (ok), 10-Май-22, 14:04 
>> всё-таки в сторону чтения документации прежде всего.
> Ну вот не попадалось прикольных примеров для скулайта для быстрого старта.

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

>> ты и ключи компилятора тоже не используешь?

…skip…
ну, то есть, задрачивать компилятор не впадлу. а сделать то же самое с другим инструментом — всё, западло, остальное пусть само как-нибудь. я этого не понимат.

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

я понял, что ты путаешь тупые хэш-таблички, и базы данных. это две СОВЕРШЕННО разные вещи.

> При этом моему низкоуровневому мозгу сие как-то проще и приятнее.

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

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

при чём тут это? они у всех разные. поэтому дефолтом идёт настройка: «среднехреново для всех». чего иногда хватает, а иногда нет.

> Но даже
> они имхо могут хотеть резвый инсерт миллиона записей в базу.

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

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

это всё ещё ничего не описывает, увы. особенно в пунктах «интересное и полезное», которые у всех разные.

>> ну что значит «прикольные»-то?
> Простые, маленькие, быстрые как п@нос. Ну как у lwan например - полстранички
> на си и вот у вас уже скоростной вебсерв, с кастомными
> хэндлерами, можно GOпникам мастеркласс на тему микросервисов показывать.

извини, но это же ужасная оверинжинирнутая дрянь. до нормального «большого» оно не дотягивает, а для «на коленке» слишком перенаворочено.

>> ограничение скулита — 2^31 на одно значение в базе (будь то ключ, или блоб-валуй).
> Вообще, вполне нормально так то по описанию. А ключом может быть произвольный
> блоб без заморочек с эспейпингом и проч?

естественно.

> С оговоркой что я - вообще совсем не text minded
> существо и у меня в байте 8 битов. Поэтому я хочу
> оперировать всем этим прозрачно без вебмакачьих причуд с эскейпингом и какой
> там еще "читаемостью".

оперируй на здоровье.

> Вон тот умеет так и в ключе и
> в значении и по диску эффективен, запрос заканчивается за пару io
> операций.

шо, каждый раз пара i/o? отвратительно, никогда не используй такой ужас. ;-)

> А еще я не люблю оверинженерию. Не надо мне никаких file like
> api, если мне будет надо это, я таки умею файловой системой
> пользоваться. А делать что-то типа doc-файлов в мои планы не входит.

не надо — не используй, бинди/читай просто кусок памяти, нет проблем.

> Ну то-есть если б у скулайта был вот реально лайт

оно есть. называется SQLite.

> мини-версия с key-value двигуном отдельно от всяких файловых апи и скуля,
> я бы вероятно с ним познакомился сильно плотнее.

самое смешное, что такое тоже есть, но ты опять не читал документацию. проект SQLite4 был закрыт, как неудачный, но его хранилище доступно отдельно, и как библиотека, и как модуль для SQLite.

> А когда мне еще кучу мусора прут, мне оно не надо.

тебе дают один c-файл, и один h-файл. которые можно тупо скопипастить себе в дерево исходников и радоваться. так, например, делает фоссил.

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

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

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

вообще-то любой инженер-практик тебе скажет, что выбрать заранее эти параметры осмысленно невозможно, вероятность ошибки 99.(9)%.

> Зато небольшая
> либа, относительно простое апи, минимум лимитов, которые просто держать в голове.

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

> А не огромный монстр с автоматической задовытиралкой для тупиц там где
> мне хотелось "немного базы". Не, скуля не хотелось - я не
> dba и не мегаархитект баз данных, это не мое. Совсем.

так ты и не пробовал, ты просто сразу, не разбираясь, решил, что НИНАДА. довольно неразумно, не находишь?

>> а если я количества записей заранее не знаю?
> B-деревьям IIRC похрен.

зато там фиксированый размер ключей.

>> чего?
> Ну там insert и retrieve произвольного блоба-ключа и значения с минимумом допущений.
> Ну, кроме размера.

на здоровье. SQLite вообще не занимается конвертацией чего-либо, если ты его явно не попросишь.

>> обычно такое говорят люди, которые не умеют применять SQL.
> А я и не хочу это уметь.

что опять-таки неразумно.

> Мне может хотеться "немного базы"
> но - именно немного. А вот всяких эскейпингов-экранирований, мега запросов и
> прочее - ну, это не ко мне.

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

>> в 99% случаев в их коде наблюдается какой-нибудь кейвалуй, на котором они
>> пытаются сэмулировать то, что SQL умеет из коробки, и получается у них всегда
>> откровенно хуже.
> Зато их не посетит боби тэйблс например. А если от него эффективно
> позатыкать все, начинается шоу, то какие-нибудь лимиты на буквы в никах,
> то экранирование с которым вечно лажа выходит. Усвой плиз, у меня
> байты 8-битные и я не хочу пытаться упихивать все как текст.

см. выше.

> Ну например, у юзера токса уникальнй глобальный ID это 32 байта ключа.
> Технически это u8[32].

не вижу проблемы. храню в базе всякое, включая бинарные иды. всё работает. что такое это ваше «экранирование» — не знаю, и знать не хочу.

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

извини, но ты сейчас очень круто сравнил два инструмента с *совершенно* разной областью применения. SQLite shell — это отладочный инструмент, а не фронтэнд. потому что SQLite предназначена для использования прямиком из кода, через её API.

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

потому что это разные паттерны работы с данными. которые требуют разных подходов. в частности, SQLite из коробки настроен так, чтобы прозрачно и без дополнительных телодвижений поддерживать работу с одной базой одновременно из кучи приложений — поэтому он базу защищает. если тебе это не надо — это всё можно отключить, и оно будет сильно быстрее.

>> потому что если это было начальное заселение базы — никто не мешал тебе отключить
>> к чёрту весь ACID и остальные «тяжёлые» механизмы на время заселения.
> Оно как бы да. Но все это напомнит о себе и при
> всплеске активности.

а подумать ДО того, как писать код — не?

> В key-value я в принципе сильно меньше грею
> мозги такими вещами: там тормозить особо нечему.

охлол.

> И если мне хотелось
> НЕМНОГО базы это не значит что я мечтал стать профессиональным DBA/девом
> умеющим в оптимизацию запросов и что там еще.

«не хочу учиться, а хочу жениться!» ;-) в подавляющем большинстве случаев для написания нормального запроса достаточно рабочего мозга и опыта функционального программирования. потому что query planner'ы довольно умные (даже в SQLite), и средней паршивости запрос вполне приемлемо разрулят. в глубокий оптимайз обычно надо если ты хочешь от базы СТРАННОГО. например, получить кучу данных со связями одним запросом, а не ходить в базу за отдельными кусками (и это имеет смысл, потому что часто так быстрее; в кейвалуе у тебя просто нет никакого выбора в этом случае).

>> будет. ему абсолютно всё равно.
> Хм, может они что-то в движке переделали? Но раньше они не советовали
> за 20 гигз вылезать, что-то по части низкоуровневой механики как раз.

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

>> это всё ещё не тормозит.)
> Ну как бы "не тормозит" без инфо по юзежу ресурсов мне ничего
> не говорит. Так то даже тяжелые и тормозные операции "не тормозят"
> если они где-то в фоне, но...

я не люблю потоки без нужды. «не тормозит» — значит именно то, что оно при использовании не тормозит безо всяких фоновых обработок. то есть, время отклика софта в среднем не выше 16 мсек. да, я привык мерять в FPS, и предпочитаю, чтобы 60. ;-)

> И я хочу вот что-то такое, когда мне надо НЕМНОГО базы
> с простой, тривиальной схемой данных.

проблема в том, что кейвалуй — ни разу не база. бд позволяет запрашивать, сортировать и фильтровать данные по разным критериям, а не тупо по одному ключу.

>> после чего преимущества кейвалуев резко уходят в никуда.
> Кроме того что с ними не придется "ну ты ручками отключи ACID"

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

> и вообще RTFMай в оптимизацию запросов дескать.

ты опять откуда-то взял странное. я тебе говорю почитать официальную документацию по API.

> может я хотел простого чатбота например накодить, с тупой как дрова
> "схемой хранения"?

с этим скулит справится даже без тюнинга. с огромным запасом.

>> и что большинство моих требований отлично умеет SQL, и руками ничего писать
>> не надо. и я стал просветлённый. хотя SQL пришлось учить, конечно.
> Ну, мне вон те кейсы просто ни к чему. Я не пишу
> почтарь с поиском по 20 критериев за присест и виртуальными вью.

а это как с фоссилом: ты не умеешь в SQL, но уверен, что оно тебе не надо. скажу тебе по секрету, что мне оно тоже было не надо, а SQLite была жирной перегруженой бесполезной ерундой — ровно до того момента, как я осознал, что даже не попытался сначала разобраться в инструменте, и только потом его браковать. и разобрался. и вдруг случилось чудо: я повыкидывал остальные кейвалуи, а SQL мне стал прельстив.

> Да, она здоровенная и всю ее я ессно не читал.

именно поэтому на родном сайте есть не только API reference.

> И фич в нем архидофига.

и что самое прикольное: никто тебя не заставляет обязательно использовать каждую из них!

> Чтение инструкции как его запускать займет больше времени чем взять
> обычный простой молоток и забить гвоздь.

но ты ведь даже не пробовал читать, ты просто решил, что многабукав.

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

это ничего не значит в контексте *базы* *данных*. эта метрика имеет смысл для какой-нибудь хэш-таблички.

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

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

>>> Да даже просто bulk insert записей в солидном объеме мне хтонически не понравился.
>> см. выше про это.
> Ну да, ну да, я должен разучивать оптимизационные трюки даже для того
> чтобы просто базу сделать. Круто, всю жизнь мечтал почитать процедуру запуска
> навернутого компрессора при желании забить гвоздь.

нет, тебе надо просто почитать документацию. это совсем небольно. в ней, например, можно найти рекомендации по тому, как делать bulk insert, и какие бывают подводные камни.

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

273. "GitHub переходит на использование обязательной..."  +/–
Сообщение от пох. (?), 07-Май-22, 09:49 
>>> гит - ненужно.
>> А что нужно то, лол?
> Fossil же. в коробке имеет вики, форум, тикеты и даже чятег. всё

да хоть тот же phabricator поставь (не прибитый насмерть к единственноверному софту) - кто тебя найдет там, кто полезет обзаводиться стотыщепервым логином (кстати пароль будет 123 потому что "зае...достали вы миллиардпервой регистрацией ради щастья сообщить что у вас баг и исправляется вот этим одним символом в вот этой строке") и вообще разбираться в этом? Уверен ли ты что ты НАСТОЛЬКО важен и нужен людям как sqlite к примеру?

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

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

278. "GitHub переходит на использование обязательной..."  –1 +/–
Сообщение от arisu (ok), 07-Май-22, 11:23 
ты как обычно: ничего не знаешь, но мнение имеешь.

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

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

286. "GitHub переходит на использование обязательной..."  +/–
Сообщение от пох. (?), 07-Май-22, 13:14 
> так, для информации: чтобы написать в фоссил, совершенно не обязательно заводить учётку.

ок, давай свой фоссил. Я тебе туда напишу миллионстотыщ предложений продажи кондомов секондхэнд и ссылок на гидру.

Не ожидал что ты тоже настолько феноменально т-пой, что не понимаешь, ЗАЧЕМ требуют регистрации.

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

359. "GitHub переходит на использование обязательной..."  +/–
Сообщение от arisu (ok), 10-Май-22, 05:35 
я рад, что ты держишь марку, и продолжаешь писать о том, в чём не разбираешься.

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

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

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

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

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




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

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