Въпрос за Linux live CD

[as9993]

 

 

Slax принципно разполага с агрегат за запазване и последващо зареждане на промените. Друга интересна възможност е за добавянето на приложения във вид на модули. Но това са малко непрактични занимания. Linux е много издръжлив - при разумна работа една инсталация е нормално да се надгражда ~ 15 години, включително да преживее надграждане и на хардуер-а.
 

 

До колкото видях, идеята е, че при стартиран жив диск, файловете и директориите съдържащи настройките, които са направени се запазват някъде по твърдия диск, тъй като по принцип се съхраняват в RAM паметта и при спиране на захранването се губят.

Като цяло това е интересен фючър, но не е и нещо, което да не може да се направи във всяка една дистрибуция. Стига да е включена поддръжката на NTFS/FATxx, за да може да се чете и пише във файловата система на Windows, то няма проблем файловете, които са ползвани за запазване на настройките да се запишат върху твърдия диск, а при стартиране със скрипт да се проверява дали има такъв файл в дадена директория на Windows и да се замести с текущите.

Въпросът е, че явно това е вече написано като скриптове от създателя на Slax  и е прилично замаскирано от потребителя.

Интересно ми е при тази модуларност на пакетите, как е решен проблемът с различните версии на библиотеките и на самите пакети? Обикновено за това се грижи пакетния мениджър, без значение RPM, dpkg, Pacman или нещо друго.

[melmak]

...Стига да е включена поддръжката на NTFS/FATxx, за да може да се чете и пише във файловата система на Windows, то няма проблем файловете, които са ползвани за запазване на настройките да се запишат върху твърдия диск, а при стартиране със скрипт да се проверява дали има такъв файл в дадена директория на Windows и да се замести с текущите.

Въпросът е, че явно това е вече написано като скриптове от създателя на Slax  и е прилично замаскирано от потребителя.

Всъщност тази функционалност се получава благодарение на специфичната файлова система, която ползва Slax. Които и файлове да се променят, после се записва само делтата. По този начин нищо не се проверява, а потребителят има усещането че може да пише навсякъде по файловата система. Решението е доста елегантно.

 

Интересно ми е при тази модуларност на пакетите, как е решен проблемът с различните версии на библиотеките и на самите пакети? Обикновено за това се грижи пакетния мениджър, без значение RPM, dpkg, Pacman или нещо друго.

Изпълнимите файлове са компилирани така, че да търсят и зареждат библиотеките в рамките на модула. Както при Mac OS и PC-BSD. Не е най-доброто решение, но тях ги устройва.

 

Всъщност Slax, Tiny Core Linux, Knoppix са много специфична порода, оптимизирани за Live OS.

 

 

Не. Сега така е прието да се означава най-масовата залязваща архитектура - х86. Най-общо това са процесорите Pentium и последващите ги. Предишни означения i386, i486, i586, i686 (тук i386, i486 предшестват Pentium, но софтуере за тях върви на всички х86 процесори).

http://bg.wikipedia.org/wiki/X86

http://en.wikipedia.org/wiki/X86

 

Най-масовата архитектура в момента (по която се прозивеждат новите компютри) пък е x86_64:

http://en.wikipedia.org/wiki/X86-64

Пропуснах да кажа, за процесорите х86 най-често казваме, че са 32 битови. А за x86_64, съответно 64 битови.

[georgi711220]

Значи това Lubuntu х86 Intel ще върви без проблеми на латпопа ми Тошиба, който е с 3 гигабайта Рам и процесор AMD и същевременно на стария ми компютър IBM с Интел Пентиум 4 с 512 Рам?

[melmak]

Да ще върви (с х86 Intel). На Тошиба-та е препоръчително, на IBM-а задължително.

[as9993]

Със сигурност ще тръгне и на двата компютъра. Както беше написал и Melmak, просто така е прието да се означават архитектурите заради исторически съображения. Intel първи въвеждат x86 с 8086 и именно заради това този тип архитектура е прието да се означава с x86 Intel, докато първите спецификации за процесори стъпващи на x86, но с 64 битова машинна дума са направени от AMD и заради това пък някъде означенията са AMD64. По принцип всички нови процесори нямат проблеми да изпълняват код, писан преди 25 години на асемблер, тъй като се поддържа обратната съвместимост.