Building an operating system from scratch sounds like a job for kernel hackers writing C. But you can spin up a simplifi

ಶೂನ್ಯದಿಂದ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ನಿರ್ಮಿಸುವುದು C ಭಾಷೆಯಲ್ಲಿ ಕರ್ನಲ್ ಹ್ಯಾಕರ್‌ಗಳ ಕೆಲಸದಂತೆ ಕೇಳಿಸುತ್ತದೆ. ಆದರೆ ನೀವು ಒಂದು ಮಧ್ಯಾಹ್ನದಲ್ಲಿ ಪೈಥಾನ್‌ನಲ್ಲಿ ಸರಳವಾದ ಸಿಮ್ಯುಲೇಶನ್ ಅನ್ನು ಸಿದ್ಧಪಡಿಸಬಹುದು, ಮತ್ತು ಪ್ರೊಸೆಸ್ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್‌ನ ತರ್ಕವು (logic) ಹೈ-ಲೆವೆಲ್ ಭಾಷೆಯಲ್ಲೂ ಅಷ್ಟೇ ಕಠಿಣವಾಗಿರುತ್ತದೆ ಎಂದು ನೀವು ಬೇಗನೆ ಕಂಡುಕೊಳ್ಳುತ್ತೀರಿ. ನಾನು ಇದನ್ನು ಕಷ್ಟಪಟ್ಟು ಕಲಿತೆ. ನಾನು ಒಂದು ಪುಟ್ಟ OS ಸಿಮ್ಯುಲೇಟರ್ ಅನ್ನು ಬರೆಯಲು ಕುಳಿತೆ. ಗುರಿ ಸಾಧಾರಣವಾಗಿತ್ತು: ಕೆಲವು ಪ್ರೊಸೆಸ್‌ಗಳನ್ನು ರಚಿಸುವುದು, ಅವುಗಳನ್ನು ಶೆಡ್ಯೂಲ್ ಮಾಡುವುದು ಮತ್ತು ಅವುಗಳ ಕೆಲಸ ಮುಗಿದಾಗ ಅವುಗಳನ್ನು ಪೂರ್ಣಗೊಂಡವು ಎಂದು ಗುರುತಿಸುವುದು. ಕೋಡ್ ಚಿಕ್ಕದಾಗಿತ್ತು. ತರ್ಕವು ಅಚಲವಾಗಿತ್ತು. ನಂತರ ನಾನು ಅದನ್ನು ರನ್ ಮಾಡಿದೆ, ಆದರೆ ಯಾವುದೂ ನಿಲ್ಲುತ್ತಿರಲಿಲ್ಲ.

ಪೈಥಾನ್‌ನಲ್ಲಿ ಮಿನಿ OS ಅನ್ನು ಏಕೆ ನಿರ್ಮಿಸಬೇಕು?

ನೈಜ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಮೆಮೊರಿ ಪೇಜಿಂಗ್, ಫೈಲ್ ಸಿಸ್ಟಮ್‌ಗಳು, ಹಾರ್ಡ್‌ವೇರ್ ಇಂಟರಪ್ಟ್‌ಗಳು

ನೀವು ಇದನ್ನು ದೃಢೀಕರಣ ಪೂರ್ವಾಗ್ರಹದೊಂದಿಗೆ (confirmation bias) ಮತ್ತಷ್ಟು ಸಂಕೀರ್ಣಗೊಳಿಸುತ್ತೀರಿ. ನೀವು ಒಂದು ಅಸೈನ್‌ಮೆಂಟ್ (assignment) ಮಾಡಲು ಉದ್ದೇಶಿಸಿದ್ದೀರಿ ಎಂದ ಮೇಲೆ, ನೀವು ಅಸೈನ್‌ಮೆಂಟ್ ಅನ್ನು ಟೈಪ್ ಮಾಡಿದ್ದೀರಿ ಎಂದು ನಿಮಗೆ ತಿಳಿದಿರುತ್ತದೆ. ನೀವು ಐದನೇ ಬಾರಿಗೆ ಕೋಡ್ ಅನ್ನು ಓದಿದಾಗ, ನಿಮ್ಮ ಮೆದುಳು ಆ ಚಿಹ್ನೆಯನ್ನು ತಾನಾಗಿಯೇ ಸರಿಪಡಿಸಿಕೊಳ್ಳುತ್ತದೆ (autocorrects). ಇದೇ ಕಾರಣಕ್ಕೆ 'ರಬ್ಬರ್ ಡಕಿಂಗ್' (rubber ducking) ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಇದು ನೀವು ಪ್ರತಿ ಸಾಲನ್ನು ನಿಧಾನವಾಗಿ ವಿವರಿಸುವಂತೆ ಮಾಡುತ್ತದೆ, ಇದರಿಂದ ನೀವು ಬರೆದಿದ್ದಕ್ಕೂ ಮತ್ತು ನೀವು ಉದ್ದೇಶಿಸಿದ್ದಕ್ಕೂ ಇರುವ ವ್ಯತ್ಯಾಸವು ಸ್ಪಷ್ಟವಾಗಿ ಕಾಣಿಸುತ್ತದೆ.

