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

"pgrust - клон PostgreSQL на Rust, проходящий все регрессионные тесты"	+/–
Сообщение от opennews (??), 10-Июл-26, 11:11
Опубликован проект pgrust с реализацией СУБД PostgreSQL, переписанной на языке Rust c использованием транслятора c2rust и  AI-ассистента. Заявлено, что проект пока не готов для использования в рабочих проектах, но уже успешно проходит все регрессионные тесты PostgreSQL, совместим с форматом хранения данных PostgreSQL 18.3 и может использовать data-каталог от PostgreSQL 18.3. Код проекта распространяется под лицензией AGPLv3, в отличие от оригинального PostgreSQL, поставляемого под пермиссивной лицензией PostgreSQL, близкой к лицензиям BSD и MIT. Доступна online-демонстрация возможностей, основанная на сборке в WebAssembly, а также docker-образ для быстрого запуска... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=65879
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 10-Июл-26, 11:11	+27 +/–
А зачем этот клон, если есть нормальный PostgreSQL? :/
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #9, #13, #38, #55, #62, #146

2. Сообщение от aname (ok), 10-Июл-26, 11:12	+3 +/–
> переписанной на языке Rust c использованием транслятора c2rust и AI-ассистента Без нейросети не осиливают уже переписать. Rust. Итоги.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #31, #65, #224

3. Сообщение от Аноним (3), 10-Июл-26, 11:13	–1 +/–
> А зачем этот клон, если есть нормальный PostgreSQL? :/ Зачем вообще что-то делать, если уже всё есть?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6

5. Сообщение от Аноним (5), 10-Июл-26, 11:13	+11 +/–
Да-да-да, знаем мы эти 146% прохождения тестов на совместимость, в убунте ржавый бизибокс отваливается каждый раз когда его пытаются пропихнуть.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #14, #57, #162

6. Сообщение от Аноним (1), 10-Июл-26, 11:15	+/–
Вот в чём и вопрос. Зачем «изобретать велосипед»?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #115

8. Сообщение от Аноним (8), 10-Июл-26, 11:16	+2 +/–
Не, ну технически можно гонять нейронку, пока все тесты не начнут выполняться. Но что там с производительностью, архитектурой?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #17, #163

9. Сообщение от aname (ok), 10-Июл-26, 11:16	+1 +/–
Стильно, модно, молодёжно же.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #33

10. Сообщение от Аноним (10), 10-Июл-26, 11:18	+9 +/–
Когда оно тихонечко съест или испортит данные, ИИ скажет юзеру: я очень извиняюсь, вы правы, мне не стоило этого делать.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #24, #164

11. Сообщение от freehck (ok), 10-Июл-26, 11:21	+4 +/–
> По словам автора проекта, в настоящее время ведётся работа над следующей версией pgrust, в которой вместо пула рабочих процессов реализована многопоточная модель обработки соединений, а также задействованы дополнительные оптимизации, такие как пакетная обработка строк в таблицах и упреждающая загрузка данных. При тестировании инструментарием percona-tpcc при обработке транзакций новая версия pgrust оказалась быстрее штатного PostgreSQL на 50%, а при обработке аналитических запросов - в 300 раз. Да неужели. Да, это быстрее, кто ж спорит. Однако любая ошибка в коде воркера приведёт к порче памяти мастер-процесса. Разработчик выбирает явно неразумный трейдофф. Я очень сомневаюсь, что транслятор смог переписать всё с учётом потоко-безопасности и без unsafe-ов.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #45

13. Сообщение от knike (?), 10-Июл-26, 11:21	–2 +/–
проведение экспериментов по изменению внутреннего устройства и созданию версии PostgreSQL, избавленной от архитектурных ограничений, от которых не удаётся избавиться по историческим причинам
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #74

14. Сообщение от Аноним (14), 10-Июл-26, 11:22	+4 +/–
Дык это только показывает что тесты не покрывают то, что должны покрывать. От улучшения тестов выигрывают все, в том числе GNU coreutils.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #16, #68

16. Сообщение от freehck (ok), 10-Июл-26, 11:26	+2 +/–
> Дык это только показывает что тесты не покрывают то, что должны покрывать. Кому должны? Тесты — это не формальная спецификация. Их пишут, чтобы отлавливать регрессы, а не для того, чтобы всякие Васяны могли переписать твой продукт. Это принципиально две разные задачи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

17. Сообщение от Пыщь (?), 10-Июл-26, 11:27	+3 +/–
Ты чего? Там святагая ржавчина! У неё нет разыменованный указатель, переполнение буфера, выход за границы, УБ-УБ-УБ, ЦВЕ, дискета, снуборд. А ещё ... "инфантильный ты"! (тут на форуме один мощно задвигает термины, смысл которых ему, видимо, малопонятен, я лишь жалкая пародия на оного, но стараюсь не сильно отставать).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

18. Сообщение от Аноним (18), 10-Июл-26, 11:27	+1 +/–
Страшно представить если кому-то придется поддерживать такой код:( Зато теперь понятно для чего нужен ИИ, так как Rust и C++ это изначально языки не для людей;)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #19, #21

19. Сообщение от Аноним (19), 10-Июл-26, 11:30	–2 +/–
> C++ это изначально языки не для людей Ты как бы врать то ври, но не завирайся. C++ появился в 1985 и до примерно C++ или чуть позже был вполне себе нормальным языком с лаконичным синтаксисом. Ты точно уверен и не брешишь, что C++ с первого дня (как ты сказал - изначально) не был для людей?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #20, #22, #29, #143, #176

20. Сообщение от Аноним (19), 10-Июл-26, 11:30	+1 +/–
* до примерно C++11
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

21. Сообщение от нах. (?), 10-Июл-26, 11:30	+1 +/–
дык эта - клава, подержи...тьфу, опечатался - поддержи кота! другой вопрос - кому оно нахрен такое надо за те деньги. тут в существующем-то постгрезе ничего толком не получается исправить, что с клавой, что без... один вон цельный core dev пыжился-пыжился, уже почти совсем готов был (снова!) избавить нас от формата нуждающегося в vacuum - упс, оподливился. Давайте говорит все выкинем и целиком заново ядро напишем, а то мой патч не работает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #23, #53

22. Сообщение от Аноним (18), 10-Июл-26, 11:31	+/–
Какая разница что там было изначально, сейчас это язык для ИИ
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

23. Сообщение от Аноним (18), 10-Июл-26, 11:38	–1 +/–
IT гигантам это надо! Ставка на  человек + ИИ агенты уже сделана, глупо это отрицать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #27, #46

24. Сообщение от Аноним (24), 10-Июл-26, 11:40	+/–
я позволил себе деструктивную операция без явного призыва сделать бэкап))) плавали знаем
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

25. Сообщение от Аноним (25), 10-Июл-26, 11:41	+3 +/–
PostgreSQL написан на чистом C, собирается очень быстро и оставьте его на чистом C
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #69, #102

27. Сообщение от Аноним (24), 10-Июл-26, 11:48	+1 +/–
ой, как будто it гиганты никогда не садились в лужу, да они вроде как только это и делают, аппаратные рейды, кому нужны сейчас? а как бродком то их продвигал, сколько раз эпл прыгала по архитектурам процов? ну, про интел думаю не надо рассказывать, так слить надо уметь, амд может оплот логики и стабильности? все деньги мира к ним потекли, и чего, драйверов нормальных написать не могут, инструкции отключают. > глупо это отрицать
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #32

29. Сообщение от Аноним (29), 10-Июл-26, 11:49	–1 +/–
Таки без С++ не было бы Qt. Да и непонятно, получилось бы Qt на каком-нибудь другом языке (на Rust бы не получилось).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #34, #73, #112

31. Сообщение от Соль земли2 (?), 10-Июл-26, 11:51	–2 +/–
А нужно ли надрываться с топором, когда есть бензопила?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #40, #70

32. Сообщение от Аноним (18), 10-Июл-26, 11:53	+/–
Ничего, скоро стадия отрицания пройдет:)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #108

33. Сообщение от Аноним (33), 10-Июл-26, 11:55	–15 +/–
И прирост производительности аналитических запросов в 300 раз. А ну да ладно, мелочь, просто игрушки...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #35, #39, #60

34. Сообщение от Аноним (18), 10-Июл-26, 11:58	+1 +/–
Да никто не отбирает заслуги С++. В свое время он отлично сослужил свою службу. Однако это не отменяет тот факт, что в текущем виде это язык для ИИ. Это уродливый и опасный монстр, над сложностью которого полностью утрачен контроль и колличество страниц в том же стандарте тому подтверждение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #50, #82

35. Сообщение от xsignal (ok), 10-Июл-26, 11:58	+5 +/–
Ну это сказки уже или плата за этот "прирост" - снижение надёжности на 300%
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #37

36. Сообщение от xsignal (ok), 10-Июл-26, 12:00	+/–
Тесты проходит, а то, что не покрыто тестами - фантазия нейросети и неопределённое поведение...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #43

37. Сообщение от нах. (?), 10-Июл-26, 12:01	–33 +/–
надежность постгреза и так всегда была околонулевой. Если оно проходит весь мильен регрешн тестов - оно скорее всего будет надежнее чем код написанный кожанновыми неумехами ниасилившими разобраться в собственном проекте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #212

38. Сообщение от нах. (?), 10-Июл-26, 12:04    Скрыто ботом-модератором	–1 +/–
тебе ж написали - нормальный он только в фантазиях импортозамещателей. Причем починить в нем уже ничего нельзя - никто не понимает в этом лапшекоде. Щас клава нам новый ла.. нормальный, хороший и документированный код нагенерит. (я вот только за хрустоси опасаюсь... сможет ли клава за ним все понаисправлять, или лучше все же было дать ей тесты и попросить написать с нуля?)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

39. Сообщение от aname (ok), 10-Июл-26, 12:04	+6 +/–
> И прирост производительности аналитических запросов в 300 раз. А ну да ладно, > мелочь, просто игрушки... И мне предлагается в это просто поверить
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #113

40. Сообщение от aname (ok), 10-Июл-26, 12:05	+15 +/–
> А нужно ли надрываться с топором, когда есть бензопила? Особенно когда у тебя уже есть готовые дрова.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

42. Сообщение от Vasyan (??), 10-Июл-26, 12:11	+/–
Claude Code по утекшим исходникам уже переписали на Rust какие-то кажется корейские чуваки. Потом еще всякое улучшили, включая добавление поддержки моделей других вендоров. Посмотрели, что никто его юзать не собирается, несмотря на все плюшки и забили на него.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #47, #56

43. Сообщение от нах. (?), 10-Июл-26, 12:15	+/–
а то что не покрыто тестами - фантазия кожановых тяпляперов с 95 года сменивших четыре поколения. Безусловно оно надежно и эффективно, как китайская стена!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #51, #58

