Back to The tech awesomeness
Table of contents
Non-functional-chapters

The article for today.

There are few highlights from the article.

Freedom, security and privacy are interrelated and interdependent.
Freedom strengthens security and privacy.

To protect own security and privacy, freedom and control are needed.
Without freedom, security and privacy require the full trust of vendors.

Freedom results in stronger security and privacy.

When freedom is decreased, security and privacy are put at risk.
And as freedom is increased, security and privacy are increased.

The update as of 2021-01-15.

Оновлення від 2021-01-15.

Можливо помітити візуально реп'яшки(такі як закрили так і відкрили), але не почути їх в мережевих програмах перегляду сторінок в інтернеті. Вони можуть слідкувати(існує такий тип реп'яшків) переміщаючися між сторінками в цей час щодо 'віувіувіу' і інших. І тоукєни теж. Більше того, реп'яшки можуть накопичуватися в таких програмах. А ще тоукєни можуть бути вcередині реп'яшка. А навпаки ні. Тож висновок: таким чином реп'яшок може бути колекційною моделлю для тоукєна. Але якщо тоукєн > ~ 4093 байтів, то він не поміститься у реп'яшок.

The update as of 2021-01-16.

Оновлення від 2021-01-16.

At least it is partially overcomeable with a help of addition and substraction of their parts. When one inside another one.

Проте щонайменш це є хоча б частково прохідно за допомогою базових додавання і віднімання (рядків) їх частин. Коли один з них в іншому. В залежності де вони знаходимуться, бо там існують інші обмеження, одне з них непрохідне(станом на сьогодні) наприклад в ~65500 байтів(приблизно).

Доте це призвело до іншої: service proposition as a service(пропозиція послуг(и) як послуга).

When I consider repeatable emails or digests and so on from this narrow point of view(service proposition as a service): spam type and non spam type, the differentiator there for them is the absence of subscription and unsubscription services in one of those types, particularly in spam type of email. In some types of paper mail the same one applies is as well.

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

