Forwarded from Linuxor ?
Forwarded from Golden Code (@lix)
ظاهر فرم ها بطور پیشفرض سادست ولی یه سری مواقع نیازه کاستوم بشن. یک قابلیتی که css ارائه داده و خیلی مفیده accent-color هستش.
با این قابلیت میشه حتی اجزای فرم مثل check box یا radio button ها رو هم به زیبایی کاستوم کرد بصورت دیفالت تا با ظاهر سایت هماهنگ تر بشن👌🏾
#Css
#UI
@GoldenCodeir
(بهمنبع و مثالش دقت کنید 👇🏾)
https://x.com/csaba_kissi/status/1695692651188916575?t=QCxTPRVdbovbQJ-9Z8PD7w&s=35
با این قابلیت میشه حتی اجزای فرم مثل check box یا radio button ها رو هم به زیبایی کاستوم کرد بصورت دیفالت تا با ظاهر سایت هماهنگ تر بشن👌🏾
#Css
#UI
@GoldenCodeir
(بهمنبع و مثالش دقت کنید 👇🏾)
https://x.com/csaba_kissi/status/1695692651188916575?t=QCxTPRVdbovbQJ-9Z8PD7w&s=35
👏1
Forwarded from کانال مهرداد لینوکس (Mehrdad Linux)
🔥سیستم عامل kolibrios با حجم 1.44 MB 😎
✅ محیط گرافیکی کامل و ویرایشگرهای متنی، شبکه، بازی، مرورگر، رسانه ها و تعداد زیادی قابلیتهای مفید دیگه همگی در یک فلاپی 1.44 مگابایتی
🗓 مدت زمان بوت شدن این سیستم عامل پس از روش شدن سیستم تنها 4 ثانیه 😁
🗓 نیازی به نصب ندارد
⁉️ سخت افزار مورد نیاز : شما چی فکر میکنید 😎
سورس کد این سیستم عامل تحت لایسنس GPL-2.0 نوشته شده با C ,اسمبلی در این مسیر در دسترس است
اخرین نسخه ۴ ماه پیش منتشر شده
از اینجا دانلود کنید
💠 از ابزار های لینوکسی و ترمینال پشتیبانی میکنه؟
❤️ ممنون از حمایت هاتون 💐🌺
✅ محیط گرافیکی کامل و ویرایشگرهای متنی، شبکه، بازی، مرورگر، رسانه ها و تعداد زیادی قابلیتهای مفید دیگه همگی در یک فلاپی 1.44 مگابایتی
🗓 مدت زمان بوت شدن این سیستم عامل پس از روش شدن سیستم تنها 4 ثانیه 😁
🗓 نیازی به نصب ندارد
⁉️ سخت افزار مورد نیاز : شما چی فکر میکنید 😎
سورس کد این سیستم عامل تحت لایسنس GPL-2.0 نوشته شده با C ,اسمبلی در این مسیر در دسترس است
اخرین نسخه ۴ ماه پیش منتشر شده
از اینجا دانلود کنید
💠 از ابزار های لینوکسی و ترمینال پشتیبانی میکنه؟
دستورات unix بیس پشتیبانی میکنه مثل
alias, cd, clear, cp, mv, ren, date, echo, free,history, kill, ls, mkdir, more, ps, pwd, reboot, rm, rmdir, shutdown و ...
اگر دنبال یک لینوکس کوچیک هستید Tiny Core با حجم 12 مگ برای شما مناسب تره
❤️ ممنون از حمایت هاتون 💐🌺
Forwarded from a pessimistic researcher (Kc)
توی این الگوریتم اگر برای پیادهسازی T از queue استفاده کنید الگوریتم تون BFS میشه و اگر از stack استفاده کنید الگوریتم تون DFS میشه. احتمالا خیلی کار سختی نباشه که به این نکته برسیم که مرتبه زمانی این الگوریتم O(|E|+|V|) هستش. این قطعا خبر خوبیه چرا که ما تونستیم با reduce کردن مسئلهی Safety Verification به Invariant Verification و reduce کردن اون به Graph Reachability به یک الگوریتم Polynomial دست پیدا کنیم.
اما متأسفانه چنین نیست. تصور کنید که درون برنامهما ۱۰ Thread وجود دارن که هر کدوم یک آرایهی یک میلیونتایی از تایپ Boolean دارن. علاوه بر اون هر کدوم یک آرایهی ۱۰۰ تایی از تایپ Integer دارن. تعداد State های این برنامه برابرخواهد بود با :
((1000 ^2) * (2^32) ^100 ) ^10
حتی با وجود یک الگوریتم Polynomial پیمایش یک چنین فضای حالتی نیاز به سالهای زیادی اجرا داره و ما رو به این نتیجه میرسونه که مسئلهی Safety Verification به طور طبیعی یک مسئلهی Hard هستش.
خب حالا چیکار کنیم. بیخیالش بشیم یعنی؟
اما متأسفانه چنین نیست. تصور کنید که درون برنامهما ۱۰ Thread وجود دارن که هر کدوم یک آرایهی یک میلیونتایی از تایپ Boolean دارن. علاوه بر اون هر کدوم یک آرایهی ۱۰۰ تایی از تایپ Integer دارن. تعداد State های این برنامه برابرخواهد بود با :
((1000 ^2) * (2^32) ^100 ) ^10
حتی با وجود یک الگوریتم Polynomial پیمایش یک چنین فضای حالتی نیاز به سالهای زیادی اجرا داره و ما رو به این نتیجه میرسونه که مسئلهی Safety Verification به طور طبیعی یک مسئلهی Hard هستش.
خب حالا چیکار کنیم. بیخیالش بشیم یعنی؟
Forwarded from a pessimistic researcher (Kc)
"مسئلهی Reachability"
There is no any free lunch with polynomial Algorithms
—————————————
مسئله خیلی ساده است، تعدادی نود که با تعدادی یال بهم متصل شدند و پرسشی این چنین : آیا مسیری از نود A به نود B در این گراف وجود دارد یا خیر. حالا اصلا ما چه دخلی با این مسئله داریم. مسئلهی ما Safety Verification هستش. به قولی ما یک برنامه به اسم P داریم و میخوایم بررسی کنیم که هیچ اتفاق بدی داخلش رخ نمیده. اگر بخوایم کمی تکنیکال تر صحبت کنیم، در کنار P ما یک Invariant ای داریم به نام Q که یک predicate ای روی متغیرهایی هستش که داخل برنامه نوشته شده. مسئلهی Safety Verification میخواد بررسی کنه که رفتار سیستم در هیچ لحظهای منجر به نقض شدن این Invariant نمیشه. برای اینکه بتونیم بیشتر پیش بریم نیاز داریم که مفهوم فضای حالت رو تعریف کنیم. هر برنامهای که ما مینویسیم رو میشه بدین شکل بهش نگاه کرد که تمام متغیرهای داخل برنامه از یک مقدار اولیهای پر میشن و ما به این لحظه از برنامه میگیم state آغازین. بر اساس دستورات داخل برنامه مقادیر این متغیرها ممکنه تغییر کنن. هرگاه مقدار هر یک از متغیرها تغییر کرد ما از state ای که درش هستیم با یک Transition به یک State دیگر میریم. به عبارت بهتر هر State نمایانگر مقادیر متغیرهای درون برنامه و هر Transition بیانگر تغییر مقدار یکی از این متغیرهاست. حال فرض کنید که که تمام متغیرهای هایی که زبان برنامه نویسی مد نظر مون (بهطور خاص Guarded Command Language) بهمون اجازه میدن تعریف کنیم باید Type دار باشن و هر Type هم مقدار محدودی از مقادیر رو میتونه نمایش بده. مثلا Type اعداد صحیح یا Int میتونه ۳۲ بیتی باشه و ۲ به قوهی ۳۲ عدد رو میتونه نمایش بده. با وجود چنین فرضی، فضای حالت برنامهی ما محدود خواهد بود و میشه سیستم رو با یک Finite State Machine مدل کرد. در حقیقت این فضای حالت چیزی بیشتر از یک Graph از دید مسئلهی ما نخواهد بود. سوالی که پیش میاد اینه که ما چطور میتونیم از یک برنامه مثل P به فضای حالت یعنی
M(P)
برسیم. با داشتن Operational Semantics زبان برنامهنویسی میشه چنین فضای حالتی رو به شکل موثری محاسبه کرد.
حال به بحثی که در ابتدا باز کردیم برمیگردیم، مسئلهی Graph Reachability چه دخلی داره با Safety Verification ؟
همونطور که گفته شد، ما دنبال این هستیم که از State آغازین شروع کنیم که در حقیقت میشه یک Node در داخل گراف و ببینیم که آیا مسیری از این نود به به یکی از نودهای مجموعهی BAD وجود داره یا خیر. مجموعهی BAD در حقیقت State هایی هستند که Q رو Satisfy نمیکنند. تصور کنید که Invariant ما باشه Y=1 به این معنا که مقدار متغیر y برابر یک میباشد. تمام State هایی که در آن مقدار این متغیر مساوی ۱ نیست میشن عضو مجموعهی BAD.
سوالی که ممکنه براتون به وجود بیاد اینه که مسئلهی Safety Verification همواره بحثش پیرامون Invariant نخواهد بود. از آنجایی که بحثش طولانی میشه بنده فقط خلاصه اشاره میکنم که با استفاده از مفهوم Monitor و ترکیب Parallel composition با M(P) میتونیم مسئلهی Safety Verification رو Reduce کنیم به Invariant Verification.
حالا تنها کاری که لازمه انجام بدیم اینه که نشون بدیم میتونیم مسئلهی Invariant Verification رو Reduce کنیم به Graph Reachability.
تصور کنید که نام مجموعهی حالت های آغازین سیستم I و نام مجموعهی حالتهای BAD برنامه T باشه. علاوه بر این دو عملگر POST و PRE نسبت به یک state مثل s بدین صورت تعریف بشن(مجموعهی E مجموعهی کل یالهاست) :
PRE(s) = { t | (t,s) \in E }
POST(s) = { t | (s,t) \in E}
حال به دو شکل میتونیم نشون بدیم که مسئلهی Safety Verification میتونه به Graph Reachability تقلیل پیدا کنه ( عملگر بستار * روی یک عملگر به معنی ترکیب بازگشتی گونهی عملگر نسبت به خود به ازای تعداد محدودی می باشد) :
Post*(I) intersect T = empty set
Pre*(T) intersect I = empty set
به reduction اول forward reachability و به reduction دوم backward reachability گفته میشه.
اگر بخوام برای reduction اولی یک الگوریتم بنویسم چیزی شبیه به این میشه :
There is no any free lunch with polynomial Algorithms
—————————————
مسئله خیلی ساده است، تعدادی نود که با تعدادی یال بهم متصل شدند و پرسشی این چنین : آیا مسیری از نود A به نود B در این گراف وجود دارد یا خیر. حالا اصلا ما چه دخلی با این مسئله داریم. مسئلهی ما Safety Verification هستش. به قولی ما یک برنامه به اسم P داریم و میخوایم بررسی کنیم که هیچ اتفاق بدی داخلش رخ نمیده. اگر بخوایم کمی تکنیکال تر صحبت کنیم، در کنار P ما یک Invariant ای داریم به نام Q که یک predicate ای روی متغیرهایی هستش که داخل برنامه نوشته شده. مسئلهی Safety Verification میخواد بررسی کنه که رفتار سیستم در هیچ لحظهای منجر به نقض شدن این Invariant نمیشه. برای اینکه بتونیم بیشتر پیش بریم نیاز داریم که مفهوم فضای حالت رو تعریف کنیم. هر برنامهای که ما مینویسیم رو میشه بدین شکل بهش نگاه کرد که تمام متغیرهای داخل برنامه از یک مقدار اولیهای پر میشن و ما به این لحظه از برنامه میگیم state آغازین. بر اساس دستورات داخل برنامه مقادیر این متغیرها ممکنه تغییر کنن. هرگاه مقدار هر یک از متغیرها تغییر کرد ما از state ای که درش هستیم با یک Transition به یک State دیگر میریم. به عبارت بهتر هر State نمایانگر مقادیر متغیرهای درون برنامه و هر Transition بیانگر تغییر مقدار یکی از این متغیرهاست. حال فرض کنید که که تمام متغیرهای هایی که زبان برنامه نویسی مد نظر مون (بهطور خاص Guarded Command Language) بهمون اجازه میدن تعریف کنیم باید Type دار باشن و هر Type هم مقدار محدودی از مقادیر رو میتونه نمایش بده. مثلا Type اعداد صحیح یا Int میتونه ۳۲ بیتی باشه و ۲ به قوهی ۳۲ عدد رو میتونه نمایش بده. با وجود چنین فرضی، فضای حالت برنامهی ما محدود خواهد بود و میشه سیستم رو با یک Finite State Machine مدل کرد. در حقیقت این فضای حالت چیزی بیشتر از یک Graph از دید مسئلهی ما نخواهد بود. سوالی که پیش میاد اینه که ما چطور میتونیم از یک برنامه مثل P به فضای حالت یعنی
M(P)
برسیم. با داشتن Operational Semantics زبان برنامهنویسی میشه چنین فضای حالتی رو به شکل موثری محاسبه کرد.
حال به بحثی که در ابتدا باز کردیم برمیگردیم، مسئلهی Graph Reachability چه دخلی داره با Safety Verification ؟
همونطور که گفته شد، ما دنبال این هستیم که از State آغازین شروع کنیم که در حقیقت میشه یک Node در داخل گراف و ببینیم که آیا مسیری از این نود به به یکی از نودهای مجموعهی BAD وجود داره یا خیر. مجموعهی BAD در حقیقت State هایی هستند که Q رو Satisfy نمیکنند. تصور کنید که Invariant ما باشه Y=1 به این معنا که مقدار متغیر y برابر یک میباشد. تمام State هایی که در آن مقدار این متغیر مساوی ۱ نیست میشن عضو مجموعهی BAD.
سوالی که ممکنه براتون به وجود بیاد اینه که مسئلهی Safety Verification همواره بحثش پیرامون Invariant نخواهد بود. از آنجایی که بحثش طولانی میشه بنده فقط خلاصه اشاره میکنم که با استفاده از مفهوم Monitor و ترکیب Parallel composition با M(P) میتونیم مسئلهی Safety Verification رو Reduce کنیم به Invariant Verification.
حالا تنها کاری که لازمه انجام بدیم اینه که نشون بدیم میتونیم مسئلهی Invariant Verification رو Reduce کنیم به Graph Reachability.
تصور کنید که نام مجموعهی حالت های آغازین سیستم I و نام مجموعهی حالتهای BAD برنامه T باشه. علاوه بر این دو عملگر POST و PRE نسبت به یک state مثل s بدین صورت تعریف بشن(مجموعهی E مجموعهی کل یالهاست) :
PRE(s) = { t | (t,s) \in E }
POST(s) = { t | (s,t) \in E}
حال به دو شکل میتونیم نشون بدیم که مسئلهی Safety Verification میتونه به Graph Reachability تقلیل پیدا کنه ( عملگر بستار * روی یک عملگر به معنی ترکیب بازگشتی گونهی عملگر نسبت به خود به ازای تعداد محدودی می باشد) :
Post*(I) intersect T = empty set
Pre*(T) intersect I = empty set
به reduction اول forward reachability و به reduction دوم backward reachability گفته میشه.
اگر بخوام برای reduction اولی یک الگوریتم بنویسم چیزی شبیه به این میشه :
Given :
G(V, E) - graph with set of vertices V and set of edges E
I - set of initial vertices
T - set of BAD vertices
Local var :
T - a multiset of nodes from V
R - a set of nodes
Initial :
R <----- Empty set
T <----- I
Body :
While ( T != empty set) {
pick a node s from T and remove it from T
if ( s not in R) {
add s to R
add all states in POST(s) to T
}
}
if ( R intersect T == empty set) Return SAFE else return UNSAFE
Forwarded from a pessimistic researcher (Kc)
This media is not supported in your browser
VIEW IN TELEGRAM
Forwarded from LinNews (Reza)
امتیاز و مشخصات پردازنده های جدید AMD لیک شد.
#AMD #APU #CPU #GPU #AI_Max #TechNews #Benchmark
@LinAcademy | @LinNews
#AMD #APU #CPU #GPU #AI_Max #TechNews #Benchmark
پردازنده های جدید AMD که با مدل هایمنبع خبر
Ryzen AI Max Pro 390
Ryzen AI Max+ Pro 395
نام گذاری شدند.
مشخصات دو پردازنده جدید به این صورت است.
مشخصات Ryzen AI Max+ Pro 395 :
با سرعت پردازنده 3.00GHz
16 هسته و 32 رشته
گرافیک مجتمع 8060s
گرافیک مجتمع دارای 40 واحد پردازشی
مشخصات Ryzen AI Max Pro 390 :
با سرعت پردازنده 3.20GHz
احتمالا با 12 هسته و 24 رشته یا مشابه مدل دیگر
گرافیک مجتمع 8050s
گرافیک مجتمع دارای 32 واحد پردازشی
پردازنده های Ryzen AI Max Pro 390 و Ryzen AI Max+ Pro 395
به ترتیب 31% و 40% از نسل قبل یعنی
AMD Ryzen AI 370
عملکرد بهتری دارند.
نمره گرافیک مجتمع 8050s با کسب 16,663 امتیاز در بخش 3D و 8060s با کسب 15,965در بخش 3D است
که قدرت برابری با RTX 3060 12GB دارند.
@LinAcademy | @LinNews