-
Fototrend
Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.
Új hozzászólás Aktív témák
-
bambano
titán
"kis ceg vagyunk": vagyis a te szükségleted az általános az összes debian usernél?
"ez relevans lenne, ha pl. merevlemezre irjatok az adatokat bitrol bitre": mindig lemezre írod az adatot, az ssd is solid state DRIVE.A logod nem csak kifejezetten lemezhiba miatt borulhat össze, hanem más hiba miatt is.
Az az orbitális nagy vicc, hogy pont ma délután futottam bele egy memória hibába, ami simán összeborogathatott volna bármilyen bináris adatállományt, miközben egy text log részben menthető maradt volna.
-
bambano
titán
ha keresek valamit a logban, akkor systemd esetén journalctl-lel kilistáztatom és utána grep-pel vagy valamivel keresem, megnézem.
ha text a log, akkor a grep külön program nélkül saját maga is képes elvégezni a munkáját.erre jobb napjaimban azt mondanám, hogy fork bomba
szerk: másik hsz-edre: "Stimmel. És a journalctl nem elérhető neked, vagy mi vele a gond?" például ha egy php alkalmazásban logot kell olvasni (nekem van ilyenem), akkor text lognál simán megnyitom, beolvasom, átnézem. bináris lognál forkolni kell egy journalctl-t és úgy kell elolvasni.
szerk: egyébként egy lemezhiba esetén annak van nagyobb valószínűsége, hogy a bináris log olvasható marad, vagy annak, hogy a text?
-
Persze, ha az onszopatas es/vagy a vendor lock-in rajongoja volnek, akkor egesz konnyeden meg tudnam oldani.
De en inkabb plain textben tarolom a logokat es azzal olvasom amivel epp kedvem tartja. Plain text olvaso 10 ev mulva is lesz, journalctl meg vagy lesz vagy nem (remelem nem), es ha lesz is, akkor vagy kepes lesz olvasni a 10 evvel azelotti logokat, vagy nem. Az biztos hogy en nem fogok izzadni, hogy 10 evvel azelotti verzioju journalctl binarist forditsak kezzel csak mert Poetteringnek anno volt egy ilyen idiota ertelmetlen agymenese, hogy legyen binaris formatumban tarolva a log (haszna semmi, de legalabb plusz potencialis hibaforras, kompatibilitasi problema stb).
Ha ennyire vagynek arra hogy egy harmadik fel dontson az EN adataim felett, akkor valoszinuleg macOS-t hasznalnek.
-
-
Binaris log olvasasra alkalmas programok listaja:
- journalctlPlain text log olvasasara alkalmas programok listaja:
- nano
- micro
- cat
- nl
- tail
- head
- more
- less
- vi
- vim
- mcview
- mcedit
- gedit
- kate
- notepadqq
- ...A hobbistak azt hasznaljak, ami keznel van, a kevesbe hobbistak meg azt ami leginkabb megfelelo az adott celra.
-
-
Ez nem human readable?
2025-03-18 19:29:51 status triggers-pending man-db:amd64 2.11.2-2
2025-03-18 19:29:51 status unpacked dkms:all 3.0.10-8+deb12u1
2025-03-18 19:29:52 startup packages configure
2025-03-18 19:29:52 configure dkms:all 3.0.10-8+deb12u1 <none>
2025-03-18 19:29:52 status unpacked dkms:all 3.0.10-8+deb12u1
2025-03-18 19:29:52 status half-configured dkms:all 3.0.10-8+deb12u1
2025-03-18 19:29:52 status installed dkms:all 3.0.10-8+deb12u1
2025-03-18 19:29:52 trigproc man-db:amd64 2.11.2-2 <none>
2025-03-18 19:29:52 status half-configured man-db:amd64 2.11.2-2
2025-03-18 19:29:52 status installed man-db:amd64 2.11.2-2
-
urandom0
senior tag
A Debian pl. nem is Systemd-rá állt át először, hanem azt hiszem, Upstartra. Aztán amikor más disztrók váltottak Systemdre, a Debian a következő kiadást is már azzal adta ki.
Ha jól emlékszem, volt erről szavazás Debianon belül, és akkor döntöttek a Systemd mellett.
De hogy miért döntött az összes fő disztrók a Systemd mellett, annak szerintem a legfőbb oka a praktikum, ugyanis a Red Hat adja a Linuxos fejlesztések egy nagy részét, és ha a Red Hat valamit bevezet, az rendszerint előbb-utóbb megjelenik a többi disztróban is (persze, vannak kivételek). Ugye a Red Hatnál főállású fejlesztők dolgoznak a Linuxon, a közösségi disztrók folyamatosan maintainer hiánnyal küzdenek...
Szóval így könnyebb lekövetni a változásokat. Mert pl. a Gnome is támaszkodik a Systemd-re, és ha egy disztró támogatja a Gnome-ot, akkor ez kevesebb munkát jelent neki hosszútávon, ha eleve Systemd-es. -
Eleinte jo volt (ertsd: mert nem volt jobb) es ott ragadtak mert lassuak, szerintem ilyen egyszeru. De ennyi erovel azt is kerdezhetned hogy miert a leggyakoribb Linux distro az Ubuntu, mikozben egy otvaros takolmany az egesz. Sosem fogom megerteni hogy miert hasznalja barki onszantabol, de ettol meg annak a legnagyobb a piaci reszesedese.
-
bambano
titán
-
bambano
titán
Például a google szerverein szinte biztosan nem oob linux disztró fut. Tehát pont ők azok, akiknek teljesen mindegy, hogy mi van az átlag desktop user linuxában.
Az ibm pc azért nyert, mert az ibm hagyta, hogy belepiszkáljanak a vasba. A linux azért nyert a mininx-szel szemben, mert Linus hagyta, hogy mások is hozzájáruljanak a kernelhez. A minix egy zárt rendszer, aminek elolvashatod a forrását. Mondjuk lehet, hogy lehetne párhuzamot vonni Pöttering és AST stílusa között... lol.
Mondjuk az egy érdekesebb vita lehetne, hogy a linux miért nyert a freebsd-vel szemben is...
-
vicze
félisten
Azért dobtam be, mert egy megtörtént eset nem elméleti.
Mivel Win-en kötelező a secureboot, így nyilván elő van írva. Én is használom, de tisztában kell vele lenni, hogy egyre kevesebb valós védelmet nyújt. A test key-es hülyeség több száz millió gépen tette értelmetlenné.
-
-
-
Nem, de ez sem éppen elfogadható, hogy nincs HW hiba (már) de nem tudsz vele mit kezdeni. Nem lehet egy hibás file-t törölni, az mi?
Gondolom az történt, hogy sikerült leírnia pár rekordot hibásan mind a két diszkre, és annak nem jó a checksumja. De hogy nem lehet azt mondani, hogy mindenképpen törölje azokat a rekordokat, az nonszensz.Azt nem is mondom, hogy ugyanígy táp kontakthiba esetén a tükör nem védett meg az adatvesztéstől (mondjuk az egy frissen telepített virtuálgép volt, szóval csak újra kellett rakni, de hát elvileg pont ez ellen védene
)
-
-
Én tudom, hogy nincs ilyen. Az egyetlen, aminek semmi esetre se állnék neki, random kernel verziókat próbálni, vagy kézzel system libeket cserélni (pl mesa) vagy gyalulni (pl systemd).
User programok telepítése mindenhol megoldott...
Valódi okra lehetne mondani privacy (opt-out megoldások az ördög művei) vagy hasonló corporate felvetéseket, de ezt mindenki magának kell eldöntenie. -
Vasti74
senior tag
Jelentem, kipróbáltam egy jófajta "pendrájvról" a KDE Neon-t, és 150 vagy 175%-ra skálázott munkaasztallal a 4k Youtube videók is remekül futnak kb. 20% körüli procihasználattal, és VLC-vel NAS-ról (dlna) is hibátlan a 4k filmek lejátszása, még alacsonyabb procihasználattal (eddig ez gyakorlatilag használhatatlan volt, ha nem 100 vagy 200%-ra skáláztam)
Mondjuk nagyon úgy néz ki, hogy hardveres videólejátszás az nincs, mert egy ilyen 8. generációs akár i3 proci Windows alatt 4k videó lejátszása közben alig dolgozik valamit, a GPU meg 20-30% között van hajtva - de ez van.
Szóval a KDE biztató, lehet, hogy sok-sok év után visszatérek hozzá :-)
Most akarom kipróbálni virtuális gépen a Fedora-t meg a SuSE-t: SuSE-t valamikor a 90-es évek végén ;-) használtam, az talán nem lesz teljesen idegen, de a Fedora ha jól tudom totál más világ, attól egy kicsit félek ;-)
-
vicze
félisten
Idézőjel okkal van ott.
Az hogy homályos, vagy hogy mennyire az a monitor FW-jétől függ, sajátom so-so, nem vészes, jobb mint a 100% CPU...A töredék skálázás maga működik, ezt senki se cáfolja, csak az overheadje ultra brutális...
Ráadásnak én VM-eket is futtatok, azzal teljessen leheteten bármilyen SW skálázás. -
Vasti74
senior tag
OK, köszi :-)
Barkácsolni, aztán egy frissítés - verzióváltás - újratelepítés után újra barkácsolni piszkosul nincs kedvem, úgyhogy nem gond, ha váltanom kell. Holnap szerintem kipróbálok valamit USB-ről futtatva, aztán ha rendesen működik, akkor csere...
Egy kicsit utánaolvasva szerintem a KDE Neon vagy a Kubuntu jönne be nekem: most feldobtam mindkettőt virtuális gépre, és érdekes. Nem olvastam utána, de szerintem a KDE Neon eléggé Kubuntu ;-) Viszont míg a Neon-ban a telepítéskor kiválasztottam a magyar nyelvet, és onnantól minden magyar lett, a Kubuntu-ban (24.04.1) ugyanígy csinálva a bejelentkező ablak német (Ausztriában élek) , a rendszer nagyrészt magyar, de a beállításoknál egy csomó minden angol...
Az ilyen engem eléggé zavar (az összecsapottság érzete) , szóval a kérdésem, hogy lábon lövöm magamat valamivel, ha a KDE Neon mellett döntök? -
-
-
sonar
addikt
-
-
-
Nem, amúgy nem, ezért kérdezek. És konkrétan ezért érdekelnének a buktatók.
Absztrakciók egymáson, az amúgy is van, és nem látom, hogy különösebb gondot okozna, nem csak itt, hanem nagyobb cuccokon sem. (Meg most az a sok absztrakció egymáson, hogy van egy valamilyen RAID tükröm, és azon egy virtuális diszk file? Hát ha ettől baja lesz, akkor a fél világ virtualizációja össze kéne dőljön naponta...)Truenas-t? Ez volt az eredeti kérdés.
OK, ha jól látom, lehet rajta futtatni VM-et, de... na, nem arra való.
Mezei Debian lesz, a kérdés csak a megvalósítás, meg a filerendszer.Az adat fontos, ezért van róla backup, de az meg ugye online nem elérhető.
-
-
bambano
titán
hogy rotálod a bináris logokat? eldobálsz fájlokat, nem?
a jobb syslogd-knek meg lehet adni, hogy milyen nevű fájlba logoljon. hogy a gép nevét bele lehet-e rakni a logfájl nevébe, azt még nem próbáltam. hogy dátumot bele lehet-e, tetszőleges formátumban, azt igen, működik. simán tudsz csinálni/var/log/%Y/%m/%d/syslog
nevű fájlt. nem kell rajta rotálni semmit, max. ráteszel egy linket a hagyományos helyéről.
-
urandom0
senior tag
Miert lenne nehezebb? A journal formatum append-only, ugyanugy helyre lehet allitani. Lattal mar eletben ilyen problemat?
Igen, láttam ilyet, volt hogy leakadt a SAN, és kb. két és fél órás művelet volt csak az, míg sikerült bebootoltatni a rendszert. Onnantól fogva, vagy vissza tudod varázsolni a journalt, vagy nem, és sok esetben sajnos nem. De amikor a
journalctl --verify
is csak annyit tud mondani, hogy "invalid argument", na akkor tudod, hogy hosszú napod lesz. -
ka.laszlo
újonc
Például log forwarding kissé nehézkes volna, remote logelemzésre. Nyilván ez otthon nem jellemzően kerül terítékre. De a rendszered logolási stratégiáját is kacifántosabb így kialakítani, mint a megszokott facility-kkel, ez viszont meg igényfüggő. Logrotálást egyébként hogyan gondolnád a binárissal kivitelezni? Mindent egybe, ahogy a journald odalöki? Az pedig, hogy a journald nyomja a logokat rsyslogba vagy syslog-ng-be, közröhej.
Nem, egy JSON-ban szűrni sokkal kevésbé egyszerű, mint egy plaintext logfájlban, ha minimális regex ismeretei vannak valakinek. A "világ jó részének" azért komplex feladat egyébként, mert a szakma felhígult.
Sajnos a systemd valóban, mint a kolléga fentebb leírta, az ipar szájába lett taposva, és a legkevésbé sem fogadták el örömmel - inkább lenyelték a békát. Nem nagyon látod jól tehát a helyzetet. Ha tetszik, ha nem: a Red Hat diktál, a kutya ugat (a Debian projekten is volt hőzöngés, és lett is Devuan, csakhogy egyébként sok választásuk nem volt, ha az enterprise terepen meg akartak maradni); és aki kicsit is ismeri a nagyobb cégeket, hogy miként tudnak ilyen-olyan projektek felfutni, az gyaníthatja, hogyan is lett sláger a systemd. Annak ellenére egyébként, hogy irgalmatlanul pocsék a dokumentációja a mai napig; hogy teljesen értelmetlenül ráfekszik mindenre; hogy minden pontján jól érezhetően egy önjelölt revolucionista "csakazértisfordítva" szellemben elkövetett alkotása.
Valóban vannak kézreálló tulajdonságai, például épp egy service unitot megírni viszonylag egyszerű. Mondjuk ha ez kicsivel komplexebb, mint xy tech userrel indítani egy httpd-t, és nem kézenfekvő a unit type, akkor már indokolatlanul macerás. Mellesleg sysvinit alatt sem ördöngösség egy service megírása, csak ugye kevésbé olvasmányos, lásd felhígult szakma. Viszont a systemd a KISS diszciplína célzott arculköpése, pedig az ilyesmiket annak idején elég okos emberek találták ki, még ha nem is huszonévesek voltak very senior divatdevops pozícióban 2,5 éves szakmai tapasztalattal. Már magára ne vegye senki terészetesen.
-
Vladi
nagyúr
Ne haragudj, de ez nem vélmény kérdése. Az egész műszaki világot szabványok határozzák meg, ha nem akkor nem egyéb mint kiscsaj picsogás. van olyan, hogy posix szabvány.
Nem kell feljeszteni azért, hogy fejlesztve legyen. Az meg a minimum lenne, hogy a 21. században a mérnöktársadalom elfogad legalább minimális morális elveket. pl: ha nem romlott el ne javítsd meg, vagy kiss, vagy azt, hogy itt embereknek készülnek a cuccok.
A mérnök tervezzen eszközt az emberek számára és ne a marketinges tervezzel terméket a fogyasztónak.
-
bambano
titán
nem nekem van elképzelésem a unixról, hanem az alkotóinak. és a teljes rendszert ahhoz igazították. az, hogy csővezeték van, olyan parancssori cuccok vannak, amilyenek, az átirányítás meg a file descriptorok rendszere, mind azt mutatja, hogy szöveges feldolgozásra optimalizálták a kernelt. minden más elhajlás. jelen esetben indokolatlan és helytelen.
ha az operációs rendszer nem felel meg az eredeti, alapvető tervezési filozófiájának, akkor katyvasz lesz belőle. lásd még: m$
majd meglátjuk, hogy a dinamikus dns konfiguráció a fontos-e vagy a jogszabály. mellesleg most is dinamikus a konfig, a dhcp kliens átírja a resolv.conf-ot.
-
bambano
titán
Oké, menjünk éttermi hasonlattal.
Régen volt mindenféle étterem, majd jött a maffia, mindet erőszakkal átvette, és azóta mind vegán étterem. De az ételt mindig elsózzák és kozmás.Tehát ne csak azt az állításomat figyeld, hogy a unix filozófiájának nem felel meg a systemd, hanem azt is, hogy egyébként a systemd jelenlegi állapotában egy bughalom.
Más: az előbb jutott eszembe, míg szűkös magányomban agyaltam (
), hogy a legújabb gyerekvédelmi szabály(tervezet) fényében a systemd-resolvd nem törvénysértő?
Alaposabban belegondolva mondhatjuk, hogy a tailscale a saját megoldása miatt erősen elfogult, tehát az, hogy szerintük mi a jó dns rezolválás, messze van az általános objektív valóságtól.
-
urandom0
senior tag
Egy szimpla ASCII fájl olvasásához bármilyen text editor jó, ami kéznél van. Nano, pico, joe, emacs, vi, vim, nvim, akármi. A journalt legfeljebb a journalctl-el tudod olvasni.
Le tudod írni, hogy mi az a use case, ami journallal nem megoldható vagy nagyon nehéz, a régi fájlonkénti text logokkal pedig könnyű? Ellenpéldat tudok mondani.
Írták már, ha pl. megsérül a diszk, a bináris logot nehezebb helyreállítani. Vagy ha maga a journald crashel, cseszheted a logokat. Vagy ha egy szép napon Poettering azt mondja, hogy bocsi, most megváltoztattuk a journalctl-t, nem kompatibilis a régi logokkal...
-
kovaax
őstag
Egy sérült ASCII log még olvasható, egy bináris már nem feltétlenül. Mindenben egyetértek bambano-vel. Én mondjuk unixokon nőttem fel, sokáig csak otthon használtam linuxot, és elég korán (bőven a systemd előtt) beláttam, hogy a linux a unix windows-a. Ez a véleményem azóta se változott, sőt!
-
urandom0
senior tag
A sudo teljesen jól el van PAM és polkit nélkül is, aki akarja, mindkettőt kiírthatja alóla.
"Azert hasznaljak a systemd-t a a valo vilagban, mert komplex kornyezetekben is jol mukodik."
Nem, azért használják, mert a Debian átvette, és miután az iparban a Linuxos közösség kb. 90%-a vagy Debian, vagy RHEL alapú disztrót használ, ezért a többi kis disztró gyakorlatilag kénytelen volt adoptálni, mivel nálunk nincs erőforrás arra, hogy külön utakon járjanak.
Van egy rakat sudo alternatíva amúgy.
-
bambano
titán
nem kérdés volt, állítás.
unixon alapvetően minden szövegfájl (a szükséges kivételekkel). erre lett az egész optimalizálva.
a bináris log az olyan, hogyha én beülök egy szték vendéglőbe, akkor nekem hiába magyarázza bárki is, hogy a szója meg a tofu jó, én akkor is sztéket fogok enni. azért van unix a gépeimen, mert szöveges logokat akarok.mindig az az oprendszer van a gépemen, amellyel a legegyszerűbben meg tudom oldani a feladatomat. tehát ha ascii log elég (mindig elég), akkor nem lesz bináris logom, pláne nem lesz xml meg json meg binary blob logom.
-
bambano
titán
Ha tényleg ők a linuxos világ teteje, akkor bajban vagyunk.
"This stuff is not documented ": a valóság az, hogy documented. A resolv.conf-ban szereplő dns szerverhez fordul, pont.Egyébként a systemd-resolvd-ben az documented volt, hogyha nem jó a névfeloldásod, akkor a google névszerverére fallback-kel? Mert egy ilyen ötlettől a linux kapásból alkalmatlanná válik komolyabb helyeken való felhasználásra.
A dbus támogatás meg micsoda? Minek dbus támogatás a rezolváláshoz? Megint ez a csináljunk egy naaaagy monolitikus böszmeséget a unix alapfilozófiájából történet, ahol pottering nem érti, hogy amit csinál, az fundamentálisan rossz. vannak dolgok, amiket el kell fogadni, mint egy axiómát. A unix az KISS. Ami nem KISS, az nem unix, hanem pl. windows. a systemd nem egy tuningolt unix init, hanem egy totál más rendszer initje, ami alatt tévedésből linux kernel van.
De ezek "filozófiai" kérdések. Az alapvető probléma, hogy a systemd nem működik rendesen. Nem teljesíti a saját ígéreteit, a doksiját. Amíg nem az történik, mint ami a kottában van, addig nincs miről beszélni, az csak a mostani munkahelyén normális, hogy a világ a bétatesztelőjük, debianban eddig ez nem volt.
A systemd elkaristol, amíg az alap dolgokhoz akarod használni. Amikor nekem bonyolultabb dolgokhoz kellett volna systemd támogatás, soha nem sikerült megcsinálni, mindig valami bugba futottam bele. Egyébként meg például milyen vicces, hogy a systemd gyűjti a logokat és forwardolja a syslogd-nek. Miért nem lehet ilyenkor kihagyni a systemd-t? bináris log unixon? minek?
A systemd alapvető baja egyébként, hogy működő, tesztelt, normális megoldásokat cserél le egy katyvaszra, látható előnyök nélkül. Miközben ezzel a cserével a rendszergazdákat arra kényszeríti, hogy erőforrásokat áldozzanak a változás követésére. Minek? Ki fizeti azt meg? Én fizessem meg pottering egoizmusát? A linux régen a szabadságról szólt, nem arról, hogy minden mocskot letolnak az ember torkán. Ha azt akarom, hogy pár egoista barom hülyeségéhez kelljen erőszakkal igazodnom, veszek windows licenszet.
-
Mar nemigen emlekszem, mit akartam elinditani vele service-kent; ha jol remlik, 2-3 ilyen probalkozasom volt, aztan hagytam a francba - mert cseszett elindulni. A resolved is hasonlo kaland volt, meloban kellett volna valami flexibilis megoldas, mindenki a resolved-ra mutogatott, hogy az a tuti, de a vege mindig az lett, hogy le kellett tiltani es manualisan konfiguralni az interface-eket. A binaris log, meg mint mondtam, egy egetvero baromsag: ha van text logom, akkor hajszaritoval is elolvasom, mi vagyon irva bele, a binaris loghoz meg kell a sajat kornyezete, hogy olvashato legyen - hurra.
Ez meg messze nem minden, ami miatt a systemd szar, de mivel mar ezeken a hasabokon is leirtam jonehany alkalommal ezeket, nem kezdem elolrol.
-
Kivéve, hogy rosszabbak. Nem volt még másik *nix probléma, amivel annyit szívtam, mint a resolved ökörségei, a bináris logolás egyenesen baromság, amikor meg unitot kellett volna használnom, sosem működött.
Az "ipar elfogadta": nem, az ipar csak spórol vele, a Red Hat megírja a unitokat, a többiek meg használják. Mindjuk kíváncsi leszek, mit csinál az ipar, ha a Microsoft benyögi annak az arrogáns marhának, hogy conflict of interest nekik a systemd fejlesztése, ezért abba kéne hagyni.
-
janos666
nagyúr
Mármint StrongsWAN vagy WireGuard helyett?
Utóbbi is tök egyszerű lenne, csak OCD-s vagyok, ezért úgy akarom megcsinálni, hogy inkább a szerver oldalon kelljen csak telepítgetni/konfigolni, aztán onnantól kintről bármi elérje extra szoftver nélkül (akár Android, akár iOS telefon is, nem csak Windows, stb).
Na ez lenne az IKEv2, csak az elég bonyolult ahhoz, hogy nem jövök rá jó leírás nélkül, a disztrós wiki-k pedig úgy látszik valamennyire disztró függőek is, illetve könnyű elveszni a leírásokban, mert ezer féle dolgot lehet csinálni (ilyen-olyan tunneling, eltérő login mód...). -
Vladi
nagyúr
Nahát mégiscsak érdekelnek az unalmas filozófiai feljtegetések?
Namármost az az alap paradigma, hogy egy cégnek törekednie kell a profit maximalizálására. Ezt jelenleg alapszabálynak tekintik, ha úgy tetszik az 1.-esz számú szabály. Ettől eltérni nem lehet, ahogy te is mondtad, nem elvárható.
Aztán jött a redhat és felrúgta ezt az egészet. Az 1.-es helyre egy alapvetően humán, morális szabályt helyetett, méghozzá a szabad szoftver szemléletet. A profit maximalizálása csak ez után következtett. Ehhez tarotta is magát vagy 15 évig és lám sikerre vitte ezt a modellt. Volt elég profit.
2 dolog következik ebből:
- a profit maximalizálásának fő szabálya nem kőbe vésett, ez elvethető.
- mivel nincs ezen szabályt kizáró példa az ibm felvásárlása óta ezért a főszabályhoz ragazskodni kell. Nem mellesleg lehet folytatni az emberiség rohanását a vesztébe. -
-
Ez itt egy erdekes megfogalmazas. Konkretan nincs megtiltva, de ha megosztod, nagy valoszinuseggel kihajitanak a fizetovendegek kozul.
Nem csak en gondolom azt, hogy ez GPL violation, hanem meg jo sokan, Internet-szerte - ami persze nem jelenti azt, hogy tenyleg violation, en azt remelem, hogy ez megfut valami birosagon, ami kimondja, mi az abra.
-
Oke, ugy latom, nem voltam eleg ertheto: a forraskodhoz jelenleg hozzaferoknek a GPL alapjan nem tilthatja meg, hogy megosszak azt masokkal (aka "visszatenni a kozosbe").
A GPL arrol szol (nagyjabol), ha barmilyen szinten hasznot huzol az igy licencelt open source kodbol, akkor nem gatolhatod az altalad hozzaadottak nyilvanossagra keruleset - igy adva vissza a sajat hasznodbol.
-
Vladi
nagyúr
Egyáltalán nem nyilvánvaló az, hogy termék. Az ibm számára és a teszámodra nyilvánvaló. Nem, az eredeti még működő szemlélet szerint a szoftver nem termék. A szoftver szolgáltatás. A hozzá kapcsolódó extrákért szedhet pénzt. Megjegyzem: nagyon is sikeresen. Mivel hozzáfér a komplett szabad szoftveres közösség összes eredményéhez, ezért hozzá is teszi - megjegyzem bőkézzel - a sajátját.
Tegyük már fel a kérdést, hogy ilyen korrekt oda-vissza hozzájárulás nélkül működőképes marad -e (majd egyszer egy nem szép napon) a szabad szoftveres világ? Vagy az egész folyamat vége az, hogy az emberi tudás csúcstermékét kiszervezik alólunk. mi az amit még kiszervbeznek majd alólunk?
Ha meg az üzleti érdek fogja összetartani az egész hóberevancot, már dobhatod is a kukába az egészet. Mert ha az üzleti érdek (értsd: profitmaximalizálás) lesz az 1. helyen, akkor már fel is ültetted a pusztulásba vezető vonatra. S nem, ne játszuk el, hogy ez racionalitás, mert nem az.
-
Vladi
nagyúr
Telejsen mindegy, hogy igazam van -e ebben vagy sem. Az is mindegy, hogy az faq-ban hogyan értelmezik. A lényeg az:
- lesz -e per?
- hogyan értelmezik a bíróságon?Egyáltalán képes még a közösség lépéseket tenni, hogy a big tech corp az mostmár bármilyen határt átlépegethet? Húzunk -e neki határt, vagy akármikor viheti az összes szabadságjogunkat? mert ez itt a lényegi kérdés.
-
Vladi
nagyúr
"But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program's users, under the GPL."
Tehát magadnak bezárhatod, ha kiadod onnan az gpl. Az, hogy odaadod másnak pénzért az már publikálás.
-
Vladi
nagyúr
Épp most tette meg. Ilyen kamu mellékutat mutat, mint a centosstream.
A másik: a gpl úgy írja elő, ha van egy gpl kód amiből ered bármi más is, tehát megpacheled, akkor annak is kötelezően örökölni kell a gpl-t.
Tehát írsz egy programot, ezt felveszik fedora tárolóba, majd átkerül centos streambe, minkkét helyen kap valami pachet, majd pachelve átkerül enterprise linuxba. Ott bezárul és ha ott kap pachet az már zárt lesz.
Legalább is én így értelmezem, nagyon nagyon nagyon bízom benne, hogy valami bíróságon is ez az érvelés elhangzik majd.
-
CPT.Pirk
Jómunkásember
Saját fejlesztésű termék teszter, én írom Lazarus alatt. Pár kB-os log fájlok gyűlnek a műszakok során, míg nem valaki x időnként lementi a gépről. Ennek jobb módja SQL adatbázisba (is) feltöltés lenne és régebben így is működött, de most erre nincs lehetőség.
ivana: még nem használtam brtfs-t de ismerős amit mondasz, ránézek.
gregory91: nem, azt nem terveztem.
-
-
fatpingvin
addikt
ez tök érdekes mert rengeteg laptop megfordult a kezem alatt de most találkozom vele először. ami nem integrált Intel volt az mind ReTek.
probléma valóban nincs vele, hálózati interfész, nekem valahol szimpatikus is de az kicsit zavart hogy kb semmi ilyen általános tudnivalók jellegű leírással nem találkoztam. ebayen viszont a tálcás kivitel röhejesen drága belőlük. -
fatpingvin
addikt
ha kisteljesítményű NASom van akkor arról nem fogok adatot streamelni hanem simán storage szervernbek fogom használni. az "annyira öreg hogy csak SMB1-et tud" meg elég nehezen értelmezhető, esetleg az lehet hogy annyira öreg hogy már nem tudok rá valami supported general purpose Linux disztrót telepíteni. ha ez amúgy sem opció, hát, olyan hardverem meg nem lesz
ahogy smart tv-m meg hasonló marhaságaim nincsenek.
-
Az NFS tényleg elég gagyi egy csomó célra, az SMB sokoldalúbb rendszer. De az SMBv1-et tényleg felejtsük már el a francba.
(#32832) emvy A CPU használat networking esetén értelmetlen kérdés protokoll nélkül. Nem mindegy mit csinálsz. Maga a fogadás az csak egy másolás szinte, de pl. egy 10G-s linken csak az alap dolgok el tudnak vinni elég sok CPU időt.
(#32838) Sub-ZeRo Első körben ezt nézd meg. Bár nem feltétlen module param, config time is ki lehet herélni belőle. zcat /proc/config.gz | grep CIFS_ALLOW_INSECURE_LEGACY + samba configból is ki lehet lőni.
-
bambano
titán
kösz, hogy flame topicot csináltál a nagy linux topicból.
hiába gondolod, hogy megfelelő otthonra az smb v1, ha nem fordítják bele a támogatását a programokba.
egyébként egy nas képes egyszerre több protokollon is megosztani. ha a telefonjának smb kell, akkor használjon a telefonja felé smb-t. ha a desktopján linux van, akkor pedig nfs-t.
-
Na, megvannak az okok.
1) Az un. "tiled" kijelzőket, amiknek a nagy felbontás miatt több bemeneten kell egyszerre hajtani, csak a Gnome támogatja. A támogatás úgy működik, hogy a kijelző az EDID információkban közli, hogy ő egy tiled kijelző, és el is mondja, hogy milyen elrendezésben. Ezt a Windows, a Mac és a Gnome támogatja, más nem, ordas hackek vannak egyéb window managerekre, rossz eredményekkel.
2) a videón látható tearing egy Mutter bug (a Gnome Wayland-implementációja), javítás majd idővel érkezik.
-
vargalex
félisten
Ráadásul találtam hasonló problémát Intel CPU-val is (még korábbi kernellel).
-
En nem tudom kiprobalni, nincs hozza vasam, de technikailag erdekelnenek a reszletek - remelem, kiderul, mert ez komoly problema lehet az AMD szamara. Nem azert, mert drukkolok nekik, hanem mert mindenkinek jo, ha egeszsegesek a piaci reszesedesek (ez pl. olyan, amit nem latunk a GPU piacon).
-
-
-
-
-
AcCEsS
senior tag
Huhhh, ez nekem semmit nem mond:
read(7, "\34\0\200\0\300\6\0\0\254\1\0\0\36op\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32768) = 64
getpid() = 20186
poll([{fd=3, events=POLLIN}, {fd=3, events=POLLOUT}, {fd=4, events=POLLIN}, {fd=5, events=0}, {fd=6, events=0}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}], 8, -1) = 1 ([{fd=3, revents=POLLOUT}])
write(3, "S\353}a\227\303\211\246\355\334\271\305!_ \352:q\322\235\315D\243\233\356'j\230\226\210\333O"..., 100) = 100
poll([{fd=3, events=POLLIN}, {fd=3, events=0}, {fd=4, events=POLLIN}, {fd=5, events=0}, {fd=6, events=0}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}], 8, -1 -
amargo
addikt
Jól átsiklottam a kérdésed felett..
Alapjában véve 10-20 közötti a context switch, a legtöbb "kicsi" konténer van 3-4 nagyobb és van 2 db virtuális gép, ami mindig fut, abból az egyik sincs kimondottan terhelve.
Van persze több kisebb DB is.Azt mondanám, hogy leginkább memória igényes feladatok vannak.
A terhelés elég alacsony:LOAD 12-core
1 min:3.03
5 min:3.81
15 min:3.55
-
CPT.Pirk
Jómunkásember
Mikor kérte a passphrase-t, akkor entert ütöttem. Vagyis elvileg nincs passphrase. Ugyanezen a gépen van git szerverem a git felhasználó alatt, ott ez a pubkey működik.
Nekem ez gyanús:
can't open /dev/tty: No such file or directory
Hogy ezt a Windowsos gép cmd-je adja vissza. Mert hát ez Linuxos fájlrendszerben keres valamit Windows alatt. Vagy nem tudom.Netszemete:
A useremnek van jelszava. -
CPT.Pirk
Jómunkásember
A key fájl az 664, és a tulajdonosa a userem. Ez szerintem oké.
Az egészet nem másoltam be, a lényeg szerintem innen van a -v -vel futtatáskor:
debug1: Next authentication method: publickey
debug1: Offering public key: C:\\Users\\Borisz/.ssh/id_rsa RSA SHA256:szPorBR6Y3azDvPx3qlkfoUKJWOCqMu0pDen/EALbVM
debug1: Server accepts key: C:\\Users\\Borisz/.ssh/id_rsa RSA SHA256:szPorBR6Y3azDvPx3qlkfoUKJWOCqMu0pDen/EALbVM
debug1: read_passphrase: can't open /dev/tty: No such file or directory
Enter passphrase for key 'C:\Users\Borisz/.ssh/id_rsa':
debug1: Trying private key: C:\\Users\\Borisz/.ssh/id_dsa
debug1: Trying private key: C:\\Users\\Borisz/.ssh/id_ecdsa
debug1: Trying private key: C:\\Users\\Borisz/.ssh/id_ed25519
debug1: Trying private key: C:\\Users\\Borisz/.ssh/id_xmss
debug1: No more authentication methods to try.
borisz@...: Permission denied (publickey).
Aztán a -vvv -vel futtatva ugyanez így néz ki:
debug3: sign_and_send_pubkey: signing using rsa-sha2-512
debug3: failed to open file:C:/dev/tty error:3
debug1: read_passphrase: can't open /dev/tty: No such file or directory
Enter passphrase for key 'C:\Users\Borisz/.ssh/id_rsa':
debug2: no passphrase given, try next key
debug1: Trying private key: C:\\Users\\Borisz/.ssh/id_dsa
debug3: no such identity: C:\\Users\\Borisz/.ssh/id_dsa: No such file or directory
debug1: Trying private key: C:\\Users\\Borisz/.ssh/id_ecdsa
debug3: no such identity: C:\\Users\\Borisz/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: C:\\Users\\Borisz/.ssh/id_ed25519
debug3: no such identity: C:\\Users\\Borisz/.ssh/id_ed25519: No such file or directory
debug1: Trying private key: C:\\Users\\Borisz/.ssh/id_xmss
debug3: no such identity: C:\\Users\\Borisz/.ssh/id_xmss: No such file or directory
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
borisz@...: Permission denied (publickey).
Vagyis ha jól értem, ezt nem lehet üres passphrase-el használni?
-
bambano
titán
nekem akkor volt csak szükségem a szervereimen monitorra, amikor nagyon összedőlt rajtuk minden. még hálózat se volt rajtuk.
ilyenkor arra számítani, hogy rádugsz valamit és lesz benne hálózat, szerintem nem hatékony.
ha meg megy a hálózat, akkor van ssh, akkor nem kell monitor. -
CPT.Pirk
Jómunkásember
és Bambano,
Igen, az embedded eclipse Remote SSH módját üzemelem most be. Nekem kicsit szokatlan a dolog, mert ennél butább beágyazott eszközökre fejlesztettem eddig ahol nem volt SSH meg hasonlók, vagy rendesen asztali PC-re.
Az már megvan, hogy ráküldi a binárist az eszközre... Futtatni még nem sikerült mert szerintem nem arra fordult le a bináris amire kellene de már az agyvérzés kerülget így is a sok több éve elavult tutoriál megnézése után.ivana: igen, headless jelenleg. Jelenleg.
Tudod mikor a marketing kitalálja, hogy ez nagyon jó, de tegyünk rá egy érintőképernyőt is, az milyen trendi manapság és biztos nem bonyolult megcsinálni...
Új hozzászólás Aktív témák
- PlayStation 4
- EA Sports WRC '23
- CMF Phone 2 Pro - a százezer forintos kérdés
- CASIO órák kedvelők topicja!
- Melyik tápegységet vegyem?
- Beárazták az projektoros Ulefone-t
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Honda topik
- Luck Dragon: Asszociációs játék. :)
- Kormányok / autós szimulátorok topikja
- További aktív témák...
- Játékkulcsok olcsón: Steam, Uplay, GoG, Origin, Xbox, PS stb.
- Eladó steam/ubisoft/EA/stb. kulcsok Bank/Revolut/Wise (EUR, USD, crypto OK)
- Microsoft licencek KIVÉTELES ÁRON AZONNAL - UTALÁSSAL IS AUTOMATIKUS KÉZBESÍTÉS - Windows és Office
- Bontatlan - BATTLEFIELD 1 Collectors Edition - Játékszoftver nélkül
- Kaspersky, McAfee, Norton, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- Apple iPhone 14 Pro Max / 256 GB / 88% akkumulátor / 1év Garanciával / Gyári Független
- Xiaomi Redmi 12 Pro 5G 128GB, Kártyafüggetlen, 1 Év Garanciával
- BESZÁMÍTÁS! ASROCK H310CM i5 9600K 32GB DDR4 500GB SSD RTX 3050 8GB DeepCool Tesseract SW 500W
- Amazon Kindle 10th Generation ébresztős tok
- Telefon felvásárlás!! iPhone 12 Mini/iPhone 12/iPhone 12 Pro/iPhone 12 Pro Max
Állásajánlatok
Cég: Liszt Ferenc Zeneművészeti Egyetem
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest