Ох уж эти выши дырявые подоконные протоколы.

Ох уж эти криворукие крикливые пожиратели мозолек

Ну дак самба дарывая как в винде так и линуксе. Вывод сам можешь сделать. ))

Уже сделал

В линуксе самбу не мс писал

А миллионы глаз которые делают любой код идеальным

Че же МС тогда без дырок не написали?

А они никогда про миллионы глаз и не говорили

Это гн торвальдс кукарекал про это

Да там полный цирк с конями. Твиттор даже специальный появился https://t.me/tech_b0lt_Genona/2124

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

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

но и потмо или пытаться сие дело протолкнуть в мейнстрим (а это тоже еще то удовольствие), или тащь свой форк, что тоже удовольствие

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

Линус со своими законами заплакал в уголочке

Насколько я помню, не так уж сложно случайно написать запросы, которые будут игнорировать настройки work_mem вообще.
Т.е. во-первых, work_mem — это рекомендация по максимальному использованию памяти одним node плана (т.е. если 60 таких node — используется 60x work_mem); во-вторых, иногда work_mem просто игнорируется, и память выделяется, и всё.

Вот пример:

SELECT x, COUNT(x), array_agg(x)
  FROM (
       SELECT ((i << 20) | (j << 10) | k)::text::xid AS x
         FROM generate_series(0,1023) AS i,
              generate_series(0,1023) AS j,
              generate_series(0,1023) AS k
       ) s
 GROUP BY x;

И пояснение (всё © RhodiumToad):

Hashaggregate currently has no way to spill to disk. Hashagg won't be planned if the estimated hashtable size exceeds work_mem,
but at runtime, it'll blow past work_mem and use as much memory as it needs.

xid is a useful built-in example of a non-sortable type for sortable types, the query will usually use a sort and therefore be subject to
work_mem limits. But xid can only be grouped by hashing, so it forces a hashagg plan regardless of work_mem. So the query will try and create a hashtable with a billion entries each of which includes an array build state.

Пиупиу попенсорс