Czy należy się wystrzegać minta a jeśli tak to przez jakie bugi ?
Dla mnie największym bugiem Minta jest... Mint sam w sobie :) Zasadniczo to, co stanowi ta dystrybucja. W zależności od wersji core systemu (w zasadzie to cały system bez GUI i aplikacji z GUI) masz z innej dystrybucji. Mint nie przejmuje tych paczek (tak jak np. robi to Ubuntu od Debiana), nie opiekuje się nimi, nie wspiera. W efekcie, jeśli tam coś się złego dzieje, to rączki do boga.
Skoro Mint nic nie poprawia w paczkach to co sądzisz o dystrybucji Rhino?
To jest taki Arch Linux ale zawsze z najnowszymi paczkami deb.
Bazuje na najnowszym Ubuntu i Debian Experimental. Ponieważ Sid ma stary kernel 6.12, a Rhino 6.15.2. Fedora, Arch, EndeavourOS, Manjaro, openSUSE ma zawsze najnowsze stabilne wydania oprogramowania, czy istnieje jeszcze inna dystrybucja?
https://rhinolinux.org/
Linux Mint kiedyś bazował na najnowszym Ubuntu i to było dobre.
Najnowszy kernel jest zawsze bezpieczniejszy i szybszy od starego kernela 6.8, ponieważ dostaje najnowsze sterowniki i łaty.
Do tego powinien szybciej działać, ja nie rozumiem polityki Linux Mint.
Skoro dodają do starych pakietów najnowszego Firefox, to czemu nie mogą dodać najnowszego kernela 6.15?
W Debianie też są idiotyzmy stable, testing, sid, experimental, a w najnowszym sid stary kernel 6.12 xD
Powinni coś zmienić z wersji stable zrobić wersję serwer, a te trzy linie zlikwidować i zrobić wersję desktop.
Z zawsze najnowszymi stabilnymi wersjami programów jak Firefox czy kernel 6.15.2
Cytat: grzesio31 w Czerwiec 13, 2025, 08:57:58 PMNajnowszy kernel jest zawsze bezpieczniejszy i szybszy od starego kernela
Nie wiem, jak to jest z tą szybkością, ale chyba bezpieczeństwo jadra dystrybucji jest priorytetowe dla każdej dystrybucji, (Debian stable - kernel release 6.1.0-37-amd64). Aktualizacje kernela (6.1) zawsze zachodziły, a zmiana była artykułowana nowym numerem końca oznaczenia, w tym przypadku jest to nr 37. Dlatego nie wydaje mi się, że kernel ze starszej wersji jest mniej bezpieczny niż ten z najnowszej.
Jeśli chodzi o debianowe kernele, to one są utrzymywane przez Debiana. Dodawane są poprawki m.in. bezpieczeństwa wg decyzji deweloperów Debiana. Niemniej jednak nieco dziwna ta polityka, albowiem kernel 6.1 (LTS) ma obecną wersję 6.1.141. I powiem tak - bardziej ufam zespołowi odpowiedzialnemu za utrzymanie kernela (kernel.org) niż deweloperom Debiana, którzy robią te swoje składaki według dość słabo przejrzystych zasad (nie wiadomo dlaczego akurat dany patch zostaje dodany, a inny odrzucony). Było to dla mnie jednym z powodów, dla których z Debiana zrezygnowałem i z decyzji jestem zadowolony.
Piszesz o tej szybkości i pijesz do tego, że wprowadzili do kernela Linux język systemowy Rust?
Fakt on się wolniej kompiluje od C a nawet od C++, ale czy to on jest odpowiedzialny za powolny kernel?
Ale muszę przyznać Ci rację, stary kernal 6.1, 6.8 jest dużo szybszy od tych nowych kerneli 6.15.
No ale czy to jest spowodowane tym, że w nowych kernelach 6.16 jest coraz więcej powolnego kodu napisanego w Rust, tego nie umiem potwierdzić.
Fakt że jak Mozilla przepisała dużo kodu z C++ na język Rust, to Firefox zrobił się strasznie powolny w porównaniu do Chrome. Ale Chromium też już zaczęli przepisywać na Rust. Może jeszcze nie w takich ilościach co w Firefox, ale jednak.
Albo się deweloperom danej dystrybucji, w tym, zastosowanemu kernelowi ufa, albo nie ufa. Wybór dystrybucji z najnowszymi paczkami, a w tym z najnowszym kernelem, niesie za sobą ryzyko "wywalenia" się systemu w którymś momencie i po którejś aktualizacji. Kilkukrotnie tak miałem, gdy chciałem mieć wszystko najnowsze i dlatego zostałem definitywnie przy Debianie stable. Bo jeśli użytkownik ma wiedzę, to naprawi sobie system, ale jeśli jej nie posiada, to będzie tracił czas na poszukiwaniach uprawiając tzw. distro-jumping.
Potrafię sobie kompilować kernel bezpośrednio pobrany z kernel.org i nigdy mi się nie wywala.
Ale szkoda mi marnować prądu, ponieważ energia elektryczna jest teraz strasznie droga.
Więc wolę jak ktoś za mnie będzie kompilował kernele i umieszczał w paczkach do pobrania.
@MSki - Tak - devom od Debiana nie ufam. Nie ufam, albowiem nikt nie wie jaką politykę w zakresie nakładania patchy mają. Teoretycznie niby mają wszelkie patche bezpieczeństwa nakładać. Może.
Tak, czy inaczej - na desktop - Debiana wrogowi nie polecę (a używałem lata i byłem aktywnym jego użytkownikiem).
@grzesio31 - Kernel jest napisany głównie w C i assamblerze. Długotrwałość jego kompilacji (jeśli to robię, to używam clang), nie wpływa na "szybkość" działania kernela. Kogo to zresztą interesuje? Raczej interesujemy się szybkością ładowania systemu (kernel tu wpływ, ale nie wyłączny), szybkością ładowania aplikacji i ich responsywnością (i również kernel nie jest tu jedynie odpowiedzialny).
O to jesteś obcykany już w tych kompilacjach kernela. A to nie Chimera Linux jako jedna z pierwszych dystrybucji wprowadziła Clang jako domyślny kompilator, zamiast GCC.
https://chimera-linux.org/
FreeBSD chyba też przeszło na Clanga. Ostatnio na githubie dodali informacje, ile procent kodu jest napisana w języku Rust. I jest to już 0.1% kodu.
https://github.com/torvalds/linux
To jest dopiero 0,1% kodu. I nie - nie jest to znane pytanie o to, czy szklanka jest do połowy pusta, czy pełna :)
Kompilowałem sobie kernel (i nie tylko) przez całe lata. Teraz mam w CachyOS taki, który po prostu mi wystarcza. Mógłbym go sobie skompilować, ale sorry - 0,5 sek. zaoszczędzone na starcie raczej mi nie robi różnicy. Lucek o te kernele dba i jest on dla mnie najlepszą firmą w tym zakresie.
Kernel linuksa kompiluje się zarówno w GCC jak i w Clang. Przeszedłem kiedyś na ten ostatni z czystej ciekawości i tak już potem zostało. Zabawa zaczyna się tak, czy inaczej, w chwili gdy ustalasz co ma być w kernel wkompilowane, bowiem to jest określona funkcjonalność, a nie to, czy to będzie Clang, czy GCC. Niewielkie ma to znaczenie dla funkcjonalności. Oczywiście jest jeszcze skompilowanie kernela pod konkretny procesor i tu w istocie bywa, że kernel skrojony pod określony system jest wydajniejszy i to niekiedy wiele.
Ponieważ kernel Linux jest monolityczny, to jest zabawa z tym, aby wybrać odpowiednie komponenty.
W nowoczesnych lepiej zaprojektowanych od podstaw kernelach typu mikrojądro, takich jak Theseus, Redox.
System sam wykrywa przy kompilacji wszystkie podzespoły i urządzenia. I pozostałych zbędnych już nie trzeba kompilować.
https://www.theseus-os.com/
https://github.com/theseus-os
Ale od tego masz kilka programików/skryptów, które zbierają info o systemie. I jak budujesz kernel, to masz 90% roboty zrobionej.
Tak w Archu są jakieś i w Gentoo, ale w Ubuntu, Debian, Mint ich nie ma.
Mint nie ma własnego kernela. Goście nie znają się na tym kompletnie. Zresztą nie tylko na tym.
Sorry - już kiedyś to powiedziałem wprost, powiem raz jeszcze - Mint jest jedną z najgorszych dystrybucji na świecie. Praktycznie z tych, o których się mówi - jest najgorszą. Dlaczego? Brak kompetencji.
Ale ma graficzny instalator, gui do firewall i aktualizacji oprogramowania i ludzie to lubią.
Jak Arch chce mieć więcej użytkowników niech zrobi instalator gui.
A jak nie chce to jak walka z wiatrakami i wmawianie sobie że odsiewamy tych głupszych.
Arch ma prosty instalator. CachyOS ma graficzny. Mint - sorry, ale to jest ostatnia dystrybucja, jaką komukolwiek mógłbym polecić. 13 letni (tak, tyle miał wówczas lat, gdy zrobił z Ubuntu forka pn. Mint jego dev) gostek zrobi lepszą dystrybucję od Minta.
GUI do firewall? Sorry, ale jaki to problem - jest np. w Plasma. Jest w GNOME. Mint tu niczego nie wymyśli, bo się na tym nie zna. Podobnie jak z graficznym instalatorem i 99% tego quasi-systemu.
Każdy używa co chce, ale jeśli ktoś mi mówi, że Mint jest cudowny, to otwiera się we mnie duch pokerzysty i mówię: sprawdzam. I zawsze wygram.
Cytat: grzesio31 w Czerwiec 14, 2025, 05:23:21 PMgui do firewall
To akurat nie jest autorskie rozwiąznie deweloperów Mint'a a zapożyczone, które to też działa na każdej dystrybucji. Instalator Arch? EndeavourOs, Cachy Os i kilka jeszcze się znajdzie opartych o Arch. Instalacja z obrazu Arch, dziś jest prosta jak budowa cepa, chociaż nazwy potrzebnych nam paczek trzeba znać. Osobiście jestem nieco śmieciarzem, bo używam w Arch pamac - graficzny instalator programów, stworzony dla Manjaro. Używam go właśnie do wyszukiwania interesujących mnie programów, lecz samą instalację wykonuję już w konsoli, chociaż nie ma to właściwie żadnego znaczenia. Mint cieszy się dość sporą popularnością, ale prawda jest taka, że nie wiele różni się od Ubuntu. Bo likwidacja Snap i przejście na Flatpak, to nie jest jakiś wyczyn. Wszystko leci z repo Cannonical. Mało tego. Nie chcij niechcący kiedyś, przerwać instalację jakiegoś programu. Całe dpkg uklęknie...Mint może ok, na sam początek.
@melis - Z całym szacunkiem, ale Mint nie jest ok nawet na sam początek. To jedno wielkie g*** w świecie dystrybucji lina.
Cytat: pavbaranov w Czerwiec 14, 2025, 11:09:09 PM@melis - Z całym szacunkiem, ale Mint nie jest ok nawet na sam początek. To jedno wielkie g*** w świecie dystrybucji lina.
G***o w papierku po cukierku?
W sensie że niedopracowany.
W takim razie co byś polecał na początek przygody z gnu/linux ?
Ja Debiana mimo ichniejszej polityki.
Cytat: linux4ever w Czerwiec 15, 2025, 12:28:56 PMCytat: pavbaranov w Czerwiec 14, 2025, 11:09:09 PM@melis - Z całym szacunkiem, ale Mint nie jest ok nawet na sam początek. To jedno wielkie g*** w świecie dystrybucji lina.
W sensie że niedopracowany.
Tego nie powiedziałem. Niemniej jednak jest to dość podłej jakości fork. Cały core systemu jest nietknięty. Do tego dodawane są elementy własne oraz elementy dostarczane przez zewnętrznych deweloperów jakichś DE czy oprogramowania. Problem jest taki, że mam uzasadnione przekonanie, że dewowie Minta kompletnie nie dbają o to co się dzieje w całym tym "zewnętrzu". Nie mają wiedzy. Skąd ten pomysł? Choćby z ich "wsparcia", jakie dawali dla KDE4, kiedy oficjalnie już paczki zarówno KDE4, jak i Qt4 przestały dostawać nawet poprawki bezpieczeństwa. Mint to "wspierał", choć nie przejął i nie rozwijał tych paczek. Możesz mi zatem odpowiedzieć w jaki sposób Mint chciał zapewnić wsparcie dla paczek, których nie miał w opiece?
Coś takiego - jak dla mnie - dyskwalifikuje taką dystrybucję. I praktycznie ośmiesza ich deweloperów.
Cytat: linux4ever w Czerwiec 15, 2025, 12:28:56 PMW takim razie co byś polecał na początek przygody z gnu/linux ?
Na desktop, do typowych zastosowań? Fedora, OpenSUSE, może OpenMandriva... Ostatecznie systemy z serii *buntu. I przede wszystkim CachyOS lub po prostu Arch.
Fedora/RedHat po przejęciu przez niemiecki IBM nie jest teraz niemiecka? OpenSUSE, Manjaro, CachyOS, są niemieckimi distro, oraz Arch (od jakiegoś czasu jest zdominowany przez niemieckich developerów). Tak samo KDE Plasma to niemieckie oprogramowanie jak samo Qt, QtCreator. Pytanie czy nie ma w nich jakiejś niemieckiej telemetrii?
Już wychodziły kwiatki w Artix Linux gdzie pakiet KDE, czyli kuserfeedback zbierał dane. Całe te schowki.
Ja mam taką zasadę, że nie używam niemieckich i rosyjskich dystrybucji i ich oprogramowania KDE, Qt, JetBrains, Kaspersky, AdGuard.
Ubuntu też wprowadzało do swojego systemu telemetrię Amazona, to czemu to polecać?
@humann - Proponuję - autentycznie - wizytę u kogoś, kto Ciebie z niemieckiej fobii wyzwoli. Gwoli ścisłości jednak. IBM to amerykańska spółka, w zespole CachyOS Niemieccy deweloperzy raczej są w mniejszości, w Archu także. W zespół KDE wchodzą deweloperzy z różnych krajów. Fakt - międzynarodowa Fundacja KDE ma siedzibę w Niemczech. Nawet nie chce mi się tych Twoich bredni komentować.
Kuserfeedback nie zbiera żadnych danych o ile go sobie nie włączysz. Ba, nie musisz go w wielu dystrybucjach w ogóle instalować. Jeśli nawet umożliwisz mu zbieranie danych, to zanim się wypowiesz - sprawdź jakiego rodzaju te dane są zbierane i jakie mają znaczenie dla deweloperów programów.
Zasadniczo jedynie Kaspersky jest w tym gronie w istocie podejrzany.