44. Сообщение от Sm0ke85 (ok), 10-Июл-26, 12:15	+2 +/–
>pgrust - клон PostgreSQL на Rust, проходящий все регрессионные тесты Сразу написали, что в случае бага - это "тесты" виноваты... ахахаха))))
Ответить | Правка | Наверх | Cообщить модератору

45. Сообщение от нах. (?), 10-Июл-26, 12:16	–2 +/–
так-то ошибки в коде воркеров только данные в базе портили, это-то точно надежно и безопастно!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #140, #193

46. Сообщение от нах. (?), 10-Июл-26, 12:21	+/–
> IT гигантам это надо! Ставка на  человек + ИИ агенты уже > сделана, глупо это отрицать. дык им ЭТО вот конкретновое (в смысле - переписанный посгрез) нафиг не надо. Это кому-то из импортозамещателей понадобилось. Причем при этих масштабах - вылилось совсем не в бесплатную подписку, там хорошо если в меньше $10k уложились. Плюс труд кожанового раба, которого кормить подавай три раза...хотя бы в неделю, а то ж сдохнет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #59

47. Сообщение от нах. (?), 10-Июл-26, 12:22	–1 +/–
> Claude Code по утекшим исходникам уже переписали на Rust какие-то кажется корейские а где, кстати, скачать?! Мне очена надо вотъ!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #121

48. Сообщение от Имя (?), 10-Июл-26, 12:31	+10 +/–
Ждём дефолтом в ближайшей версии Ubuntu, успех с coreutils непременно нужно закрепить xD
Ответить | Правка | Наверх | Cообщить модератору

49. Сообщение от Аноним (50), 10-Июл-26, 12:44	+6 +/–
Соседняя новость: 73% проектов на Flathub, созданных с помощью AI, были заброшены спустя несколько месяцев
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #52, #77, #89

50. Сообщение от Аноним (50), 10-Июл-26, 12:46	+/–
при этом лучше всего ИИ пишет на пайтоне ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #135

51. Сообщение от Аноним (50), 10-Июл-26, 12:48	–1 +/–
тяпляпер так-то починить может и есть спросить с кого, с ИИ взятки гладки и поддерживать прожект сложнее привет, мир ИИ пока не очень чтоб...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #123

52. Сообщение от заголовок (?), 10-Июл-26, 12:55	+/–
"После запрета размещения в каталоге Flathub приложений, сгенерированных при помощи AI..."
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #93

53. Сообщение от freehck (ok), 10-Июл-26, 12:57	+/–
> один вон цельный core dev пыжился-пыжился, уже почти совсем готов был (снова!) избавить нас от формата нуждающегося в vacuum Да сомнительная изначально была затея. Вся разница в том, как оно ведёт себя в критической ситуации. Вот что приводит к блоатингу таблиц? Активные update-ы и delete-ы. И zheap должен, по идее, облегчать жизнь в этом случае... Но цена за это — кратное замедление этих запросов (а это очень критично, между прочим), плюс ещё сильное разрастание WAL-ов. Ну то есть овчинка выделки явно не стоит: лучше уж вакуум гонять.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #97

55. Сообщение от Аноним (55), 10-Июл-26, 13:06	+2 +/–
Возможен перехват клиентской базы, контрактов, грантов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #61

56. Сообщение от Филипп Филиппович (ok), 10-Июл-26, 13:08	+/–
Писать такое на расте или плюсах — безумие полное. Тайпскрипт, Питон и подобное. Проблемы с производительностью и ресурсами там на 99% в модели, а клиент (сравнительно с моделью, конечно) тонок. Так-то он тоже большой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #127

57. Сообщение от Colorado_House_of_Representatives (?), 10-Июл-26, 13:12	–3 +/–
> в убунте ржавый бизибокс Сразу видно человека, который абсолютно не разбирается в вопросе. 1. Не BusyBox. 2. Прохождение тестов не гарантирует аналогичный функционал. Это буквально каждый программист знает. 100% охвата тестов не бывает. В том числе из-за неопределённого поведения Си.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #96, #221

58. Сообщение от Смузихеб забывший пароль (?), 10-Июл-26, 13:17	+/–
нет теста - нет результата провала теста, доказывавшего бы ненадёжность. Пока всё сходится
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

59. Сообщение от Андрей (??), 10-Июл-26, 13:26	+/–
Что за бред с импортозамещением?! Харе на политику всё валить. PG-раст опубликован от имени Michael Malis malisper Freshpaint San Francisco, Ca https://malisper.me/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #118

60. Сообщение от Аноним (60), 10-Июл-26, 13:26	+/–
И прирост неподдерживаемости в 100500 раз.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #79

61. Сообщение от Аноним (60), 10-Июл-26, 13:30	+1 +/–
Это ж так типично: делают клон, а на оригинал санкции накладывают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55

62. Сообщение от Аноним (62), 10-Июл-26, 13:33	–2 +/–
Ты только заголовок прочитал? Кроме того, что тебе уже написали (про эксперименты по изменению архитектуры и избавление от вакуума) многим было бы интересно и такое: "При тестировании инструментарием percona-tpcc при обработке транзакций новая версия pgrust оказалась быстрее штатного PostgreSQL на 50%, а при обработке аналитических запросов - в 300 раз."
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #75, #78

65. Сообщение от Аноним (62), 10-Июл-26, 13:41	+2 +/–
Ога. В постгрю тысячи человеколет всунуто. Давай перепишем по-дедовски, ручками, с нуля, сохраняя текущий он-диск формат и (пока) основные механизмы работы. Перепишем в три рыла. Наверное быстро и просто получится. Курсовая на выходные? Растянутая на кучу лет для этих нескольких рыл. Зачем? Ручками пилить такого клона целесообразно разве что как хобби на всю оставшуюся жизнь, где важен процесс, а не результат.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #95, #161

68. Сообщение от fidoman (ok), 10-Июл-26, 13:51	+/–
На каждый тест просто отрастает ещё один if, никак покрытие тестами не улучшает архитектуру.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #116

69. Сообщение от Аноним (62), 10-Июл-26, 13:57	–1 +/–
А что, текущие разработчики оригинальной постгри выступили с заявлением о переписывании на раст? Постгрю у тебя никто и не забирает. Пользуйся на здоровье сишной. А кто-то в будущем (может быть) захочет пользоваться другой, растовской.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

70. Сообщение от Аноним (60), 10-Июл-26, 13:58	+4 +/–
Удачи тебе колоть дрова бензопилой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #94

73. Сообщение от Аноним (60), 10-Июл-26, 14:03    Скрыто ботом-модератором	–1 +/–
> не было бы Qt И наступила бы райская жизнь в мире с GTK.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

74. Сообщение от Аноним (60), 10-Июл-26, 14:04	+/–
И поддерживать это будет... кто?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #81

75. Сообщение от Аноним (60), 10-Июл-26, 14:06	+2 +/–
> При тестировании инструментарием percona-tpcc Можно написать тест, в котором AMD будет на 100% быстрее Intel. Но отразит ли это реальность?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #114

76. Сообщение от Аноним (77), 10-Июл-26, 14:08	+/–
Нейрослопный нейрослоп.
Ответить | Правка | Наверх | Cообщить модератору

77. Сообщение от Аноним (77), 10-Июл-26, 14:09	+1 +/–
Это просто людишки пытаются сделать так чтобы их не заменила ИИ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #153

78. Сообщение от Аноним (78), 10-Июл-26, 14:12	+2 +/–
про 300 раз написали, а про потребление ресурсов — нет, но там может быть не так интересно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #91

79. Сообщение от Аноним (79), 10-Июл-26, 14:22    Скрыто ботом-модератором	+/–
О, снова ты со своей мантрой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

80. Сообщение от Анлним (?), 10-Июл-26, 14:24	+/–
Опеннет только способствует ИИ хайпу, который спадет как только большинство людей поймут что такие проекты не поддерживаемы без существенных затрат, а затраты это не столько написание кода сколько его рецензия и планирование.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #228

81. Сообщение от Аноним (79), 10-Июл-26, 14:24	–5 +/–
Например авторы. Тем более у ЫЫ-шного кода качество всегда выше среднего. И в поддержке ЫЫ работает еще быстрее чем в разработке, ибо скоуп задачи сильно уже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #90

82. Сообщение от Аноним (82), 10-Июл-26, 14:25	+/–
Это если руки не из плеч. Если сложность пугает, всё ещё есть простая сишечка, на которой тем не менее создают довольно сложные и крупные системы, а по выразительности (кол-ву строк на заданную функциональность) она примерно на уровне раста, только закорючек меньше и под борова прогибаться не нужно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #222

84. Сообщение от Аноним (84), 10-Июл-26, 14:39	+/–
>По словам автора проекта, в настоящее время ведётся работа над следующей версией pgrust Внутри которой будет сразу крутиться модная-стильная нейронка без лишних прослоек.
Ответить | Правка | Наверх | Cообщить модератору

85. Сообщение от BlackV (?), 10-Июл-26, 14:57	–1 +/–
Забавно, но в целом бесполезно. Если команда разработчиков не будет больше команды PostgreSQL, то в лучшем случае они продолжать слегка пилить базу на уровне PostgreSQL 18.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #92

86. Сообщение от penetrator (?), 10-Июл-26, 15:06	+1 +/–
не верю в 50% прирост вообще и почему используется percona-tpcc а не oltp_read_write из стандатной поставки sysbench а еще пулинг под вопросом, у меня плагин для пулинга работал сильно медленне на хайлоде, чем стандартные соединения постгреса 17 короче опять надо тестировать и проверять на звиздеж, а на это нет времени
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #99, #124

87. Сообщение от Аноним (87), 10-Июл-26, 15:18	+/–
ага, проходящий "все тесты", но такой же калеч тормозной как, например, Pangolin
Ответить | Правка | Наверх | Cообщить модератору

88. Сообщение от n1kt0 (??), 10-Июл-26, 15:19	+/–
Уже спрашивали? А? Нет? Я спрошу. С 1С уже совместима? Если нет, то поделие не взлетит.
Ответить | Правка | Наверх | Cообщить модератору

89. Сообщение от n1kt0 (??), 10-Июл-26, 15:21	+2 +/–
Уже там же и ответили! Программы сразу получились идеальными, нечего переделывать или добавлять.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49

90. Сообщение от Аноним (60), 10-Июл-26, 15:22	–1 +/–
> у ЫЫ-шного кода качество всегда выше среднего Ну т.е. авторы применения ИИ уже не смогут его понять. Если бы они умели понимать такой код, они бы сами написали, но они не могут, потому использовали более умный, чем они сами, ИИ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81 Ответы: #157, #219

91. Сообщение от Аноним (60), 10-Июл-26, 15:24	+/–
Странно, что они не описали тест, что именно они отправляли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78 Ответы: #196

92. Сообщение от Аноним (60), 10-Июл-26, 15:30	+/–
> Если команда разработчиков не будет больше Легко: наберут индусов за миску риса.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85 Ответы: #137

