Úgy, hogy az Arch egy más világ. Ennyi.
Ha akarod az Arch-ba is belegyógyíthatod a PackageKit-et, ha akarod. Csinálhatsz rá AUR vagy GIT megoldást, aztán vagy fogják használni vagy nem.
Soha nem értettem, miért kéne egy egységes kaptafa minden disztrónak.
Te most valami ilyesmit hiányolsz. Szerintem. Vagy nagyon elbeszélünk egymás mellett.

Hiányolja a franc, nekem totál mindegy, mit csinálnak az Archosok, nem használok Archot. Én csak leírtam, hogy az apt, a dnf, a zypper és más csomagkezelőket támogatja a PackageKit, a pacmant, pamacot, yayt és a többi AUR helpert nem, és Archban nincs összeheggesztve a PackageKit azokkal az összetevőkkel, amikkel sok más disztróban összevan (pl. a Gnome Software, KDE Discover, Muon, Apper...).

Na álljunk meg egy szóra!! A pure Arch csomagkezelője a pacman! Semmi nem kényszerít arra, hogy AUR csomagokat használj! A pacman-nek van egy grafikus frontendje a pamac. Amit feltehetsz a pacman-el. Az AUR csomagok kezelésére van legalább 5 paracssoros megoldás ( Trizen, Pacaur, Yay és sorolhtnám). Ezek mindegyike más és más egy kicsit, lényegtelen.

Soha nem lesz az Arch-ban összehegesztve semmi, semmivel! Neked kell hegeszteni, salakot verni, új pálcát betenni!!!

Ami más disztróban szokás az itt nem! Ennyi.

Szerintem elbeszeltek egymas mellet...

Passionate about minimalistic software, the Linux philosophy, and having fun. SFF enthusiast.

Szerintem lényegében semmi.

Nem ismerem az Ubuntu universe repo-t, de ha jól látom, ott ugyan úgy előre összerakott, elkészített, telepíthető csomagok találhatók, mint a többi (pl. main) repo-ban. Azaz, ez egy ugyan olyan repo. Pont ezért is lehet az apt-vel kezelni ezt is.
Ugyanakkor Arch alatt az AUR csak csomag csak telepítő leírókat (valamint általában leírást, kiegészítő scriptet, desktop file-t) tartalmaz. Maguk a telepíthető csomagok az AUR helper használatával (vagy manuálisan a makepkg paranccsal) állnak elő a saját gépeden, majd ez kerül telepítésre. Természetesen, ha szükséges (vagy szeretnéd) a PKGBUILD-et és az egyéb scripteket a folyamat során módosíthatod.

Hogy szemléltessem a dolgot: pl. intellij-idea-ultimate-edition esetén az AUR repo-ból csak egy 1978 byte-os (jelenleg) tar.gz jön, a saját gépen áll elő az abban található PKGBUILD leíró által definiált feladatok során a több 100 MB-os telepíthető csomag.
Éppen ezért Arch linux alatt az AUR repo-ból nem lehet telepíteni pacman-al.

[ Szerkesztve ]

Alex

Van valakinek valami tuti módszere olyasmire, hogy egy Linux (Debian) bebootoljon BIOS és EFI-n is?
Külön már van rá scriptem, de a kettő együtt nem akar menni :S (USB-re akarom rakni, mindenes nyúzósnak.)

[ Szerkesztve ]

Mutogatni való hater díszpinty

Megoldva... csak egy nap volt
De az tuti hogy erről csinálok egy image-t, és elteszem backupba Még egyszer nem

Mutogatni való hater díszpinty

Sziasztok, tudnátok segíteni, hogy az alábbi cron job, hogy hogy fut ma? Azt szerettem volna megoldani, hogy minden hónapban 1-21-ig minden hétfőn fusson, tehát 27-én (ma) már pl ne.

*/3 * 1-21 * 1


“At every 3rd minute on every day-of-month from 1 through 21 and on Monday.”


Előre is köszönöm a tippeket.

inkább logoutra írnál róla

A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

Majd

Mutogatni való hater díszpinty

azé

A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

