https://youtu.be/2PgjgTT27Os?t=1061
جدیدترین پیش نمایش از سیستم Async Io زیگ

با این خبر تیر دیگری به بازار غیر حوش زده شد
حالا ممکنه براتون سوال باشه که خب اینا چرا توی این بازار پرسود خب حجم تولیدو بیشتر کنن دیگه
۲ دلیل داره
۱. آدمای سامسونگ و هاینیکس و به طور کلی صنعت میدونن که این روند پایدار نمیمونه
۲. بازار رم یکی از ناپایدار ترین بازارا بین تمام قسمت های صنعت نیمه هادیه و بازیگراش پایداری رو ترجیح میدن و افزایش قیمت رم به اندازه کافی سودشون رو بالا میبره

این پایین سقوط های مختلف بازار DRAM رو مشاهده میکنید :

1. The First Major Crash (Mid-1980s)

Cause: In the early 1980s, many new players (especially Japanese companies) entered the market and invested heavily in fabrication plants (fabs). This led to massive overproduction.

Effect: A brutal price war ensued. Prices plummeted by up to 70%. Many U.S. manufacturers, including Intel, were driven out of the DRAM business entirely. The era of Japanese dominance began.

2. The Crisis of 1996-1998

Cause: A perfect storm of over-investment in new fabs (expecting endless Windows 95-driven PC demand) combined with the 1997 Asian Financial Crisis. Demand collapsed just as massive new supply came online.

Effect: DRAM prices fell by as much as 80%. This caused severe financial distress for almost all manufacturers. Samsung famously survived only by "counter-cyclical investment"—doubling down on production and R&D while others retrenched, a strategy that ultimately cemented its future dominance.

3. The Post-Dotcom Bust (2001-2002)

Cause: The collapse of the dot-com bubble led to a sharp reduction in IT spending. Servers and PC demand dried up, leaving DRAM makers with huge inventories.

Effect: Prices crashed again. The downturn was so severe that it led to major industry consolidation. For example, the Taiwanese DRAM industry was restructured, and the German company Infineon (later Qimonda) was severely weakened.

4. The Financial Crisis Collapse (2008-2009)

Cause: The global financial crisis caused a sudden stop in consumer and corporate electronics spending. PC shipments dropped sharply.

Effect: DRAM prices went into freefall. The DRAM spot price index dropped over 60% in a matter of months. This led to the bankruptcy of Qimonda (2009) and Elpida Memory of Japan eventually filing for bankruptcy in 2012 as a direct consequence of this period's debts and losses.

5. The 2011-2012 Downturn

Cause: Another case of overcapacity following investment in new technology (shift to 30nm processes) combined with weak PC demand and fallout from the 2011 Thailand floods, which disrupted the HDD supply chain and thus PC production.

Effect: Prices fell steadily throughout 2011, leading to significant losses for all players and the aforementioned bankruptcy of Elpida in early 2012. Elpida was later acquired by Micron.

The "New Stability" Era (Post-2013)

یه چیز جالب هم در مورد این بگم
توی یه بازه ای از ۱۹۸۰ تا حدود ۲۰۰۰
ژاپنیا از امریکاییا جلو میوفتن و بعد آمریکا با تعرفه و این ها صنعت نیمه هادی ژاپن رو میزنه زمین

البته خب این تنها دلیل شکست خوردن زاپن نبود و یه چیز دیگش هم اهمیت کمتر به پردازش داده بین شرکتای ژاپنی بود و از اونطرف امریکاییا رفتن به طرف پردازش داده و intel و amd و nvidia و ibm و ... رفتن اونطرف که همونطور که بالا مشاهده میکنید خیلیی بازار پایدار تری داره نسبت به DRAM

واقعا داستاان جذابی داره نیمه هادی ژاپن
https://www.youtube.com/watch?v=bwhU9goCiaI&pp=ygUfYXNpYW5vbWV0cnkgamFwYW4gc2VtaWNvbmR1Y3Rvcg%3D%3D
https://www.youtube.com/watch?v=0Av6aGG2vZY&pp=ygUfYXNpYW5vbWV0cnkgamFwYW4gc2VtaWNvbmR1Y3Rvcg%3D%3D
https://www.youtube.com/watch?v=ZOKBUI3p_cs&pp=ygUfYXNpYW5vbWV0cnkgamFwYW4gc2VtaWNvbmR1Y3Rvcg%3D%3D
https://www.youtube.com/watch?v=e7sH1dGsxpo&pp=ygUfYXNpYW5vbWV0cnkgamFwYW4gc2VtaWNvbmR1Y3Rvcg%3D%3D
بعلاوه این کانال آسیانومتری واقعا حقه