93. Сообщение от Аноним (93), 10-Июл-26, 15:39	+/–
не совсем так — они просто заброшены, потому что не было цели их развивать. Попадание во флатхаб это не та ачивка, которая гарантирует жизнь проекту
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

94. Сообщение от Аноним (94), 10-Июл-26, 15:44	+2 +/–
Т.е ты не сможешь бензопилой распилить полено вдоль? Я знал что это инженерный форум деградировал, но не думал что настолько. Это печально.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70 Ответы: #100, #110, #187, #190

95. Сообщение от aname (ok), 10-Июл-26, 16:34	–1 +/–
> Ога. В постгрю тысячи человеколет всунуто. Давай перепишем по-дедовски, ручками, с нуля, > сохраняя текущий он-диск формат и (пока) основные механизмы работы. Перепишем в > три рыла. Наверное быстро и просто получится. Курсовая на выходные? Растянутая > на кучу лет для этих нескольких рыл. Зачем? Ручками пилить такого > клона целесообразно разве что как хобби на всю оставшуюся жизнь, где > важен процесс, а не результат. Меня, по- дедовски, устраивает оригинал. Я не переписываю ради переписывания ибо это же раст
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #111

96. Сообщение от aname (ok), 10-Июл-26, 16:35	+/–
>> в убунте ржавый бизибокс > Сразу видно человека, который абсолютно не разбирается в вопросе. > 1. Не BusyBox. > 2. Прохождение тестов не гарантирует аналогичный функционал. Это буквально каждый программист > знает. 100% охвата тестов не бывает. В том числе из-за неопределённого > поведения Си. Придётся добавить UB в раст
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #139

97. Сообщение от U202204161753 (?), 10-Июл-26, 16:40	+/–
Ясненько... ( Наверное...) Оk -- отложим и: В ORIOLE со всем этим как обстоят дела? Thank!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #104, #120

99. Сообщение от aname (ok), 10-Июл-26, 16:43	+/–
> не верю в 50% прирост вообще > и почему используется percona-tpcc а не oltp_read_write из стандатной поставки sysbench > а еще пулинг под вопросом, у меня плагин для пулинга работал сильно > медленне на хайлоде, чем стандартные соединения постгреса 17 > короче опять надо тестировать и проверять на звиздеж, а на это нет > времени Тесты берут либо те, которые под рукой, либо те, о которых знают, либо те, которые удобные. Время покажет, что за тесты были
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86

100. Сообщение от Ox (?), 10-Июл-26, 17:05	+2 +/–
*ля! Инженер, ты не теоретизируй, просто попробуй. Полено -- это уже конечный продукт, его пилить не нужно, пили чурбаки. О масштабировании не забудь, чурбаков 5 кубов -- штук 80. ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #160

102. Сообщение от Аноним (102), 10-Июл-26, 17:20	–1 +/–
Нельзя вот так вот просто взять и.... (с) А если серьезно, то западники явно продавливают раст системно, вероятно даже договорившись между собой. Я имею ввиду самые крупные компании. Вон и Линуса, видимо, _очень_ вежливо попросили раст в ядро запихать. В общем. Я думаю, что раст, ко глубокому сожалению, - это надолго, и в покое они приклады на сях не оставят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #217

104. Сообщение от freehck (ok), 10-Июл-26, 17:39	+/–
Да собственно именно так, как описано выше, дела и обстоят: у ораклов по сравнению с постгрой — дорогие update-ы и delete-ы. Именно потому, что undo-лог требует больше ресурсов вот прямо здесь и сейчас, а не потом, во время вакуума. Поэтому блоатинг таблиц у ораклов болит сразу же, а не через недельку, когда блоат накопится из-за того, что вакуум захлебнулся и не справился с задачей. Хорошо это или нет — вопрос весьма непростой, судить не берусь. Потому что вот с одной стороны постгрес получается шустрее, а оракл предсказуемее. Предсказуемость оракла способствует отлову косяков заранее, и позволяет спокойно спать по ночам. Но с другой стороны, если проблема таки пролезет и вскроется лишь на проде, то с постгрой у тебя ещё будет время повертеться и худо-бедно выжить, а что делать с ораклом — вот не знаю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97 Ответы: #225

106. Сообщение от Аноним (106), 10-Июл-26, 18:03	+/–
> AGPLv3 И что, кто-то в здравом уме переведет свою инфраструктуру на вот это?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #107, #125, #131, #232

107. Сообщение от Сладкая булочка (?), 10-Июл-26, 18:30	+/–
Кажется, что все эти проекты по переписыванию спонсируются создателями соответсвтующей модели. По факту реклама, бесмысленная и беспощадная.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106

108. Сообщение от Сладкая булочка (?), 10-Июл-26, 18:31	+/–
Скоро ИИ хайп пройдет. Цены поднимут. Энергоносители подорожают. Вот тогда вы запоете.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #136, #235

110. Сообщение от Аноним (110), 10-Июл-26, 18:38	+/–
Что быстрее, 2 - 3 раза тюкнуть топором или безопилой вдоль волокон?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #195

111. Сообщение от Самсонов (?), 10-Июл-26, 18:41	–1 +/–
А что ты скажешь, когда яжефинское ведро проржавеет насквозь?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95 Ответы: #138

112. Сообщение от Аноним (110), 10-Июл-26, 18:41	+1 +/–
Например, на D получидось бы. Даже ещё, возможно, с меньшим числом строчек кода.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

113. Сообщение от Аноним (113), 10-Июл-26, 19:06	–2 +/–
Нет, тебе предлагается взять открытый код, и убедиться самостоятельно. Если умеешь конечно. Если не умеешь, то можешь поныть на форуме.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #128, #147, #214

114. Сообщение от Аноним (113), 10-Июл-26, 19:12	+2 +/–
> Можно написать тест, в котором AMD будет на 100% быстрее Intel. Но отразит ли это реальность? Если ты реально напишешь такой тест, реально запустишь, и он реально покажет заявленное, то это и будет реальность данная тебе в ощущениях. А если только поговоришь на форуме, то не будет. Реальность упрямая штука, требует встать с дивана, пойти и сделать. Будет ли этот тест полезен чем-то ещё кроме доказательства что так можно сделать -- другой вопрос, но он не имеет отношения к реальности или нереальности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #165

115. Сообщение от Аноним (113), 10-Июл-26, 19:15	+/–
> Зачем «изобретать велосипед»? Затем же, зачем студентов в MIT заставляют писать операционные системы под окаменевшие процессорные архитектуры: чтобы чем-то научиться. Mens et manus. И никак иначе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #171

116. Сообщение от Аноним (113), 10-Июл-26, 19:17	+/–
Тесты и не должны улучшать архитектуру. Тесты должны её формально валидировать, в первую очередь в нетривиальных условиях. То, что 2+2=4 можно не проверять, если это не так, мир сломается задолго до запуска теста.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68

117. Сообщение от Аноним (117), 10-Июл-26, 19:18	+/–
Есть RED HAT, то бишь - Красная шапка, а теперь будет RUST POSTGRES, то бишь - Ржавый Postgres, скрипучий и пыльный.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #122

118. Сообщение от нах. (?), 10-Июл-26, 19:20	+/–
> Что за бред с импортозамещением?! Харе на политику всё валить. ну казалось наиболее вероятным поворотом. Учитывая кто и где на самом деле активно внедревывает постгрезы последние годы. > PG-раст опубликован от имени https://www.postgresql.org/community/contributors/ - и чо?! Все мы знаем, кто там на самом деле начальство. > Michael Malis malisper Фамилие - интересное. Ну ок, конечно жеж, совпадение. > Freshpaint какой-то одноклеточный стартап вроде бы по шпионажу за посетителями сайтов. Полагаю, с нулем покупателей кроме кого-то из родственников. (потому что изивини но все занято апдырявиксом и соревноваться с ним не получится, даже если о тебе вообще кто-то слышал. Что в данном случае нульвероятно.) Видимо, у его владельца дофига свободного времени и лишних денег чтобы заниматься переписыванием постгреза. (И бэкграунд интересный. DBA а не разработчик. Впрочем, может и не dba а свадебный генерал в чине лейтенанта.) Ну ок, все лучше чем постгрез.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

119. Сообщение от Аноним (117), 10-Июл-26, 19:22	+/–
Лучше бы механизм работы с файлами данных переработали на манер Oracle DB, без необходимости вакуума, этого плана мамонта из 80х того века. Но это, навряд ли, - кишка тонка у переписсчегов pgrust-ов
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #126

120. Сообщение от нах. (?), 10-Июл-26, 19:26	+/–
> Ясненько... ( Наверное...) Оk -- отложим и: > В ORIOLE со всем этим как обстоят дела? Thank! так мы тебе о чем? Никак они там не обстоят, пыжился-пыжылся автор улучшайкнуть постгрез, исключительно в рамках плагин-бэкэнда, а потом выдал реляцию "патчами тут не обойдется, тут все ядро переписать надо чтоб мой замечательный плагин мог нормально работать". И пошел переписывать. Назад не возвращался. Все та же "public beta" уже четвертый год к ряду. Не работает и не будет. (кстати, они там вроде клавой пользоваться начали. Правда успешного успеха все равно нет. Клава не умеет убивать людей.)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97

121. Сообщение от Аноним (113), 10-Июл-26, 19:32	+/–
Пользуйся pi.dev. Там не раст, зато поддержка чего угодно и полная свобода творчества. Очень рекомендую.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #134

122. Сообщение от Аноним (8), 10-Июл-26, 19:32	+/–
> Есть RED HAT, то бишь - Красная шапка, а теперь будет RUST > POSTGRES, то бишь - Ржавый Postgres, скрипучий и пыльный. rust не прилагательное, только существительное или глагол
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #117 Ответы: #151

123. Сообщение от нах. (?), 10-Июл-26, 19:33	–2 +/–
> тяпляпер так-то починить может Как там с vacuum full? Уже починили? С 2010го года чинют! Правда, после примерно 15го в каждой новой версии перестало появляться "теперь уже точно окончательно deprecated, нинунанининанинуна!" "— Починил!— радостно сказал мальчик." > и есть спросить с кого, с ИИ взятки ну вот поди и спроси с кого.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

124. Сообщение от Аноним (113), 10-Июл-26, 19:34	+/–
> а на это нет времени Зато есть время на опеннете покалякать. Агенту поручи, раз занятой такой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86 Ответы: #218

125. Сообщение от Аноним (125), 10-Июл-26, 19:35	+/–
А расскажи нам на чем твоя инфра работает и какая там лицензия =)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106

126. Сообщение от Аноним (113), 10-Июл-26, 19:35	+/–
Кишка тонка и у PostgreSQL core dev team, как оказалось. А там -- если ты не в курсе -- последний оплот настоящихъ™ сишниковъ™.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #119 Ответы: #132

