معادل ریجستری ویندوز

[obontu]

سلام
معادل ریجستری ویندوز اینجا تو اوبونتو چی داریم ؟

[سودو.]

نداریم !

[آرمان اسماعیلی]

سلام
معادل ریجستری ویندوز اینجا تو اوبونتو چی داریم ؟

سلام. اینجا دیگه یه فضای خاص سیستمی شلوغ و به‌هم‌ریخته و کثیف وجود نداره که راه دسترسی بهش تنها از طریق ابزاری باشه که سیستم‌عامل در اختیار می‌ذاره. بلکه تمام تنظیمات و پیکربندی‌ها در قالب پرونده‌های پیکربندی ذخیره میشن که اکثرشون داخل دایرکتوری ‎/etc موجودن.

[obontu]

سلام
معادل ریجستری ویندوز اینجا تو اوبونتو چی داریم ؟

سلام. اینجا دیگه یه فضای خاص سیستمی شلوغ و به‌هم‌ریخته و کثیف وجود نداره که راه دسترسی بهش تنها از طریق ابزاری باشه که سیستم‌عامل در اختیار می‌ذاره. بلکه تمام تنظیمات و پیکربندی‌ها در قالب پرونده‌های پیکربندی ذخیره میشن که اکثرشون داخل دایرکتوری ‎/etc موجودن.

سلام این  دایرکتوری ‎/etc کپی بشه همون نسخه اوبونتو نصب بشه میشه جایگزین کرد این پوشه را ؟

[سودو.]

شخصی سازیا و کانفیگای کاربر تو خونش ذخیره میشه !

[آرمان اسماعیلی]

سلام این  دایرکتوری ‎/etc کپی بشه همون نسخه اوبونتو نصب بشه میشه جایگزین کرد این پوشه را ؟

همونطور که گفتن شخصی‌سازی‌های نرم‌افزارهای کاربر در پوشه‌ی ‎/home/user ذخیره میشن. یعنی کافیه توزیع رو نصب کنید و کل محتویات این پوشه رو به home جدید انتقال بدید.

راستی لطفاً اسم خودتون رو بعد از ۲ سال که عضو انجمن هستید به شکل صحیح بنویسید. اسپل درست اوبونتو میشه ubuntu. وقتی می‌بینم به شکل فینگیلیش و با تلفظ نادرست اُبُنتو نوشتید یه حس OCDطور بدی می‌گیرم 😆

[mobin1387]

ریجستری ویندوز یکی از بدترین برنامه های دنیا است و نیازی هم به ارائه جایگزینی براش وجود نداره. به طور مثال یکی از ایرادات اساسی ریجستری رو توضیح می‌دم:

ریجستری هیچ ساختار کنترل سطح دسترسی نداره! یعنی نمی‌تونید به درستی تعیین کنید چه کاربری به قسمتی از پوشه ها/اطلاعات دسترسی داشته باشه.
در ویندوز های قدیمی تر از Vista، هرکسی می‌تونست از طریق regedit.exe ریجستری رو دستکاری کنن، این یک فاجعه طراحیه! یعنی هر کاربری/برنامه ای می‌تونست هرچیزی که دلش خواست رو دستکاری کنه و رایانه منفجر کنه یا حتی به اهداف دیگه دست پیدا کنه! همچنین بسیار از بدافزار ها از این ضعف استفاده کردند (مخصوصا بدافزار هایی که قصد خرابکاری در سامانه رو داشتن).
مایکروسافت که این فاجعه طراحی دید به جای اصلاح پایه و اساس ریجستری یا منسوخ کردنش، یک راه حل چرت رو پیاده سازی کرد: حالا تنها راه ویرایش کردن هرچیزی در ریجستری، اینه که regedit.exe رو با کاربر Admin بازش کنید! یعنی عملا مایکروسافت صورت‌مسئله رو پاک کرد. این شاید جلوی بسیار از بدافزار هارو گرفت اما مدیریت سامانه رو برای مدیران سامانه جهنمی کرد. اگه لازمه کاربری چیزی رو توی HKEY_CURRENT_USER خودش تغییر بده نیازه که وارد Admin بشه، یعنی مدیران سامانه مجبور می‌شدن یا خودشون کارو انجام بدن یا رمز Admin رو در دسترس اون کاربر قرار بدن. این یک ریسک امنیتی خیلی بزرگه، کاربر Admin تقریبا معادل کاربر root در سامانه های یونیکس مانند هست.

همین یک مسئله کافیه که بگیم چرا ریجستری یک فاجعه طراحیه! حتی خود مایکروسافت هم اصراری در استفاده ازش نداره!