این مقاله هه حق بود :
https://deplet.ing/the-copilot-delusion/
واکنش پرایماجن بهش :
https://www.youtube.com/watch?v=-Q8c5vzYjfg

https://www.youtube.com/watch?v=mf0WzTOe-40
این داداشمون هم آدم جالبیه و پروژه جالبی داره

- هوش مصنوعی خیلی پیشرفت کرده.
+ آره ولی می‌خوام که <بخوام>.
#زندگی

🆔 @lifeAsAService

https://github.com/al13n321/nnd
یه دیباگر جالب که برای لینوکس تحت tui توسعه داده شده
رابط کاربریش خیلی مشتیه خواستید امتحان کنید
خودم میخوام ازش همین هفته استفاده بکنم ببینم چطوریه

https://graphite.art/
FOSS Photoshop/Illustrator Killer

اگه یه وقت به گذرتون خورد که میخواستید توی لیبره آفیس یه کدی رو رنگامیزی نحوی (syntax highlighting) کنید میتونید از افزونه زیر استفاده کنید :
https://extensions.libreoffice.org/en/extensions/show/code-highlighter

پدربزرگای RISCV

بلاخره خب هندیام انسانن 🥺
خسته میشن خب 😴

رنگین کمان از طبقه هفتم CE

زیبایی خالص

https://github.com/rohanrhu/gdb-frontend
پوسته جذاب و کارامدیه برای gdb
اگه نتونم zeditor رو برای مسخره بازی هایی که میخوام بکنم با دیباگر ها آماده بکنم از همین استفاده میکنم

خب در نهایت بعد کلی گردش بین کلی ابزار و تنظیمات مختلف به
gf2 : https://github.com/nakst/gf
رسیدیم و راضی شدیم

حالا شاید براتون سوال باشه که خب چرا اینهمه دارم میگردم دنبال دیباگر و خب دیباگر vscode یا zeditor هم هستشون و نیاز نیست و این حرفا
ولی خب ۲ تا نکته وجود داره و کاری که با دیباگر میخوام بکنم صرفا با یه gdb یا lldb ساده انجام پذیر نیست

چیزی که میخوام دیباگ کنم یه هلوورد ساده نیست که بتونیم با next و step دیباگش کنیم
تخمینی که دارم اینه که حدود ۵۰ میلیون دستور داره اجرا میشه و میخوام تحلیل کنم که این سامانه چرا داره به قهقرا میره و اخرش میترکه
در این وضعیت حتی اگه breakpoint هم بذاری و در هر مرحله بپری به بریکپوینت بعدی هم پاسخگو نیست و یا اینطوریه که کلا یه بار به اون میخوری یا ۱۰۰۰۰ بار به توقفگاه میخوری و خب متوجه نمیشی داری چه اتفاقی میوفته یا اینکه بینهایت طول میکشه و خسته میشی و باز هم به هدفت نمیرسی

اینجاست که یه ایده به سرم زد که یه سری توقفگاه داشته باشیم که اینا یه سری پرچم داشته باشن که با روشن خاموش شدن این پرچم ها بقیه توقفگاه هارو فعال و غیر فعال کنن

حالا سوالی که شاید داشته باشید اینه که چطوری میشه اینکارو کرد؟
و خب جوابش اینه که کل هرچیزی که gdb میتونه انجام بده روی یه درگاه pythonی قرار داره و از اونجا میتونی عملا هرکاری بکنی و حتی این توقفگاه های ویژه رو هم داشته باشی

ولی مشکلی که وجود داشت این بود که zed خیلی خوشحال نبود که من یه توقفگاه شخصی سازی شده درست کنم و استفاده کنم
همچنان روی کد حرکت میکرد و متوقف میشد و اینا ولی مشکلی که بود این بود که کلا console و ترمینال وجود خارجی نداشت
و خب اینطور شد که چیزای مختلفی رو نگاه کردم

در نهایت gf2 و gdb-frontend گزینه های مطلوبی بودن که همه کاری که میخواستم رو میکردن ولی gf2 با c گسترش پیدا میکنه و سبکتره ولی gdb-frontend با python و js گسترش پیدا میکنه و روی یه chromium سوار میشه (الکترونی نیست) و سنگین تره
پس درنهایت ماجرا gf2 رو انتخاب کردم برای این منظور

یه نکته دیگه هم که وجود داره اینه که ide ها برای اینکه دارن خیلی کار های مختلفی رو پوشش میدن مجبود میشن توی تخصیص کلید های میانبر یه سری مصالحه انجام بدن و خب معمولا کلیدای میانبر دیباگرا جاهای ناجوریه
ولی وقتی یه دیباگر اختصاصی داری دیگه این مشکل رو نداری + میتونی ابزارای خوبی هم برای نمایش داده برای خودت بسازی