Linux Kezdõknek

[jagdtigger 260]

52 minutes ago, bcom said:

Ja persze, azt tudom. Arra akartam utalni, hogy egy másik, nem ubuntu alapú distrót húzok le, hátha az alapból más drivert telepít. 

Ja, bocsi... Ubuntu-n kívül a Linux Mint-et illetve a PoP!_OS-t tudom ajánlani. Vagy ha esetleg nem bánod vastagabb fába vágni a fejszédet esetleg egy Manjaro (Arch alapú szóval előfordulhatnak nehézségek)...

[jagdtigger 260]

Alakul a molekula....

[jagdtigger 260]

  

54 minutes ago, payskin said:

Hát az én esetemben valami nagyon komoly szellemi balesetnek kéne ehhez történnie.

Vagy csak visszanyergelsz linuxra, apropó miért tértél vissza winfosra?

[payskin 917]

Mert a Windowsban 25+ éve itthon vagyok, értek hozzá, "hatalmam" van felette, (meg)szokásaim és folyamataim vannak. Nálam működik a Windows, nincsenek napi szintű gondjaim, és kb. ugyanolyan jól tudok rajta dolgozni és kikapcsolódni.

Ebből semmi nem igaz a Linuxra.

Mondok két példát.

A 22.04-ben már alapból wayland van (kivéve a Pop OS-ben, mert ott a system76 visszarakta az x11-et). Waylanden nem működik Chrome alatt Meetben a képernyőmegosztás. WTF?! Nem valami olyan dolog, amire számítanál: felraktad az oprendszert, működik, felraktad a Chome-ot, működik, ahogy megszoktad. Aztán egyszer neked kell prezentálni 86 másik ember előtt, megnyomod a gombot, amit az elmúlt években számtalanszor megnyomtál és beüt a gebasz, mert a másik 86 ember nem látja, amit mutatnál neki. És ha nekiállsz guglizni, akkor a 3-4. találatban megtalálod, hogy a Waylandhez a Chrome-ban valami kísérleti WebRTC (?) beállítást át kell kapcsolni. Ekkor a következőképpen működik a képernyőmegosztás:

- rákattintasz a prezentálás gombra Google Meetben
- feljön egy OPRENDSZER PANEL (!!!), hogy wtf-ot akarsz megosztani?
- kiválasztod a teljes képernyőt, erre feldob egy LISTÁT, hogy a DELL U2311h-t vagy a DELL U2311h-t akarod-e megosztani?
- kiválasztod az egyiket (fingod nincs, melyik melyik, előnézet nincs)
- felugrik a Meet megosztási ablaka, amiben már látod előnézetben, hogy melyik képernyőt választottad
- ha nem jót, akkor Cancel, vissza az oprendszer panelhez
- ha jót, akkor rá kell kattintani az előnézeti képre, mert addig nem megnyomható a Share gomb (de erre nem utal semmi, percekig nem érted, hogy most miaf* van)
- ha megnyomtad a Share gombot, a Meet azt hiszi, hogy minden oké, és behozza a képernyőmegosztó ablakot, ami nem működik
- egészen addig, amíg vissza nem mész vissza az oprendszer panelre, és nyomod meg ott is a Share gombot.

Ez szerinted normális? X11 alatt megnyomod a prezentálás gombot a Meetben, feljön a két képernyő-előnézeti kép, kiválasztod melyiket akarod megosztani, és prezentálsz.

Telibe szarom, hogy ki a hülye: a Canonical, a Wayland fejlesztők, vagy a Google, ez így elmebeteg.

Mint ahogy az is, hogy kijön a 22.04 LTS úgy, hogy egyszerűen kiveszik a legacy TLS/SSL-titkosítást (nem kikapcsolják, kiveszik), és másfél hetet szívsz az új munkahelyeden a zsír új notebookra felrakott 22.04-gyel, mert sem a vállalati WiFi-hez, sem a céges VPN-hez nem tudsz kapcsolódni, sem az ssh nem működik a belső tesztszerverekre. Az IT-soknak rögtön óriási kedvence leszel, garantált. És oké, hogy a cég a Puding!, ahova dolgozni mentem, hogy nem frissítették az elmúlt X évben a titkosítási beállításokat, de miért frissítették volna, ha a 20.04-gyel mindez tökéletesen működik? És még egyszer mondom: nem egy kurva kapcsolót raktak off-ba, amit megkeresel, átállítasz, és mész tovább, nincs itt semmi látnivaló, hanem az a megoldás, hogy a 21.10-ből kell visszatenni a vállalati wifi-modult, és bevédeni az apt-ben, hogy ne akarja frissíteni. Csakhogy a 21.10 támogatása időközben lejárt, már nem tudod belőle felrakni a modul tavalyi változatát, mert beszántották az Impish repókat. Úgyhogy ha holnap véletlenül újratelepítem a 22.04-et, tökön vagyok lőve, mert nincs megoldás a problémára, illetve mehetek vissza 20.04-et használni.

