<bgdev />free

| |  


All tags 2023 9may ai algorithm alpha amd american api argon2 arm asm asmbb assembler attachment awareness balgaria bay888 bcrypt bender beta bgdev-next bgdev-next.👍 big.data bitchnigga bitcoin bmw boi borg brexit bug bulgaria business c cad chat cloud computer-names console crossorigin deprivation desktop dna dotnet email eupl falling feature forum foundation fp fresh fun game github goats google gpl gpt gpt.3.5 gypsies happiness harvard hash improvement include investment it java javascript js kleta kleta.maqka.balg lambi language learning leftovers legend level levenshtein.dist libx license linkedlist linux ma mcafee mele microsoft minimag minimalism negro net nginx nigga not.a.bug oop paradigm parler patterns perception persuasion pipe play.station politics populi pornhub pow pro programming protonmail python reba rust sci-fi scripting seks seo server shell sleep smartbeauty soft-skills sqlite srabska sse starship sugerface syntax tablet tailwindcss telegram theme thug troll80lvl tutanota typescript uacme ui uk unix untermensch upload uptime usa utilities ux vb via viber virtual.reality vox vps vulnerable war wasm weapons-grade web windows word x86 xbox xss youtube zig ziglang Übermensch БОКЕБЪЛГАРИН БЪ БЪлгария Белезниците Били Били.Белезниците БялДонор Веган Виста Възраждане ГЛУПАК Гана Глиста ЕС Казарма Копейкин Мода.и.овча.мисъ НЕКАДЪРНИК НРБ ПО-ЗЛЕ.И.ОТ.РАБИ Подкасти Разни Румен СИК СКУМ СетенЧук Скум ТИР Туче Украйна Урсула Яначков авангард аз айфонджия алгоритми амбиции анархизъм антиваксъри армения аудио аутисти бази.данни бакъп без без.пръчове безпросвета бенчмарк биготи биомаса бира боклук борисов ботев брадва булшит бъг бъгове бял ваксина вандал век венерика викинги вицове вишу война вървежен гана ганорник гей гейщина германия герои гешев глупак говеда групировка гюбек данъкоплатец двойни.стандарти дедотия демокрация дизайн дисциплина добитък докери долар донори држава дришльо дрон ебане еврогейски.съюз езици експеримент електроника електроника.s2 емиграция ендпойнт енум ерген ергономия жалкар задача затоплизъм защита здраве златен злато игри идеали идиократ идиократи идиокрация идиот избори избори.рабин изкуство икономика имбецили имейл инвестиране инокулация инструмента интервю ипад искам.да.си.реда казах камшикодържач капитализъм карабах караница картечница кино клавиатура ковид19 колайдер колям.кур комари комплексар комунизъм консолидация конспирации космонавтика кофа кофит-19 краставица криптовалути курви кучелюбци лайно лаладжия лаптоп либерастия литература лоши.практики луд лъжеучени лъжец любов майни майтапи малоумници мафия мениджмънт месо местене метавселена метафизика механика мистика мисъл мода мода.овча.мисъл модерация морал мутра мутри наука национализъм не.it негър некадърник некадърници неон нидерландия овча овчи олигофрени организация офтопик парички партия педал пенджури пенсия пишока плюскане победа погромист поезия политика порно посредствен почивка празници прасе превод предалщина програмиране проект проста простотии против.правилата проф пръч пръч.дришльо пръчка психика психични.болести психология пустиняк путин путката путьо рабин рабин.е.шибан.пе работа радост разврат разни разработка расизъм резерват рейтинг реклама рекламен религия рест ризи ропче ропчета русия руски.език рутина самоковска сасипаха секира село селяндур сериали сериозно.програм сетен сеянин симулация скопяване скръм слушалки сортиране софия софтуер софтуни социализъм спектрометър спринтове сране стандарти стил стуйо стюи сушилня сцена съвет съм сън сървър сърничка таб ташаци телевизия тема територията терминология термояд технологии титли традиция тролинг тръмп туба туче тъпак тъпанари тъпня уиндоус украйна умнокрасивци фалит фантастика фашизъм фейк.акаунти физика филми форум форумни.проекти футбол хазарт хамали харабия хардуер хахаха хомофобия хостинг храна хумор цайко цайси целофан цензура цензурра циганин чалга чалгар чекии чернокраки честота чипове чнг чужбина чук шпация щайга юан яката яко ям 🔨 😂 🪓


