You are currently browsing the category archive for the 'نرم افزارهای آزاد' category.
هیچ وقت روزهای خوبی که با SUSE داشتم یادم نمیره. اون موقع ها خیلی از لینوکس سرم نمیشد (حالا نه که الآن میشه!) ولی SUSE اونقدر راحت بود که حتی منه تازه کار هم بخوام باهاش کار کنم. و KDE ….. از نظر من و خیلی های دیگه KDE و SUSE با هم پیوند خاصی دارن کلا KDE تو هیچ توزیع دیگه ایی مثل SUSE به آدم حال نمیده.
“سوزه”
“سوزی”
“زوزه!”
“سوزا”
“سوسا”
“سوسه”
هر چی که دلتون می خواد صداش کنید. مردمی که تو ناول اینور اونور میرن “سوسه” صداش میکنن ولی در واقع هر کی هر جور که تو زبونش میچرخه اسمشو تلفظ میکنه.
اما خوب به هر حال تو یه تغییر استراتژیک OpenSUSE میزکار پیش فرض خودش رو به گنوم تغییر داد. از طرفی هم اون زمان مثل الآن نبود که کار کردن با بسته های RPM اینقدر راحت باشه. وقتی می خواستی یه بسته ی RPM نصب کنی کلی باید دردسر میکشیدی. رو همین حساب من هم مثل خیلی های دیگه به اوبونتو مهاجرت کردم. اوبونتو شاید بشه گفت کاری رو برای گنوم کرد که SUSE داشت برای KDE انجام میداد. یه توزیع واقعا جالب و راحت که خداییش خیلی پایداره. کار به نسخه ی دیگش مثل کوبونتو ندارم ولی خود اوبونتو خیلی سیستم پایداری داره.
هر روز استفاده از اوبونتو برام لذت بخشه. اما خوب همیشه دلم می خواست مثه روزهای قبلی یه توزیع درست حسابی KDE داشته باشم. کوبونتو, درست بر عکس اوبونتو, هر روز که میگذره کاربرهای بیشتری رو دلسرد میکنه. اگه یه روزی واقعا کوبونتو بخواد هم قد رفیقه خودش پایدار بشه توزیع فوق الآده ایی میشه.
توزیع دیگه ایی که خیلی ازش تعریف شندیم Arch هستش که تا الان کسی رو پیدا نکردم که بخواد ازش بد بگه. یه سیستم کاملا match شده با KDE که فوق الاده پایدار و سریعه. از همه مهم تر سیستم مدیریت پکیج هاشه که میگن خیلی جالب و همیشه به روزه. اما خوب Arch برای شروع کار دنگ و فنگ زیاد داره و همونطور که خودشم میگه برای کسایی هست که از خط فرمان هیچ ترسی نداشته باشن. من خودم به شخصه دوست دارم سیستم عاملی که استفاده میکن اونقدر ساده و راحت باشه که من بتونم بیشتر به کارهای دیگه ام برسم نه اینکه بخواد وقت زیادی رو صرف پیکر بندی خود سیستم عاملم بکنم. شاید یه روزی Arch رو امتحان کردم ولی مطئنا اون روز امروز نیست! حالا میپرسید چرا؟
چون تازه دوزاریم افتاد که OpenSUSE 11.2 دوباره به پایه ی خودش برگشته و میز کار پیش فرض رو KDE قرار داده. میدونستم نسخهی 11.2 جدیدا انتشار پیدا کرده ولی چون زیاد OpenSUSE رو دنبال نمیکردم بعد یه تاخیر طولانی متوجه شدم که میز کارش عوض شده. فورا رفتم به فروشگاه محبوب خودم “سیتو“, و دی وی دیش رو سفارش دادم. احتمالا چند روز دیگه میرسه دم خونه. خیلی چیزها از SUSE و کلا سیستم های مبتنی بر RPM یادم رفته. مثلا یادمه اون موقع ها نصب داریور NVIDIA یه دنگ و فنگ هایی خاصی توی SUSE داشت که تو بقیه توزیع نداشت. الآن واقعا نمی دونم سیستمی که قراره چند روز دیگه بهم برسه چجوری می خواد از آب در بیاد. واسه همین از کلیه رفقایی که با OpenSUSE و کلا سیستم های RPM آشنا هستن در صورت احتمال درخواست کمک میکنم D: به هر حال در حال حاظر هنوزم فکر میکنم UBUNTU یکی از بهترین توزیع های لینوکسه که واقعا محبوبیتی که داره رو همینطوری به دست نیاورده.
من آدم خیلی سیاسی ای نیستم. آدمی هم نیستم که هر کی هرچی بگه قبول کنم. پس من بر عکس خیلی های دیگه به زن و بچه ی رییس نوکیا فهش نمیدم. یه شرکت چاقو سازی چاقوش رو میفروشه به مشتری؛ اون مشتری میتونه فقط با اون چاقو خیار پوست بکنه, یا بزنه شونصد نفرو بکشه. نوکیا هم تکنولوژی هایی رو به عنوان یه تولید کننده به ایران فروخته که به 900000000000 هزار تا کشور و سازمان دیگه هم فروخته. حالا اینکه دولت مهرورز ما داره چجوری از این ابزارها استفاده میکنه گناهش پای خودشه. نوکیا که NSA نیست بشینه واسه خودش وسیله ی جاسوسی طراحی کنه.
تو همین یکی دو روزه نوکیا نسخه ی جدید QT رو منتشر کرده که با کلی امکانات جدید و بهینه سازی های مختلف همراه هست. از همه مهم تر شاید بشه به سیستم عامل های جدیدی که QT توی این نسخه اش ساپورت میکنه اشاره کرد, مخصوصا سیمبیان! افکت های گرافیکی یا مجتمع سازی بیشتر با WebKit هم که دیگه بماند. محیط توسعه ی QT Creator هم ارتقا پیدا کرده. واسه اطلاع بیشتر میتونید به سایتش سر بزنید.
اگه از ویندوز استفاده میکنید (مثل خیلی های دیگه), یا مجبورید برای بعضی چیزا از ویندوز استفاده کنید (مثل خودم) یا برنامه های مولتی پلتفرم مینویسید (مثل اونایی که برنامه های مولتی پلتفرم مینویسن!!!) ممکنه از خودتون بپرسید توی ویندوز میشه برنامه نویسی ++C/C آزاد کرد؟
بلهههههههههههههههههههههههههههههههه که میشه.
اما یه اشکال وجود داره. شما اگه از C++ BUILDER یا Visual Studio استفاده میکنید برنامه ی شما آزد به حساب نمیاد. چرا؟ چون این برنامه ها رو دزدیدید! اونایی که این برنامه ها رو واقعا خریدن که خوشا به حالشون. ولی اکثر افراد (حداقل توی ایران) نسخه های دزدی این برنامه ها رو استفاده میکنن. شمایی که سنگ ماکروسافت رو به سینه میزنین آیا تا به حال به این موضوع فکر کردن که کمپانی دلبندتون اگه دستش بهتون برسه اولین کاری که میکنه اینه که شما رو بندازه زندان؟
حالا روی ویندوز چی داریم؟ MingW و MSYS میتونن جواب خوبی برای این سوال باشن.
برای مبتدی هایی که می خوان بدونن:
MingW مجموعه کامپایلر های گنو (GCC) هست که برای ویندوز کامپایل میشه.
MSYS تعدادی از ابزار های سیستم های یونیکس مثل SH یا TAR یا چیزهای دیگه هستش که ممکنه برای کامپایل بعضی برنامه ها لازمتون بشه.
برای پیکر بندی این دوتا بسته روی ویندوز شما نیاز دارید سه تا فایل اجرایی زیر رو دانلود کنید:
1- از این آدرس, بین زیر شاخه هایی که در این صفحه لیست شده اند, زیر شاخه ی MSYS Base System رو پیدا کنید و داخل اون جدید ترین ورژن این برنامه رو دانلود کنید که اسم فایلش شبیه اینه: MSYS-1.0.11.exe
2- دوباره در همون آدرس بالا, بین زیر شاخه ها ی لیست شده, زیر شاخه ی MSYS Supplementary Tools رو پیدا کنید و جدید ترین ورژن برنامه ی msysDTK رو ازش دانلود کنید که اسم فایلش شبیه اینه: msysDTK-1.0.1.exe
3- در آخر هم از این صفحه, و در قسمت Download اولین فایلی که برای دانلود گذاشته شده رو دریافت کنید. این فایل با عنوان Bundled Installer مشخص شده.
یکی یکی به ترتیب فایل ها رو نصب کنید. برای نصب دوتا فایل اول از آدرس زیر استفاده کنید:
C:\msys\1.0
و فایل آخر رو هم توی آدرس زیر بریزید:
C:\msys\1.0\mingw
بعد از نصب این فایل ها, فایل fstab.sample رو که در آدرس C:\msys\1.0\etc قرار داره رو به fstab تغییر نام بدید. فایل رو باز کنید و دو تا خط آخر فایل رو از چیزی که در پایین میبینید:
#Win32_Path Mount_Point
c:/mingw /mingw
c:/ActiveState/perl /perl
به صورت زیر ویرایش کنید:
#Win32_Path Mount_Point
c:\msys\1.0\mingw /mingw
#c:/ActiveState/perl /perl
بعدش هم ادرس های زیر رو به متغیرهای PATH سیستم خودتون اضافه کنید:
C:\msys\1.0\bin
C:\msys\1.0\mingw\bin
به روز رسانی: این پست در تاریخ 25 آبان 88 مورد ویرایش مجدد قرار گرفته است.
من هیچ صحبتی ندارم بکنم جر اینکه به استفاده کنندگان ویندوز 7 و بقیه محصولات انحصاری ماکروسافت توصیه کنم حداقل یکبار که شده فقط صفحه ی اول این سایت رو با دقت از اول تا آخر مطالعه کنند:
تا به حال این جور عبارتا به گوشتون خورده؟
DVCS
software revision control
Distributed Version Control
Revision control
خوب ممکنه به گوشتون نخورده باشه. اما احتمالا این اسم ها باید به گوشتون آشنا باشه:
Monotone
Git
Bazaar
Subversion
BitKeeper
CVS
خب پس فهمیدید قراره امروز در موردی چی حرف بزنم. برنامه هایی که چار چشمی کدهای شما رو زیر نظر میگیرن و تمام تغییرات رو ثبت میکنن. این کار خوبی های زیادی داره مخصوصا برای کار توی پروژه های بزرگ و از اون مهم تر پروژه های اوپن سورس. یکی از ویژگی هایی که من خیلی در مورد این برنامه ها دوست دارم اینه که اگه یه وقت گند بزنید به کدهاتون خیالتون راحته که میتونید برگردید به چند مرحله قبل تر وگند خودتون رو اصلاح کنید (فهمیدید چرا این ویژگی رو دوست دارم؟) احتمالا اصلی ترین ویژگی ایی که بقیه برنامه نویس ها دوسش دارن راحتیه کار تیمی روی کدهای یه برنامست. خب این یعنی چی؟ این که دیگه پرسیدن نداره. فکر میکنید چجوری 100 نفر روی یه برنامه کار میکنن هیچ وقت هم کدها قرو قاطی نمیشه؟
قبل از اینکه باز شروع کنم به وراجی کردن این بار هم خواهش میکنم یکی یه ترجمه مناسب در مورد “Revision control” یا “Distributed revision control” ارایه بده چون خسته شدم از اینکه وقتی میخوام در مورد این جور برنامه ها صحبت کنم باید اسم خارجکی شون رو به طور کامل تلفظ کنم.
من خودم از Bazaar خوشم میاد و واسه برنامه هام استفاده میکنم. میدونید چرا؟ چون با پایتون نوشته شده, پس من بهتر می فهممش و مثل بقیه برنامه های پایتون ساختار ساده ولی پرقدرتی داره. حالا یه جوری فکر نکنید که الآن من دارم در هفته روی 10-12 تا برنامه کار میکنم و زندگیم داره با برنامه نویسی میچرخه نه بابا از این خبر ها نیست. من خودم کار و زندگی و درس و دانشگاه و کلی کاره دیگه دارم اما گاهی اوقات کسایی که منو میشناسن بهم پیشنهاد میدن منم کارشون رو قبول میکنم. (نه, پروژه دانشگاهی قبول نکردم تاحالا!)
حالا از این حرف ها بگذریم. می خوام به لیست برنامه های بالا اسمی رو اضافه کنم که خیلی ها هنوز باهاش آشنا نیستن. تا چند وقته پیش منم جزو همون خیلی ها بودم. اگه اونقدر خنگید که از عنوان پست نفهمیدید اسم برنامه چیه مجبورم اینجا تکرارش کنم: Mercurial
حالا چرا Mercurial؟ اولین دلیل: بگم اولین دلیل چیه یا خودتون متوجه شدید؟ خب فکر کنم متوجه شدید. آره چون با پایتون نوشته شده. دلیل بعدی: این لعنتی جدا کارش درسته. یعنی حاج آقامون متخصصه بکار گرفته شدن تو پروژه های گندست. و از اون جایی که ذهن یه برنامه نویس پایتون پشتش بوده پس به صورت پایتونیک نوشته شده یعنی ساده, تمیز, پرقدرت و از همه مهمتر جالب و لذت بخشه! این زیر یه سری از پروژه های معروفی که از Mercurial استفاده میکنن رو واستون قرار دادم :
IcedTea
medit
LinuxTV
MoinMoin
Mozilla
NetBeans
Nuxeo
OpenJDK
OpenOffice
OpenSolaris
Pida
Pylons
Python Programming language
rpm.org
SymPy
Symbian Platform
Wget
Xen
حالا اگه برنامه ایی نوشتین که خواستید با بقیه توش شریک بشید باید بهتون مژده بدم که سایت های زیر از Mercurial پشتیبانی میکنن:
SourceForge.net
Savannah
Mozdev
Google Code
BerliOS Developer
…..
خوب میبینم که با دیدن اسم های بالا ترغیب شدید که یه نیگاه بندازید به Mercurial مگه نه؟ Mercurial کلی ویژگی دیگه داره که من جدا حال ندارم همشو توضیح بدم برید خودتون تو سایتش ببینید دیگه.
نکته ی اخلاقی:
یه چند تا اسم بود که فکر کنم فکر شمارو مشغول کرد مثل NetBeans و OpenJDK
ذهن من هم کمی مشغول شد. که حتی سان ماکروسیستم (بابای جاوا) هم داره از Mercurial استفاده میکنه. اتفاقا این یه کار کاملا حرفه ایی از طرف یه شرکت کاملا حرفه ایی هستش. اگه بر نامه ایی واقعا خوب بود, باید بدون تعصب ازش بهره برد. برای خیلی از ماها مهمه که برنامه با جاوا نوشته شده باشه یا با سی شارپ. با دلفی نوشتنش یا با وی بی. با پایتون نوشتنش یا با روبی. از QT استفاده میکنه یا GTK یا هر جور فکر مزخرف دیگه.
پس مهم نیست یه برنامه از چه زبان یا چه ابزاری استفاده میکنه, مهم اینه که با کیفیت و مرغوب باشه. به قول یکی از بچه ها هر چیزی خوبش, خوبه!
خوشم میاد از کسایی که جای شعار دادن می شینن یه گوشه واسه خودشون حرف هاشون رو به عمل تبدیل میکنن بدون اینکه براشون مهم باشه بقیه بابت کارشون بهشون توجه می کنن یا نه. گوگل یکی از همین هاست.
همونطور که همتون میدونید ( یا شاید هم نمی دونید ) یکی از سه زبان اصلی برنامه نویسی مورد استفاده در گوگل, پایتون هستش. دو تای دیگه, یکی ++C هست که قسمت زیادی از کدهاش به عنوان توسعه دهنده های پایتون نوشته شدن و اون یکی که نیاز به گفتن نداره. جاوا.
و باز هم همونطور که همتون میدونید (یا شاید اینبار هم نمیدونید) سایت محبوب یوتیوب با پایتون خالص نوشته شده! البته جو گیر نشید یوتیوب هم از ++C استفاده میکنه ولی بر عکس گوگل, یوتیوب تقریبا 99.99% درصد از کدهای ++C رو برای ساخت توسعه دهنده های پایتون نوشته. و احتمالا این رو هم میدونید که گوگل یوتیوب رو خیلی وقت پیش خریده پس با این توضیحات میشه به صورت تئوری اینطور بیان کرد که گوگل بزرگترین منبع سورس های نوشته شده با پایتون رو در اختیار خودش داره و از طرفی هم خیلی از افراد کلیدی پایتون توی گوگل مشغول به کارن که خوب دلیلش هم کاملا واضحه.
یکی از چیزهای دیگه ایی که باید بدونید اینکه من دو تا پاراگراف بالا رو از یه جام در نیاوردم! یه سرچ تو گوگل بزنید یا مطلب رو تا پایین ادامه بدید و فایل PDF ای که براتون می ذارم رو بخونید تا درستی این گفته ها بهتون ثابت بشه.
به هر حال؛ اینطور که پیداست (یا بهتره بگم پیدا بود) گوگل به عنوان شرکتی که ستون های اصلیش روی پایتون ساخته شده, تصمیم گرفت که سرعت این زبان برنامه نویسی رو با توجه به چیزی که خودش از مفهوم “سرعت” انتظار داره, بالاتر ببره. حداقل 5 برابر بالاتر از سرعت فعلی پایتون!
می دونید پایتون یه زبان تفسیری و دینامیک هستش. تو این مدل از زبان های برنامه نویسی سرعت عمل برنامه نویس خیلی بالاست اما لزوما قرار نیست سرعت برنامه هم به همون اندازه بالا باشه! رو همین حساب گوگل چند تا از برنامه نویس های با تجربه در زمینه ی کامپایلرها و مفسر ها رو به صورت تمام وقت یه جا جمع میکنه تا تحت پروژه ایی به اسم “Unladen Swallow” سرعت این زبان برنامه نویسی محبوب رو بهبود ببخشن.
کاری که بروبکس Unladen Swallow (یکی یه ترجمه ی مناسب ارائه بده خواهشا) انجام دادن این بوده که سورس کدهای اصلی منبع پایتون رو گرفتن (با تشکر فراوان از از آزادی و متن باز بودن این زبان برنامه نویسی) و به صورت جداگونه دارن با بر مبنای LLVM روش دستکاری انجام میدن تا بتونن علاوه بر بهبود در ترجمه و تفسیر بهتر پایتون, یه کامپایلر زمان اجرا (JIT Compiler) براش بسازن و از طرفی هم میزان منابع سخت افزاری مورد نیاز مثل حافظه یا پردازنده رو کاهش بدن.
اینجا فکر کنم لازم باشه توضیح بدم این LLVM چی هست کلا:
LLVM عزیزم یه سازه…. اوخ باز من جوگیر شدم…. برو بچه های یکی از دانشگاه های معروف امریکایی (University of Illinois) از مدت های پیش یک سری استراتژی ها و ابزارهایی روتحت اسم LLVM طراحی کردن که منحصرا برای استفاده در لایه های زیرین یک کامپایلر کاربرد داره و می تونه باعث بهبود در قسمت های مختلف یه کامپایلر بشه. این بهینه سازی بر جنبه های مختلف کار یه کامپایلر مثل عملیات زمان کامپایل, عملیات پیوند دهی!!!!, و عملیات زمان اجرا تاثیر گذاره.
مجموعه ابزارها و کدهای LLVM با ++C نوشته شده و اولش قرار بود برای بهینه سازی کامپایلر ++C/C مجموعه ی GCC استفاده بشه اما از اونجایی که ساختارش مستقل از یه زبان برنامه نویسی خاص طراحی شده, می تونه برای بهبود کار کامپایلر ها و یا مفسرهای بقیه زبان های برنامه نویسی هم استفاده بشه. برای مثال مجتمع سازی LLVM با جاوا در حال توسعه هستش یا برو بچه های Unladen Swallow قراره کاری کنن که پایتون هم بتونه از LLVM استفاده کنه.
پروژه Unladen Swallow قرار نیست کارها رو با عجله و هول هولکی انجام بده و در عوض با تقسیم بندی پروژه در چند فاز مختلف سعی کرده آروم آروم به پیشرفت کار اضافه کنه.
- فاز یک پروژه به پایان رسیده و سرعت پایتون 35-25 در صد افزایش پیدا کرده.
- فاز دوم پروژه به پایان رسیده و کامپایلر زمان اجرا بر پایه LLVM به پایتون اضافه شده و علاوه بر اون تا 25 درصد نسبت به فاز یک بهبود در سرعت حاصل شده !
- فاز سوم هم جدیدا به پایان رسیده. بهبود سرعت نسبت به فاز دوم پروژه از 70-15 درصد دیده میشه و در ضمن میزان استفاده از حافظه نسبت به فاز دوم پروژه 930 در صد کاهش پیدا کرد. (درست خوندید 930 درصد!)
- پروژه هنوز به اتمام نرسیده و باید منتطر کامل شدن فاز های بعدی باشیم. چرا؟ چون:
- سرعت پایتون میتونه از این هم زیادتر بشه. تیم متوجه شده که کار سخت تر از اونیه که فکر میکردن. در واقع سختی بیشتر کار بابت اینه که تیم نمی خواد خیلی زیاد هسته ی پایتون رو دستکاری کنه. به خاطر همین ممکنه سرعت به حدی که انتظار میرفت نرسه.
- میزان استفاده از منابع سخت افزاری هم باید کاهش بیشتری پیدا کنه چون در حال حاظر این ویرایش پایتون از 2 تا 3 برابر نسبت به ویرایش معمولی CPython بیشتر حافظه مصرف میکنه.
- در ضمن باید این کدها به پلتفرم های مختلف پورت بشن چون در حال حاظر فکر میکنم بیشتر با سیستم های یونیکس و لینوکس و بقیه رفقاشون سازگاره.
- با تغییرات انجام شده عملیات debug کردن برنامه ها مشکل پیدا کرده و باید فکری براش بشه.
- از همین الآن تعدادی از برنامه نویس های برتر مفسر پایتون خالفت خودشون رو با ترکیب شدن کدهای این پروژه با کدهای اصلی CPython اعلام کردن.
به روزرسانی: چند خط از این نوشته (مواردی که با دایره های سیاه رنگ نوشته شدن) در تاریخ 13 آبان 88 اضافه شده ان.
خوبیه این پروژه اینکه قراره با کدهای معمولی پایتون کاملا سازگار باشه و توسعه دهنده هایی که تا امروز برای پایتون نوشته شدن بدون هیچ تغییری به راحتی اجرا بشن. در آخر هم هدف اصلی پروژه اینکه نمه نمه تغیرات صورت گرفته رو به سورس اصلی پایتون (CPython) اضافه کنه.
این فایل PDF رو هم دانلود کنید بد نیست. فایل یکی از کنفرانس های معرفی پروژه ی Unladen Swallow هستش. البته یکم قدیمی شده چون پروژه خیلی سریع داره پیشرفت میکنه. من نظرم اینه که اگه به سایت پروژه برید و اطلاعات اونجا رو بخونید بهتر کمکتون میکنه.
دومیش رو هم نوشتم که میتونید از اینجا ببینیدش.
توی این قسمت با یه مثال عملی آشنا میشید.