Előbb ki kéne találni, mi a francot csináltam

Mutogatni való hater díszpinty

Érdekelne, hogy ha van itt olyan, aki váltott CentOS-ről vagy váltani fog, az mire váltja le. Össze kéne raknom egy szervert, Ansible, Jenkins, Kubernetes menne rajta egy kisebb, sandbox jellegű környezetben. Mindenképp rpm-es vonalon maradnék.

Akkor szerintem Centos.
Suse se rossz, de ilyen szinten szerintem nem nagyon érdemes. Mi lenne ami nem tetszik a Centos-on?

Mutogatni való hater díszpinty

CentOS Stream? Végső soron az sem lenne rossz, csak kicsit tartok tőle, hogy instabilabb, mint egy downstream disztró.
A Suse nem lenne rossz, de azért a RHEL/CentOS vonalnak nagyobb a támogatottsága. Igazából az Oracle Linux vs. Rocky vs. Alma között vacillálok, csak nem tudok dönteni. Én szívem szerint az Oracle-t választanám, de ahogy utánaolvastam, a többség inkább az Almát vagy a Rockyt ajánlja (jellemzően csak azért, mert az Oracle az az Oracle-é).

Szerintem egy spinoff sosem lesz igazán jó , főleg szerveroldalon, mint az eredetije. Amihez az Oracle hozzányúl, az meg...

RHEL meg üzleti (amúgy jó is, de egy Red Hat-ből némi repózással CentOS-t tudsz csinálni, szóval...)

Mutogatni való hater díszpinty

Igazából RHEL-ből van free verzió, de csak magánszemélyek részére, 16 gépig (azt hiszem). De ez most céges dolog lesz. Lehet, hogy akkor maradok mégis a CentOS-nél.

Ez a Oracle Linux nem tűnik rossznak, állítólag 1:1 RHEL kompatibilis, de van belőle "unbreakable kernel" nevű, hiper-szuper stabil változat.

Az egy Red Hat spinoff Vagy Centos? Nem hiszem hogy sokkal többet adna.

Mutogatni való hater díszpinty

100 dollár/év egy developer RHEL licence a cégeknek, igazából nem nagy összeg.

Vanilla kubernetes összerakáshoz azért utána kell olvasni rendesen...

Eredeti kérdésre, hogy mire váltottunk: Ubuntu Aminek maradnia kell, az még nem eldöntött... esélyesen egyedileg lesz eldöntve, de játszik a Rocky, OL és RHEL is.

[ Szerkesztve ]

Tegnap még működött...

Az Oracle is Red Hat spinoff.

100 dollár/év egy developer RHEL licence a cégeknek, igazából nem nagy összeg.

Ha prod szerver lenne, akkor elgondolkodnék rajta, de igazából ez csak ahhoz kell, hogy ezt-azt leteszteljek néhány tíz gépes környezetben.

Ja, sokan írták, hogy Debianra váltottak...

Ezt mondtam.

Mutogatni való hater díszpinty

Akkor jót mondtál
CentOS Stream lesz, eldöntöttem, már telepedik is felfelé.

Sziasztok, segítségetekre lenne szükségem. Egy Rpi 4-en fut a Volumiom, amihez USB-n keresztül használnék egy VFD kijelzőt. LCDproc+mpdlcd segítségével pedig kiírna a számcímet, előadót. Az lcdproc automatikusan indul, viszont az mpdlcd-t nem tudom rávenni, hogy automatikusan induljon. Manuálisan kell az mpdlcd paranccsal indítani. Találtam hozzá egy leírást, de az nem működik. Valami nyűgje van és a google segítségével hiába bújom a fórumot, nem találok megoldást.

Automatically start mpdlcd @ reboot with a systemd service.

nano /etc/systemd/system/mpdlcd.service

################################
[Unit]
Description=mpdlcd
After=mpd.service lcdd.service

[Service]
Type=simple
WorkingDirectory=/tmp
ExecStart=/usr/bin/mpdlcd --no-syslog &
RestartSec=5
Restart=always

[Install]
WantedBy=multi-user.target
################################

systemctl enable mpdlcd

