Change Instance

HTTP 200 OK
Allow: GET, HEAD, OPTIONS
Content-Type: application/json
Vary: Accept

{
    "unit": "https://hosted.weblate.org/api/units/82733354/?format=api",
    "component": "https://hosted.weblate.org/api/components/debian-handbook/09_unix-services/?format=api",
    "translation": "https://hosted.weblate.org/api/translations/debian-handbook/09_unix-services/pl/?format=api",
    "user": "https://hosted.weblate.org/api/users/paradigm_shift/?format=api",
    "author": "https://hosted.weblate.org/api/users/paradigm_shift/?format=api",
    "timestamp": "2024-04-10T20:22:44.259507+02:00",
    "action": 2,
    "target": "W obu przypadkach faktyczny bootloader przejmuje kontrolę, wyszukuje albo chained bootloader, albo jądro na dysku, ładuje je i wykonuje. Jądro jest następnie inicjowane i rozpoczyna wyszukiwanie i montowanie partycji zawierającej główny system plików, a na koniec wykonuje pierwszy program - <command>init</command>. Często ta „partycja główna” i to <command>init</command> znajdują się w rzeczywistości w wirtualnym systemie plików, który istnieje tylko w pamięci RAM (stąd jego nazwa, „initramfs”, wcześniej nazywany „initrd” dla „inicjalizacyjnego dysku RAM”). Ten system plików jest ładowany do pamięci przez bootloader, często z pliku na dysku twardym lub z sieci. Zawiera on absolutne minimum wymagane przez jądro do załadowania „prawdziwego” głównego systemu plików: mogą to być moduły sterowników dla dysku twardego lub innych urządzeń, bez których system nie może się uruchomić, lub, częściej, skrypty inicjalizacyjne i moduły do montażu macierzy RAID, otwierania zaszyfrowanych partycji, aktywowania woluminów LVM itp. Po zamontowaniu partycji głównej initramfs przekazuje kontrolę do prawdziwego init, a maszyna wraca do standardowego procesu rozruchu.",
    "id": 87280307,
    "action_name": "Translation changed",
    "url": "https://hosted.weblate.org/api/changes/87280307/?format=api"
}