я краще на реддіт на англійський мові буду далі контент потребляти

Давно пора перейти на латинку (так! саме так, свідомо відмовитися від «споконвічного алфавіту», рашка вже забрали назву країни, то най і букви забирають)

Qırımtatar elifbesi давно на латинку перейшли
A a B b C c Ç ç D d E e F f G g
Ğ ğ H h I ı İ i J j K k L l M m
N n Ñ ñ O o Ö ö P p Q q R r S s
Ş ş T t U u Ü ü V v Y y Z z

Тільки в нас й далі вперлися, тому будь який пошук з кирилічними літерами в гуглі веде в «рускій мір» на «апщєпанятний»... (звісно, не всі досить завзяті, щоб юзати -и при кожному запиті, або налаштувати то як частну кожного запиту)

Цитата

А для чого українцям ті, хто не зміг вивчити українську для творення контенту?

Тобто це — єдина претензія? Я б тоді додав реки фільтрації за мовою...

А насправді то українцям треба було б навпаки написати для «рускіх» палалельну вікіпедію їхньою мовою, так, щоб було «в Україні» а не «на» й щоб «вони» ходили до нас читати про історію, а не навпаки
(так так, гадський скріпт на «їхній» вікіпедії не дає «на» на «в» виправити!)

А зараз за кількістю контенса гугль більшість запитів кирилицею веде в рашку, на їхні лесурси, навіть технічні топіки, якщо не «хабрахабр» то «альона С++» або ще щось типу того...

Тепер залишилося знайти приклад живої на сьогодні «крафтової соцмережі»,
іфорум закінчився в 2023 (та й трохи «нете»), «порталюа», теж нето... нема «інфостора» та «мейлюа»...

Й всі ті штуки зовсім «нето», бо «не редіт», «не стековерфлов», не «квора»...

Ні в якому разі не применшую успіхів та досягнень справді визначного та талановитого діяча, яким був Олексій, але, все ж, люди не сиділи на таких ресурсах, так, як то колись в ЖЖ чи на PHP-BB форумах (так так, на PHP-BB форумах, кокинутий «харківтурист» крутіший за ті всі фейсбучеки) і не сидять як зараз в Цукербергівскому фейсбучеку/інсті чи в фсбшній телеграмці (про Ютуби та Тіктоки вже і не згадую, але це все теж трохи нета спрямованість)...

Звісно моя позиція сугубо «технарська», мені бракує саме «українського хабра» чи «українського стековерфлов», й хоч я можу позагуглювати то що мені треба на «енглісх лангуаге», але зазвичай люди коли гуглять «циріліцей» то попадають саме в «рускій мір»...

проекти Мася

якась дуже невдала назва, гугль нікуди не веде, ніколи не чув

цей самий Доу

нажаль, занадто «HR орієнтований»...

але нова «подєлка», нажаль, то не «український реддіт», а «український вконтакт», але навіть оригінальний «вконтакт» він початково був «прибацаним» навіть в часи до бану (за самим UX!)...
І навіть залучення відомого персонажа «ібігдана» не допоможе...
І навіть якщо покличуть Білозерську, Джесфора, Далі-Буде, Спарров Хока, Пана Андрія й bf109e (чи як там його?) та інших ЖЖшних персонажів типу «v-n-zb», але все одно «вже нето»)

(насправді навіть ЖЖ та PHP-BB форуми, чи й той же запоребриковий ворожий «хабрахабр» за UX краше від ідеї «вконтактіка», що годиться хіба що виставляти селфі з дупами няшних котиків...)

8 байт, і один вказівник на 8 байт. Тобто щоб зберігати 4 байта, треба використати принаймні 16 додаткових.

Ем... інтеджери в Пайтоні «нескінченні» й там трохи нетак (перше ж, що й видав гугль)