De az utolsó parancsra ezt írja ki:
volumio@volumio:~$ systemctl enable mpdlcd
Synchronizing state of mpdlcd.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable mpdlcd
insserv: warning: script 'mpdlcd' missing LSB tags
insserv: warning: script 'mpdlcd' missing LSB tags
insserv: Default-Start undefined, assuming empty start runlevel(s) for script `mpdlcd'
insserv: Default-Stop undefined, assuming empty stop runlevel(s) for script `mpdlcd'
update-rc.d: error: mpdlcd Default-Start contains no runlevels, aborting.

Mi lehet a nyűgje?

Alighanem hiányzik pár sor a script elejéről, valami ilyesmi:

### BEGIN INIT INFO
# Provides: mpdlcd
# Required-Start: $syslog
# Required-Stop: $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: MPD client for lcdproc
# Description: Display MPD status
### END INIT INFO

Nézd meg itt az init scripteket: https://github.com/rbarrois/mpdlcd/tree/master/initd

Szerintem az ExecStart= sorban nem az mpdlcd-t kellene beleírni, hanem az mpdlcd.debian-t. Ez legalább valid LSB scriptnek tűnik (így néz ki egy LSB initscript), Szóval lemented valahová, adsz neki +x jogosultságot, ha kell kijavítod benne az elérési utakat, bemásolod mondjuk az /etc/systemd mappába, és átírood a systemd unit-ot, hogy ezt indítsa el. De ez csak tipp, nem ismerem a szoftvert.

[ Szerkesztve ]

Átírtam erre az mpdlcd.service-t:

GNU nano 3.2                                /etc/systemd/system/mpdlcd.service

#
# mpdlcd initscript for mpdlcd
# by Stefaan Verfaillie
#
### BEGIN INIT INFO
# Provides:          mpdlcd
# Required-Start:    $syslog
# Required-Stop:     $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: MPD client for lcdproc
# Description:       Display MPD status
### END INIT INFO
#
#
#
[Unit]
Description=mpdlcd
After=mpd.service lcdd.service

[Service]
Type=simple
WorkingDirectory=/tmp
ExecStart=mpdlcd.debian
RestartSec=5
Restart=always

[Install]
WantedBy=multi-user.target

És próbáltam neki jogot adni,de már az elején elakadok :/
volumio@volumio:~$ chmod +x /etc/systemd/system/mpdlcd.service
chmod: changing permissions of '/etc/systemd/system/mpdlcd.service': Operation not permitted

A systemd unit-ot pedig hol találom és hogyan írom át?

[ Szerkesztve ]

Jajj, ez így nem lesz jó! Lehet, hogy én fogalmaztam rosszul, de a lényeg az, hogy van a systemd unit fájl, ez most így néz ki:

[Unit]
Description=mpdlcd
After=mpd.service lcdd.service

[Service]
Type=simple
WorkingDirectory=/tmp
ExecStart=mpdlcd.debian
RestartSec=5
Restart=always

[Install]
WantedBy=multi-user.target

Ugye az első sorból látszik is, hogy ez egy unit.

És van az init script, ez pedig ez az mpdlcd.debian.

Na mármost, két lehetséges megoldás van. Az 1. elméletileg megy Debianon (ha a systemd-sysv-generator működik):

1. Fogd az mpdlcd.debian-t, másold be az /etc/rc2.d mappába, és adj neki x jogot.
Igazából az /etc/init.d mappába kellene másolni, és egy symlinket tenni az /etc/rc2.d-be, de most ne bonyolítsuk.
Próbáld ki, hogy így működik-e. Ez esetben a unit fájlt el is lehet felejteni.

2. Fogd az mpdlcd.debian-t, másold be az /usr/bin mappába, és adj neki x jogot. A /etc/systemd/system/mpdlcd.service fájlod pedig így nézzen ki:

[Unit]
Description=mpdlcd
After=mpd.service lcdd.service

[Service]
Type=simple
WorkingDirectory=/tmp
ExecStart=/usr/bin/mpdlcd --no-syslog &
RestartSec=5
Restart=always