ASM future

  

0 1 2 3 4 5 6 7 8


  stewie  Създадено на 28.07.2020, видяно: 2309 пъти. #1247
Courvoisier
stewie

Какъв е смисълът на цялото това напрежение? Винаги да си в топ форма за интервю? В последните 2 години уча нещо ново само ако ама много ми се налага.

Да! Аз съм негър с мнение, карам се на шефовете. Ще ги ева и геевете, като ги мързи да четат нови аналогии и искат некви имплементации от преди 20 години, ще ги унижавам пред всички. Ако се уважаваме взаимно нема проблем, но повечето ме гледат като негър и аз се кефя да им давам газ.

Хмм. Хайпаджия ли си? Увличаш ли се като излезе нещо ново веднага да го бутнеш във фирмените проекти, не защото е по-добро, а за да си трупаш цв-то?



  Courvoisier  Създадено на 28.07.2020, видяно: 2466 пъти. #1248

Любими теми са ми неразбирането на микросървиси и асинхронна комуникация, неразбирането на agile, глупваите time estimates базирани на story point-ове, както и като почнем да усложняваме, щото сме баси кодерите, което е против идеята за микросървиси. Още по- яко е като кажат тая технология я ползвах преди 10 години и е супер. То и аз преди 10 години пишех на jquery, обаче вече не го ползвам.



  stewie  Последно редактирано на 28.07.2020 от stewie, видяно: 2307 пъти. #1250
Courvoisier

Любими теми са ми неразбирането на микросървиси и асинхронна комуникация, неразбирането на agile, глупваите time estimates базирани на story point-ове, както и като почнем да усложняваме, щото сме баси кодерите, което е против идеята за микросървиси. Още по- яко е като кажат тая технология я ползвах преди 10 години и е супер. То и аз преди 10 години пишех на jquery, обаче вече не го ползвам.

Микросървисите могат да са голямо зло. Особенно когато един такъв трябва да джойне огромни данни от два други, всички използващи различни бази. Ти да видиш как като не се домислят нещата как се репликира част от едната база на единия сървис в базата на другия. Лайна с царевица! Имай впредвид, че много ползват микросървиси без да има нужда. Просто така е модерно.



  Golden Gega  Създадено на 28.07.2020, видяно: 2460 пъти. #1251

Аз досега не съм виждал приложен смислен аджайл, поради естествената причина че никой (от тези които трябва да го разбират) не го разбира



  Courvoisier  Създадено на 28.07.2020, видяно: 2457 пъти. #1252

Ажура от ден на ден се променя. Онзи ден ми писаха некви, Хайпърнещо си, правили неща с Azure Log Analytics. Викам им, по принцип го ровя от година и нещо, обаче сега не ми се рискува с вас.

Имах два свестни шефа. Единия се казваше Ивелин. Другия е македонец :D Всички останали не са пипали код от 10 години и само на теория, на практика не. Толкова хайп чак не съм, допреди година не използвах netcore в production. Но сега 3.1 е достатъчно ОК, последните няколко месеца пуснах 10-на сървиса с netcore. До преди 2 години пишех все още WCF :) Просто не се кефя като ми се мрънка против нъгет сървъра и как е било по- яко да си инклуудвам dll-и без никъв вършънинг, щото, why not, едно време работело. Или да ме карат да инсталирам access database engine, щото едно време го правили така. Едно време почнах .net-а на mvc 2, но сега не бих го ползвал.

Особено зле виждам от фирма на фирма как не разбират домейна, сегрегацията на домейна на поддомейни и прочее, а разделят функциите на микросървисите по усет и благозвучие и после като трябва да имплементирам сага става ебахти приключението и си проличава колко недодялана е била първоначалната идея.



  Courvoisier  Последно редактирано на 28.07.2020 от Courvoisier, видяно: 2455 пъти. #1254
stewie

Микросървисите могат да са голямо зло. Особенно когато един такъв трябва да джойне огромни данни от два други, всички използващи различни бази. Ти да видиш как като не се домислят нещата как се репликира част от едната база на единия сървис в базата на другия. Лайна с царевица! Имай впредвид, че много ползват микросървиси без да има нужда. Просто така е модерно.