127. Сообщение от нах. (?), 10-Июл-26, 19:36	+1 +/–
> Писать такое на расте или плюсах — безумие полное. то ли дело писать на то ли zig то ли bun от безумного автора, как оно сейчас? Причем пишет-то за них - модель, а ей в общем все равно. Баг с .git, кажется, до сих пор не исправлен и исправлять никто не собирается, да? В общем, давайте хрустоподелку, может она работает ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #183, #227

128. Сообщение от ааа (??), 10-Июл-26, 19:41	+5 +/–
Тот самый код, который даже "аффтары" не отсматривали? Ловко ты это придумал
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113

131. Сообщение от нах. (?), 10-Июл-26, 19:45	+/–
>> AGPLv3 > И что, кто-то в здравом уме переведет свою инфраструктуру на вот это? Что мешает этому... Малису заплатить деньгов и переводить свою инфраструктуру под коммерческой лицензией? postgrespro поди платишь?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106

132. Сообщение от нах. (?), 10-Июл-26, 19:46	+/–
> Кишка тонка и у PostgreSQL core dev team, как оказалось. всего у одного из. Остальные послали его подальше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #126

134. Сообщение от нах. (?), 10-Июл-26, 19:51	+/–
ну как-то стремно штуке которая не умеет даже в запрос на исполнение давать доступ даже к диску D: список "мы этого не будем делать но ты можешь напилить себе сам" как-то огорчает. И еще и node.js
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121

135. Сообщение от нах. (?), 10-Июл-26, 20:13	+/–
> при этом лучше всего ИИ пишет на пайтоне ;) у меня с пихоном, наоборот, худший опыт взаимодействия с ыы на текущий момент. (причем он был ровно по схеме пыгрусти - ыы попыталась соскочить, переложив рутину на автоконвертилку. автоконвертилка наконвертила дерьма. ыы долго и не очень убедительно чинило за ней. До сих пор не уверен что получилось хорошо.)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50

136. Сообщение от нах. (?), 10-Июл-26, 20:15	–1 +/–
> Скоро ИИ хайп пройдет. Цены поднимут. Энергоносители подорожают. Вот тогда вы запоете. даже если цены поднимут в десять раз - это по моему опыту все равно дешевле и качественнее кожановых поделок. (только не говорите это антропику!)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108 Ответы: #173

137. Сообщение от нах. (?), 10-Июл-26, 20:18	+1 +/–
>> Если команда разработчиков не будет больше легко. запустить агентов по числу разработчиков + еще пяток для надежности. И еще одного назначить CTO чтоб присматривал за ними. > Легко: наберут индусов за миску риса. останутся без риса с неработающим кодом, который никакой ыы не возьмется исправлять (думаешь, я не предлагал?)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92

138. Сообщение от aname (ok), 10-Июл-26, 20:19	+/–
> А что ты скажешь, когда яжефинское ведро проржавеет насквозь? Есть нормальные альтернативы
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111 Ответы: #152

139. Сообщение от _ (??), 10-Июл-26, 20:29	+/–
И! И _неотключаемый_ unsafe{}   :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96 Ответы: #148

140. Сообщение от ptr (ok), 10-Июл-26, 20:33	+/–
Речь тут, в первую очередь, о Python, Perl и т.п., которыми испортить данные в БД затруднительно, а вот обвалить весь процесс - без проблем. И одно дело, если это форкнутый процесс этого конкретного соединения, а совсем другое - когда это сам postmaster.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #142

141. Сообщение от ptr (ok), 10-Июл-26, 20:37	+1 +/–
> Перевод на многопоточную внутреннюю архитектуру. То есть они хотят, чтобы возникновение критической ошибки в интерпретаторах Python, Perl или еще какого-то процедурного языка приводила к падению всего сервера, а не только форкнутого процесса одного соединения, в котором эта ошибка возникла?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #158

142. Сообщение от нах. (?), 10-Июл-26, 20:41	+/–
> Речь тут, в первую очередь, о Python, Perl и т.п. речь о пуле рабочих процессов. Исполняемых в контексте субд на ее стороне. А не о васянских питонах и перлах которые к нему обращаются (а может и тру сишный кот). А если ты имел в виду что у тебя из-за багов при исполнении команд от клиента падает постмастер - так ведь он и какой-то код вместо этого может выполнить ведь. От юзера postgres, ага. Причем оно вот так у постгреза _регулярно_ и бывает. И как, помогли тебе твои форки? И да, у форкнутых процессов есть доступ и они напрямую работают с базой. Так что и повредить им ее ничто совершенно не мешает. Разница только в том что так будет падать еще и соединение у всех остальных. Ну, собственно, ora-0600 передает вам привет. Возможно это даже и к лучшему, потому что лучше бы после таких полетов перепроверить консистентность базы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140 Ответы: #145

143. Сообщение от нах. (?), 10-Июл-26, 20:43	–1 +/–
> нормальным языком с лаконичным синтаксисом. Ты точно уверен и не брешишь, > что C++ с первого дня (как ты сказал - изначально) не > был для людей? Скорее не был. Даже во времена любимого тобой "Си-с-классами" было очень много подводных камней и чудес на ровном месте. Ну может еще во времена cfront было не так, но тогда на нем не было написано примерно и ничего.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

145. Сообщение от ptr (ok), 10-Июл-26, 20:53	+/–
>> Речь тут, в первую очередь, о Python, Perl и т.п. > речь о пуле рабочих процессов. > Исполняемых в контексте субд на ее стороне. > А не о васянских питонах и перлах которые к нему обращаются К чему обращаются? Сейчас каждое соединение в PostgreSQL - отдельный процесс. В нём всё соединение и живет, за исключением обращений к дополнительным воркерам, которые тоже отдельные процессы. > А если ты имел в виду что у тебя из-за багов при > исполнении команд от клиента падает постмастер Как раз сейчас он в принципе упасть не может, так как живёт в отдельном процессе. А уж допустить ошибку в DO блоке любой пользователь может. Это неизбежно. > Причем оно вот так у постгреза _регулярно_ и бывает. У меня за те шесть лет, которые PostgreSQL в продуктивной эксплуатации, по причине ошибки допущенной в процедурном языке пользователем, postmaster не падал ни разу. И это уже на нескольких десятках кластеров. Из-за pg_variables - падал. Из-за pg_clickhouse - падал. Но от ошибки в коде Perl, Python или R - ни разу. Можете привести пример, как у Вас пользователи этого добились?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #142 Ответы: #156

146. Сообщение от Анонисссм (?), 10-Июл-26, 20:59	+/–
>нормальный PostgreSQL нормальный PostgreSQL то ли денег стоит, то ли не существует. ну, простите, я не могу в 2026м без HA. Если не мультимастер, то хотя бы auto-failover.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #159

147. Сообщение от aname (ok), 10-Июл-26, 21:02	–2 +/–
> Нет, тебе предлагается взять открытый код, и убедиться самостоятельно. Если умеешь конечно. > Если не умеешь, то можешь поныть на форуме. Что было утверждено без пруфов, может быть отброшено без обоснований. Или тащи пруфы, или не плачь
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113 Ответы: #172

148. Сообщение от aname (ok), 10-Июл-26, 21:03	–1 +/–
> И! И _неотключаемый_ unsafe{}   :) В ведре увидим
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139

149. Сообщение от Аноним (149), 10-Июл-26, 21:07	+2 +/–
Rust как самоцель. Печально.
Ответить | Правка | Наверх | Cообщить модератору

151. Сообщение от Аноним (151), 10-Июл-26, 21:20	+1 +/–
ПО-барабану. Пусть будет Rusty Postgres, хотя, и Rust Postgres в современном английском тоже проканает. Смысл это не меняет - Ржавый Постгрес, причем, во всех смыслах этого слова.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122

152. Сообщение от Аноним (152), 10-Июл-26, 21:58	+/–
> Есть нормальные альтернативы Огласите весь список. Ладно, не надо список. Что-нибудь одно для начала, чтобы просто перекатиться. На том же железе, плюс-минус с тем же софтом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138 Ответы: #191

153. Сообщение от нах. (?), 10-Июл-26, 22:15	+/–
> Это просто людишки пытаются сделать так чтобы их не заменила ИИ. жалкий кожановый хлам. В биореактор!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77

155. Сообщение от Витюшка (?), 10-Июл-26, 22:23	+1 +/–
Я так и представляю как все программисты PostgreSQL побегут с пермессивной лицензии на AGPLv3. Почти всех проекты под copyleft почти заглохли или находятся в полузаброшенном состоянии.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #168, #192, #231

156. Сообщение от нах. (?), 10-Июл-26, 22:26    Скрыто ботом-модератором	+/–
> К чему обращаются? Сейчас каждое соединение в PostgreSQL - отдельный процесс. С полным доступом к физической базе. И возможностью ее повредить если навернется в процессе. (ну или возможностью непринужденно запустить чужого кота) > Как раз сейчас он в принципе упасть не может, так как живёт в отдельном процессе. И, щастья-то нам с того? Ну вот только что остальные соединения не рвутся. Но и обработки катастрофической ошибки нет. ну тут будет падать всем инстансом. да и хрен с ним, в общем-то. Уже ж приехали. Но есть шанс что таки хруст поможет падать пореже. Когда-нибудь... лет еще через двадцать. > У меня за те шесть лет, которые PostgreSQL в продуктивной эксплуатации, по причине > ошибки допущенной в процедурном языке пользователем, postmaster не падал ни разу. постмастер не упал, а база - битая.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #145 Ответы: #177

157. Сообщение от нах. (?), 10-Июл-26, 22:35	+/–
как будто авторы сишечки смогли понять? Вон там у коллеги пихоновые скрипты роняют базу - и похрен. (подтверждаю, фигня вопрос ... э.. запрос.)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90

158. Сообщение от User (??), 10-Июл-26, 22:36	–2 +/–
Ээээ... да? И за одним сами эти интерпретаторы того-этого... закопать-с. Кому нужно legacy из 90х с охапкой бизнес-логики в БД писатой как попало и на чем попало - ну он пусть как нибудь там сам-сам-все-сам на технологиях из вот тех 90х...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141 Ответы: #178

159. Сообщение от нах. (?), 10-Июл-26, 22:39	–1 +/–
ну хрен знает, в 2k26 уже ж можно позволить себе хотя бы один надежный сервер в надежном месте куда не прилетает? а мультимастер - не существует. Ну точнее такой какой вообще может в принципе существовать - тебе не понравится. Оно так - у всех.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #146

160. Сообщение от нах. (?), 10-Июл-26, 22:41	+/–
> О масштабировании не забудь да что нам мешает запустить 80 суб-агентов-то?! Пусть пилят! (ну раз механизм для колки неосилен - как это по-русски я не знаю, а финское слово забыл)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100 Ответы: #175, #240

161. Сообщение от нах. (?), 10-Июл-26, 22:43	+/–
> Курсовая на выходные? э, але, какая нафиг курсовая? postgres - это кандидатская диссертация вообще-то! И не одна! Курсовые были в ingress, ну так та и не умела ничего еще.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65