[Install]
WantedBy=multi-user.target

Ennek ne adj semmilyen jogot. Próbáld meg így is, elindul-e.

ez így biztos rossz. az lsb rész tuti nem kell az elejére, azt scriptekbe szokás irni, nem systemd unit fileokba.
nincs véletlenül egy /etc/init.d/mpdlcd script és azzal akad össze?
systemctl status mpdlcd
systemclt daemon-reload volt?

egy szerveren kubernetes
esetleg Microshift-re érdemes ránézni.

Elméletileg az systemd-sysv-init generator megcsinálja neki automatikusan a unitot, ha a script bent van /etc/init.d-ben, és van futtatási jog rajta, igaz?

HU bazz....10x olvastam el , de nem sikerült értelmeznem, bárhogy próbálkozom.

1, A systemd unit hol találom milyen címen?
2, Az 1. pontban írtat végképp nem értem. Most akkor hova másolom a debiánt? /etc/init.d- ide vagy /etc/rc2.d ide? A symlink meg ....
3, A 2. pontban másolásra meg ezt raktam össze:
wget -O /usr/bin https://github.com/rbarrois/mpdlcd/blob/c39cce8eafd4308bf255a9fcb2f92db4cfcab586/initd/mpdlcd.debian
 /usr/bin: Is a directory


De ha jól értem ilyen mappám pedig nincs.

A mpdlcd.service az megvan az már így néz ki ahogy írtad.

Jól összezavartalak, bocs.
Egyelőre semmi mást ne csinálj, csak ennyit:
wget -O /etc/init.d/mpdlcd https://github.com/rbarrois/mpdlcd/blob/c39cce8eafd4308bf255a9fcb2f92db4cfcab586/initd/mpdlcd.debian
chmod +x /etc/init.d/mpdlcd

Utána indítsd újra az RPi-t, és elméletileg mennie kell.

Én bocsi csak vakon vagyok pythonból :/
letöltés lefutott hiba nélkül, a chmod is lefutott reboot, nem történt semmise utána megpróbáltam újra lefuttatni a
bash-5.0# chmod +x /etc/systemd/system/mpdlcd.servic
chmod: cannot access '/etc/systemd/system/mpdlcd.servic': No such file or directory

De erre még mindig hibát ír :/

Gondolom kell egy e betű a végére.

Tegnap még működött...

Ennek ne adj futtatási jogot, ez a unit fájlt. Ezt töröld is ki inkább (az e-t írd oda a végére).

A systemctl status mpdlcd parancs mit ad vissza?

Sziasztok!
ma délelőtti agyvérzés során rájöttem hogy ha tetszik ha nem a nyomtatónk mögé kell egy nyomtatószerver is, ez hogy minden gép külön csatlakozik rá ez nem állapot.

szóval kérdés, illetve leginkább iránymutatást kérnék, az elképzelés a következő:

legyen egy kis SBC a nyomtató mögött amire az rá van kötve, ezen fusson egy CUPS szerver ami önmaga kezeli a nyomtató PPD-jét ha ilyet lehet, a többi gép a hálózaton keresztül ennek a gépnek küldje a nyomtatandó dolgokat.

a CUPS szerver beüzemelése oké a nyomtatószerveren, viszont az számomra nem világos hogy a kliens gépeken mit kell beállítani hogy a nyomiszervernek el is tudják küldeni a print anyagot. mindegyik Linuxos, windows kompatibilitás nem kell.

Kérhetek erre esetleg valami monkey level tutorialt vagy egyéb iránymutatást?

Köszi!

A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)

Felesleges mi?

Mutogatni való hater díszpinty

Igen, HDD-n is gyors volt, így vm-ben pedig még gyorsabb, csak úgy száguld.

Ja neem, ebből nem lesz semmi sem. Megy az archívba, aztán majd egy-másfél éven belül úgyis le lesz cserélve az egész mindenség.

a cups szerver nem tud bonjourt?

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

nem vagyok különösebben képben a bögrék lelkivilágával, ezért kérdeztem

azt se tudom hogy mivel célszerű kezdeni

[ Szerkesztve ]

A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)