Але навіть яби треба було засторити 4байти у варіанті «лічильник посилань у 8 байт, і один вказівник на 8 байт», то, все ж, найімовірніше це 20додаткових (разом 24) бо вирівнювання...

Ідея заповнити Інтернет додатковим українським контентом — правильна!
Але то мають бути не лише відяшки та картинки, чого й так повно...
Конкурувати з «інфопомийками», де ті самі персонажі викладають «контент» — нето

Чого насправді й далі бракує в «Українському сегментів», то об’єднань професійних спільнот які легко мейнтейняться самими учасниками й де учасники дійсно діляться чимось корисним (чогось такого, що, наприклад, існує довкола ютубу Дядька Максима, але Ютуб та ФБ занадто обмежені щоб красиво акумулювати це все),
Й, умовно кажучи, треба щоб запит в гугль якоїсь такої технічної штуки кирилицею не вів до «шанувальників скрєп»...

...
Щодо сайту (абсолютна суб’єктивщина):
Ота «стіна» яку треба прокручувати вниз (фейсбучна чи вконтактова) — це «нето»,
хочу групувати/фільтрувати джерела надходження постів кастомно за своїм вподобанням (ієрархічно, отак, як кастомні фільтри мітки гмейлу ага!, щоб можна було або за автором, або за темою/автором/тагами закинути в фільтр)

«Підписки» однім потоком теж нето, один автор може «забити» все фотками голих дуп няшних котиків і тре буде забагато крутити, щоб знайти щось що зараз цікавить, але якщо не хочеш банити того автора, а просто щоб була можливість потім «переглянути дупи заголовки по діагоналі» й «позначити все прочитаним», то нема як...
(грубо кажучи, якщо я шукаю пости про «токарку» то мій фільтр для «токарки» повинен бути забитий виключно токаркою а не голими дупами няшними котиками... і навпаки...))

Теми Новини, Політика, Кіно, Музика, Спорт, Меми присутні всюди, чим вони «визначніші» на цьому сайті, ніж «там в інших локаціях»? (та й на них зараз неможливо клікнути)...
Якби я міг створити свій список фільтрів/тем, й в кожному з них були свої оновлення, то було б набагато веселіше, ніж прокрутка «стіни»...

іншими словами проблема всіх «ресурсів», «порталів» і тд... завжди в переповненості інформацією... й кожен вирішує то по своєму (закладки з лінками, фільтрації, чи просто пам’ятати «давненько нічого не дивився від Дядька Максима») або й не вирішує (є люди з тисячами непрочитаних мейлів в робочій пошті, що проглядають тільки заголовки, або й не проглядають))

PS. А може ті всі функції, що я описав вони десь є присутні? Ну то якщо я їх «просто» не знайшов, отже дровбек... так, я розумію, що вони відсутні також й в умовному твіттері чи в фейсбучеку, але саме тому я і вважаю X та ФБ — помийкою (заховати всі «потоки» за умовним червоним дзвіночком з цифрами 99+ то знущання...
так, я розумію, що це «так і задумано» і частина бізнес моделі, щоб все було на купу й люди весь час никалися і напорювалися на «новий потенційно цікавий контент», але це вже «нето», «ддос атака», «спам», простіше відмовитися від такого «контенту», ніж бавитися з ним в ті «ребуси» коли він тобі сам підпихає «то, що тобі мало б бути цікаво», але воно насправді «ніразу не то»)

Кожен бачить свій зміст... насправді зміст саме в «networks of objects» й тому, що, походу, один об’єкт може брати участь в кількох «networks» одночасно...

А ще, по ідеї, головна фішка не просто поєднати всіх учасників «взаємодії» в «контексті», а й специфікувати до них вимоги, відповідно в контекст туди можна усе, що реалізує певні вимоги чи «інтерфейс» (не обов’язково буквальний «інтерфейс», головне щоб були такі методи, такий собі «дак тайпінг»... або «концепти» коли на оту role AMOUNT катить все що має double amount() const а на role SOURCE_ACCOUNT то, де є decreaseBalance, availableBalance, updateLog)...