Ако данните не трябва да са ми баш real time и са много, мога да си ги джойнвам предварително в Reddis или Mongo и по- скоро ще направя така. Това е именно лош дизайн. Трябва да се мисли именно кое от какъв поддомейн е и това е точно тънкото в микросървисите. Ако го правиш agile, за момента ще имаш правилен отговор, но това може и да не е правилен отговор след време и трябва да не те е страх да поправиш идеята.

То си трябва и gateway отпред, да джойнва заявки.



  Courvoisier  Създадено на 28.07.2020, видяно: 2454 пъти. #1255
Golden Gega

Аз досега не съм виждал приложен смислен аджайл, поради естествената причина че никой (от тези които трябва да го разбират) не го разбира

Аз съм виждал, но не в бг фирми. На ниво мениджмънт и организация сме прословуто зле. Има единици, но като цяло редовно е бай иван копа с лопатата, а 10 човека му дават акъл и всеки акъл инвалидира другия акъл.



  Courvoisier  Създадено на 28.07.2020, видяно: 2451 пъти. #1256
Golden Gega

Аз досега не съм виждал приложен смислен аджайл, поради естествената причина че никой (от тези които трябва да го разбират) не го разбира

Любим момент ми е сутрин да дейлито да стоим 1 час и да си говорим глупости. Виждал съм го в 3 фирми :D



  stewie  Създадено на 28.07.2020, видяно: 2307 пъти. #1257
Courvoisier
stewie

Микросървисите могат да са голямо зло. Особенно когато един такъв трябва да джойне огромни данни от два други, всички използващи различни бази. Ти да видиш как като не се домислят нещата как се репликира част от едната база на единия сървис в базата на другия. Лайна с царевица! Имай впредвид, че много ползват микросървиси без да има нужда. Просто така е модерно.

Ако данните не трябва да са ми баш real time и са много, мога да си ги джойнвам предварително в Reddis или Mongo и по- скоро ще направя така. Това е именно лош дизайн. Трябва да се мисли именно кое от какъв поддомейн е и това е точно тънкото в микросървисите. Ако го правиш agile, за момента ще имаш правилен отговор, но това може и да не е правилен отговор след време и трябва да не те е страх да поправиш идеята.

Малко теоретично се изказа. След 5 години работа с монго осъзнах следното - е не може преджойнеш всичко. Да не говорим, че трябваше да се пише домейн ивент дривън сървиси, които ъпдейтват преджойнатите данни на база оплога на монго. На 3 терабайта продъкшън база това не е хич евтина работа.А иначе много ме кефи некви бастуни, като имат х апита с една база и споделен общ модел как казват, че били ползвали микросървиси.



  stewie  Създадено на 28.07.2020, видяно: 2307 пъти. #1258
Courvoisier
Golden Gega

Аз досега не съм виждал приложен смислен аджайл, поради естествената причина че никой (от тези които трябва да го разбират) не го разбира

Любим момент ми е сутрин да дейлито да стоим 1 час и да си говорим глупости. Виждал съм го в 3 фирми :D

Затова бачкаш ремоут със слушалки на такива срещи. В една слушаш "Тъпак" в другата 2pac. Меринджея ми нещл сипваше днед на срещата, а аз поклащам глава на 2pac - No More Pain.



  Golden Gega  Последно редактирано на 28.07.2020 от Golden Gega, видяно: 2448 пъти. #1259
stewie
Courvoisier
stewie

Микросървисите могат да са голямо зло. Особенно когато един такъв трябва да джойне огромни данни от два други, всички използващи различни бази. Ти да видиш как като не се домислят нещата как се репликира част от едната база на единия сървис в базата на другия. Лайна с царевица! Имай впредвид, че много ползват микросървиси без да има нужда. Просто така е модерно.

Ако данните не трябва да са ми баш real time и са много, мога да си ги джойнвам предварително в Reddis или Mongo и по- скоро ще направя така. Това е именно лош дизайн. Трябва да се мисли именно кое от какъв поддомейн е и това е точно тънкото в микросървисите. Ако го правиш agile, за момента ще имаш правилен отговор, но това може и да не е правилен отговор след време и трябва да не те е страх да поправиш идеята.

Малко теоретично се изказа. След 5 години работа с монго осъзнах следното - е не може преджойнеш всичко. Да не говорим, че трябваше да се пише домейн ивент дривън сървиси, които ъпдейтват преджойнатите данни на база оплога на монго. На 3 терабайта продъкшън база това не е хич евтина работа.А иначе много ме кефи некви бастуни, като имат х апита с една база и споделен общ модел как казват, че били ползвали микросървиси.