Саму послугу відрізняння електронних листів спама від електронних листів неспама надає звичайно не електронний лист а постачальник електронної пошти(як послуги разом з іншими постачальниками). Як імовірно і паперової, але це неточно. Тож таке відрізняння електронних листів спама від електронних листів неспама як послуга як мінімум ділиться на три типа: 1) не відрізняння(нібито спама немає, лол); not marking as spam, 2) неавтоматичне помічання як спам(і від цього як кажуть там всередені щось електронне вчиться з цього процесу помічання); non automatical marking as spam і 3) помічання автоматичне(як кажуть те, що там всередині навчилося електронне, може робити це помічання теж); automatical marking as spam. Для паперової пошти умовно так само(необов'язково електронне звичайно).

А далі, як втретє, зазвичай, вже зі спаму ця електронна листова купа може бути видалена(автоматично) через скікі-то проміжку часу. І це теж послуга з видалення електронного листу зі спаму у постачальника електронної пошти. І вона теж ділиться на ввімкнену і вимкнену. Але тут в цих двух послугах процес можливий лише такий:


    1 -> 2.

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


    2 -> 1(але з кошиком для подібних).

Це два різних процеси.

Так послуги фільтрації і переадресації дуже розвинені в електронних поштових постачальниках і системах. Проте я досі декілька років шукаю постачальника електронної пошти і/або подібний стандарт де існує присутня інтерграція з чимось накшталт drools, іншої зайнятості бізнес правил керівної системи business rule management system (BRMS) яка додає можливість створювати подібні процеси(помічання як спам і видалення як спам і можливих інших компоненталів) для наявної електронної пошти.

Але продовжуючи на цьому потужному компоненталі: ось фантантастично, Ілантославе Мохначевече, але це можливо витратить твій коштовний час на дд;нч tl;dr, або tl;dl, проте там є і про інших відомих людей минулого, і безпосередньо про Томаса Бейза, 1702 — 1761, чий винахід є залученим в деякі алгоритми маркування як спама деяких електронних листів.

Тож визначення компоненталя тут відсутнє, тож послуга як компоненталь. І водночас компоненталь це щось чітко визначене. Але компоненталь для щонайменш цих двох послуг(позначання як спам і видалення спаму) може дозволити копіювати послуги, як функцією контроль це control c, контроль ве control v.

І тоді після тієї ознайомлення з цим, стане більш вочевид, що можливо копіювати окрім:


    1. операндів(значень). ну і операторів звісно.
    2. формул.
    3. даних для формул.
    4. додатково отут саме ці компоненталі.

Бо на створення нестандартизованих гачків хуків hooks, я і витрачав найбільший проміжок часу. І у нестандартизованій формі саме це займало найбільше і створювало найбільше запитань і проблем. Ну це мої, як зазначили і критикують інші, суб'єктивна думка і твоє суб'єктивне спостереження.😉

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

Розповім ще одну таємничку, тобто таке спостереження котре я помітив в електронних сервісах послугах: захучені послуги сервіси(електронні) рідко змінюються. Чи ознака це того, що це складно, або що це крихко(fragile) чи інша я не знаю.

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

Досі їх неможливо копіювати. І досі в тому я витрачу найбільший проміжок часу.

Але з іншого боку цьому є ціна: достатньо запитати когось залученого до створення того алгоритму, особливо пришвидшено: ну як ти. І помітно що кожен день створюються нові перемикачеві системи з нестандартизованими хуками без компоненталів.😉

Компоненталь, ну як ти.◼️

Умовно:


                                                      |
                                                      |
компоненталь зі стандартом для кнтрл це,ве            |--
компоненталь без стандарту                            |-
                                                      |
                                                      |________________________
                                                       менший проміжок часу; більше ефікасі; х
                                                      |
                                                      |
componental with Standart{/*Standard*/} for ctrl c,v  |--
componental with no Standart{/*Standard*/}            |-
                                                      |
                                                      |________________________
                                                       less period of time; more efficacy; x

Іншими словами: достатньо уявити що ви можете якось скопіювати цілий сервіс цілу послугу в інший сервіс іншу послугу. Електронно. Приблизно способом як копіюються інші з наприклад натисканням кнтрл це,ве. Ті послуги, які це дозволяють, тобто ті послуги, які надають таку можливість.

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

Звичайно без цього вейстін тайм та й годі.

Звичайно мені подобаються замовники і замовниці, котрі замовляють перемикачеві системи без компоненталів, бо подібного стандарту ж немає вже декілька років. Ось ці електронні системи і функціонали і копіюються, дублюються , без перевикористання і відрито кодово і закрито кодово. І за подібну діяльність це ще й сплачують від 62500 грн (UAH) і від 82500 грн (UAH) у мінімальних випадках десь. ◼️ Дуже помітно, що за подібне іноді і в еквівалентах рівнозначеннях, якщо компанія немісцева, заморська, заокеанська. Оминаючі навіть про неелектронні варіанти, паралелі подібного. ◼️

Влаштування електронним хукером. Проте ж існує і інший, неелектронний хукінг. Ням. Ще ж існує і ⛏. І не один. Вейстін тайм та й годі бо це є цілком за даних умов. ◼️

Отам десь були шкали, так, ідеальні. Somewhere there were some scales.

Тепер для цього випадку є інша шкала, у цей раз неідеальна:

There is for this case another scale at this time, not ideal one:


      less period of time; more efficacy; менший проміжок часу; більше ефікасі <-------------------> вейстін тайм, wasting time

І такє вже щонаймеш триває як мінімум декілька років. По селящянські для вас. Але це не трівіа. Гра така.

це кодовий протекціонізм. 😉

Maybe it is a case, a phenomenon of a code protectionism. 😉

тоді це оновлення про кодовий антипротекціонізм.

Maybe this update is about a case, a phenomenon of a code antiprotectionism.

Хтось розцінив це як критику. Так, можливо. Але це ні, не критика, заперечу: це спостереження, факти, аналізи і фантастично.

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

The update as of 2021-01-17.

Оновлення від 2021-01-17.

Для подібного конпоненталя для копіювання електронної послуги я згадав одразу лєго Lego, ХЕйТОАС HATEOAS. Проте сервіси послуги не схожі на блок лєго Lego.

Ще це нагадало історію про перевантаження пост ярмаркових площ з товарами речей продуктів. Там є мабуть дві системи: вантажівкова і пост ярмарково площинна. І умовно третя для переміщення цих товарів речей продуктів.

І ту історію де всередині пост ярмаркових площах автоматичні працівники чи автоматичні працівниці переміщають ці товари продукти речі.

Так само і електронний сервіс послуга має дані і методи і спілкування.

Якщо ХЕйТОАС HATEOAS більше для спілкування і навігації між становищами послуги сервіса, то для копіювання електронної послуги треба копіювати не лише дані і наступні методи.

Тож це копіювання дерево подібної структури, ієрархічної структури, як файли(документи) і папки, і які наприклаж теж підтримуються форматами ДжейСОН JSON, ІксЕмЕль XML.

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

Тож в експортній частині для копіювання сервіса послуги яка генерує подібну структуру це нагадує файл з купою пов'язаних зразків файлів зразків ХЕйТОАС HATEOAS зі своїми деякими особливостями.


{service_name_sample_28473876584: {
        move: {
            from: "variablestartvariableend",
            to: "variablestartvariableend",
            result: {
                message: {"variablestartvariableend"},
                error: {"variablestartvariableend"},
                next_actions: "unmove, remove, measure_available_power, recharge_power",
                next_actions_as_a_collection: ["unmove", "remove", "measure_available_power", "recharge_power"],
                next_actions_as_another_collection: {
                    "unmove":{}, 
                    "remove":{},
                    "measure_available_power":{},
                    "recharge_power"{}
                }
            }
        },
        unmove: {
            from: "variablestartvariableend",
            to: "variablestartvariableend",
            result: {
                message: {"variablestartvariableend"},
                error: {"variablestartvariableend"},
                next_actions: "move, remove, measure_available_power, recharge_power",
                next_actions_as_a_collection: ["move", "remove", "measure_available_power", "recharge_power"],
                next_actions_as_another_collection: {
                    "move":{},
                    "remove":{},
                    "measure_available_power":{},
                    "recharge_power":{}
                }
            }
        },
        remove: {
            from: "variablestartvariableend",
            to: "variablestartvariableend",
            result: {
                message: {"variablestartvariableend"},
                error: {"variablestartvariableend"},
                next_actions: "unmove, move, measure_available_power, recharge_power",
                next_actions_as_a_collection: ["unmove", "move", "measure_available_power", "recharge_power"],
                next_actions_as_another_collection: {
                    "unmove":{},
                    "move":{},
                    "measure_available_power":{},
                    "recharge_power":{}
                }
            }
        },
        measure_available_power: {
            result: {
                message: {"variablestartvariableend"},
                error: {"variablestartvariableend"},
                next_actions: "unmove, move, remove, recharge_power",
                next_actions_as_a_collection: ["unmove", "move", "remove", "recharge_power"],
                next_actions_as_another_collection: {
                    "unmove":{},
                    "move":{},
                    "remove":{},
                    "recharge_power":{}
                }
            }
        },
        recharge_power: {
            to: "variablestartvariableend",
            result: {
                message: {"variablestartvariableend"},
                error: {"variablestartvariableend"},
                next_actions: "unmove, move, remove, measure_available_power",
                next_actions_as_a_collection: ["unmove", "move", "remove", "measure_available_power"],
                next_actions_as_another_collection: {
                    "unmove":{},
                    "move":{},
                    "remove":{},
                    "measure_available_power":{}
                }
            }
        },
        locate: {
            to: "variablestartvariableend",
            result: {
                at: {"variablestartvariableend"},
                at_x: {"variablestartvariableend"},
                at_y: {"variablestartvariableend"},
                message: {"variablestartvariableend"},
                error: {"variablestartvariableend"},
                next_actions: "measure_available_power, recharge_power",
                next_actions_as_a_collection: ["measure_available_power", "recharge_power"],
                next_actions_as_another_collection: {
                    "measure_available_power":{},
                    "recharge_power":{}
                }
            }
        }
    }
}

Оновлення від 2021-07-02.

The update as of 2021-07-02.



    Внутрішній обслуговувач --- Зовнішній обслуговувач для зберігання даних
      |
      |
    Клієнт


    Internal Server --- External Server for data storage
      |
      |
    Client

У такій схемі клієнт не має доступу до обмінів його даних між внутрішнім обслуговувачем і зовнішнім обслуговувачем. Якщо дані в тому обміні даними закодовані і розкодовані з шифром у внутрішньому обслуговувачі, то це можливо й гаразд для клієнта, але можливо бути не гаразд для зовнішнього обслуговувача бо невідомо які дані зберігаються і навпаки якщо дані не закодовані, то це можливо й гаразд для зовнішнього обслуговувача але можливо бути не гаразд для клієнта бо дані не закодовані а зберігаються на зовнішньому обслуговувачі. Немає уточнення щодо типа обслуговувача в цій схемі. В закрито кодових системах існує ще менше засобів цю конфігурацію перевірити. Навіть у випадку застосування шифру це є не беручи до рахунку зусилля хакінгу. Це не ділема бо присутня якась конфігурація в імплементації такої схеми. Також якщо подібне кодування й декодування з шифром триває в зовнішньому обслуговувачі, то він має доступ до тих даних обміну що еквівалентно відсутності такого кодування й декодування із шифром там. Якщо клієнт виконує подібне кодування і декодування тих даних з обміну з шифром, тоді існує підвищене логістичне навантаження на мережу передачі даних і це є можливо не гаразд для й зовнішнього й внутрішнього обслуговувачів.

In such schematics the client does not have access to exchanges of client's data between internal server and external server. If the data in such exchange has encoding with cypher and backwards inside the internal server, then it is maybe ok for client, but it maybe not ok for external server because it is unknown data for storing and vice versa if the data of exchanges has no encoding with cypher, then it is maybe ok for external server but it is maybe not ok for client because such data has no encoding being stored in external server. There is no specification of server type in this schematics. In closed source type of systems there are even fewer means to verify that situation with configuration. Even in situation with application of cypher it is not taking into account the hacking effort. It is not a dilemma because there is such specific configuration in the implemetation of such a schematics. It is also if such encoding and decoding with cypher the external server performs, then it has access to that data from such exchange which is equvalent to the absence of such encoding and decoding with the cypher there. If the client performs such encoding and decoding of the data with cypher, there is more network load then and it is maybe not ok for both external and internal servers.

Оновлення від 2021-07-25.

The update as of 2021-07-25.

Читаючи декілька звітів, СВВ про те як файли малюнків, файли звуків, файли шрифтів, файли веб вмісту, файли інших типів документів ламають ПЗ і це є повторюване .

Reading several reports, CVEs about the image files, sound files, font files, web content files, other type of document files hack the software and it is repetative.

Ось коротенько про частини, які повторюються .

These ones are the repetables in brief.


A type confusion issue
 was addressed with
  improved code state memory handling.
A use after free issue
 was addressed with
  improved code memory management.
This issue
 was addressed with
  improved code checks, code assertions, code conditions.
An out-of-bounds read
 was addressed with
  improved code bounds checking.
A logic issue
 was addressed with
  improved code validation.
An out-of-bounds write
 was addressed with
  improved code input validation.
Multiple issues
 was addressed with
  improved code logic.
An information disclosure issue
 was addressed by
  removing the vulnerable code.
This issue
 was addressed with
  improved code entitlements.
This issue
 was addressed with
  improved code environment sanitization.
An access issue
 was addressed with
  improved code access restrictions.

Типова конфузія як несправність
 була адресована
  покращеним кодовим становим пам'ятним керуванням.
Використання після звільнення як несправність
 було адресовано
  покращеним кодовим пам'ятним керуванням.
Ця несправність
 була адресована
  покращеними кодовими перевірками, кодовими умовами.
Випадок зчитування поза межами пам'яті як несправність
 був адресований
  покращеним кодовим перевірянням меж.
Несправність у логіці кода
 була адресована
  покращенною кодовою валідацією.
Випадок записування поза межами пам'яті як несправність
 була адресована
  покращеною кодовою валідацією вхідних.
Декілька несправністей
 були адресовані
  покращеним кодом у логіці.
Випадок витоку інформації
 був адресований
  видаленням уразливого кода.
Ця несправність
 була адресована
  покращеними кодовими призначеннями.
Ця несправність
 була адресована
  покращеною кодовою середовищною очисткою.
Невалідний доступ як несправність
 був адресований
  покращеними кодовими обмеженнями доступу.

Деякі нагадують про розширення, наприклад. Some ones remind about extenstions, for example.


    клас ВалідаціяВхідних розширює Валідацію{/**/}
    class InputValidation extends Validation{/**/}

    клас СтановеПам'ятнеКерування розширює Пам'ятнеКерування{/**/}
    class StateMemoryHandling extends MemoryManagement{/**/}

Оновлення від 2021-10-17.

The update as of 2021-10-17.

Приватність над виставленням є дієвою особливістю для запобігання впливу активних тіньовиків і активних тіньовикинь в ПЗ. І включні особливості до неї блоковані деякою кількістю інших особливостей які у свою чергу іноді блоковані навіть дублікованими іншими принаймні у деяких системах. Так що ПЗ буде з впливом активних тіньовиків і активних тіньовикинь якийсь час щонайменш до якогось імовірного перемикачевого моменту.

Privacy over exposure is an actionable feature for prevention of the influence of the active shadowees in software. So the inclusion of other features for it is blocked by some other amount of some features which are in turn sometimes blocked even by duplicated else ones at least in some systems. So software will be with the influence of active shadowees for some time period at least until some probable triggeral moment.

Оновлення від 2021-10-19.

The update as of 2021-10-19.

І адже FaaS, SaaS, PaaS мають щось спільне як і віртуальні сервери як то оброблювачі, то тіньовикі і тіньовикині є впливом там особливо протягом знаходження і позбавлення недоліка для інших розташованих якщо було оголошення чи ні.

And as long as FaaS, SaaS, PaaS have something common to share as well as virtual servers then shadowees have an impact there, especially during trace and debug for hosted others if announced or not.

Оновлення від 2021-10-20.

The update as of 2021-10-20.

Таким чином той спільний елемент має бути дуже доведеним від зламів інакше усі так звані віртуальні розташуванці вразливі.

Therefore that common element should be pretty hack proofed otherwise all so called virtual tenants are vulnerable.

Оновлення від 2021-10-28.

The update as of 2021-10-28.

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

Тому http://thetechawesomeness.ideasmatter.info/internet-and-exinternet-and-internetless.html наприклад таке рішення досі краще ніж його відсутність.

Інакше це наприклад майже нескінченні цикли чогось на зразок як цитата Випадок зчитування поза межами пам'яті як несправність був адресований покращеним кодовим перевірянням меж.

No programming language among those I found is providing the amount of all mistakes in some code there, otherwise it is a sandboxed one.

That is why for example such http://thetechawesomeness.ideasmatter.info/internet-and-exinternet-and-internetless.html solution is still better than its absence.

Otherwise it is for example almost unlimited cycles of something for example as a quote A use after free issue was addressed with improved code memory management.

Оновлення від 2021-11-07.

The update as of 2021-11-07.

https://dzone.com/articles/from-java-microservices-to-lambda-functions-a-jour.

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

Data mirgations are helpful solely against hackers or solely against shadowees after the next migration point provides hackproof corresponding features or shadowee proof corresponding features instead of similar promises about such features and alike.

Оновлення від 2022-01-11.

The update as of 2022-01-11.

Деякі ППІ клієнти мають внутрішнє обмеження до кількості вхідних запитів, яке змінне з налаштовуємими кодами помилок. У інших більш стандартизованих ніж такі клієнти наприклад до протоколу такого як ГТТП, присутні коди помилок які незмінні.

Документовані обидва чи ні але які схожі за цією особливістю до http://thetechawesomeness.ideasmatter.info/internet-and-exinternet-and-internetless.html від 2020-12-21. Які є здатними і нездатними до пошуку згідно тієї ознаки щодо такого коду помилки. Згідно пошуку схожим як і у http://thetechawesomeness.ideasmatter.info/gravitron.html та у http://thetechawesomeness.ideasmatter.info/dry-and-wet-and-null.html.

Some API clients have internal limit on amount of such external requests, which is changeable with configurable codes of mistakes. In other more standardized clients than such ones for example with to HTTP as a protocol, there are codes of mistakes which are not changeable.

Whether they are documented or not both ones are similar by this feature to http://thetechawesomeness.ideasmatter.info/internet-and-exinternet-and-internetless.html as of 2020-12-21. Which are searchable and not searchable according to that feature for such mistake code. For search as well as in http://thetechawesomeness.ideasmatter.info/gravitron.html and in http://thetechawesomeness.ideasmatter.info/dry-and-wet-and-null.html.

Оновлення від 2022-01-20.

The update as of 2022-01-20.

Випадок записування поза межами пам'яті як несправність також може бути адресованим передобчисленням хоча коштом додаткового проміжку часу для такого обчислення однак досі у межах самого іншого обчислення, але є 2 випадки з одним коли обсяг буферу чи стосу чи іншої пам'яті невідомий наприклад приватний чи прихований та іншим коли такий обсяг гнучко змінюємий тобто нестатичний навіть у межах 1 байт менше ніж сам обсяг для самих об'єктів перетворюючи такі передобчислення на непотріб у цьому випадку з за його невикористуваємості тоді. Якщо той вміст об'єктноподібний інакше НОП якщо він не примитивний наприклад.

An out-of-bounds write can be addressed also with precalculation eventhough in cost of additional period of time for such precalulation though being in scope of other calculation, but there 2 cases with one when size of buffer or size of stack or size of other writable piece is unknown for example private or hidden and other one when such size is flexibly changeable as non static even in scope of 1 byte less than the size of for objects themselves turning such precalculation into junk in such case due to its non usabitity then. If that content is object like else NOP unless they are primitives for example.

Оновлення від 2022-03-04.

The update as of 2022-03-04.

Для веб послуг і інших які з функцією входа і вихода щодо приватності даних ПІСЛЯ закриття а саме

For web services and others which are with log in and log out functionality per privacy of user data after closure of


                                     per; до                   за замовчанням вимкнено чи ввімкнено
                                                               enabled or disabled by default

    keep logged in;remember me       web site;web service
    which does not involve browsing  веб сайта;веб послуги
    history removal;котре не         веб місця;веб сервіса
    включає вилучення історії
    з ППіНТВСуІ
                                     
        in settings;
        у налаштуваннях

            per cookie;
            реп'яшком

            per token;
            тоукєном

    private window;private tab
    приватне вікно;приватна вкладка  web browser; ППіНТВСуІ
    which involves browsing
    history removal;котре
    включає вилучення історії з 
    ППіНТВСуІ

http://thetechawesomeness.ideasmatter.info/table-chapters.html;24.

http://thetechawesomeness.ideasmatter.info/table-chapters.html;1.

Оновлення від 2022-04-27.

The update as of 2022-04-27.

Так званий білошляпочний хакінг тобто white hat з не завжди видимими але принаймні іноді публікованими наслідками частково компенсує так звану чорношапочну частіше невидиму ніж видиму чорношапочну розробку тобто black hat. Але це не надає причин для цих явищ чорношапочних розробок. Це створює частково додатковий тягар для перегляду і не лише коду з його наявної кількості і тих можливостей перегляду і не лише того коду принаймні у відкритокодових і якщо це помітно у відкритокодових у закритокодових і змішаних це й додатково сховано тобто не помітно. Звичайно якщо вважати таку чорношапочну розробку сумішшю як одного з типа зусиль хакінгу так і як у межах не зусиль хакінгу.

Майже кожній відомо що у


                                     ← отримання зусуль хакінга
    запуск        → її виконання 
    якоїсь                           ← отримання запитів
    віртуальної
    системи
    ____
    мені невідомо як це зветься 
    наприклад щодо замість запитів або замість зусиль хакінгу
    у не веб додатках і у не веб застосунках 
    а для інших включно з мобільних і Dapps.

а якщо комусь невідомо то тоді це додатково один раз доводить перевагу тих хто програмує над тими хто не програмує щодо чого вже було публіковано цими веб сторінками одного разу. Принаймні як навички навіть якщо це лише щодо навички щобо переміщення віртуального робота у 1 напрямок у відповідній існуючій мові програмування. Тобто це доступно майже кожній але неперевірено чи є у тій мові програмування невізуальна частина тобто така що є невидима а наприклад озвучена наприклад для озвучки результатів того програмування. Хоча така перспектива і створює деяке ділення. Але вона і присутня тривалий проміжок часу десь з 2009-2017 однак і необов'язкова але вона демонструє достатньо швидко деякі особливості принаймні якогось типа програмування.

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

Тоді зусилля хакінгу щодо такого елементу якоїсь віртуальної системи дуже ймовірно означити як все те що не увійшло до типового циклу розробки включно з дизайном і архітектурою включаючи і таких її залежностей але з можливим впливом з непередбаченими наслідками для такої віртуальної системи.

Оновлення від 2023-01-04.

The update as of 2023-01-04.

Нарешті знайшов цю ситуацію але не те щоб втрачав її. Достатньо складна для мене. На межі приватності чи у межах приватності на диво. Технічно не вирішу а описово так у цьому оновленні звітово. Тож один обчислювач почав бути невідповідаючим з/після 2023-01-01 як то not responsive. Як зазвичай. Значок завантаження і екран без змін. Зазвичай він виходив із цього становища сам по собі через 1-5 хвилин 2023-01-01 і 2023-01-02. Але не з 2023-01-03. Але у даному випадку ні. Більше ніж одну добу. Тож була лише кава для мене поки очікував. Легким рішенням було б повторно запустити але проблема у тому що це протиріччя з http://thetechawesomeness.ideasmatter.info/issues.html там у тій веб сторінці де описано про біткоїн про причину цього. Тож очікуючи більше однієї доби щодо цього була лише кава для мене. Адже цей обчислювач з такої групи обчислювачів яка можлива до розрядження я вирішив після десь доби розрядити обчислювач щоб уминути такої проміжної ситуації. Це не допомогло. Нагадаю про існування обчислювачів для яких розрядження і повторний запуск після початку зарядки міг би допомогти. Тобто restart only обчислювачі як група. Можливо він тобто саме цей обчислювач зламався. Maybe so but not today. Адже залишився лише повторний запуск як опція/варіант. Висновок: ПЗ мало; з цієї ситуації має й ймовірно матиме помилки. Але не цю. Тому що залишився повторний запуск як варіант для рішення. А наразі про складну частину. І він допоміг. Тобто повторний запуск. Як можливо ви це помітили припустивши й успішно з цього оновлення. Живого оновлення у цьому випадку. Але що складного так це у цьому рідкому випадку допомогло би і припинення постачання електроенергії тобто blackout. Тобто у повторного запуска теж є типи якщо щодо цих принаймні 2 причин. Ручний і з за того припинення тобто з за blackout. Це було першою складною частиною для мене в цьому дослідженні. Друга така як наступно. Як вам відомо і ймовірно то ПЗ буває різних типів як то закритокодово і так далі. Навіть з цих веб сторінок. Цей обчислювач невідомо щодо якої частини але ймовірно з закритокодової тому що він не оголошує про це. Як теж відомо і про таке навіть, вам можливо, з цих веб сторінок в закритокодовому є 2 типи для повідомлення про помилки а саме закрите і в ньому повідомлено про це як у Windows у Microsoft і як в macos у Apple і відкрито/закрите тобто сумішю як для Androida у Google. Достатньо ймовірно в деяких з них. У відкрито/закритому типі є для заповнення Last steps чи щось подібне, але не в цьому випадку тому що моя кавова залежність і деякий обсяг навантаження протягом 2022-2023 тоді. Не завжди але дуже часто густо. Це одна підчастина другої складної частини. А друга це подібне вони а саме купа деталів в закритокодових стилях про таке показується але нередагуєма тобто не змінюєма або not editable як знову ж наприклад в стилі Android/Google. Якщо там присутнє а тож опціональне. Це і є рішення. Описове однак і без назви йому. Висновок: якщо б я повторно запустив одразу я би зберіг але 1. не було б цього живого оновлення й звітово. 2. не було б цих кроків для цієї віртуальної стежки для цього. А тож також такі висновки: 1. Це є і ще однією додатковою причиною для http://thetechawesomeness.ideasmatter.info/issues.html про те чому не запускати повторно. Принаймні невідомо коли не запускати повторно. 2. Підтвердження малому за обсягом але місцю для ідеї We do not coop. Тобто спрощено для not coop тобто не кооп. Навіть у цих межах. Існують прекрасні видимі записи цьому але кому це цікаво якщо на них лише темний екран зі значком завантаження. До речі, в Україні я знайшов закон на додачу до GDPR якщо вони застосовуються до даних у цьому випадку і який починається з Порядок.. і теж про захист даних якщо він застосовується до даних у цьому випадку.

Настільки достатньо складне це оновлення було для мене так що мушу додати його до інших оновлень про ПУРЛ цими веб сторінками. Пост скриптум. Були помітні два коментаря для цієї ситуації. 1. Не чіпати. Але це повністю виключає купу рішень у http://thetechawesomeness.ideasmatter.info/hypothetical-cat-to-computer-interface.html. 2. Так звано упав. Це повністю не відповідно і не точно для цієї ситуації. Тому що навіть у жорстких межах за відсутністю інших варіантів/опцій це був і планований повторний запуск. А також частково про забуття ситуації blackout.