Іншими словами «ідеологічно» вся концепція в тому, щоб запхати в контекст рілейтед дані відповідно до їхніх ролей (щоб вони відповідали заданому рікваєру) + щоб були операції (interaction), які існують тільки в даному контексті для тих наперед визначених ролей (щоб ми їх не смикали з інших «контекстів»?)

То таке можна реалізувати на будь якій мові програмування «і так, без спеціальних мов», просто залежно від мови кількість перевірок компайлтайму версус рантайм буде різною... Умовний ЖС й його дактайпінгом чудово канає, тільки ж про те, що «щось відвалилося» (що об’єкт не відповідає ролі на яку його запхали) ми взнаємо лише в рантаймі... а з іншого боку умовний С++ з його темплейтами й концептами, що дозволить зв’язати «те що треба» в одному «контексті» (і тоді консепти поматюкаються завчасно ще на етапі помпіляції)... Спеціальна мова Trygve просто робить то все явно, а не по неймінг конвеншенах

Й тоді все «стає логічно»...
й тепер очевидно TransferMoneySink та TransferMoneySource це воркераунди, які позначають підтримуваня даними ролі (наче якіто «таги», щоб не робити «дактайпінг» і не юзати концептів для розпізнання required...)

// Methodless role types
public interface TransferMoneySink
{
}
// Methodful roles
public interface TransferMoneySource
{
}
public static class TransferMoneySourceTraits
{

в книжці неправильно, адже TransferMoneySource це також «Methodless role types» а «Methodful roles» то вже нижче над TransferMoneySourceTraits

далі

Account self_=self as Account;
Account recipient_=recipient as Account;

то також воркераунд щоб брати участь в «потаганих» класах

public class SavingsAccount :
Account,
TransferMoneySource,
TransferMoneySink
{

причому воркераунд доволі потворний, бо що як той клас, який включає TransferMoneySource та TransferMoneySink так й не заімплементує Account — ми про те взнаємо лише в рантаймі...

іншими словами в такому варіанті не лише Java, а й C# не катить, головну ідею «поховано» а «оте все» виглядає як «таємничі танці з бубном на забагато рядків коду»... (я припускаю що якась магія з атрибутами/декораторами/рефлекшенами/інтроспекцією, можливо дозволила б то виявлення неправильного юзу «порішати» раніше, але трюк з as Account точно не катить)

В тому плані навіть консепти й темплейти С++ заїхали б краще, бо невідповідність консепту трапилася б в компайлтаймі (але так як зазаз стало «модно», незважаючи ні на що, поливати С++ брудом, то відмічу що неявні інтерфейси Go походу також чудово катять!))

вони можуть не вірити в те про що говорять «на публіку»,
але «всередині» вони ж вірять в те, чого хочуть досягти
так от та їхня «внутрішня віра» вона ж також «ненаукова»

Спострігаючи за будь-якою передвиборчою кампанією помітно, що можна «від фанаря» обрати будь яку сторону, й копіпейстити ті самі безумні картинки, що й вони, ті самі наративи, й «решта» на «цій стороні» вважатимуть тебе «за свого»...

Усі «об’єктивні критерії істини» давно «пішли лісом» (особливо то було видно в твіторах X коли там обирали «їхнього» президента)... Можна стверджувати придумувати будь які «факти», головне щоб їх було неможливо перевірити...
Коли ніяких «подвійних, сліпих, рандомізованих, плацебо контрольованих», лише сліпа віра, то прихильників здобуває не той, хто «об’єктивно кращий», а той, хто краще вішає лапшу на вуха агітує, «проповідує»... І проповідувати можна що завгодно, головне, щоб «лохторатові» було цікаво.

В тому, напевно і є основний «фейл» сучасної науки, вона стала для «простих смертних» така ж «неверифіковувана», як й всі оті безумні теорії «конспірологів»...
Й більшість тих, хто нібито «вірить в науку» вони теж не можуть довести що Земля кругла геоїд, вони вірять в це так само як й умовні плоскоземельщики сектанти!!!
Звідти й «антиваксерство» та решта «приколів» (й, кому насправді вірити — а чорт його знає!)

А найгадіше, що то все «антинаука» пролізло в середовище політиків, вони навіть валідність того всього, в що вони самі вірять не можуть проверіфікувати до застосування... й лише потім бачать (або й не бачать) наслідки, для яких, втім, завжди придумають такі ж неверивіковувані виправдання...

_____
Так от «До чого готуєтесь?» — насправді «а чорт його знає»... То все що відбувається, воно ще більш непередбачувало ніж погода, буквально, менш передбачувано ніж Атрактор Лоренца...

Вся сучасна «політична аналітика», то така сама «антинаука» як й «сучасна політика», навіть «передбачення погоди» надійніше, ніж ті «прогнози», більшість ютубівських (чи телефізійних) «пророків» самі не шарять що там вони вповідають (насправді кожен вповідає те, що хоче чути його аудиторія)...

Ті політики/бізнесмени, хто криймають рішення «відкрутити краник хаотичного млина сильніше», вони й самі не знають, куди наступного дня буде «крутитися колесо»... Єдине, що «працює», той «фідбек», який на них діє, то хіба їхня власна очевидна безпосередня вигода... Але й то не завжди... тобто вони — гравці в казино, оте про «в тебе нема карт», якраз «з тої ж опери» (головна біда, що «ставки» в основному за чужий рахунок)

________
Єдине раціональне рішення в такому світі «азартних ігр» та дурнуватих «ставок», то хіба рухатися туди, де «колесо крутиться повільніше»...

Так звана «Священна Римська імперія» проіснувала до 1806 і навіть керувалася «римськими цезарями» (ну, тобто «кайзерами», Erwählter Römischer Kaiser)...

А взагалі отой от «політичний копіпейст» на «наслідування» всякої «величі» з «вазвращєнієм в радную гавань», то ровсюдно поширена штука...

Тому «Рим — мать гарадоф священноримськоімперських» й треба приєднати Італію до Німеччини, «щоб відновити історичну справедливість»

Вірити обіцянкам рашки, ніби вони там щось проти Китаю зроблять?

Так отожбо... виходить що людей «поставлять перед фактом»: вимітайтеся з свого житла, покиньте своє майно, або ж беріть російські паспорти й живіть під бутом в окупанта.

А пустивши окупанта на Правий берег, то вже «плацдарм» для продовження наступної атаки...

ем... а хто сказав, що жителі тих міст погодяться?
та й де про те, ніби Трамп зібрався виконувати й ту «хотілку» рашки?

Судячи з передісторії той пан, що назвався «Юрий Павленко» (чи та команда тролів, що його запустили сюди) винайшли «AI чат бота» ще задовго до того, як «подєлки» Open AI стали відомі... й тепер той самий бот всім тут й відписує «стандартну капітанщину»...

Винайшов десь, напевно, в ті ж часи, коли й з’явився «Корчувальник».

І вдало «тролить» усе шановне співтовариство... (важко повірити в те, що «це все серйозно»))