То интересното започва когато трябва да се посочи как микросървисната архитектура ще оптимизира нещо, да кажем като за по-просто скорост. Присъствал съм в интересни проекти в които всичко - архитектура, технологии, схеми и каквото се сетиш бяха на топ ниво. Следваше въпроса как това ще оправдае допълнителните ресурси, т.е. как ще вдигне производителноста като цяло. Беше трагикомично, много подобно на един по-стар форум.



  Courvoisier  Създадено на 28.07.2020, видяно: 2448 пъти. #1260
stewie

некви бастуни, като имат х апита с една база и споделен общ модел как казват, че били ползвали микросървиси.

Точно това съм виждал няколко пъти.

Да не говорим, че трябваше да се пише домейн ивент дривън сървиси

Да, основната идея на microservices, иначе влизаш във филма с HTTP Chaining, който сваля availability-то и вдигна Latency-то сериозно.

След 5 години работа с монго осъзнах следното - е не може преджойнеш всичко.

Именно, лош дизайн. Ловят комари с базуки и слонове с прашки. Имплементирания домейн не отговаря на желаният домейн и почват да се появяват дракони. Почваш да правиш неестествени неща и започваш да се питаш ко става.

Ако трябва да върнеш много данни през gateway, напълно е ок да ги сглобиш от няколко сървиса през queue, по възможност паралелно. Ако едните данни ти зависят от другите данни, то тогава може би след корекция на домейна ще стане по- леко. ОК е. Кофти е ако трябва да имплементираш сага и влизаш в дедлок, което е падението на всякаква абстракция.



  Courvoisier  Последно редактирано на 28.07.2020 от Courvoisier, видяно: 2445 пъти. #1261

Микросървисите са за нас и за организацията. Има намалена когнитивна сложност, някой по- лесно ще влезне в микросървиса и ще може да направи нещо в него. Имаме отделни компоненти, което правят нещо добре, без да се съобразяват с други неща и могат да следват собствена еволюция. Те могат да се пишат на различни езици, според случая, За скрейпър и текстообработка пих ползвал питон, просто има по- добри библиотеки от .net. Също така скалират по- добре и по- лесно от монолитите. Скалират и по- точно от монолитите. Ако имам 100 use-case-а от 3 поддомейна в един монолит, от които 1 поддомейн се използва в 80% от заявките, скалирам ли, ще скалирам всичко. Ако е на микросървиси, ще скалирам само поддомейна. Даже в Ажур това го приветствам и на ниво Web App/App Service, не само Kubernetes + Docker.

Обаче да имаш 100-200 сървиса означава, че трябва да имаш свястна документация на общата картинка, да имаш и добри архитекти. Трябва да се мисли, не става само с кодене.

Също така е естествено. Когато имате голям проблем за решаване го разделяте на малки под-проблеми. И микросървисите така.



  stewie  Последно редактирано на 28.07.2020 от stewie, видяно: 2307 пъти. #1264
Golden Gega
stewie
Courvoisier
stewie

Микросървисите могат да са голямо зло. Особенно когато един такъв трябва да джойне огромни данни от два други, всички използващи различни бази. Ти да видиш как като не се домислят нещата как се репликира част от едната база на единия сървис в базата на другия. Лайна с царевица! Имай впредвид, че много ползват микросървиси без да има нужда. Просто така е модерно.

Ако данните не трябва да са ми баш real time и са много, мога да си ги джойнвам предварително в Reddis или Mongo и по- скоро ще направя така. Това е именно лош дизайн. Трябва да се мисли именно кое от какъв поддомейн е и това е точно тънкото в микросървисите. Ако го правиш agile, за момента ще имаш правилен отговор, но това може и да не е правилен отговор след време и трябва да не те е страх да поправиш идеята.

Малко теоретично се изказа. След 5 години работа с монго осъзнах следното - е не може преджойнеш всичко. Да не говорим, че трябваше да се пише домейн ивент дривън сървиси, които ъпдейтват преджойнатите данни на база оплога на монго. На 3 терабайта продъкшън база това не е хич евтина работа.А иначе много ме кефи некви бастуни, като имат х апита с една база и споделен общ модел как казват, че били ползвали микросървиси.

