Universal Package Manager di Linux

Tiba-tiba Linux membutuhkan paket manajer universal untuk menginstal perangkat lunak. Setidaknya itulah yang diklaim Canonical Software ketika memperkenalkan Snappy paket. Namun jika berdasarkan kebutuhan yang ada, seperti apa Universal Package Manager di Linux yang sesuai ?

Pikiran Anda, kebutuhan ini jauh dari jelas. Canonical telah menggunakan manajer paket Debian selama lebih dari satu dekade, tampaknya tanpa kesulitan besar. Selain itu, pengelola Debian bersikeras bahwa solusi untuk masalah adalah format paket didefinisikan dengan baik, seperti yang tertulis di Debian Policy Manual.

ux

Bahkan mengingat Flatpak, Fedora dan Red Hat calon manajer paket universal, dilarikan keluar beberapa hari setelah Snappy diumumkan, tampak bahwa masalah ini bukan keharusan begitu banyak sebagai persaingan perusahaan yang sedang dimainkan di komunitas Linux, tempat terakhir.

Namun, menerima klaim tentang paket manajer universal pada nilai nominal, mana yang akan menguntungkan Linux ? Beberapa pilihan pastilah dibuat, atau hasil utama mencoba untuk menerapkan manajer paket universal, karena banyak titik keluar akan menggantikan persaingan lama antara Debian dan paket RPM dengan belum lagi konflik lain antara standar bersaing yang akan menghapus salah satu rasionalisasi utama untuk mengangkat masalah ini.

Universal Package Manager Secara teknis Berbicara

Universal Package Manager adalah tidak mungkin dibuat berdasarkan alasan teknis saja. Bahkan sekilas pada empat kandidat utama - AppImage , Flatpak, Snappy dan GNU Guix. Menunjukkan bahwa mereka semua fitur serupa saham untuk menginstal, menghapus, memperbarui, atau rolling back paket atau daftar paket yang diinstal.

Masing-masing memiliki fitur yang lain; misalnya, Snappy memiliki update delta yang hanya menginstal kode yang baru sejak update terakhir, sementara Guix dapat menggunakan dependensi sudah terpasang, atau mendownload dan membangun dependensi yang diperlukan. Namun tampaknya tidak ada alasan apapun dari empat calon tidak dapat dimodifikasi untuk menyertakan salah satu fitur yang yang lain memiliki.

Demikian pula, semua kandidat mengisolasi paket untuk meningkatkan keamanan, tetapi keamanan yang sama dapat menggunakan Firejail untuk menjalankan aplikasi atau dengan memasang dalam wadah jika mereka tidak sudah melakukannya.

Halaman manual dan wiki proyek bercerita: tidak ada calon yang memiliki sebuah keuntungan teknis yang kuat bahwa mereka menjadi pilihan yang jelas. Selain itu, semua masih dalam tahap pengembangan di mana fitur yang hilang dengan mudah dapat ditambahkan.

Pilihan Politik

Dalam situasi ini ada pertanyaan cepat: siapa yang Anda inginkan untuk mengontrol fitur dasar seperti instalasi software di Linux?

Canonical sudah hangus seperti tingkat kepercayaan. Ini memiliki sejarah biasa memulai proyek-proyek seperti Mir, Unity dan Upstart, dan membutuhkan kontributor luar untuk menetapkan ke Canonical semua memiliki hak dalam kode mereka, termasuk hak untuk mengubah lisensi perangkat lunak.

Semua kebiasaan ini dapat diilustrasikan dalam pengembangan Snappy untuk Ubuntu yang hanya porting ke distro lain beberapa minggu setelah pengumuman awal. Dalam frase ini, Canonical telah bermain baik dengan orang lain, dan tidak menunjukkan tanda-tanda memperbaiki cara-caranya.

Meskipun sebuah perusahaan jauh lebih besar dari Canonical, Red Hat akan menjadi pilihan yang lebih baik karena telah menjadi teman baik untuk membuka source. Diakui, Red Hat telah memiliki saham proyek yang awalnya dikembangkan di rumah, dan sebagian besar oleh karyawan, namun Red Hat juga telah memberikan kontribusi untuk proyek-proyek komunitas. Sampai batas yang jauh lebih besar dari Canonical, tampaknya memahami kebutuhan untuk aspek utama Linux dikendalikan oleh masyarakat.

Namun mengapa harus paket manajer universal didominasi oleh setiap perusahaan? Jika tidak ada yang lain, beberapa pengembang Linux tidak suka berurusan dengan perusahaan. Sama seperti kernel Linux disimpan independen dengan memiliki pengembang kunci dana Yayasan Linux, sehingga manajemen paket harus disimpan independen dari pengaruh perusahaan langsung.

Dengan logika ini, pilihan harus berupa AppImage atau Guix. Namun dari dua, Guix lebih disukai karena sebagai bagian dari Proyek GNU, ia memiliki ikatan yang kuat dengan Free Software Foundation dan menunjukkan komitmen yang kuat di situsnya dengan prinsip-prinsip perangkat lunak bebas. Sebaliknya, AppImage adalah unaligned dan dengan lisensi BSD yang kurang berkomitmen untuk perangkat lunak bebas. Jika manajemen paket yang universal harus dilaksanakan, saya berharap itu akan dengan Guix dan di bawah kontrol masyarakat.

Kerjasama masyarakat Vs Dominasi perusahaan

Korporasi diterima di open source ketika mereka mematuhi standar komunitas. Namun ketika mereka mengambil persaingan mereka ke masyarakat, itu adalah masalah lain. Namun penting manajer paket yang universal mungkin untuk tujuan Canonical dan Red Hat, perbaikan inkremental dalam manajer paket yang telah melayani cukup baik selama bertahun-tahun tampaknya pendekatan yang lebih bermanfaat bagi masyarakat. Di masyarakat, berbaris di belakang dua pilihan perusahaan hanya selingan.

Juga tidak mengamati perbedaan ini hanya soal ideologi. Open source dibangun atas gagasan bahwa dalam keadaan tertentu kerjasama lebih efisien daripada kompetisi. Namun dengan menawarkan standar bersaing di bagian inti dari Linux, Canonical dan Red Hat merusak ide-ide yang membuat open source layak berpartisipasi di dalamnya. Bahkan jika mendominasi aspek kunci dari Linux tampaknya bermanfaat bagi perusahaan dalam jangka pendek, dalam jangka panjang menjalankan program studi yang paling bermanfaat bagi semua orang untuk menjaga persaingan perusahaan dari masyarakat.

Leave a Reply

Your email address will not be published. Required fields are marked *