162. Сообщение от нах. (?), 10-Июл-26, 22:49	+1 +/–
авторы прекрасно это знают (в отличие от бабуинов). Тем не менее это неплохой признак что в принципе-то код работоспособен. И что можно двигаться дальше. (ну и вообще-то они уже _нагрузочный_ тест гоняют, что тоже показатель)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

163. Сообщение от нах. (?), 10-Июл-26, 22:52	+/–
тебе ж показали - на сложных запросах заметно выше. архитектура пока не менялась, просто реализация.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #166

164. Сообщение от нах. (?), 10-Июл-26, 22:53	–1 +/–
ага, кожановые-то афтыри постгрезпры такого бы не допустили! oh, shi...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #188

165. Сообщение от Аноним (165), 10-Июл-26, 22:54	+1 +/–
Кстати, о цветочках. Делал как-то функцию. Работала небыстро, т.ч. решил попробовать задействовать SSE2. Сделал реализацию в лоб. Стало побыстрее, но на более мощном Intel-е коллеги работало раза в два медленнее, чем на моём уже не новом AMD. Удивился. Ради интереса заменил свою реализацию частного случая на полную версию алгоритма из OpenCV (там существенно больше операций). Так мало того, что скорость раза в два выросла на моём проце, так уже Intel стал обгонять AMD раза в 1.5-2. Посмотрел реализацию в OpenCV: там оптимизации на асме с раскладкой по конвейерам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114

166. Сообщение от Аноним (8), 10-Июл-26, 23:00	+/–
если выше, ищи, где мухлюют -- я ещё не видел кода на расте быстрее без мухлежа
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #163 Ответы: #167

167. Сообщение от нах. (?), 10-Июл-26, 23:05	+1 +/–
код на расте работает ровно с той же скоростью что и на сях - пока это один и тот же код. У данного проекта код - другой, потому что цель изначально и поставлена сделать другим. ну и я видел код на расте, который работает, там где у сишочников не получилось ничего кроме сегфолтов (зато очень быстрых). Да, опоздали на десять лет, пока от борова бегали и крейты без конца обновляли, но у сишочников-то ВООБЩЕ ничего не вышло. С двух попыток. И заметь - у тех ребят не было ыы, они своей башкой об клавиатуру долбили. Еще и периодически тратя время на ублажение больных гнусными копирайтами. Да, я над ними тут периодически смеюсь, но другого-то вообще нет. ruffle.rs если кто еще не догадался.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166 Ответы: #169

168. Сообщение от нах. (?), 10-Июл-26, 23:10	+/–
так _программисты_то нахрен теперь не нужны. А ан@л-итиков никто и не будет спрашивать. Что поставили, тем и будут пользоваться. agpl это защита от попыткок постгрезпры и прочих слямзить чужой тр...токен. Тебе никто не мешает дать деньгов автыр... э... менеджеру с характерной фамилией, и использовать под коммерческой лицензией.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #155

169. Сообщение от Аноним (8), 10-Июл-26, 23:20	–1 +/–
Предлагаешь писать на расте без рантайм проверок? Далеко ли такой код уедет? Ruffle мертворождённое, что-то большее, чем воспроизвести h263 видео, уже может? До нейронок это единственное, на что оно было способно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #167 Ответы: #170

170. Сообщение от нах. (?), 10-Июл-26, 23:37	–1 +/–
> Предлагаешь писать на расте без рантайм проверок? Далеко ли такой код уедет? туда же куда и сишочный. рантаймпроверка тебе что должна делать-то если вернула ошибку? Починить твой кривой код? panic() вместо sigsegv, и всех достижений. > Ruffle мертворождённое, что-то большее, чем воспроизвести h263 видео, уже может? и пять лет назад могло. Как раз с h263 научилось в последнюю очередь. А вот флэшовые элементы в древних сайтах - могло еще тогда. Для чего и было ограниченно нужно. с 263 увы, опоздали. но повторю - сишочники нешмагли. Совсем. С двух попыток. И торопиться им было не надо, они начинали еще при живой адобе. Ясен пень, дело не только в языке, но выбрать язык способный сразу в wasm для этой вот конкретной цели было не худшей идеей. Был бы у них тогда современный ии - может даже успели бы спасти то что еще можно было спасти.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #169

171. Сообщение от Аноним (171), 10-Июл-26, 23:54	+/–
Не стоит связываться с выгоревшим. У нас отличный пример "Можно, а зачем?" уже в историю вошел.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115

172. Сообщение от Аноним (172), 11-Июл-26, 00:21	+/–
>>> И мне предлагается в это просто поверить >> Нет, тебе предлагается взять открытый код, и убедиться самостоятельно. Если умеешь конечно. > Что было утверждено без пруфов, может быть отброшено без обоснований. > тащи пруфы Чел, ты спросил, стоит ли тебе в это "просто поверить". Тебе ответили, что нет, не верь, а убедись самостоятельно. Ведь любые пруфы, в которые сделал не ты, тебе придется "просто поверить". В чем твоя проблема?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #147 Ответы: #223

173. Сообщение от Сладкая булочка (?), 11-Июл-26, 01:41	+/–
>> Скоро ИИ хайп пройдет. Цены поднимут. Энергоносители подорожают. Вот тогда вы запоете. >  даже если цены поднимут в десять раз - это по моему > опыту все равно дешевле и качественнее кожановых поделок. твой опыт работы в такси никому не интересен
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #136 Ответы: #180

175. Сообщение от Ox (?), 11-Июл-26, 04:07	+/–
>> О масштабировании не забудь > да что нам мешает запустить 80 суб-агентов-то?! > Пусть пилят! > (ну раз механизм для колки неосилен - как это по-русски я не > знаю, а финское слово забыл) Да-да, а потом как и в реальном мире выяснится, что пилят они медленно, отходов до жопы, а еще их и кормить нужно! Ну а когда ваша "цивилизация" таки внедрит топор или колун и окажется, что всего один агент справляется со всем объёмом, остальных сократят. ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160 Ответы: #220

176. Сообщение от Аноним (-), 11-Июл-26, 06:52	+/–
> Ты точно уверен и не брешишь, что C++ с первого дня (как ты сказал - изначально) не был для людей? Я не то что уверен, я знаю это. > C++ появился в 1985 и до примерно C++[11] или чуть позже был вполне себе нормальным языком с лаконичным синтаксисом. Да ладно, ври да не завирайся. В C++ зачем-то есть два способа перегружать операторы, и это по-твоему "лаконичный синтаксис"? Перегрузка функций: зачем она нужна вообще? Синтаксичкий хлам, который только осложняет чтение кода. У меня есть гипотеза, почему так, Страуструп хотел перегружать операторы как методы классов, но поскольку это не работало для не классов, он добавил перегрузку функций, чтобы можно было бы так же перегружать операторы для типов, которые не классы. А как насчёт наследия C, с этой спиралью правила парсинга деклараций? Или C'шного for'а, который для итерации от 0 до N требует трёх (трёх Карл!) выражений для организации этого цикла. C++ исходно был крайне непродуманным языков, Страуструп напихал в него всего, что тогда было на хайпе, типа ООП, но вот вылизывать язык до ортогональности фичей ему было влом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

177. Сообщение от ptr (ok), 11-Июл-26, 08:52	+/–
>> К чему обращаются? Сейчас каждое соединение в PostgreSQL - отдельный процесс. > С полным доступом к физической базе. Что есть всегда и в любой СУБД, вне зависимости от того, многопоточная архитектура у этой БД или многопроцессная. И такие проблемы решаются совсем иными путями. Например, ошибочно изменить страницу БД в shared buffers так, чтобы у неё контрольная сумма совпала - уже на грани фантастики. >> Как раз сейчас он в принципе упасть не может, так как живёт в отдельном процессе. > И, щастья-то нам с того? Счастье в том, что система остаётся доступной. Про SLA ничего не слышали? > Причем оно вот так у постгреза _регулярно_ и бывает. Где пример кода на процедурном языке, который укладывает postmaster?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #156 Ответы: #179

178. Сообщение от ptr (ok), 11-Июл-26, 09:03	+/–
> legacy из 90х Например, поддержка вызова интерпретаторов Python и R появилась только в MS SQL 2016. Я так понял, Вы и plpgsql предлагаете убрать? )))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #158 Ответы: #204

179. Сообщение от нах. (?), 11-Июл-26, 09:17	+/–
> Что есть всегда и в любой СУБД, вне зависимости от того, многопоточная архитектура у этой > БД или многопроцессная. но некоторые не падают от просто "ой, в DO ошибочка". Ну или хотя бы - пореже. (занимаем места в партере и открываем попкорн - ща ща руст спасет мир... или хотя бы пару девяток) > Например, ошибочно изменить страницу БД в shared buffers так, чтобы у неё контрольная > сумма совпала - уже на грани фантастики. фиговый ты какой-то стратег! Сперва испорти страницу, потом пересчитай сумму, не надо падать прямсразу - нам еще ее записать на диск надо! Откуда ж по твоему еще берутся невосстановимо побитые постгрезовые базы?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #177 Ответы: #181

180. Сообщение от нах. (?), 11-Июл-26, 09:27	–1 +/–
он ТЕБЕ станет интересен, когда очередному, хм, такси, ты не сможешь продаться. Потому что у него и так всеработает, софтасрое - агентами. А ты даже пользоваться не научился, потому что копротивлялся изо всех сил вместо того что должен делать нормальный инженер - разбираться с новой технологией.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #173 Ответы: #197, #198

181. Сообщение от ptr (ok), 11-Июл-26, 09:37	+/–
> но некоторые не падают от просто "ой, в DO ошибочка". Ну или > хотя бы - пореже. Пореже? Я же написал - за шесть леть эксплуатации десятков кластеров - не разу. При этом ошибки в запросах к БД от аналитиков я вижу сотни за день. Строго говоря - тысячи, но мы сейчас говорим только о PostgreSQL, а не pg_clickhouse. >> Например, ошибочно изменить страницу БД в shared buffers так, чтобы у неё контрольная >> сумма совпала - уже на грани фантастики. > фиговый ты какой-то стратег! Сперва испорти страницу, потом пересчитай сумму, не надо > падать прямсразу - нам еще ее записать на диск надо! Ну вот жду ещё один пример кода на процедурном языке от Вас из Вашей практики, портящий по ошибке  страницу в shared buffer, но при этом так, чтобы контрольная сумма совпала. > Откуда ж по твоему еще берутся невосстановимо побитые постгрезовые базы? Обычно, из-за ошибок в коде расширений и функций, у которых возможностей попортить БД несравнимо больше, чем у интерпретируемого процедурного языка. Третий раз, где пример кода на процедурном языке, который укладывает postmaster? Если в следующем же Вашем ответе не увижу оба примера, то мне (и не только мне) остаётся только считать Вас треплом и игнорировать. Это осознаёте?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #179 Ответы: #182