З іншого боку цілком повірю: напевно ж той самий «алгоритм» від цього пана й надалі продовжує «брєдогенерити» всі оті «наукові праці», що їх захищають численні «кандидати» та «доктори» наук, й що містять приблизно такий же контент, як й «корчувальник»... Звідти й гроші на хостінг та на утримання «гавносайтів» як частини цього тролінга :)

І всі учасники процесу будуть просто знати всі структури даних синхронізованим чином

ем... так це ж і є як сьогодні працюють Лінухи, от прямо зараз — то «моноліт» де «всі бачать все», і повинні «ковирятися» в розшарених на весь світ лінкедлістах де всі поля «кишками назовні» (і всі повинні знати правила ковиряння в тих кишках)...

А от щоб послати на «сопроцесор», то вже має бути теж відомий формат для обох сторін, який «просто дані»)) А «друга сторона», то може бути взагалі не Лінукс, а «електроніка» без ніякої OS...

щоб вони були аллоковані узгодженим чином в компайл таймі на всіх сопроцесорах

яких «сопроцесорах»? Якщо мова про фізичний девайс який «щось вміє» й куди ми посилаємо «дані на обробку» щоб «розпакуй/декодуй мені ось це», то він «там в себе» не може звільнити те, що ми зробили (k)malloc (чи вицепили з лінкед ліста) «тут»! Тобто «той» девайс він алокує «в себе» дані «як хоче», але викликати деалокацію в «нашому» процесорі він вже не може ніяк!