ಇಂತಹ ಸಣ್ಣ ಬಗ್‌ಗಳನ್ನು (bugs) ದೊಡ್ಡ ಮಟ್ಟದ ಕ್ರ್ಯಾಶ್‌ಗಳಿಗಿಂತ (crashes) ಕಂಡುಹಿಡಿಯುವುದು ಕಷ್ಟ. ಒಂದು segfault ಅಥವಾ syntax error ತಕ್ಷಣವೇ ಎಚ್ಚರಿಕೆ ನೀಡುತ್ತದೆ. ಒಂದು ಮೌನವಾದ no-op ಕೇವಲ ಸ್ಟೇಟ್ ಅನ್ನು (state) ಹಾಳುಮಾಡುತ್ತದೆ ಮತ್ತು ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ಅಸ್ತವ್ಯಸ್ತವಾಗಿ ಮುಂದುವರಿಯುವಂತೆ ಮಾಡುತ್ತದೆ. ವೈಫಲ್ಯವು ಮುಂದಿನ ಹಂತದಲ್ಲಿ (downstream) ಸಂಭವಿಸುತ್ತದೆ, ಮತ್ತು ನಿಮ್ಮ ಸಹಜ ಪ್ರವೃತ್ತಿಯು ಕಾರಣಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿ ಲಕ್ಷಣವನ್ನು (symptom) ಡಿಬಗ್ ಮಾಡುವುದೇ ಆಗಿರುತ್ತದೆ.

ಉತ್ತಮ ರಕ್ಷಣೆ

ನೀವು ಕೇವಲ ನಿಮ್ಮ ಕಣ್ಣುಗಳನ್ನು ಮಾತ್ರ ನಂಬಲು ಸಾಧ್ಯವಿಲ್ಲ. ಈ ಘಟನೆಯ ನಂತರ, ತಪ್ಪುಗಳನ್ನು ಮೊದಲೇ ಪತ್ತೆಹಚ್ಚಲು ಸಹಾಯವಾಗುವಂತೆ ನಾನು ಕೆಲವು ಅಭ್ಯಾಸಗಳನ್ನು ಬದಲಾಯಿಸಿಕೊಂಡೆ.

ಮೊದಲನೆಯದಾಗಿ, ನೀವು ಡಿಕ್ಷನರಿಯಲ್ಲಿ (dictionary) ಸ್ಟೇಟ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತಿದ್ದರೆ, ಪ್ರೊಸೆಸ್ ಸ್ಟೇಟ್‌ಗಳಿಗಾಗಿ dataclass ಅಥವಾ enum.Enum ಅನ್ನು ಬಳಸಲು ಪರಿಗಣಿಸಿ. ನಿಮ್ಮ ಸ್ಟೇಟಸ್‌ಗಳನ್ನು ಕಾನ್ಸ್ಟಂಟ್ಸ್ (constants) ಅಥವಾ ಎನ್ಯಮ್ ಮೆಂಬರ್‌ಗಳಾಗಿ (enum members) ವ್ಯಾಖ್ಯಾನಿಸಿ:

from enum import Enum

class ProcessState(Enum):
    READY = "ready"
    RUNNING = "running"
    FINISHED = "finished"

ಸ್ಪಷ್ಟವಾದ ಟೈಪ್‌ಗಳೊಂದಿಗೆ (explicit types), mypy ನಂತಹ ಪರಿಕರಗಳು ಸ್ಟ್ಯಾಟಿಕ್ ಅನಾಲಿಸಿಸ್ (static analysis) ಸಮಯದಲ್ಲಿ ಅನುಮಾನಾಸ್ಪದ ಹೋಲಿಕೆಗಳನ್ನು ಗುರುತಿಸಬಹುದು. ಅಸೈನ್‌ಮೆಂಟ್ ಇರಬೇಕಾದ ಜಾಗದಲ್ಲಿ ಅಕಸ್ಮಾತ್ ಹೋಲಿಕೆ ನಡೆದಾಗ, ಟೈಪ್‌ಗಳು ನಿರೀಕ್ಷಿತವಾಗಿಲ್ಲದಿದ್ದರೆ ಅದನ್ನು ಪತ್ತೆಹಚ್ಚುವುದು ತುಂಬಾ ಸುಲಭವಾಗುತ್ತದೆ.

ಎರಡನೆಯದಾಗಿ, ನೀವು ಶೆಡ್ಯೂಲರ್ ಲಾಜಿಕ್ (scheduler logic) ಬರೆಯುವ ಮೊದಲು ಸ್ಟೇಟ್ ಟ್ರಾನ್ಸಿಷನ್‌ಗಳಿಗಾಗಿ (state transitions) ಯೂನಿಟ್ ಟೆಸ್ಟ್‌ಗಳನ್ನು ಬರೆಯಿರಿ. ಒಂದು ಪ್ರೊಸೆಸ್ ಅನ್ನು ಸೃಷ್ಟಿಸಿ, ಒಂದು ಟಿಕ್ ಕೆಲಸವನ್ನು ಮಾಡಿ, ಶೆಡ್ಯೂಲರ್ ಅನ್ನು ರನ್ ಮಾಡಿ, ಮತ್ತು ಅಂತಿಮ ಸ್ಟೇಟ್ FINISHED ಎಂದು ಖಚಿತಪಡಿಸುವ ಒಂದು ಸರಳ ಪರೀಕ್ಷೆಯು ತಕ್ಷಣವೇ ವಿಫಲವಾಗುತ್ತಿತ್ತು. ಆ ವೈಫಲ್ಯವು ಇಡೀ ಲೂಪ್‌ನಲ್ಲಿ ಅಲೆದಾಡುವ ಬದಲು, ಹುಡುಕಾಟವನ್ನು ಕೇವಲ ಸ್ಟೇಟ್ ಅಪ್‌ಡೇಟ್ ಲಾಜಿಕ್‌ಗೆ ಸೀಮಿತಗೊಳಿಸುತ್ತಿತ್ತು.