182. Сообщение от нах. (?), 11-Июл-26, 09:50	+/–
> Пореже? Я же написал - за шесть леть эксплуатации десятков кластеров - не разу. по-моему кому-то просто везло. ошибки в запросах - это ошибки в запросах, вернули тебе сообщение об ошибке. А вот такая ошибка чтоб sigsegv в самом постгрезе - дорогого стоит. К счастью, я это видел только в те времена, когда постгрез себе ставили те кому орацла поддерживать (я даже не про купить) не по зубам. (с тех пор я просто на таких не работаю) > Обычно, из-за ошибок в коде расширений и функций васянские расширения - это что-то прям из уникальных ноухау местных подвалов, функции в виде бинарников тоже. Те крэши что я видел - ничего подобного не содержали, и валились от обычных запросов. Ну чуть посложнее select * from table Причем куда более примитивных чем то что роняет оракла. Показать, извини, не могу - даже если бы у меня еще оставались доступы к тем подвальным, светить их бизнес-логику немного некомильфо. Но там ничего особенного и не было, запрос и запрос.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #181 Ответы: #185

183. Сообщение от Vasyan (??), 11-Июл-26, 09:51	+/–
https://github.com/ultraworkers/claw-code
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #127

185. Сообщение от ptr (ok), 11-Июл-26, 10:14	+/–
>> остаётся только считать Вас треплом и игнорировать Ваш выбор )))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #182

187. Сообщение от Аноним (187), 11-Июл-26, 11:52    Скрыто ботом-модератором	+/–
>Т.е ты не сможешь бензопилой распилить полено вдоль? Можно. Как и любым другим способом, хоть кухонным ножом можно распилить полено пополам при должном усердии. Вот только это все будет дороже и дольше, чем хряснуть колуном. О том и речь. Нужно инструмент подпирать под задачу и использовать его для решения задачи, а не *дрючить на инструмент, показывая всем как ты чудесато пилишь чурбаки вдоль. На деревне засмеют. Вся суть нейрофантиков
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94

188. Сообщение от Аноним (187), 11-Июл-26, 11:56    Скрыто ботом-модератором	+/–
Кожанного хоть натянуть можно, а тут соатнется только натягивать себя
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #164 Ответы: #189

189. Сообщение от нах. (?), 11-Июл-26, 13:23	–1 +/–
"э... а если они нас?!" выйдут к тебе на code review "тридцать витязей младых, тридцать юных....ГОЛУБЫХ! (В узких кожанных трусах, плотно облежащих пах.)" не, я лучше с fable пока посижу. Еще пол-дня невозбранно можно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #188

190. Сообщение от xPhoenix (ok), 11-Июл-26, 13:25	+1 +/–
> OpenNET > инженерный Сколько лет тут сижу, но шутки лучше не видел.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #194

191. Сообщение от МИСАКА (?), 11-Июл-26, 13:27	+/–
NT
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #152 Ответы: #242

192. Сообщение от ptr (ok), 11-Июл-26, 13:29	–1 +/–
> Я так и представляю как все программисты PostgreSQL побегут с пермессивной лицензии > на AGPLv3. Почти всех проекты под copyleft почти заглохли или находятся > в полузаброшенном состоянии. Следует отметить, что большое количество форков PostgreSQL, даже с проприетарными лицензиями, оказывается в итоге источником патчей в mainstream. Чего ну никак не скажешь, например, про GPL MySQL, фактически контролируемый Oracle. Сравните https://github.com/postgres/postgres/activity и https://github.com/mysql/mysql-server/activity Для того, чтобы понять, что из пермессивных, AGPL, GPL и даже проприетарных лицензий нет "лучшей" или "худшей", а есть наиболее подходящие разработчикам конкретного программного продукта на текущем уровне его развития, достаточно избавиться от юношеского максимализма. Впрочем, это относится почти ко всем дискуссиям "что лучше", без привязки к конкретной задаче.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #155

193. Сообщение от freehck (ok), 11-Июл-26, 13:42	+/–
> так-то ошибки в коде воркеров только данные в базе портили, это-то точно надежно и безопастно! От этого спасает ACID: подавляющее большинство критических ошибок, приводящих к крашу сервиса, случаются во время выполнения операции, когда транзакция ещё не закоммичена. Когда такие ошибки случаются, транзакция откатывается полностью, и поэтому данные остаются не повреждены. Вы, товарищ нах, подменяете тему разговора: Вы пишете про защиту данных, в то время как я писал про защиту собственно самого сервера. Многопроцессная модель постгреса может и имеет накладные расходы на создание и поддержку пула процессов, однако она обеспечивает лучшую отказоустойчивость по сравнению с многопоточной моделью.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #199

194. Сообщение от нах. (?), 11-Июл-26, 13:47	+/–
>> OpenNET >> инженерный > Сколько лет тут сижу, но шутки лучше не видел. недавно, видимо, сидишь. До примерно 16го года был таки инженерный. Отдельные инженеры, с которыми было о чем поговорить, продержались до 22го. Там случилось что-то и на русскоязычных сайтах вообще инженеров резко поубавилось.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #190

195. Сообщение от нах. (?), 11-Июл-26, 13:48	+/–
> Что быстрее, 2 - 3 раза тюкнуть топором или безопилой вдоль волокон? тебе быстрее или дрова нужны? Вот есть раб, у него есть бензопила. Мне чего - идти в лабаз за топором, оставив раба без присмотра, или все же - бери пилу, иди пили!? Не нравится ему вдоль - пусть поперек пилит, блинами топить будем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #110

196. Сообщение от нах. (?), 11-Июл-26, 13:50	+/–
> Странно, что они не описали тест, что именно они отправляли. они написали - percona-tpcc google for that. Ну или попроси ЫЫ разжевать тебе, что там отправляется.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91

197. Сообщение от Сладкая булочка (?), 11-Июл-26, 13:52	+/–
> он ТЕБЕ станет интересен, когда очередному, хм, такси, ты не сможешь продаться. > что должен делать нормальный инженер - разбираться с новой технологией. Нормальный инженер сразу поймет, что технология завязанная на дядю, ни разу не нормальная. Апроприетарился, внедрил троянского коня и сидит напыщенный.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #180 Ответы: #201

198. Сообщение от Сладкая булочка (?), 11-Июл-26, 13:53	+/–
> он ТЕБЕ станет интересен, когда очередному, хм, такси, ты не сможешь продаться. > Потому что у него и так всеработает, софтасрое - агентами. Ну... удачи) А за меня ты не переживай.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #180

199. Сообщение от нах. (?), 11-Июл-26, 13:58	+/–
> От этого спасает ACID: нет, конечно. acid это про логику, а не про реализацию. Предполагается что реализация - безупречна. А не запишет тебе пару килобайт мусора по рандомному адресу. Разумеется, пометив транзакцию как - завершенную. (а чотакова, она ж завершилась до того как еще и sigsegv прилетел) Повторяю - в отличие от нашего местного гения с аж шестью суперкластерами - я такой результат видел вживую. Поскольку ыы у нас тогда не было - мы даже не смогли точно найти КАК оно такое делает. Но "неупавший постмастер", как ты догадываешься, нам не очень пригодился в те разы. (с орацлом, кстати, получше вышло. ну или повезло) Никак у нас сервер не защищается тем что мы вместо спавна используем треды или наоборот. Если б там была какая-то супериерархическая мультивровневая модель, когда процессы не лезут напрямую в базу а через какой-то (допустим-постмастер) присылают команды на изменения - но постмастер как бы самим названием намекает что он немного для другого. Там просто accept loop.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #193 Ответы: #205

201. Сообщение от нах. (?), 11-Июл-26, 14:20	–1 +/–
вот тебе результат деятельности "нормальных инженеров": https://github.com/lizardfs/lizardfs/issues/746 (заметь - через четыре года (sic!) заинтересованные лица (не имевшие никакого отношения к "нормальным инженерам" все это нагадившим) даже дотрейсились до того-самого-комита который все и испортил - но не шмагли понять ни о чем и зачем комит, ни как починить - глядя в код увидели фигу) По результатам: "main developers stopped commiting for 4 years", компания - де-факто банкрот (ну как обычно - признавать не хотелось, трижды перепродана, кожановые уволены на второй итерации, причем на первой был эпик фейл с наймом обратно того-самого-гения-который-десять-лет-назад... кстати обгадился он десять лет назад. Но не фатально, можно было исправить. Но он нешмог. Старый наверно стал.) после трех попыток как-то обойти проблемы и трех почти-уже-но-немного-не рабочих пре-пре-релизов, кожановые витязи младые частично скрылись в нетях, частично переехали внезапно в Ригу и продолжают пакостить в коде уже от имени новой конторы и под якобы-другим проектом. (нет, они не исправили баг, и не нашли его, зато совместимость сломали) Тинькову-потанькову купившему за миллион это уг - передаем пламенный привет. Сегодня, поскольку работать в шабат нельзя, а токены протухают и завтра доступ отключат, я отправил фаблю исследовать вопрос (шабесгоям работать не возбраняется, совершенно). "технология завязанная на дядю" через пятнадцать минут (ско... кодобаза не такая все ж маленькая) принесла мне a) объяснение зачем вообще всю эту хрень затевали (таки да, место проклято, нешмагли в ec с первой попытки правильно - и заметь ты ХРЕН это узнаешь пристальным вглядыванием в репо - если и было документировано, осталось в закрытой копропротивной репе или трекере) b) где на самом деле проблема и почему возникла (вопрос пары строчек кода, где дятлы совершили совершенно детскую ошибку) Может лучше было все же попросить на 20 баксофф помощи у дяди, а не обанкротиться, а?!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #197 Ответы: #210

204. Сообщение от User (??), 11-Июл-26, 14:47	+/–
Ээээ... а что, они тоже перешли на новую-инновационную технологию "1 соединение == 1 процесс"? Или просто технологию интеграции не нарушали - ну там "изолента должна быть синего цвета", "мотать строго по часовой стрелке" и вот это вот всё? Вот от plpgsql которая trusted я проблем не то, чтобы "не видел", а и "не слышал" даже. А от pl\python таки да, своими глазами. Впрочем, хвала аллаху, милостивому и милосердному - последние лет 5 единственная проблема от них - требование ИБ "отключить возможность выполнения..."
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #178 Ответы: #207

205. Сообщение от freehck (ok), 11-Июл-26, 14:48	+/–
>> От этого спасает ACID: > нет, конечно. Да, конечно. Весь твой опус сводится к "а что, если портящий память баг случится после COMMIT". Но это весьма небольшой кусок кода в самом конце, отлаженный годами, и который стараются лишний раз не трогать. Вероятность поломки именно в нём — ничтожна, и уж точно и несоизмерима с гарантированным падением всего экземпляра при любой ошибке памяти в потоке. Возможно, когда-то на заре эпохи твой серверный софт был ещё слишком сырым, или может быть ты был неопытным — и ты видел что-то, что могло выглядеть как "ошибка кода субд испортила данные". Но сейчас этот код уже сто лет в обед отлажен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #199 Ответы: #208