і протоколи з якими це все працює ніколи не будуть змінюватися

Чого ж не будуть? будуть!... Але наш наявний допоміжний фізичний девайс з своїм іншим процесором, він змінює свій протокол доволі рідко!

А от ядро змінюється щоразу, і щоразу при автоматичному апдейті ядра dkms (що теж запускається автоматично) мучає процессор, хоча мій хардвар ніразу не змінився, все то само, як і було, але треба перекомпілити існуючий драйвер під нове ядро, бо ядро «щось змінило» в своїх «кишках назовні»))

1024×768 вистачить кожному і назавжди, наприклад...

якщо хардвар на моєму старенькому ноуті фізично вміє тільки в MP2, і перепрошивки не передбачено і там вже «хардваєред» електричних колах, то в MP4 його вже ніяк не заставиш))
І ніякий (k)malloc чи elem = free_blocks->next; тут вже ніяк не допоможе))

оффлоад всього що тільки можна в залізо і сопроцесори стає все більш значимим

саме так! саме так!
тому чим далі, тим «передаються дані», а не якіто структурки з алокуємими в тому ж адресспейсі поінтерами/ресурсами, які потім треба звільняти/деалоковувати, «десь в іншому тому процесорі» (ваш «співпроцесор» не може «бачити» адресспейс викликаючого процесу й «звільняти» в ньому якіто «ресурсти»!)...

іншими словами «struct data» з якимито заалокованими даними в такій новій парадигмі не повинен існувати взагалі!
Вірніше повинен бути просто «структуркою без посилань», що сама містить всі дані, які треба!
Й тоді його можна буде пересилати «як є» і між процесами і між (спів)процесорами, і через всякі шини, і по мережі (вважаємо що ендіаннес співпадає)...

Й тоді «стандартизована» АПІшка для передачі даних «куди треба» вона «всюди однакова» і посилає «просто байтики»))

Ще раз, це код умовний. Для іллюстрації простіше написати malloc чим якусь власну реалізацію пула.

та я розумію що умовний, тому й просуваю умовний блокпул))

Тебе навіть не смутило те, що в ядрі немає malloc. Невже важко уявити, що замість нього буде щось

lock();
if (list_empty(free_blocks)) {
unlock();
return; /* Drop no space */
}
struct list_head * elem = free_blocks->next;
list_del_init(elem);
unlock();

struct data * data = container_of(...);
...
bad:
lock();
list_add(free_blocks, elem);
unlock();
Це ближче до реалій, але втрачається ілюстративна цінність.

яка ілюстративна цінність?
там в ідеальному світі повинно бути

BlockPool<Data, КонстантаСкількиЇхТреба> моїБлоки;
... 
auto тойБлок = моїБлоки.Emplace(параметри, конструктора)

а не весь отой мазохізм з (умовно) rcu_read_lock() та rcu_read_unlock() й відчіплянням хеда вручну (це все має бути заховано, а не ручним розлокуванням для кожної гілки))