Ez egy vicc.
 

[jagdtigger 260]

Az elsőt még meg tudom érteni, bár sajnos szükséges nyűg. Az x11 már igencsak csere érett.....

 

A második viszont, hogy is mondjam finoman. Ha az IT arra nem képes hogy sok év alatt átálljon a legacy megoldásról valami modernebbre akkor maguknak keresik a bajt.....

[jagdtigger 260]

Kicsit szórakoztam arch linuxal, telepítés nem épp egyszerű ezért írtam egy faék telepítő script-et:
 

Spoiler

#!/bin/zsh
#
# https://wiki.archlinux.org/title/installation_guide
#
# Basic arch install on single disk formatted as gpt and lvm, no encryption.

#Variables
OS_Drive="sda"
KB="hu"
TZ="Europe/Budapest"
hostname="arch_base"
GUI="y"

# Set KB layout.
loadkeys $KB

# Sanity chheck.
echo "Install arch on: /dev/"$OS_Drive
echo "Keyoard layout: "$KB
echo "Hostname: "$hostname
echo "Root user password: "$root_passwd
echo "Install Gnome GUI: "$GUI
if read -q "REPLY?Is this OK? (Y/N)"
then 
    echo "Proceeding to install Arch!"
else
    echo "Abort! Please edit variables at beginning of script!"
    exit
fi



# Set timezone
timedatectl set-timezone $TZ

# Format and partition disk. Presuming $OS_Drive is the drive intended for the OS.
parted -s /dev/$OS_Drive mklabel gpt
parted -s /dev/$OS_Drive mkpart primary 0% 4096MiB
parted -s /dev/$OS_Drive mkpart primary 4096MiB 12228MiB
parted -s /dev/$OS_Drive mkpart primary 12228MiB 100%
parted -s /dev/$OS_Drive toggle 1 boot

# Fromat partitions.
mkfs.fat -F 32 /dev/$OS_Drive"1"
mkswap /dev/$OS_Drive"2"

# Setup LVM.
pvcreate /dev/$OS_Drive"3"
vgcreate arch /dev/$OS_Drive"3"
lvcreate -l 80%FREE arch -n root
mkfs.ext4 /dev/arch/root

# Mount root and /boot
mount /dev/arch/root /mnt
mkdir /mnt/boot
mount /dev/$OS_Drive"1" /mnt/boot

# Activate SWAP.
swapon /dev/$OS_Drive"2"

# Install essential packages
if test  $GUI = y 
    then
pacstrap -K /mnt base linux linux-firmware lvm2 grub efibootmgr nano htop mc lightdm lightdm-gtk-greeter gnome gnome-flashback gnome-applets sensors-applet
else
pacstrap -K /mnt base linux linux-firmware lvm2 grub efibootmgr nano htop mc
fi

# System config
genfstab -U /mnt >> /mnt/etc/fstab

# Finishing install in chroot.
arch-chroot /mnt /bin/sh -- << EOCHROOT
ln -sf /usr/share/zoneinfo/$TZ /etc/localtime
hwclock --systohc
sed -i 's/#hu_HU.UTF-8\ UTF-8/hu_HU.UTF-8\ UTF-8/g' /etc/locale.gen
sed -i 's/#en_US.UTF-8\ UTF-8/en_US.UTF-8\ UTF-8/g' /etc/locale.gen
sed -i 's/HOOKS=(base\ udev\ autodetect\ modconf\ kms\ keyboard\ keymap\ consolefont\ block\ filesystems\ fsck)/HOOKS=(base\ udev\ autodetect\ modconf\ kms\ keyboard\ keymap\ consolefont\ block\ filesystems\ fsck\ lvm2)/g' /etc/mkinitcpio.conf
mkinitcpio -P
locale-gen
sed -i 's/KEYMAP=de-latin1/KEYMAP=hu/g' /etc/vconsole.conf
loadkeys $KB
systemctl enable systemd-networkd.service
systemctl enable lightdm.service
echo $hostname > /etc/hostname
grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=ARCH
grub-mkconfig -o /boot/grub/grub.cfg
#echo $root_passwd | passwd --stdin
useradd -m heathcliff
echo -e 'default\ndefault' | passwd heathcliff
EOCHROOT

umount -R /mnt
#reboot

 

 

[jagdtigger 260]

https://www.openwall.com/lists/oss-security/2024/03/29/4

 

Quote

After observing a few odd symptoms around liblzma (part of the xz package) on
Debian sid installations over the last weeks (logins with ssh taking a lot of
CPU, valgrind errors) I figured out the answer:

The upstream xz repository and the xz tarballs have been backdoored.

At first I thought this was a compromise of debian's package, but it turns out
to be upstream.

Na faxa, nem épp ezzel akartam tölteni a napot........