207. Сообщение от ptr (ok), 11-Июл-26, 17:18	+/–
> Ээээ... а что, они тоже перешли на новую-инновационную технологию "1 соединение == > 1 процесс"? А какие ещё варианты? Создают процессы через сервис Launchpad. Вот только если в PostgreSQL процесс создается один при инициации соединения даже без пулинга, то в MS SQL создаётся процесс на каждый вызов sp_execute_external_script. Альтернатива - CLR, которым как раз вполне можно уронить весь сервер. > Вот от plpgsql которая trusted я проблем не то, чтобы "не видел", > а и "не слышал" даже. Ну так на то он и trusted. > А от pl\python таки да, своими > глазами. Впрочем, хвала аллаху, милостивому и милосердному - последние лет 5 > единственная проблема от них - требование ИБ "отключить возможность выполнения..." У нас удовлетворились ограничением untrusted процедурных языков средствами SELinux. То есть, на уровне файловой системы он ограничен. А вот на уровне памяти процесса - увы. Обучать же модели на отдельном сервере или, тем более, на локале, при наших объёмах (такие БД 5-8 ТБ размером) - тоже не вариант. Как бы понятно, что пересылка память-память на порядки быстрее, чем по сети. Радует ещё, что у нас plr, а не plpython. Там возможностей навернуть свой процесс заметно меньше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #204

208. Сообщение от нах. (?), 11-Июл-26, 18:19	+/–
> Весь твой опус сводится к "а что, если портящий память баг случится после COMMIT". нет. Ты зачем-то удалил из цитаты ключевую строчку - это работало бы при идеальном коде. У нас в этом коде прямой доступ к файлам базы, а не sql с acid'ами. Можно просто записать мусор в базу в любой произвольный момент. До комита, после комита, вместо комита. При уже поврежденном стеке это легко и просто. > Вероятность поломки именно в нём — ничтожна тем не менее битые и невосстанавливающиеся постгрезы откуда-то берутся, и пипл ноет что кластер хреновый а pg_dump_all бесполезный. Постгрез никогда и не был надежным кодом. А учитывая его размер и попытки догнать и перегнать с пустым ведром - я предпочту не поверить что вдруг стал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #205 Ответы: #213

210. Сообщение от Аноним (210), 11-Июл-26, 19:50	+/–
Нашли бы те две строчки, если бы искали. А так скорее всего были проблемки, и было не до тех двух строчек.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #201 Ответы: #211

211. Сообщение от нах. (?), 11-Июл-26, 20:55	+/–
> Нашли бы те две строчки, если бы искали. ну конечно же не искали, их целью было обанкротить лавку и лишиться работы. > А так скорее всего были проблемки, и было не до тех двух строчек. когда у тебя "новая улучшенная версия" твоей поделки просто удаляет именно те данные которые должны были храниться максимально надежно - у твоей подвальной лавки начинаются ПРОБЛЕМКИ. Учитывая степень подвальности - они уже сразу могли стать фатальными. Потому что это не тот случай когда быстроподнятое считается неупавшим, о чем в том issue тоже ткнуто носом. Но те таки пробарахтались еще три года, каждый раз выкатывая новый неработающий пре-препре релиз. И каждый раз их восхищенные пользователи тыкали носом в незакрытый фатальный баг, и получали в ответ - "ищутЪ!" (там была еще парочка тоже феноменальных, но хотя бы не автоудаление всех данных вообще, просто падал сервер в теплично-воспроизводимой ситуации, например) Безусловно "нашли бы". "Просто не искали." И те у кого данные удалились - тоже не искали. Вообще никто ничего не искал, нахрен не надо, этих данных - полный интернет, новые накачаем. Ну и, кстати, а какая мне-то разница - не искали потому что намеренные вредители или потому что некомпетентные лузеры заблудившиеся в собст..(вряд ли, все же - скорее уволился кто-то) коде? Хрен я теперь таким денег дам за их натуральный-органик-продакт-без-всякого-ыы. (и с ыы не дам, у меня тоже ж есть ыы) И патчей не дам. Сами пусть прдлятся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #210

212. Сообщение от AnonNumxx (?), 11-Июл-26, 21:00	+/–
О, ты еще и в БД толк знаешь. Ну расскажи уже, че там вместо постгреса нужно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #241

213. Сообщение от freehck (ok), 11-Июл-26, 21:02	+/–
> Постгрез никогда и не был надежным кодом. А учитывая его размер и попытки догнать и перегнать с пустым ведром - я предпочту не поверить что вдруг стал. А, то есть весь этот тред на самом деле был только для того, чтобы написать "постгрес гoвнo"? Да ну тебя, нах. =) Ну не любишь ты постгрес, ну хочешь помуштровать его. Ну зачем выдумывать ерунду всякую, будто постгрес реально не за что поругать. Время моё ещё вон потратил. Тфу ты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #208 Ответы: #215

214. Сообщение от Аноним (214), 11-Июл-26, 21:20	+/–
> открытый код, и убедиться самостоятельно > открытый код уровень экспертизы от ананимусов
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113

215. Сообщение от нах. (?), 11-Июл-26, 21:26	+/–
> А, то есть весь этот тред на самом деле был только для того, чтобы написать "постгрес > гoвнo"? наоборот, я полагал это общеизвестным постулатом, недостойным отдельного упоминания. > Ну не любишь ты постгрес э... я вообще никакой современный (да и не очень - тоже) софт, мягко говоря, не люблю. Но вот невосстановимо грохающиеся (причем не по одному разу раз в сто лет) базы на исправном железе я видал только от постгри. С ораклом приключения были, но закончились в мою пользу. (к тому же там вероятно виноват сбой железа) При том что лишних знаний о нем у меня был минимум (и в процессе обрести не понадобилось, обошлось достаточно тривиальными ходами, в отличие от). mssql мне почти не попадался, а тот что попался как-то самопочинился почти без ручных приседаний. А, mysql еще был, тоже фатально. Но там тоже внешние причины. Но тоже не вызвало приступов любви и обожания к тем кто так надизайнил.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #213

216. Сообщение от Аноним (217), 11-Июл-26, 22:51    Скрыто ботом-модератором	–1 +/–
> проведение экспериментов по изменению внутреннего устройства и созданию версии PostgreSQL, избавленной от архитектурных ограничений Логичный вопрос: тогда какой был смысл ПЕРЕписывать сам Постгрес?! :))) Взяли бы и начали новый проект! Или растаманы НЕ УМЕЮТ в архитектуру и только способны набегать на ЧУЖИЕ проекты и конвертить сорсы??
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #234

217. Сообщение от Аноним (217), 11-Июл-26, 22:58	–1 +/–
Не переживай. Раст - как и "штаны с мотнёй" - мелькают ТОЛЬКО пока кто-то тупой и настырный башляет их продвижение. Адекватные прогеры СРАЗУ же отгородились от этого нелепого язычка. Неадекваты помыкаются и тоже недолго будут его юзать. Так что просто ждём, когда гуглу надоест пихать это дерьмо и все про него забудут как про Windows Millenial :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102 Ответы: #226

218. Сообщение от penetrator (?), 12-Июл-26, 01:24	+/–
>> а на это нет времени > Зато есть время на опеннете покалякать. Агенту поручи, раз занятой такой. куенту, сразу видно человека, не видевшего R&D в глаза, зато совет ты свой не забыл )))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124

219. Сообщение от Прохожий (??), 12-Июл-26, 09:52	+1 +/–
У вас очевидные проблемы с логикой и/или знанием предметной области. >Ну т.е. авторы применения ИИ уже не смогут его понять. Из чего это следует? >Если бы они умели понимать такой код, они бы сами написали По времени это заняло бы намного больше времени. Человек не может с такой же скоростью писать код, как LLM.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90

220. Сообщение от Прохожий (??), 12-Июл-26, 10:03	+/–
В реальном мире выясняется, что пилят они на несколько порядков быстрее, качество вполне на уровне, если тесты есть. И едят гораздо меньше, чем мешки. Вот, к примеру https://bun.com/blog/bun-in-rust
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #175

221. Сообщение от svpcom (ok), 12-Июл-26, 10:03	+/–
Вместо тысячи слов вот вам пример: ----- $ QEMU_CPU=max docker run -it --platform armhf  arm32v7/ubuntu:26.04 root@3a736c2369ad:/# set -eux     mkdir -p /tmp/x/d     echo x >/tmp/x/d/a     chmod --version | head -n 1     chmod -Rv u+rw,go=rX /tmp/x/d + mkdir -p /tmp/x/d + echo x + head -n 1 + chmod --version chmod (uutils coreutils) 0.8.0 + chmod -Rv u+rw,go=rX /tmp/x/d mode of '/tmp/x/d' retained as 0755 (rwxr-xr-x) chmod: Value too large for defined data type ---- просто 32rust'ы не умеют в понимание системных вызовов в ядре...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57

222. Сообщение от Прохожий (??), 12-Июл-26, 10:36	+/–
>всё ещё есть простая сишечка, на которой тем не менее создают довольно сложные и крупные системы ... где потом десятки лет продолжают находить критические уязвимости >а по выразительности (кол-ву строк на заданную функциональность) она примерно на уровне раста, Да неужели? Покажите, как банальный хеш написать на Си. Или как с Юникодом совладать. Ой, не шмогла, надо сначала свой велосипед переизобрести. >только закорючек меньше и под борова прогибаться не нужно Закорючек столько же, таблица спецсимволов практически один в один. А то, что под борова прогибаться не нужно - это недостаток огромный, что и демонстрирует наглядно нескончаемый поток CVE
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82

223. Сообщение от Прохожий (??), 12-Июл-26, 10:39	+2 +/–
>В чем твоя проблема? Очевидно же. Проблема в логическом мышлении, точнее, в полном его отсутствии.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #172

224. Сообщение от Прохожий (??), 12-Июл-26, 10:42	+1 +/–
Ты размер кодовой базы смотрел? Очевидно, что в разумные сроки это сделать невозможно. И, что сказать-то хотел?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

225. Сообщение от Прохожий (??), 12-Июл-26, 11:12	+/–
>а что делать с ораклом — вот не знаю Размещать undo на отдельном дисковом массиве, например, увеличивать размеры  буферов памяти и т. д. Обычно (не всегда) в нормальных системах апдейтов и делитов гораздо меньше, чем операций чтения. Там, где их гораздо больше, заранее планируют соответствующую архитектуру. Оракл везде справляется, иначе бы не был самой популярной коммерческой СУБД (при этом и самой дорогой).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104 Ответы: #229

226. Сообщение от Прохожий (??), 12-Июл-26, 11:20	+/–
>Адекватные прогеры Это те, которые ничего в своей жизни, кроме Си не видели? 🤣
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #217