й той, хто ті блоки юзає, він взагалі не повинен знати деталі реалізації звідки вони беруться навіть для випадку Сшки треба гуглити про трушні блокпули в ThreadX а не про гавнопадєлки курсачі фінських студентів де вони по всьому пректу багатократно демонструють свої здібності роботи з двозвязними списками... бути «списком» — то «деталі реалізації» які взагалі не повинні «світитися» в місці виклику))

Я не зрозумів, що там може бути незрозумілого... Дивишся код та усе ж видно! Там же немає нічого прихованого.

ні ні, не дивишся (зі мною не погодяться, але якщо для юзу не достатньо побачити *.h, а треба дивитися реалізацію в *.c то це велика печаль!)
... але в *.c коді реалізаці жодного коментаря про те, чи порядок суттєвий (тому «на всякий випадок його не змінюй, бо що буде, якщо зміниш — а чорт його знає»)

(я той пост якраз поедітав і дописав ще й про те, що free_data мастхев і викликати його для рідкісного кейсу «навернулася алокація одного ресурсу» — цілком норм!)

Няшна Сшка стає прекрасною тоді, коли

struct data_container;
typedef struct data_container* data;

data data_create();
тип_для_статуса data_якийто_метод(data, ...);
тип_для_статуса data_якийто_ще_метод(data, ...);
...і тд
тип_для_статуса data_free(data).

А в ідеалі дрова живуть кожен в своєму «процесі» й спілкуються через якийто IPC «великими кусками», й ми «забиваємо» на «оптимізції бліх», й отримуємо «якето Minix QNX» що цілком прекрасно живе в світі «швидкодіючих девайсів з прогнозованим часом реакції на подію»))

Звісно для часів появи Лінухів мікроядро й дрова в окремих процесах, було «дуже дорого», але ота «інша крайність», коли всі частини до всіх частин «кишками наружу» і «ковиряй що хочеш», то це якась зовсім печалька...

Золоті слова:

Проблема, якщо і є, то зовсім не в мові, а в архітектурі

Попри всі «мікрооптимізації» Лінух не є QNX!

в разі ядра ми гадки проце не маємо

та ні, зазвичай ми якраз знаємо що робимо і тоді:
* умовий «хендл» якогото девайса з його ресурсами в нас добувається не так то й часто... то чи Rust чи С++ чи няшна Сшка — без різниці, головне убезпечити щоб юзер потім правильно позбувся того «хендла» (в цьму «убезпеченні» Rust та С++ таки кращі!)
* а якщо такі «алокації» робити на кожен пакет даних від (умовно) якогото блутуза девайсу, який присилає дані, то за такі алокації треба «виривати руки»

. Плюс код може бути день в IRQ, де нам треба якнайшвидше витягнути, покласти та перейти до нижньої половини.

От якраз в IRQ треба запихати дані в чергу/буфер «як є» без ніяких алокацій та інших «мудрих дій», і вже «на тому боці» черги персати залежно від потреб... (або і не парсати, а одразу надавати можливість читати те, що вже прийшло, з юзерспейсу через /dev/чототам)

а в питаннях коли треба економити на інструкціях взагалі не хочу таким займатися

я «трохи про інше»: в «няшно Сшній частині» там «багато цікавого» заховано в готовенькому

call alloc_resource

а в Rust

Resource::new

порозгорталися/заінлайнилися, порівняння некоректне.

Але найбільші граблі: насправді в Сшному
create_data якщо то робити без готовенького free_data взагалі незрозуміло, що з тим data робити потім (в загальному випадку незрозуміло нaвіть чи воно thread safe, або чи можна елементи data звільняти по окремості...)
тобто create_data й free_data завжди мають йти «парою», й «оптимізація» всередині create_data не має смислу, також, зокрема й з огляду на те, що «зазвичай» все алокується, тобто оптимізувати треба лише «позитивний» шлях а не корнер кейс коли «щось навернулося»