То интересното започва когато трябва да се посочи как микросървисната архитектура ще оптимизира нещо, да кажем като за по-просто скорост. Присъствал съм в интересни проекти в които всичко - архитектура, технологии, схеми и каквото се сетиш бяха на топ ниво. Следваше въпроса как това ще оправдае допълнителните ресурси, т.е. как ще вдигне производителноста като цяло. Беше трагикомично, много подобно на един по-стар форум.

Хахаха, точно! Само, че нашите архитекти никой не им поиска сметка (май само аз и още двама колеги), защо беше нужно 2 годишно преминаване и пренаписване на целият монолитен блок с множество апита, сплитване на десетки бази, после докери, ама после ай заеби докерите, дай кюбернетис, ама дай да е ранчър, ама ей кво си. Ама енджиайенекса ми не форуардва хедърите на уя ми, ама тоя контейнер не може се въже към базата заради еди какъв си проблем с айпитата и т.н и т.н. И накрая същият перформънс хуй както като си бяхме качили всичките апита на две ИИС-та зад лоад балансър. Отговорът на защо всичко това беше, че като са ни сплитнати базите, много по-лесно можем да ги бекъпваме и репликираме. Ми хубо бате, ама сме над 30 програмиста, контрактори, папкаме повече от негър в балканско ЕООД. За тея години това са милиони долари. Всичко се прави с една единствена цел - мангизи и нищо друго. Ако може сайт за лютеница с микросървиси - давайте смело.



  Courvoisier  Последно редактирано на 28.07.2020 от Courvoisier, видяно: 2437 пъти. #1265
stewie

Ако може сайт за лютеница с микросървиси - давайте смело.

Сайт за лютеница на Сайткор :) Доволно скъпо! Джаварите имат ли сайткор? :D Нямат!

Хардуерът е евтин. Ние и лицензите са по- скъпи.



  stewie  Последно редактирано на 28.07.2020 от stewie, видяно: 2307 пъти. #1266

Явно вие четете много, аз съм затъпял от писане на джабаскрипт, репортинг агрегации за монго, или поредните поправки на множество разцепени бази през драйвера му за .нет. Та попадна ми следното вчера. "Архитектът" почна да ми мрънка как сега имало Channels в .нет патладжан. Въпреки, че е с по-малко опит и от мен в .нета, ходи там на конференции, лектор е, снимки с микрофони в слака, а-у. А аз чета 9гаг, щот съм тъпо мързеливо копеле като един друг форумен администратор.

Тоя е надъхан повече и от рабиняк върху затлъстяла домакиня. Вика ползвай го. Викам ко да еба е туй, той producer/consumer.

Задава се въпроса запознат ли съм с какво е producer/consumer !!! Нали щотото проблема на много четящите е, че те знаят всичко, а другите сме прости рая. Викам да уе, кензъл и гребъл патърна. Единият сере, другия гребе. И на място, което плаче за прост foreach и много далеч от нужда на употреба на Dataflow (TPL) той просто иска да го набутаме, нали защото е ново.

Надявам се да ме разбираш сега защо не съм фен на всичко ново и на хайпъджиите. Хайпъджиите са като нарко босовете - те няма да се спрът пред нищо, важното е да са номер 1 и егото да расте. Дразнят много, но : удължават с години проекта (повече пари присвоявате) и научаваш най-новите неща докато гледаш мемета :)



  Golden Gega  Създадено на 28.07.2020, видяно: 2434 пъти. #1267

Ако за простота се ограничим само в проектирането на даден продукт, има две генерални цели - едната е да се постигне нужната функционалност (за простота слагам тук и гъвкавост, т.е. възможност за склаиране), другата е цената за постигане на първата цел.

Естествено, от едната страна са технологичните гурута, които ще си отхапят и чурките само и само проекта да се прави с най-най-най ама наистина най-най-най правилната технология/платформа/... От другата са момците с пачките които се интересуват от две неща - нещото да стане в срок и разходите да са най-малки. По средата е така наречения архитект който трябва да поеме ритниците и от едната, и от другата страна.

И тук започва интересната част - обикновено дадена технология е създадена да реши даден проблем... но за сметка на друг такъв. Типичен пример са микросървисите - те привидно решават едни проблеми, като обаче решително създават други. И тук започва голямата мъка - да се преценят плюсовете и минусите, да се вземе правилното (оптимално) решение и ... битката е спечелена наполовина, защото остава да се убедят двете пасмини че то е оптимално. И това не е краят, защото трябва да ги убедиш че е оптимално за целия срок на проектиране/изработка/експлоатация на решението.

