- Android szakmai topik
- Milyen okostelefont vegyek?
- iPhone topik
- Apple Watch
- A hagyományos (nem okos-) telefonok jelene és jövője
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Fotók, videók mobillal
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Android alkalmazások - szoftver kibeszélő topik
-
Mobilarena
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
-
samujózsi
senior tag
Az egy hibát csinál, nem görgeti végig a fájlrendszeren. Pár éve nyűglődött egy ismerősöm hasonló témával, akkor körülnéztem a google-n és találtam egy oldalt, ami sorolt pár ellenérvet ellenük.
Az egyik az volt, hogy ECC RAM nélkül veszélyes a crc/checksum használat ezeken a fájlrendszereken, mert ha a memóriában elállítódik egy bit, annak alapján automatikus javításba kezd(het?), ami viszont sokkal nagyobb adatvesztéshez vezethet, mintha csak az az egy bit sérülne.
Sajnos már nincs meg a bookmark
Ha ott hülyeséget irtak, mea culpa! -
Dißnäëß
nagyúr
Hát ezt próbálom mondani, hogy egyáltalán nem, nem láttatok még eleget
(Minden bántás nélkül). Nem infráról beszélek és alapmegoldásokról, hanem egy üzleti részleg teljes számlázója, CRM rendszere, nyilvántartója, marketing eszközei, analitikája, full-fullba úgy az egész. És ha ezen gépeket, legyen az akár virtuális, akár fizikai, beleszámoljuk a nagy egészbe, akkor gyorsan oda a torta egyharmada MS-nek. 
Nyilván többet nem szeretnék erről mondani, pláne nem megoldás és cég neve(ke)t, de ez van, ezt jobb elfogadni, mint dobálózni azzal vakon, hogy 99% linux. (5 magyar telco-snál voltam és 2 banknál eddigi pályafutásom során). De nekem mindegy is, nem hittéríteni akarok itt (pláne nem szívem mélyén Linuxosként), csak a tényeket próbálom a valósághoz közelebb hozni. 1 példa még nem példa, én pedig rálátok mindre, vannak mindenféle megoldások, de meglepően sok MS cucc van szerver oldalon is.
-
Frawly
veterán
Persze, tökéletes teszt meg tökéletes garanciák nincsenek semmire. A fizetős, 10 éves támogatású rendszer is épp úgy eltörhet.
A tesztrendszer nem is arra való, hogy hibátlanul teszteljen, hanem teljesen blőd hibákat ki lehessen zárni vele, mikor az egész rendszer csak úgy letérdel zusammen, meg bootképtelen lesz. Tehát nagy szarvashibák kizárására van.
Egyébként nem is annyira a használt rendszer számít, hanem a szakértelem, meg hogy az ember betartsa a szakmai ajánlásokat (redundancia, backupok, snapshotok, tesztelés), és a szoftveres infrastruktúra is minél nyíltabb, minél szabványosabb legyen, és ne ilyen házilag összegányoltatott, csak régi verziókon futó, nem szabványos, zárt kódos dolgokat kell erőltetni, ami pl. szeret akármilyen rendszeren könnyen törni, és akadálya mindenféle frissítésnek. A legtöbb cégnél az utóbbi a probléma, nem is az alatta használt rendszer, hanem az inkompetens gányolás.
-
Frawly
veterán
Na, látod, ezt nem kéne tényként kezelni. A rolling semmivel nem alkalmatlanabb, mint a fizetős vállalati disztrók. Ez megint csak marketing miatti sztereotípia. Igazából aki ért hozzá, annak mindegy mit használ, meg tudja válogatni az eszközöket, licenceket, meg ha valami probléma lenne, meg tudja oldani magának. Pont ez a Linux szépsége egy Windows Server ellenében, nem is a licencdíjon spórolos, hanem Linuxon minden problémát tuti meg lehet oldani, sokféle alternatívára lehet azon belül támaszkodni, és nem vagy egy multicég zárt forráskódú megoldására rászorítva, ami vagy működik, vagy nem, újraforgatni nem tudod, alternatívák nincsenek rá.
Én nem is szeretek céges supportra támaszkodni. Mert mi van, ha a supportáló cég tönkremegy, lehúzza a rolót? Vagy épp a supportjuk XY problémánál nem tud segíteni? Akkor sok ilyen felelősségetelhárítós, öltönyös-nyakkendős, hojjdeszupport-de-szupport-100-évig-eltéess lúzereknek nagyon gyorsan megáll az élet, és megy a pánikolás, hogy nem megyen a szerver, maja világvége, rohanjon mindenki a bunkerba túlélni. Aki idióta a dolgokhoz, meg gányol, azon egy support meg egy hosszú támogatási idő sem fog tudni segíteni, tényleg csak arra lesz jó, hogy valaki megpróbálja jogászkodással a felelősséget áthárítani valaki másra.
Szerintem a licenccel sincs probléma, főleg nem szerveren, mert a legtöbb szerveres dolog pont GPL-es opensource. Ez a nonfree csomagok problémája inkább a desktopot, DRM-es és egyéb dolgokat érintik, ezek meg szerveren nem létező probléma. Meg igazából a legtöbb céget nem szokta zavarni a licenc, rezzenéstelen arccal tolják a rendezetlen licencű ZFS-t, meg hasonló megoldásokat. Ahol meg annyira licencfetisiszták, ott meg pont BSD-t szoktak használni Linux helyett, mivel megengedőbb a licence, igaz cserében a leghosszabb támogatási idő BSD-ken 5 év max.
Azt én is néztem, hogy a SUSE-nek a leghosszabb a támogatási ideje, 12 év. Ja az jó hosszú. Persze a CentOS 11,5 éves támogatása se piskóta, szerintem az is overkill kategória erősen.
-
Dißnäëß
nagyúr
Így van. Általában. (Köszi a pontosítást).
Érdekes amúgy, mert az ext4 még csak nem is CoW fájlrendszer, míg egy btrfs, zfs igen. És még ezeket sem feltétlen kell defrag-olgatni, pedig jobban van bennük az implementálva, hogy ne fragmentálódjanak annyira és ez működni is látszik, míg nincsenek agyon-teleírva (kb. háromnegyede egészséges maximum). -
-
samujózsi
senior tag
Hát az is lehet. De miért a könyvtár (ami úgy tűnik, következetesen a DCIM alatti könyvtárak egyike) n. fájljánál?
Ettől függetlenül sajnos igazad is lehet (bár ha azt veszem, hogy nem elhajt azzal, hogy nincs joga, hanem csak lefagy, akkor nem annyira security gond)A régi ubuntun mtp-tools segítségével egyáltalán nem férek hozzá, a 18.04-en meg van gnome, ott a gnome egyből mountolja(?), nem tudom, nem azzal akad-e össze a parancssor.
-
Frawly
veterán
Feltettem pár hozzászólással később a hibaüzenet első felét is. Lényegében a legelső sor volt a lényeg, NULL pointer dereference. Magyarán csak olyan memóriaterületre nyúlt, amihez nem kellett volna, szimpla bug miatt totálisan összefosta magát. Ez még oké is, de akkor a kernel panic végére ne ilyen attempted to kill init baromságot írjon, félrevezetve az embert, hanem írjon akkor unknown error, vagy erre a NULL pointer reference dologra mutató dokumentációs linket.
Az amatőr ügyfélszolgálatok szoktak ilyen baromságokat javasolni, hogy egyszerű netkimaradásnál vagy energiagazdálkodási beállítás miatti gikszernél is újratelepíttetik a Windowst, csak hogy ki legyen zárva a hiba, kényelemből félrevezetik a laikust.
Mondom, nem az a baj, hogy nem ment, mert arra számítani lehetett, hogy a legfrissebb RC nem épp a legstabilabb dolog a világon. Csak akkor ne vezessen félre a hibaüzenet, jól megvezetett, mert még nincs a témában nagy tapasztalatom, és emiatt magamban kerestem a hibát, vergődtem mindenféle konfiggal, partíciócsatolással, init problémával, közben a hibának 0 köze volt ezekhez.
-
inf3rno
nagyúr
Nem nagyon megy át, de nem ezzel van a problémánk, hanem azzal, hogy olyan hibaüzeneteket dob, amik minimálisan vagy egyáltalán nem segítenek a probléma megoldásban. Ennek semmi köze a kernel debuggolásához vagy fejlesztéséhez. A fenti esetben pl annyit kellett volna dobnia, hogy nincs rootfs csatolva és ezért leáll, mert az átlag felhasználónak erre az információra van szüksége. Ehelyett valami baromságot írt. Szerintem ez így nincs rendben, és szerintem megoldható lenne, hogy normális hibaüzeneteket adjon, csak a fejlesztők nem foglalkoznak a kérdéssel, mert plusz munka. Egyébként ez a windows-t is érinti, főleg hardver hibánál csak találgat az ember, mert nálam pl alaplap hibára írta, hogy a videokártya illesztő összeomlott...
-
bambano
titán
"Ez teljesen megoldhatatlan. A kernel nem valami 10 ezer soros sufni program.": ha meg tudod számolni, hogy hány sorból áll a kernel, akkor megoldható.
"Az end-user beleértve a rendszer gazdit is inkább ne nyúlkáljon kernel kódba pls.": miért ne? azért opensource, hogy bárki belebabrálhasson.
-
inf3rno
nagyúr
Int return-el is ugyanúgy megoldható, egyszerűen magasabb szinten másik integert kell visszaadni, nem azt, amit alacsony szintről kapsz. A goto err esetén nyilván nem megoldható, de gondolom legtöbbször az is magasabb szinten dől el, hogy szükség van e rá, vagy áthidalható a probléma máshogy. Nyilván kevesebb fejlesztési idő, meg egyszerűbb úgy, ahogy ők csinálják, aztán az end user szívhat vele.
-
Jester01
veterán
Rohadtul nem kéne ext4-et initramfs nélkül csatolgatni.
De. Az initramfs megint egy egyszerű dolog elbonyolítása. Ha saját rendszert építesz szépen minden szükséges megy a kernelbe és nem kell szórakozni az initramfs-el. Felcsatol valami átmeneti / könyvtárat amiben ki tudja mik vannak (és aminek a frissen tartása megint plusz feladat), futtat mindenféle mágiát majd a végén valahogy kicseréli a futó kernel alatt az igazi gyökérre. Kösz, nem kérem
Frawly: szerintem a blokk eszköz vagy annak valami függősége nincs belefordítva. Azt nem tudom qemu alá mi kell, de nekem ilyesmik vannak:
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_BLK_DEV_PIIX=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_SCSI_MOD=y
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
CONFIG_SCSI_PROC_FS=y
CONFIG_BLK_DEV_SD=y
CONFIG_ATA=y
CONFIG_SATA_AHCI=y
CONFIG_ATA_SFF=y
CONFIG_ATA_BMDMA=y
CONFIG_PATA_OLDPIIX=y
CONFIG_PCI=y -
Frawly
veterán
A gentoo-s kernelek is bootolnak épp úgy, ext4-ről, initramfs nélkül. Initramfs akkor kell, ha van RAID vagy LVM vagy titkosítás, esetleg a /var, stb. másik partíción lenne a roothoz képest. De ezen speciális esetek EGYIKE SEM áll fenn. Pont azért írom, hogy sima ext4 partíció, semmi extra konfig, semmi extra mount paraméter nem kell. Tehát nem ez a gond. RAID-et sem használok, csak azért lett említve, hogy nem ez a gond, hiába az md-s sorok után hal be. Egy későbbi screenshoton becsatoltam a kernel panic elejét is.
Ezt a tty konzolos mókát ki fogom próbálni. Egyébként nekem nem az a bajom, hogy nem működik, hanem hogy nem írja ki normálisan, hogy mi a baja. Lehet valami kernelfordításkor maradt ki, mert make defconfig-ot használok, de utána végigszaladok rajta egy make menuconfiggal, hogy még beletegyek 1-2 dolgot, de lényegben defconfig az egész.
-
inf3rno
nagyúr
Nem éppen, mert korrekt az lenne, ha azt írná, hogy nincs csatolva rootfs, itt meg valami huszadrangú következményt ír, hogy nem tudja az initet elindítani. Igazából még azt sem, azt írja, hogy "not syncing, attempted to kill init", ami szerintem max a kernel fejlesztőknek mond bármit, vagy még nekik sem, annyira alacsony szintű bullshit.
-
samujózsi
senior tag
Nem, írja is, hogy nem használ RAID-et. Csak ott van valami fontosnak gondolt dolog a logban.
Lehet, hogy a statikus mára elavult, én 0.99.x kernelen kezdtem és valahol 1.0 v. 1.2 környékén hagytam abba a saját kernel fordítást, akkor még a modul elnevezés volt a szokásos, a nem modul meg ugye statikusan van beledrótozva.
-
Dißnäëß
nagyúr
Semmi komoly amúgy, csak nálam úgy "kell" archiválni, hogy közben elérhetőek is maradnak az adatok.
Mondjuk az a rahedli saját CD backup, amiket a kilencvenes évek óta gyűjtögettünk anno faterral, meg sokminden egyéb még.
Kitehetem polcra is (kint is van egy 500 GB-sen) ami hiperfontos nekem, a többi ennél mérsékelten fontosabb csak, de annál meg megint fontosabb, hogy egyetlen diszken legyenek.
Nem vagyok egyszerű eset. Na, ilyenekre jó a softraid + btrfs (míg a btrfs saját raid-szerű megoldása nem lesz iszonyú stabil, silent corruption ellen jó). De lehet végül nem tökölök és feldobok egy VM-ben egy BSD alapú NAS-t, alárendelem a diszkeket és jónapot, zfs.
Még agyalok ezen azért.rsync: a tippet köszi, le-man-ozom.
-
inf3rno
nagyúr
Mert a backup is hozzásegít a rendelkezésre álláshoz, hiszen ha elveszik az adat, akkor minden leáll. Illetve a RAID is hozzásegít a biztonsághoz, mert többször letárolja ugyanazt, így egy meghajtó hibája miatt nem veszik el az adat, és nem kell azonnal a backup-hoz nyúlni. Ezen kívül a modern fájlrendszereknél (zfs, btrfs) RAID-el szokták kombinálni a block checksum-ozást, és így ezek a fájlrendszerek védenek bitrot ellen is, amire a backup önmagában nem képes. A helyzet komolyságától függően lehet a backup-ra is szoftveres RAID-et tenni, illetve lehet több backup-ot is használni, de ez azért a legtöbb projektnél ágyúval verébre.
-
Frawly
veterán
Init rendszeren tágabb értelemben nem csak a PID 1-es folyamatot hívják, hanem azt az egész megoldást, amivel a többi folyamat indítható, az induló folyamatok konfigurálhatók, stb..
De nem véletlenül írtam, hogy a systemd-vel az a baj, hogy nagyon rég nem csak egy initrendszer. Egy komplett, bloat mini OS beékelve az kernel és userspace közé. Nem csak az initfeladatokat veszi át, hanem egy csomó hálózati, biztonsági, naplózási, hardverkezelési dolgot is, meg alkalmazások közötti kommunikációs felületet.
Ha tényleg megmarad volna initrendszernek, ami tényleg csak initként működik, semmi mást nem is tud, akkor nem lenne vele nagy baj. De így kezd egyre jobban elfajulni, most fogják behozni, hogy a homed komponens a home mappát, meg egy csomó felhasználói konfigot is fog kezelni, azt is saját kézbe veszi. Így meg egy szép nap azon kapjuk magunkat, hogy az egész Linux megszűnik Linuxnak lenni, és linuxd lesz belőle, amit nem a Torvalds-féle kernel fog hajtani, hanem Pöcstering által foltozott kerneld. Na, ennek kéne elejét venni.
-
bambano
titán
"Ha minden normálisan működik és rendesen van megírva a service fájl": ezt nem vitatom, csak ha összeveted azzal, amit a vita elején írtam, akkor kiderül, hogy ez egy üres állítás.
te azt támasztod feltételnek, hogyha minden normálisan működik, én meg azt írtam, hogy a systemd jelentős része nem működik. következmény: a feltétel utáni rész sosem valósul meg.
-
bambano
titán
debianon és solarison is ugyanúgy működött, tehát van két "disztró", akkor már szabványos?
ha az init maga szabványos, de nem korrekten implementálják, akkor az az init hibája vagy az implementációé?szerinted jó a systemd, szerintem egy nagy vödör csavar. hogy ne tartson ez a vita túl sokáig, azt is megígérem neked, hogyha külső segítségre lesz szükségem hardverfejlesztési stratégia kialakításához, te leszel az első, akit meg fogok keresni.
és azt az állításomat is fenntartom, hogyha szerinted a systemd magas százalékban le van fedve tesztekkel, akkor a tesztek se érnek többet egy vödör csavarnál. a systemd használata egy rakás elpazarolt munkával jár és ez engem bosszant.
-
Frawly
veterán
A P3-ast extrém példának írtam. Nyilván értelmes ember nem használ ilyen gépet, csak hobbisták, retrózók. Ők viszont szórakozásból meghúzzák, hogy modernebb OS-t tesznek rá. Ilyen körülmények között de, felmerül, hogy mi milyen gépen hogy fut, meg az is, hogy a systemd valójában bloat.
C2D, C2Q, régi genes Core i gépek, laptopok használtan, meg refurbolva elég olcsón mennek. Ezért is nem értem, hogy miért veszi még mindig sok ember ezeket az Atom-os, Celeronos szutyok gépeket, de még olyan ember is betér néha linuxos topikokba, aki Pentium 4-re meg Athlon XP-re keres sovány disztrót. Meglepődünk rajta.
Pont itt a PH-n is az egyik retrós topikban most volt egy csóka, aki kései, 14 éves Pentium M-es gépre tett fel Win10-et. Nyilván nem ezt használja fő gépnek, van vagy másik 100 gépe otthon, közöttük gondolom modernebb is, inkább csak a kihívás meg érdekesség kedvéért kísérletezik ilyennel.
-
inf3rno
nagyúr
"Fejlesztői szemmel a systemd egy értelmezhető, modern, tesztekkel lefedett kód, ami fent van a githubon." - Hát 4 éve még nem volt túl erős a lefedettsége, reméljük azóta javult. [link] Ha már szóba került, akkor inkább OpenRC-hez lenne értelme hasonlítani, az állítólag hasonló tudású rendszer: [link].
Mindkettő fent van githubon. Beszéljenek a számok.
OpenRC: [link]
- 13k sor kód C-ben (összesen 21k sor adatfájlokkal)
- 41 nyitott issue, 114 zárt, 6 alap issue label
- 103 contributor, 52 watcher
- 3k commit, az utolsó 2 hónapja
- benchmark a cikkből 46.5 secSystemD: [link]
- 355k sor kód C-ben (összesen 650k sor adatfájlokkal)
- 1143 nyitott issue, 4226 zárt, 165 issue label
- 1185 contributor, 332 watcher
- 42k commit, az utolsó 3 napja
- benchmark a cikkből 43.5 sec355/13 = 27, tehát 27x annyi sor kód van a systemd-ben
13k/(41+114) = 84, 355k/(1143+4226) = 66, durván 20%-al kevesebb sor kódra jut egy issue a systemd-nél, igazából engem meglepett, hogy csak ennyivel rosszabb
13k/103 = 126, 355k/1185 = 300 sor kódra jut egy contributor
13k/52 = 250, 355k/332 = 1069 sor kódra jut egy watcher
300/126 = 2.4, 1069/250 = 4.3
tehát 2.4x több munkát végez egy contributor, és arányaiban 4.3x annyi kód jut egy watcher-re a systemd-nél, bár az utóbbi csalóka, mert(46.5-43.5)/46.5 = 6.5%-al több idő a bootolás OpenRC-vel
Nagyjából annyi a véleményem, mint eddig is, most vagy nagyon balfaszok a systemd fejlesztői és overengineered az egész, vagy a kód nagyrésze egyáltalán nem is az inittel foglalkozik, ha elfogadjuk, hogy az ő megközelítésükkel ugyanannyi kódból ki lehet hozni egy init rendszert, mint az openrc megközelítésével. Igazából meg lehet nézni még más init rendszereket is. SysVinit 8k sor, upstart 71k sor, mindkettő jóval elmarad a systemd-től, az upstart, ami legalább kicsit megközelíti kód mennyiségben.
Az a fogalom, hogy "standard-nek mondható" nem létezik. Vagy szabványosítva van valami, vagy nincs. A szabvány készítés általában több éves folyamat, nem csak ilyen összeszórunk valamit, aztán jó lesz alapon megy.
"Ez kb. minden fejlesztő több havi munkáját igényli, költsége millió $-ban mérhető. De valószínűleg a Debiannál sem két perc volt a váltás." - Pont ezért kellett volna valami normális init rendszerre áttérni, nem erre a szemétre. Mindenkinek kevesebb munkájába került volna egy moduláris init rendszerre való áttérés, mint egy ilyen monolitot beletákolni a disztrójukba, ahol minden mindennel összefügg. Sokan hoztak már ostoba döntéseket ilyen vagy olyan okból, elég csak megnézni a főpolgármester választás eredményeit pártpreferenciától függetlenül.
-
Sokat lehetne találgatni, hogy a Debian miért emelte be a systemd-t a rendszerbe, de az tényként kezelhető, hogy nagyjából pofán köpték magukat, amikor ezt megtették - szakítottak a KISS filozófiával, a POSIX kompatibilitással - és nincs kétségem afelől sem, hogy ezzel elindították a Linux világot egy proprietary irányba és már nem mások, mint a Red Hat szócsöve.
-
Jester01
veterán
azért ha a spotify-on leállítom a zenét, hogy megnézzek egy youtube videót ne kelljen valahogy átadni, mert rohadtul nem fog menni normálisan a dolog.
Megkockáztatom, hogy alsa-ban régebb óta van szoftveres keverés (dmix/dsnoop) mint amióta a pulse létezik. Normális rendszeren az az alapértelmezett és csak akkor van baj ha egy adott program konkrétan a hw eszközt kéri. De a legtöbb programban ez egyébként is konfigurálható. Ha meg nem, arra nem az a megoldás, hogy kitalálunk egy új hangrendszert amit minden programba külön implementálni kell hanem megjavítjuk azt az egy programot ami hülye volt. A spotify-t amúgy nem ismerem de esélyes hogy nem hülye és be lehet állítani melyik hangeszközt használja. A teljesség igénye nélkül a chrome, firefox, mplayer, xine, xbmc, wine, teamspeak, openal mind kiválóan működik alsa-val.
Az egyetlen pulse szolgáltatás ami kicsit hiányzik az az alkalmazásspecifikus hangerőszabályzás de általában ezt tudják a programok maguk.
-
bambano
titán
"A klasszik BSD style init lényegében egy shell scriptet indít, esetleg több shell scriptet, rohadtul nem a stabilitás mintaképe.": értem, tehát az egy darab, ezer éve használt, debuggolt init shell szkript az instabil, a rakás systemd szkript meg stabil.
kizártnak tartom, hogy magamévá tegyek egy ilyen véleményt systemd-től függetlenül.
"Fejlesztői szemmel a systemd egy értelmezhető, modern, tesztekkel lefedett kód": ez csak annyit jelent, hogy a teszteset írók munkája se ér egy vödör csavart se.
"service fájlt írni elég egyszerű.": és működő service fájlt?
"a sysvinit buta, mint a franc": aki ért hozzá, az ezt a tényt pozitívumként kezeli, nem hátrányként. érdekes módon én mindent meg tudtam oldani vele triviálisan.
"A gcc talán a legkomolyabb compiler jelenleg": melyik gcc? és miért nem az intel c fordítója a legkomolyabb?
-
bambano
titán
"A systemd amúgy az OS X initjére hasonlít erősen, nem a windowsra.": én nem arról beszéltem, hogy a szolgáltatásai mire hasonlítanak, hanem arról, hogy milyen szemlélettel programozták le. Ez a nagy bloatware egybe-minden-vackot szemlélet ez windows. Ez az állítás nem zárja ki, hogy beleértsd, hogy akkor az osx-et is lewindowsoztam.
"Amúgy érdekes, hogy a deb alapú csodák használói vinnyognak folyamatosan a systemd-re.": mert a deb alapú csodák tökéletesen működtek külsőleg oktrojált szemét nélkül is. Semmi szükség nem volt rá, hogy az rpm kitalálójának alkalmazottja szétcsessze a deb alapú csodákat is. Egyébként pöcstering már kifejtette, hogy a csomag rendszert is meg akarja reformálni meg a home könyvtárakat is. Csak azt nem értem, miért nem tette még helyre senki. Ha osx-et meg windowst akar csinálni a debianból, tegye meg otthon magának. Az én rendszereimet meg hagyja békén, mert az én fizetésem függ tőlük és ezért harapok.
"A pulseaudio funkciója feltétlen szükséges a rendszerbe a normális működéshez": nem, nem szükséges. De hagy emeljem már ki a korábbi állításomat ismét: sokkal könnyebben elfogadnák az emberek pöcstering lomjait, ha azok nem lennének tele hibával. És könnyebb lenne elfogadni pöcsteringet, ha amikor egy hibára reagál, a válasza nem tűnne totál elmebetegnek.
"Az ALSA magában nem elég több programos használathoz": minek kellene több programból használni a hangrendszert??? Az olyan lenne, mint amikor egy társaságba kerülsz több nővel, és egyszerre pofáznak mindenféléről. Az ember füle nincs felkészítve arra, hogy több, különböző audio streamet értelmezzen.
"A BSD init amúgy egy mindennél rosszabb szkript gányolás, komplex rendszerek készítésére alkalmatlan.": merugye a systemd az nem egy szkript gányolás...
-
Jester01
veterán
A pulseaudio funkciója feltétlen szükséges a rendszerbe a normális működéshez.
A feltétlen szükséges kicsit túlzás, én lassan 30 éve megvagyok nélküle. Mellesleg a felhasználói hang problémák 90%-a pulseaudio miatt volt abban az időben amikor még részt vettem egy program támogatásában.
Amúgy érdekes, hogy a deb alapú csodák használói vinnyognak folyamatosan a systemd-re.
Igen, mert a deb alapú csodák már eddig is stabilak voltak. Semmit nem lehet nyerni a systemd-vel csak fejfájást ha valami mégse működik mert akkor nem annyi, hogy beletúrkálsz a megfelelő scriptbe mert pontosan érted mi miért felelős és hogyan működik. Plusz bizonyos disztrók használóit még érdeklik olyan dolgok mint a szabadság és a unix filozófia. Nem kell windowst csinálni a linuxból aki azt az architektúrát kedveli az telepítsen windowst egyből.
-
bambano
titán
a systemd-ben levő cuccok jelentős százaléka nem működik.
megismétlem: NEM MŰKÖDIK. az svr4 init töredékét se tudta annak, amit a systemd, de azt mindig megcsinálta jól.a másik probléma, hogy a unix attól lett unix és sikeres, hogy kis, egyszerű építőelemekből van összerakva. van másik irányzat, azt windowsnak hívják. windowsos szemlélettel unixot programozni alapvető tévedés, mintha egy vegán arról kezdene vitatkozni, hogy a bélszínt mennyire átsütve szereti.
a harmadik probléma, hogy egy közösség által összelapátolt rendszerben egy őrültnek ekkora hatalmat adni a kezébe pocsék ötlet. különös tekintettel arra, hogy pöcstering nem először próbálkozott és bukott meg a hülyeségével, lásd pulse audio.
a negyedik probléma, hogy senkinek nincs joga ekkora pénzkidobásra kényszeríteni senkit, amennyibe a systemd megtanulására fordítandó erőforrás kerül, különös tekintettel arra, hogy egyébként a systemd nemlétező problémákra ad (rossz) megoldást.
tehát a 2-4 problémák akkor is a systemd ellen szólnának, ha egyébként az rendesen működik. de mivel ettől a rendes működéstől igen messze vagyunk, az, hogy a systemd megvalósítása egy rakás sz.r, übereli az összes többi problémát.
további probléma még, hogy például akik devuant fejlesztenek, fejleszthetnének debiant is, ha nem ette volna bele a fene a systemd-t a debianba. azzal, hogy systemd-s lett a debian, pazarlódik a munkaerő és lassul a fejlesztése. így eljutottunk odáig, hogy akik eddig debianra alapozták az életüket, azoknak most jelenleg nincs működő oprendszer választási lehetőségük.
-
A példád bőven nem ok arra, hogy egy bloatware fos legyen. Csinálja az initet és csak azt, semmi mást, de nem, már ez kezeli a logind-t, a tűzfalat, a networköt, a cups-ot... Ha elindítasz egy hosszú futásidejű ssh sessiont, majd kilépsz, cseszheted, mert teljesen kitakarítja a userspace-edet... Naccerű...
-
haddent
addikt
Ízlés kérdése. Feleslegesen (és igen, mindig, minden eset 100% -ban felesleges
) nem helyeznék ki semmit sem távoli helyszínre, főleg nem egy - egy olyan megbízható nem kémkedős aranyos kis cég kezébe, mint az m$$$$ vagy a guggle. bambano Modern, működik és egyszerű. Néhány speciális feladattól eltekintve (pl matlab) simán minden mehet webes appnak, egy helyre. Nem kell azt kiengedni sehova, mehet lokálban, aztán ha távolról mégis akarnak dolgozni akkor openvpn-as. De a lényeg, hogy nulla telepítgetés, nincs adatvesztés a kliensek meg lényegében kb eldobható hasztalan kis semmiségek. A networking is leegyszerűsödik, mert mindent megold 443 -on. Persze, nem hatékony, de azért egy modern JS / HTML5 frontend + Python backend kemény cucc tud lenni. És újra: airbag fejlesztés matlabbal, meg kernel patchelés terminálos vim -ben nem így fog történni, de így kb. ezeket leszámítva a hülye usernek oda tudsz rakni valamit amit nehéz elb.... és ha sikerül akkor is kap egy új klienst egy böngészővel aztán mehet tovább.
Nyilván ez az én értelmezésem és ennél több és kevesebb is tud lenni a "cloud". De egy példa: a cégnél konkértan 2019 -ben kiba....ott keepass fájlokat küldözgettek egymásnak emailben, és pontosan ahogy egy levlistánál régen, úgy itt is nyilván kialakult egy össze-vissza cross dependency meg 25 branch kb. És akkor így megkérdeztem, hogy oké, akkor miért nem használunk pl. egy Syspass -t? HTTPS, php encrypted, benne lehet a személyes és a csoportokra osztott jelszavak is stb.. Megszűnik a probléma. Tehát pl. kollaboráció is.
Röviden szerintem lényegében addig a pontig amíg megengedhető/belefér a veszteségesség / "hatékonytalanság", addig csak előnye van -
CPT.Pirk
Jómunkásember
Az is lesz, de a "sokkal jobban működik", az erős túlzás. Két cégét is használom, de olyan alap hibái vannak, hogy pl. az email értesítő megjön egy új plan kommentről, miközben magában a Teamsben meg várhatok 2 percet is, mire frissül a plan comment mezeje és az se gyorsítja meg, ha becsukom kinyitom a plant... Egyszer ilyen, egyszer meg normálisan megy...
Feltölteni se lehet úgy általában, hanem először a sharepointba, aztán onnan továbblikelni a planhoz... -
Ha windows 10 akkor WSL-el talán megoldható a dolog.
hogyan?
mármint úgy, hogy a legegyszerűbb mindenki is megértse a működését, ne rontsa el, ne kelljen parancsokat gépelni, és ne legyen bonyolultabb a jelenlegi Ctrl-C - Ctrl-V-nélPlusz a nem változó dolgokra hasznos lehet egy sima tar.gz
ez jelenleg úgy néz ki, hogy a kolléga végzett a munkájával, akkor felmásolja a projektet szerverre, hogy a következő kolléga folytatni tudja a következő fázissal. ennél bonyolultabb műveletet senki nem lesz hajlandó végezni, ezért kell vagy szerveroldalról megoldani, vagy kliensoldalról úgy, hogy a usernek ne legyen vele dolga.De amúgy mi ez?
Unity3D projektek -
-
Frawly
veterán
Nálam sima Archon sehogy sem ad debug kimenetet, hiába futtatom a dmesg -l debug vagy dmesg --level debug parancsokat. Sanszos, hogy kapitánynak van igaza, és külön így kell fordítani hozzá a kernelt.
De az is lehet, hogy az általad írt dynamic debug-ot nem kapcsoltam be, ezt hol lehet megtenni?
-
Ha KDE-t használok, akkor OK, amúgy a Nautilus alapú Nemo tudása nem nagyon marad el a Dolphintól. Bár ezt kinevetik, akik nem használták még.....
![;]](//cdn.rios.hu/dl/s/v1.gif)
(#28138) emvy
Abban mondjuk igazad van, hogy először a meglévő dolgok működjenek flottul!
(#28139) Plasticbomb
Nem tudom, hogy a waylandra átállás-e az oka vagy az, hogy egyszerűen ne legyen ott minden vacak csak a vertikális panelen, ami kell. Nem ismerem a Gnome3-at, egyszer foglalkoztam vele fél napig, de akkor meg teljesen átalakítottam Cinnamon kinézetűvé, abból meg már volt már épp elég......
-
-
#27428
Victor Súgó
tag
ivana
#27427
Victor Súgó
tag
Nincs kéznél a gép, így csak emlékezetből: ha két lokális könyvtár közt akarok másolni, mi a különbség, ha a könyvtárnév végére odabiggyesztem a /-t vagy ha nem írom ki?
Az egyikkel semmit sem csinált, a másikkal meg a néhány megányi eltérést tartalmazó forrást teljes egészében átmásolta, azonos kapcsolókkal (-a -r --progress), illetve kipróbáltam a -u-val is, de az is feleslegesen másolt.
Biztos, hogy PEBKAC, csak már nem látom, mit rontok el. -
Az mindegy is, annyira nem kritikus a cucc, ezért is lehet pl. permissive, kibírják, ha hétvégén belassul.
Akkor letolom a full relabelt... Hétvégén izzadni fognak a winyók
Hely az van (már ahol, de most rakom rendbe az egész szemétdombot, se az nem lesz baj, hogy esetleg elfogy a hely a /var/log-on, se az, ha megnövelem).Köszimindenkinek
-
Permissive-n lesz a végleges, szóval kizárás gond nem lesz, de maga a relabel futó rendszeren, mennyire problémás?
(A céges szabályok szerint lehet permissive, de eddig disabled volt :S Most kaptuk meg a supportját ennek a trágyadombnak, ez csak a jéghegy csúcsa, de valamit kezdeni kell vele.) -
Telepítőt kéne bootolni. Ez szerveres környezet, fejrekoppintás bármiért, de pl. iso meg kicsomagolt iso lehet.
NFSroot nem csak úgy megy, ha egy full OS van fent a hálón? Otthon csináltam olyat, melóhelyen csúnyán néznének érte.
ISO azért lenne jó, mert azzal egyből a telepítőt tudjuk behúzni, s az mar mehet fullban, vagy minimál ISO, és az tölt le NFS-ről csomagokat.De alapvetően igen, valami ilyesmi jobb lenne,nfsroot nélkül.
Meg tftp se lehet,persze. -
kezdosql
tag
a wireshark használata nem ide való, még nem is linux specifikus.
Akkor hova?
Nem lattam semmilyen hasonlo forumot, es a valaszok alapjan jol gondoltam, hogy nem linux kezdo kategoria.Amugy nem wireshark a gondom, hanem az, hogyan tudom letiltani a nem hasznalt portokat gyorsan, utana majd lehet keresgelni, mi van a gepen wiresharkkal vagy egyebekkel.
-
-
brickm
őstag
-
Tanulási céllal is lett volna - több mindent ki akartam próbálni, Vmware ESXi, Hyper-V, stb., aztán az egyiket kiválasztani, és használni is. Nem jött össze egyik sem
.
Valószínű a kernel / hálókártya modul bugos, mert amint hálót kap, kifagy.
Most Xenserver van rajta, ez már frankón megy (elég jól összerakták), az OpenXenmanager-rel elég jól el is lehet managelgetni, csak az a problem, hogy csak egy hálókártya van. Amint hálót adok a virtuálgépnek, meghal a management interfész Valahogyan meg lehet oldani...
Meg akarok még próbálni egy Ubi-t Xen kernellel aztán ha nem megy, akkor KVM amíg nem ér ide a második hálókártyám, és akkor Vmware, Xen teszt megint. -
spammer
veterán
-
CPT.Pirk
Jómunkásember
Igen ismerem, csak ő nem KDE-t használ. Amúgy egy ideje nem csináltam ilyet, mert a digiKam egy régebbi frissítése óta az állítása szerint nem nem tudja megnyitni a kamerát, pedig korábban ment neki. Mindegy, SD kártyán átviszem azt a néhány képet, amit lőni szoktam a paprikáimról.
-
Osiris
őstag
BADRAM:
Szóval lefutott a memtest:
Mivel ez elvileg a BADRAM-nak megfelelő hiba formátum, így be is írtam a /etc/default/grub fájlba, ami most így néz ki:
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
# info -f grub -n 'Simple configuration'
GRUB_DEFAULT=0
#GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=2
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX=""
# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
GRUB_BADRAM="0x91277914,0xfffffffc,0x8ca77914,0xfdfffffc,0x94947914,0xfffffffc"
# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console
# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480
# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true
# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"
# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"Természetesen az upgrade-grub is megvolt.
A dmesg kimenetében semmi nem látszik abból, hogy ezeket a memóriacímeket kikerülné.
Most akkor mi van? Rossz formában van a címzés? (Ubuntu 14.04 x64 server)
-
Osiris
őstag
A ram már ki van szedve, de így nem maradhat: virtualizált gépek vannak ezen a szerveren és kevés a memória. Sajnos nincsenek jó tapasztalataim a ram kompatibilitással kapcsolatban, az új modulokon nagyobb kapacitású csipekből van kevesebb, próbálkoztam ilyen új modullal, de nem ment együtt a maradék 3db 8GB-os modullal. Persze próbálok használtan ugyanilyen modult venni, csak még nem jött össze.Addig is érdekes téma ez a "badram". A hibás modul egyetlen helyen hibás, így szerintem nem lenne gáz így tovább használni, annyira nem kritikus a szerver és minden mentve van.
-
Erre rájöttem, hogy nem lehet megoldani csak opengl-es compositor tudja, szóval keresek valamilyen light vm-et ami tud rendes opengl és nem xrender-el megy. Valaki nem tud ilyet? A compiz már túl sok arra a gépre (512MB ram), a kwin meg főleg, az E17 talán tud ilyet, de amikor utoljára próbáltam az nem ment.
-
Rickazoid
addikt
Ez általában elég, de igazából a csomagtól függ, hogy mi is az, egyáltalán milyen programnyelvvel íródott, kész-e a "./configure+make+make install" trióval történő telepítésre, vagy mást kell vele tenni... ha kernel-hez köze van, a kernel-headers is kellhet neki (nem tudom mi a pontos neve openSUSE alatt).
A make kimenetéből általában meg lehet tudni, hogy mi a baja, mit hiányol.
(Minden bántás nélkül). Nem infráról beszélek és alapmegoldásokról, hanem egy üzleti részleg teljes számlázója, CRM rendszere, nyilvántartója, marketing eszközei, analitikája, full-fullba úgy az egész. És ha ezen gépeket, legyen az akár virtuális, akár fizikai, beleszámoljuk a nagy egészbe, akkor gyorsan oda a torta egyharmada MS-nek. 
Nyilván többet nem szeretnék erről mondani, pláne nem megoldás és cég neve(ke)t, de ez van, ezt jobb elfogadni, mint dobálózni azzal vakon, hogy 99% linux. (5 magyar telco-snál voltam és 2 banknál eddigi pályafutásom során). 
) nem helyeznék ki semmit sem távoli helyszínre, főleg nem egy - egy olyan megbízható nem kémkedős aranyos kis cég kezébe, mint az m$$$$ vagy a guggle. 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
- Csere-Beszámítás! Asus Rog Strix GTX 1080Ti 11GB GDDR5X Videokártya!
- ÁRGARANCIA!Épített KomPhone Ryzen 5 4500 16/32/64GB RAM RX 6500 XT 4GB GAMER PC termékbeszámítással
- Bomba ár! HP ZBook Studio G5 - XEON I 32GB I 512SSD I Nvidia I 15,6" 4K DreamColor I Cam I W11 I Gar
- Lenovo ThinkCentre M720s SFF / M920T tower -Számla, garancia, WIN11
- Motorola E40 64GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest