مقایسه مجوزهای سورس باز
Open Source Initiative OSI - Common Public License Version 1.0:Licensing
[OSI Approved License]
Common Public License Version 1.0 (CPL)
چیزی ننوشته بودید
در تصویر بالا هری و سالی، یک کپی از مخزن موجود را گرفته و سپس هر کدام جداگانه بر روی کپیهای خودشان مشغول به کار میشوند. سپس سالی کارش را زودتر به اتمام رسانده و مخزن را به روز میکند. بعد از آن، هری هم کارش به پایان میرسد و قصد به روز کردن مخزن را دارد ولی سیستم به او اجازه این کار را نمیدهد؛ چون این مخزن آن مخزن نیست که هری قبلا از آن کپی گرفته است. آن مخزن بعد از به روزرسانی سالی تغییر یافته است. پس او مجبور است تا تغییرات جدید مخزن را دریافت کرده و کپی خودش را به روز کند. پس از آن میتواند کپی خودش را بر روی مخزن اعمال کند (با فرض اینکه تغییرات جدید هیچ تصادمی با تغییراتی که روی کپی خودش اعمال کرده است ندارند).
سناریو بالا با احتساب وجود تصادم
اگر همین سناریوی بالا را فرض کنیم که تغییراتی که هری روی فایلها داده است همان تغییراتی است که سالی قبلا روی مخزن اصلی روی همان فایلها اعمال کرده است، آیا در این حالت دریافت به روزرسانیهای جدید باعث ایجاد تصادم میشود؟
هری درخواست ادغام آخرین تغییرات مخزن را با کپی خودش میکند. از آنجا که فایل A تصادم دارد یک فلگ flag از این وضعیت میگیرد. حال هری میتواند تفاوتهای ایجاد شده را ببیند و بین آنها یکی را انتخاب کند. در این وضعیت هری همپوشانیهای کدها را برطرف میکند و شاید هم بحثی در مورد این تصادم با سالی داشته باشد تا بهترین تغییر کد انتخاب گردد و نهایتا به روشی کاملا امن و مطمئن، با مخزن اصلی ادغام میشود.
پی نوشت : نرم افزارها نمیتوانند موضوع تصادم را به طور خودکار اعمال کنند. از آنجا که نیاز به تصمیم گیری و درک هوشمند دارد این کار به صورت انسانی باید بررسی گردد.
قطع VPN دلیل احتمالی اختلال در اینترنت است
ضمن اینکه چون هنوز برای بستن بعضی از ف شکنها راهی پیدا نکردن الان دو هفته است که از روش قطعی کل اینترنت در هر چند دقیقه استفاده میکنن (ما توی شرکت چک کردیم تقریبا هر سه تا چهار دقیقه یک بار همه سرویسهای اینترنت دچار قطعی موقت میشن) و از این روش بیشتر روزهای 4شنبه و 5شنبه و جمعه استفاده میکنن
در طول روند تولید یک برنامه، چه به صورت تیمی و یا حتی انفرادی، بارها برای برنامه نویسان این نیاز پیش میآید که به نسخههای قدیمیتر فایلهای خود دسترسی داشته باشند تا بتوانند آنچه را که در قبل نوشتهاند مورد بازبینی قرار دهند. شاید کسانی که با سیستمهای مدیریت نسخه آشنایی ندارند، این کار را با استفاده از copy و paste کردن فایلها در پوشههای جداگانه انجام دهند؛ اما روند توسعه یک برنامه در محیط عملی، امکان استفاده از چنین روشی را به ما نمیدهد. زیرا مدیریت این فایلها علی الخصوص در پروژههای تیمی، بعد از مدتی بسیار دشوار خواهد شد. بنابراین نیاز به سیستمی احساس میشود که بتواند این کار را به صورت خودکار انجام دهد.
Git توسط سازنده سیستم عامل لینوکس یعنی آقای Linus Torvalds و برای مدیریت کدهای آن ساخته شد که بعدها توسط Linux-BitKeeper ارتقا یافت. BitKeeper یک سیستم مدیریت کد توزیع شده است که البته رایگان نیست. تیم BitKeeper در ابتدا پروژه لینوکس را به صورت رایگان پشتیبانی میکرد اما در سال 2005 این حمایت را قطع کرد. در این هنگام تیم توسعه لینوکس تصمیم گرفت که خود یک سیستم مدیریت کد توزیع شده ایجاد کند. آنها این سیستم را با Perl و C نوشتند و آن را برای اجرا شدن بر روی انواع سیستم عاملها نظیر لینوکس ویندوز و حتی مک آماده کردند اهداف اصلی Git عبارتند از:
سیستمهای کنترل نسخه را میتوان بر اساس خصوصیات مختلف در دستههای متفاوتی قرار داد اما از نظر معماری سیستم, به دو دستهی زیر تقسیم میشوند :
مخزن یا همان Repository محلی است که یک سیستم مدیریت نسخه از آن برای نگهداری تغییرات فایلها استفاده میکند. در سیستمهای VCS این مخزن به صورت متمرکز یا اصطلاحا Centralized Repository میباشد. به این معنا که یک Repository بر روی یک ماشین، خواه سیستم خود برنامه نویس(در پروژههای انفرادی) و خواه یک سرور قرار دارد (در پروژههای تیمی) و برنامه نویسان تغییرات فایلهای خود را به سمت این سرور میفرستند و این سرور وظیفه نگهداری تمامی نسخهها و اطلاعات مربوطه از برنامه نویسان مختلف را به عهده دارد. اشکال این روش در این است که برنامه نویس تنها به نسخه جاری که بر روی سیستم خود است دسترسی دارد و اگر بنا به دلیلی بخواهد از نسخههای پیشین استفاده کند باید آن را از سرور بخواهد که این کار مشکل دیگری ایجاد میکند و آن این است که ممکن است برنامه نویس همیشه در موقعیتی نباشد که بتواند به سرور دسترسی داشته باشد. به همین دلیل این روش وابستگی زیادی برای برنامه نویس ایجاد میکند اما پیاده سازی این روش آسانتر از مدل توزیع شده است.
پاسخ به این سوال بسیار ساده است: هر آنچه برای ما مهم است که این شامل فایلهای کد, فایلهای پیکربندی, خروجیهای نظیر dll و غیره است. البته در این بین استثنائاتی نظیر فایلهای EXE و یا پکیجهای نصب شده وجود دارد که در بسیاری از موارد نیازی به پیگیری نسخههای آنها نیست اما تمامی اینها وابسته به نظر برنامه نویس است.
برنامه Cppcheck ابزار آنالیز سورس کدهای برنامههای C و CPP جهت یافتن اشتباهات برنامه نویسی، مشکلات امنیتی، نشتی حافظه و امثال آن است. این برنامه رایگان و سورس باز را میتوانید از آدرس زیر دریافت کنید:
در دو نسخهی خط فرمان و همچنین GUI عرضه میشود که نگارش دارای UI آن از QT استفاده میکند. تا به حال 22 باگ موجود در کرنل لینوکس توسط این برنامه کشف و برطرف شده و همچنین در بسیاری از برنامههای سورس باز دیگر نیز مورد استفاده قرار گرفته است.
لیست مواردی را که این برنامه بررسی میکند، در این آدرس قابل مشاهده است.
- همچنین از آنجائیکه ما در یک دنیای محض زندگی نمیکنیم، نیاز خواهید داشت از IUnitOfWork گاهی از اوقات در لایه نمایشی هم استفاده کنید تا بتوانید یک تراکنش حاصل از چند موجودیت و چند کلاس لایه سرویس را در پایان کار درخواست رسیده (فقط یک تراکنش به ازای کل تعاملات یک درخواست)، به بانک اطلاعاتی اعمال کنید. بنابراین internal تعریف کردن آن در دنیای واقعی میسر نیست. حتی برای تعریف سیمکشیهای تزریق وابستگیهای اولیهی آن هم نباید internal تعریف شود. همچنین باز هم یک برنامهی واقعی الزاما تمام نیازهای تجاریاش در لایه سرویس قرار نمیگیرد. مثلا نیاز خواهید داشت با میانافزارها، اکشن فیلترها و غیره هم کار کنید که اینها محل قرارگیری استاندارد و مشخصی ندارند و هر جائی قابل تعریف هستند.
Security Advisory Notice for 16.6.2
CVE-2020-1108 / CVE-2020-1108.NET Core Denial of Service Vulnerability
To comprehensively address CVE-2020-1108, Microsoft has released updates for .NET Core 2.1 and .NET Core 3.1. Customers who use any of these versions of .NET Core should install the latest version of .NET Core. See the Release Notes for the latest version numbers and instructions for updating .NET Core.
CVE-2020-1202 / CVE-2020-1203 Diagnostics Hub Standard Collector Service Elevation of Privilege Vulnerability
An elevation of privilege vulnerability exists when the Diagnostics Hub Standard Collector or the Visual Studio Standard Collector fails to properly handle objects in memory.
CVE-2020-1293 / CVE-2020-1278 / CVE-2020-1257 Diagnostics Hub Standard Collector Service Elevation of Privilege Vulnerability
An elevation of privilege vulnerability exists when the Diagnostics Hub Standard Collector Service improperly handles file operations
Top Issues Fixed in Visual Studio 2019 version 16.6.2
- Visual Studio 2019 16.60 hang at run or build when modified not saved in C++/CLI project
- An unhandled exception of type 'System.NullReferenceException' occurred in Microsoft.VisualStudio.DesignTools.WpfTap.dll
- Recurring null reference when reopening documents
- "Create new project" dialog search does not find templates for third-party language providers
- IntelliSense shows that "tilde-slash" (~/) points to ASP .NET Core 3.1 project root instread of wwwroot subfolder after upgrading Visual Studio Enterprise 16.5.6->16.6.0
- Fixed a compiler error (error C2475: redefinition; 'constexpr' specifier mismatch) affecting std::atomic when compiled as C++/CX in C++17 mode.
- URL completion values and format was fixed in Razor views. App-relative URL format is now used again and the values in the URL completion list show files and folders rooted under app root, i.e. wwwroot.
- Fixed a crash when using snippets.
- Restore item templates that could be hidden by extensions.
Guriddo همان jqGrid قدیمی است که مجوز آن تغییر کردهاست. fork نسخهی با مجوز MIT آن در اینجا نگهداری میشود.