Като се заговорихме за микросървисите - това си е за отделна тема. Най-малкото защото с плюсовете си те имат и много съществени недостатъци, и когато се реши да се ползват трябва да се прави баланс с плюсовете и минусите не само в проектирането и изработката, ами и в QA фазата, скалирането, експлоатацията, интеграцията с други системи и т.н. и т.н. И освен това този баланс трябва да включва спецификите на приложението, качествата на екипа, срокове, БА анализа...

Въобще проектирането е една доста тегава и неблагодарна професия, с доста мистика и с много повече здрав (ама необясним за околните) разум.



  Courvoisier  Създадено на 28.07.2020, видяно: 2431 пъти. #1269

Това за проектирането е много вярно. Те затова и вземат заплати. Много е важно да знаеш какво може да си позволиш. На ниво 1-2 да правят нещо, 3-4 да се опитват и 10 да са там за красота е по- лесно с микросървиси. Джуниъра като види 20 класа и вика не е сложно, има желание. Като види 2000 класа и вика What Da Fuck, защо са толкова и какви са тези всичките интерфейси и защо има не знам си какво. Аз лично намирам когнитивната комплексност за много важна и като имам време на работа по някой малко забозен проект, почвам да раздробявам методите на такива между 5 и 15 реда, според зависи. Те джуниърите се стряскат и да многото проекти, защото не са свикнали да боравят с абстракция. Имам ключове, ок, 10 ключа. Този отключва входната, този колата, този избата, този е за пощата, онзи е за къщата на нашите. Всеки ключ си върши работата, нямам един универсален ключ за всичките ми врати. По- естествено е. По- ниска когнитивна комплекстност. Нетрениран човек може да държи между 5 и 9 единици информация едновременно в кеш, magic number 7. С тренинг стават и повече. На момента, като го пиша, мога да ти кажа с точност какво прави всеки един ред код от 6-те ми сървиса, които писах 3 месеца паралелно. След още 6 месеца, обаче няма да си спомням. Но ако са loose coupled, ще влезна в единия, ще видя, ако е с ниска комплексност, по- бързо ще разбера какво става. Имам добра памет, но забравям. Тук микросървисите са добри, раздробяват проблема. И скейлват много по- лесно, особено с докер и кюбернетис е детска игра. За мен това е достатъчно полезно, ако fit-ва на бизнеса. По- естествено е за дистрибутирани системи. Разделение на труда. Аз съм зидаромазач, съседът отсреща е лекар, под мен съседа прави шпакловки и бани, домоуправителят е електротехник, другият домоуправител ОВК, разбираме се целия блок. Всеки допринася с каквото може. Ние сме един вид микросървиси в тази конкретна абстракция, макар да правим и други неща.



  stewie  Създадено на 28.07.2020, видяно: 2307 пъти. #1270

И като трябва всички комшии да се обедините дружно и да си платите асансьорната такса и става греда :)



  Courvoisier  Създадено на 28.07.2020, видяно: 2427 пъти. #1272
stewie

И като трябва всички комшии да се обедините дружно и да си платите асансьорната такса и става греда :)

Плащаме, даже през една стара щайга контролираме тези, които не плащат асансьор и им изключваме чиповете :D Изградили сме комунизма.

Плуралсайта не е хайп, има много интересни неща. Сега гледам:

Useful Cryptography: An Introduction

In this talk, Randall Degges discusses useful cryptographic primitives and how to practically apply them in your development projects. You'll learn about hashing, HMACs, encryption, TLS, and more. You'll gain a strong foundational knowledge of cryptographic principles and an understanding of how to make use of various algorithms to secure your applications. You'll also know what to look out for when building secure applications and where to be careful during implementation.

Стана ми интересно от дискусията за сертификатите, TLS с ECC и т.н., преговарям и гледам нови неща.


0 1 2 3 4 5 6 7 8


ASM future

  



AsmBB v3.0 (check-in: 7544654b24928b93); SQLite v3.47.0 (check-in: 03a9703e27c44437);
©2016..2024 John Found; Licensed under EUPL; Powered by Assembly language Created with Fresh IDE