جایگزین چنین چیز فاجعه ای در سامانه های یونیکس مانند موجوده! در سامانه های یونیکس مانند، شاخه /etc وجود داره که برنامه ها می‌تونن به راحتی پرونده های پیکربندیشون رو در این شاخه بزارن، همچنین به لطف ساختار بسیار منعطف سطح دسترسی میشه دقیق تعریف کرد کی بتونه پرونده هارو ببینه/بخونه/بنویسه/اجرا کنه! این باعث می‌شه بشه به راحتی سطح دسترسی رو کنترل کرد.

[🇬🇧بریتانیای کبیر🇬🇧]

تازه کار هم نمی‌کنه. من صد بار آپدیت ویندوز رو غیر فعال کردم از ریجستری  ولی با باز آپدیت  می‌شد ولی وضعیت آپدیت در ریجستری  غیر فعال بود.
O____________O

[جعفر فرقانلوژ]

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

[mobin1387]

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

مشکل اینجاست که کسی حتی گندکاری های قبلی رو هم جمع نمی‌کنه :/

[Dragon-]

سلام این  دایرکتوری ‎/etc کپی بشه همون نسخه اوبونتو نصب بشه میشه جایگزین کرد این پوشه را ؟

اگه همینجوری جایگزین کنید، ممکنه مشکل پیش بیاد.
فایل fstab نباید جایگزین بشه. معمولا توی فایل fstab، از uuid استفاده میشه. تقریبا همیشه، وقتی توزیع رو دوباره نصب می‌کنید، جایی که روت قرار داره از اول فرمت میشه و با اینکار، تقزیبا همیشه یه uuid جدید برای اون فایل‌سیستم ایجاد میشه.

به خاطر همین، اگه فایل fstab یه سیستم دیگه رو جایگزین فایل fstab فعلی کنید، به احتمال زیاد مشکل پیش میاد. شاید مشکل رو همون موقع نبینید ولی بعد که  سعی می‌کنید پیکربندی اصلی گراب رو مجدد ایجاد کنید، به مشکل بخورید.

ممکن هست داخل پیکربندی‌های /etc/ چیز‌هایی قرار داشته باشه که فرض می‌کنند یه سخت‌افزار وجود داره و توی حالت خاصی هست. به همین خاطر ممکنه با گذاشتن اون پیکربندی‌ها توی سیستم دیگه، نتایج ناخواسته‌ای ببینید.

معمولا بهترین گزینه این هست که تغییراتی رو که ایجاد می‌کنید ذخیره کنید تا اگه لازم شد، بعدا از اونها یه جای دیگه استفاده کنید.

[obontu]

تاریخچه دستوراتی که داخل ترمینال اجرا شده کجا ذخیره میشه البته از خود ترمینال میشه بهش رسید ولی ایا تو فایلی ذخیره میشه جدا ؟
یا اتصالاتی مثل فلش هارد یا هر چیز دیگه ای از قبیل کجا ذخیره میشه
یا مثلا زمان اتصال به اینترنت
روشن خاموش شدن یا ری استارت سیستم کجا ذخیره میشه
و
.
.
.

[سودو.]

تو گنو همه چیز لاگ میشه ، همه چیز ، همه چیز ، همه چیز !

[Dragon-]

تاریخچه دستوراتی که داخل ترمینال اجرا شده کجا ذخیره میشه البته از خود ترمینال میشه بهش رسید ولی ایا تو فایلی ذخیره میشه جدا ؟

بستگی داره از چه پوسته‌ای استفاده می‌کنید. معمولا توزیع‌ها به طور پیش‌فرض‌، از bash استفاده می‌کنند.
bash، تاریخچه دستوراتی که اجرا شدند رو توی فایل bash_history. توی هوم کاربر مربوط نگهداری می‌کنه.

یا اتصالاتی مثل فلش هارد یا هر چیز دیگه ای از قبیل کجا ذخیره میشه

این یکی رو احتمالا می‌تونید بین گزارش‌های کرنل پیدا کنید.
گزارش‌های کرنل در حال اجرا رو میشه با خوندن فایل kmsg  توی /proc/ دید. البته اگه پارامتر kernel.dmesg_restric از کرنل برابر ۱ باشه، فقط کاربر روت یا افرادی که قابلیت CAP_SYSLOG دارند، می‌تونند اون فایل رو بخونند.
اینکه مقدار پیش‌فرض این پارامتر کرنل چی باشه، بستگی به این داره که CONFIG_SECURITY_DMESG_RESTRICT توی پیکربندی کرنل موقع کامپایل، فعال بوده یا نه.

یا مثلا زمان اتصال به اینترنت

منظورتون از این جمله دقیقا چی هست؟ چون میشه اون رو به شکل‌های مختلفی تفسیر کرد.

روشن خاموش شدن یا ری استارت سیستم کجا ذخیره میشه

فکر کنم این هم توی گزارش‌های کرنل باشه. شاید هم بتونید توی گزارش‌های init system اطلاعات مربوط رو‌پیدا کنید.