227. Сообщение от Прохожий (??), 12-Июл-26, 11:24	+/–
bun уже на Rust переписали https://bun.com/blog/bun-in-rust
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #127 Ответы: #233

228. Сообщение от Прохожий (??), 12-Июл-26, 11:28	+/–
Вот здесь люди переписали примерно 500 тыс. строк кода за 11 дней, пофиксив параллельно несколько сотен багов https://bun.com/blog/bun-in-rust Бюджет - 165000 долларов. У нескольких людей бы это заняло год и стОило бы существенно дороже в итоге.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80

229. Сообщение от freehck (ok), 12-Июл-26, 12:17	+/–
> Размещать undo на отдельном дисковом массиве, например, увеличивать размеры  буферов памяти и т. д. Ну и на постгресе примерно то же самое делается. Тоже тюним размеры буферов, количество обработчиков, количество воркеров вакуума... > Обычно (не всегда) в нормальных системах апдейтов и делитов гораздо меньше, чем операций чтения. Да кто ж спорит, что их меньше. Важней то, как долго они блокируют операции чтения, пока выполняются. Вот самый частый сценарий, который у меня выстреливал, выглядел примерно так, если обобщённо: - регулярный update дёргется раз в секунду/несколько - таблица, на которой он дёргается, имеет дохреналион FK-связей - ORM-ка и разработчики знали про FOR UPDATE, но ничего не знали про FOR NO KEY UPDATE - итого имеем множество локов, не очень быстрый update, и следовательно периодические тормоза И как ты понимаешь, скорость выполнения update-запросов в данном случае очень критична. Я, безусловно, прекрасно понимаю, что этот сценарий — это плохая архитектура. Но она встречается на удивление часто. Я бы может и рад был бы не допускать подобного, однако я как девопс не могу контролировать вообще всё. Я занимаюсь CI/CD, SRE, безопасностью... Я частенько блокирую релиз, когда разработка притаскивает откровенную фигню вида "а давайте отдавать статику через js" / "а давайте завяжемся на внешний ресурс"... Но вот архитектура запросов в базу — это всё-таки должны прорабатывать CTO / техлиды / DBA (который, кстати, не везде есть, ибо стоит дофига, а полноценно загрузить его работой не у всех есть возможность), а отследить косяки — могли бы и автотестеры (чтобы нанять которых в дополнение к ручным, бывает, надо ещё убедить менеджмент) во время стресс-теста. Ну в самом деле, я ж не один тут воюю. И потому, я скажу честно: мне очень импонирует возможность постгреса продолжать жить в условиях, когда уже в проде под нагрузкой выяснилось, что стресс-тесты что-то там не покрыли, и что разработчики не предусмотрели, а откатывать миграции уже слишком дорого и долго, да и функционал на проде нужен уже сейчас, ну вот потому что через два дня уже поздно будет. В этом случае мы анализируем сложившуюся ситуацию уже на живую, оцениваем запас времени до пришествия северного зверя песца, и выясняем, что мы можем сделать, дабы сгладить нагрузку. Это время передаётся разработке, и они как правило умудряются уложиться в него, чтобы оптимизировать запросы и выкатить хотфикс. И в качестве хотфикса — обычно либо оптимизация запросов, либо вынесение части бизнес-логики отдельно во внешний сервис, будь то очереди или kv-бд. Вот кстати, один из таких примерчиков[1] у меня даже в KB записан "на память". Пока что — так и живём. Безусловно, оптимизируем процессы, и стараемся минимизировать прохождение подобного на прод. Но увы, иногда всё же случается. В конце концов, наша задача как девопсов — заставить продукт летать 24/7/365, не смотря на то, что продукт имеет аэродинамику шкафа. [1] https://www.opennet.ru/openforum/vsluhforumID3/136533.html#14
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #225 Ответы: #236

231. Сообщение от Аноним (-), 12-Июл-26, 16:38	+/–
> Я так и представляю как все программисты PostgreSQL побегут с пермессивной лицензии > на AGPLv3. Почти всех проекты под copyleft почти заглохли или находятся > в полузаброшенном состоянии. Особенно Linux в сравнении с BSD какими-нибудь :). Но в целом сабж конечно забавная штука, один rust - не pgrust!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #155

232. Сообщение от Аноним (-), 12-Июл-26, 16:41	+/–
>> AGPLv3 > И что, кто-то в здравом уме переведет свою инфраструктуру на вот это? У вас дофига своих патчей, которые вы не запинули апстриму? Ну в общем это беспокоит только несколько наиболее отборных жадин на планете. Которые хотят нахапать и ни с кем не делиться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106 Ответы: #239

233. Сообщение от нах. (?), 12-Июл-26, 20:47	+/–
> bun уже на Rust переписали > https://bun.com/blog/bun-in-rust _начали_же ж переписывать! (я и говорю, трындец, давайте чо там сперли, посмотрим хоть)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #227

234. Сообщение от нах. (?), 12-Июл-26, 20:51	+/–
>> проведение экспериментов по изменению внутреннего устройства и созданию версии >> PostgreSQL, избавленной от архитектурных ограничений > Логичный вопрос: тогда какой был смысл ПЕРЕписывать сам Постгрес?! :))) Взяли бы именно тот что написано - создание версии _САМОГО_ПОСТГРЕЗ_ без бесконечных проблем на пустом месте. > и начали новый проект! Или растаманы НЕ УМЕЮТ в архитектуру и растаманы умеют, в отличие от тебя, сообразить, что "новыйпроект", ни с чем несовместимый, нахрен никому не упал. А вот работающая версия постгреза, не требующая ничего глобально менять на клиентах, может и занять место под солнышком (заодно подвинув постгрезпро по лавку) И пока у них в общем неплохо получается... непонятно только, хватит ли бабла платить ЫЫ чтобы она довела проект до чего-то примерно нужного. Но если фамилие действительно принадлежит той мишпахе - то там с деньгами все норм. На токены должно хватить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #216

235. Сообщение от нах. (?), 12-Июл-26, 21:10	+/–
тем временем антропик: We're extending Claude Fable 5 access on all paid plans, as well as keeping ▎ Claude Code’s weekly rate limits 50% higher, through July 19. иппитес! Ну ок, пойду узнавать у нее через какую ж задницу можно ухитриться написать erasure codes "давно известная и хорошо изученная алгоритмическая задача (c)sonnet" чтоб они не работали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108

236. Сообщение от Прохожий (??), 13-Июл-26, 00:38	+/–
> Тоже тюним размеры буферов, количество обработчиков, количество воркеров вакуума... А ещё в Oracle можно несколько UNDO создать, подключить in-memory database, если уж апдейтов, инсертов очень много (несколько десятков тысяч в секунду). Можно также перенаправить DML на standby (хотя это недешёво и не всегда лучший способ разгрузить primary db). > Важней то, как долго они блокируют операции чтения, пока выполняются. В смысле? Читатели не блокируются. Они читают предыдущую версию данных. На то Оракл и версионник (собственно, как и PostgreSQL). >  ORM-ка и разработчики знали про FOR UPDATE, но ничего не знали про FOR NO KEY UPDATE - итого имеем множество локов, не очень быстрый update, и следовательно периодические тормоза > И как ты понимаешь, скорость выполнения update-запросов в данном случае очень критична. Ну, кто ж им доктор? Читать доку ж никто не запрещает, это бесплатно. В любой СУБД, как ты понимаешь, можно накуралесить и завалить её одним единственным пользовательским сеансом. > однако я как девопс не могу контролировать вообще всё Контролировать ресурсы БД - это дело DBA, совершенно не девопса. Девопс только за разворачивание отвечает, а не за администрирование. > а откатывать миграции уже слишком дорого и долго У Oracle (Enterprise Edition) для этого flashback database есть. Очень дёшево (по времени, а не по деньгам) и очень быстро.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #229 Ответы: #238

238. Сообщение от freehck (ok), 13-Июл-26, 01:40	+/–
>> Тоже тюним размеры буферов, количество обработчиков, количество воркеров вакуума... > А ещё в Oracle можно несколько UNDO создать, подключить in-memory database, если > уж апдейтов, инсертов очень много (несколько десятков тысяч в секунду). In-memory database в Oracle — это ж вроде ускорялка для аналитических запросов, а не операций записи. Но может я чего-то не знаю? > В смысле? Читатели не блокируются. Они читают предыдущую версию данных. На то > Оракл и версионник (собственно, как и PostgreSQL). Извиняюсь, у меня специфика своего продукта в голове сейчас. В общем, у нас добрая треть запросов — это SELECT ... FOR UPDATE. И эти читатели — очень даже блокируются. Возможно я неправ, конечно, называя их читателями. Всё-таки это уже смешанная операция. >> однако я как девопс не могу контролировать вообще всё > Контролировать ресурсы БД - это дело DBA, совершенно не девопса. Девопс только > за разворачивание отвечает, а не за администрирование. Да, да. В идеальном мире оно и должно быть так. Но, как говорится, ложка хороша к обеду, а лучшее оружие во время боя — это то, которое сейчас в руках. Иногда, короче, нужно организовать создание продукта быстрее, чем есть возможность правильно его спроектировать / найти всех нужных специалистов. Тем более, что мы, думаю, все в курсе, насколько остро нынче проблема квалифицированных кадров. А потому в реальности и DevOps отвечает не только за развёртывание. В реальности это ещё и SRE, и SecOps; и ещё залезть в гoвнocepвис, дабы прогнать там strace и найти причину крашей, которые случаются только на проде; и остановить разработчиков вовремя... >> а откатывать миграции уже слишком дорого и долго > У Oracle (Enterprise Edition) для этого flashback database есть. Очень дёшево (по > времени, а не по деньгам) и очень быстро. Почитал. Вероятно, это можно сэмулировать на постгре при помощи снапшотов ФС. Но это, конечно, сложно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #236

239. Сообщение от нах. (?), 13-Июл-26, 16:52	+/–
agpl3 не требует передавать свои патчи апстриму, проснись, ты обгадился, как обычно. Там совсем-совсем другая проблема, и она реально не позволит использовать эту хрень (не заплатив автору) ни для чего путного. Ты бы это знал если бы умел в ингриш. Или хотя бы попросил алису пересказать понятным тебе пацанским языком.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #232

240. Сообщение от EuPhobos (ok), 13-Июл-26, 17:23	+/–
Субагенты пытаются тесто месить из дров.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160

241. Сообщение от Илья (??), 14-Июл-26, 16:49	–1 +/–
СУБД redis
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #212

242. Сообщение от Аноним (242), 16-Июл-26, 01:28	+/–
Ну если без шуток, то в последнее время всё чаще и чаще думао об этом. Хотя в лагере майков тоже всё не очень, там хотя бы многий проф софт работает нативно. С сегодняшними вечными драмами вокруг линукса, нт-шка уже не кажется такой плохой, а от какой нибудь висты или хрюши и вовсе, олдскулы сводит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #191

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

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