-
IT café
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
-
ToMmY_hun
senior tag
válasz _Dumber_ #23303 üzenetére
Kicsit utánajártam és a VMPlayer hivatalosan nem támogat ilyen funckiót. Az oka az, hogy ez felhasználói interakciókra épít, tehát elvárja hogy kézzel állítsd le mielőtt a host-ot kilövöd alóla. A szerver verzió támogatja a host-guest együttes shutdown mechanizmust.
A megoldás emiatt nem triviális. Gyanítom, hogy a fenti okból kifolyólag a szoftver készítője szándékosan nem hagyott kiskaput ennek kijátszására, szóval csak nagyon csúnya módszerekkel lehetne ezt megoldani.
Az egyik opció, hogy készítesz egy scriptet, ami shutdown esetén fut le és várakozik addig, amíg nem állítottad le kézzel a VMPlayer-t. Aztán például írhatnál egy kapcsolat orientált protokollra alapuló szerver-kliens programot, ahol a szerver a guest OS-en fut és figyelni a klienstől (host) érkező adatokat. A host-on lévő programot a shutdown scriptet editálva az első helyre rakod, ezzel elérve hogy a shutdown szekvencia kezdetén kérje a guest leállítását. Ennek elindítását a guest egy nyugtával jelezné és mondjuk a kapcsolat megszakadásából nagy valószínűséggel arra lehetne következtetni, hogy a guest leállt. Hangsúlyozom, hogy ez iszonyat csúnya és rendkívül rizikós megoldás. Semmi sem garantálja, hogy a guest valóban leállt, előfordulhat olyan eset, hogy egy mentés megfogja a leállítást, ugyanakkor az általad írt shutdown szerver már rég leállt és nincs információd a guest valódi állapotáról. Egy fokkal jobb lenne, ha közvetlenül a VMPlayer-rel tudnál kommunikálni, de gyanítom hogy erre nem adnak lehetőséget, mert akkor nem lenne értelme ezt a feature-t a szerverben kiemelni.Mi lenne, ha alapból a szerver verziót használnád?
[ Szerkesztve ]
C programmers never die, they are just cast into void.
-
bambano
titán
válasz _Dumber_ #23305 üzenetére
abszolút teljesen téves megközelítés.
először is az utolsó, ami eszembe jutna, hogy felrakok egy bármit a linuxomra, amitől nem lehet bármikor rebootolni. emiatt majd amikor fontos dolog miatt le kell állítani, akkor se fog sikerülni.másodszor neked az a problémád, hogy a windowsod nem értesül arról, hogy le kellene állnia, tehát ezt a problémát kell megoldani, nem pedig kotorászni a rendszerben és hasonlók.
a probléma helyes azonosítása után már nem is olyan nagy truváj beírni a guglinak, hogy remote shutting down windows és akkor ilyen remek oldalak kerülnek elő, amiben olyan fejezetcím van, hogy remote shut down windows from linux.
tehát a helyes eljárás az, hogyha le akarod állítani a gépet, akkor álljon le szabályosan a windows is.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
őstag
válasz _Dumber_ #23793 üzenetére
Alapból ott van elszúrva az egész, hogy a class neve és a fájl neve egyezni illik.
Egyébként beírtam ugyanezt a kódot, és compile után ment is. De!
[build_settings]
# %f will be replaced by the complete filename
# %e will be replaced by the filename without extension
# (use only one of it at one time)
compiler=javac "%f"
run_cmd=java "%e"
Itt is látható, hogy amíg te alul a java class nevével operálsz, addig ő a fájlnévvel.[ Szerkesztve ]
Tegnap még működött...
-
-
spammer
veterán
válasz _Dumber_ #24883 üzenetére
De ha dd-vel akarod, akkor ezt olvasd át: Disk cloning
[ Szerkesztve ]
„A feketébe öltözött ember a sivatagon át menekült, a harcos pedig követte."
-
BoB
veterán
válasz _Dumber_ #25594 üzenetére
Be lehet állítani a beállítások között hogy másik ablakkezelővel működjön a kwin helyett. Ha letörlöd a beállításokat akkor visszaáll default-ra, de ezek szerint vagy csak képzelted hogy openbox-al ment, vagy nem törölted rendesen.
You may corrupt the souls of men, but I am steel. I am doom.
-
_Dumber_
őstag
válasz _Dumber_ #25615 üzenetére
Annyi változott, hogy teszteltem egy kicsit.
Ha az energiakezelés ki van kapcsolva:
vagy bekapcsolom, de a beállítás így néz ki (természetesen hálózatról üzemelek):
Akkor nem történik semmi, azaz a képernyő mindig bekapcsolva marad.
Ha az energiabeállítások ilyenek:
(azaz 5 percnél több van beállítva), akkor
5 perc után lehalványodik, majd cc 3-4 perc után elsötétül a képernyőHa viszont 5 percnél kevesebbre állítom, akkor a beállított idő múlva halványodik el, majd rá 2-3 percre elsötétül (holott én ezt nem kértem).
Lassan kihullik a hajam. Van ötlet, hogy mit nézzek meg?
-
Frawly
veterán
válasz _Dumber_ #25615 üzenetére
/etc/systemd/logind.conf-ban [Login] részlegében szétnéztél az Arch Wikinek megfelelően?
-
Frawly
veterán
válasz _Dumber_ #26551 üzenetére
Nálam Arch Openbox alatt jó volt az 5.x-es és most jó a 6.0-ás LibreOffice is, mindig is fresh-t használtam. Sose volt vele semmilyen gond, bugmentesen működik. KDE alatt mondanám, hogy próbából a kompozitort állítsd le, de ha Openbox alatt is csinálja, akkor ott lehet más gond lesz.
[ Szerkesztve ]
-
_Dumber_
őstag
válasz _Dumber_ #26551 üzenetére
Probléma megoldva:
Archwiki:
force the use of a certain VCL UI interface, use one of the SAL_USE_VCLPLUGIN=gen, SAL_USE_VCLPLUGIN=kde4, SAL_USE_VCLPLUGIN=gtk or SAL_USE_VCLPLUGIN=gtk3 environment variables. These variables can be uncommented in /etc/profile.d/libreoffice-fresh.sh or /etc/profile.d/libreoffice-still.sh.
Nálam a GTK3-as beállítás vált be.
-
_Dumber_
őstag
válasz _Dumber_ #26646 üzenetére
MÉg egy két teszt:
A smartd futott, de leállítottam, -> eredmény ugyanaz..
inotifywatch kimenet:
inotify /dev/sda
-bash: inotify: command not found
root@nuc:~# inotifywatch /dev/sda
Establishing watches...
Finished establishing watches, now collecting statistics.
total access close_nowrite open filename
684 128 278 278 /dev/sda -
Domonkos
Ármester
válasz _Dumber_ #26836 üzenetére
Linux van a remote oldalon is? Ha igen akkor miert nem hasznalsz egy a linuxhoz kozelebb allo technologitat? pl X forward. Sokkal rugalmasabb tud lenni, ha a remote ablakokat is a sajat ablakkezelod kezeli.
Ha nem linux van a masik oldalon, akkor passz.Gender of electrical connectors is defined by the pins.
-
ivana
Ármester
válasz _Dumber_ #30578 üzenetére
Ne szivasd magad nem üzleti géppel, ha linuxot akarsz. Elitbook, thinkpad, latitude akár használtan. Esetleg ezek gagyibb verziói újonnan (E-s thinkpad, probook stb.), de azokkal azért lehetnek érdekes dolgok. A csúcskategória tuti megy Linuxal és abból is jobb 1-2 generációval ezelőtti.
Ugyan ez igaz a desktopokra is, csakis brand gépet érdemes.
[ Szerkesztve ]
-
ubyegon2
nagyúr
válasz _Dumber_ #30580 üzenetére
Mivel kötelező oprendszerrel eladni a gépeket, ezért ez a spórolós megoldás.
Ez nem így van, kb a gépek 15%-a Dos*, FreeDos vagy OS nincs paraméterrel megy ki a nagykerekből. Innentől kezdve, ha mégis raknak rá mást és az nem működik, tapipad hibával menne vissza az összes gép a 14 napos elállás miatt és pár hét múlva a kiskerek egyszerűen nem rendelnének több ilyen gépet a nagykerektől, az meg a gyártótól. Persze aztán lehet, hogy úgy van, ahogy írod, a gyártók meg nem olvassák az Archwiki-t.
Ja ésa 15"-os gépeken Asusnál is van normál numerikus bill.
[ Szerkesztve ]
-
ubyegon2
nagyúr
válasz _Dumber_ #30588 üzenetére
Dos/freedosnál sem hiszem hogy bármi extra működne rajta
Ezt csak arra írta, hogy kötelező lenne oprendszerrel eladni.....szóval semmi nem ösztökélné a gyártót, hogy egy Linuxot szabjon/rakjon rá, ha FreeDos is elegendő. De azt simán el tudom képzelni, hogy a tapipad numerikus része tényleg nem működik Linuxon vagy csak az átkapcsolással vannak gondok, fene tudja. A Vivobook 14-nél amúgy tán csak a metálszürke van szerelve ezzel az okos tapipaddal.
-
Vladi
nagyúr
válasz _Dumber_ #31051 üzenetére
Frissítésnél azt nézd, hogy hálózati program, vagy driver frissült -e kb akkor amióta hiba van.
Alap pszichológia, évtizede alkalmazom fórumon. Ha fingomnincs a megoldásról akkor is visszakérdezek, ezzel más szempontú problémamegközelítésre késztetem a kérdezőt. Anno smart qestion néven futott a hőskorban.
Nem félünk! Nem félünk! Itthon vagyunk e földön. Nem félünk! Nem félünk! Ez nem maradhat börtön!
-
_Dumber_
őstag
válasz _Dumber_ #31054 üzenetére
Lentebb látható előzmény után, teszteltem pár dolgot. Volt:
AP mozgatás/csere hálózaton belül (2 AP van telepítve) - hiba továbbra is jelentkezett
Más hálózatra csatlakozás. - Nem volt hiba
Beállítások csesztetése - hiba megmaradtEgy dolog maradt még, amire MasterMark kolléga hívta fel a figyelmemet, mégpedig a ARCH-on beül a kapcsolati beállítás törése.
Kitöröltem a csatlakozás beállításokat (KDE), majd újra létrehoztam (networkmanager). Azóta minden rendben ment egészen a mai napig. 1 óra után (cc 6-7x hálózatvesztés), kitöröltem ismét a beállítást. Azóta megint jó,
Mi a **kömtől száll el a beállítás és mi lehet a ludas egy egyszerű config fileban?
Van ötlete valakinek?
-
-
_Dumber_
őstag
válasz _Dumber_ #31226 üzenetére
Ha valakit érdekel akkor a problémát azonosítottam. Megoldásra vár.
(Kikerülni már ki tudom.) -
fatpingvin
őstag
válasz _Dumber_ #32253 üzenetére
miért kéne forrásból fordítani? /etc/systemd/system.conf-ban átírod ezt a két sort valami szimpatikusan kicsi időértékre, pl 5 másodpercre:
DefaultTimeoutStartSec=5s
DefaultTimeoutStopSec=5s
hogy konkrétan melyik folyamat azt leehet hogy poettering se tudja.[ Szerkesztve ]
A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)
-
-
_Dumber_
őstag
válasz _Dumber_ #32715 üzenetére
Válaszolva a saját kérdésemre:
2 napos szívás és internet feltúrása után egy kernel visszaűállítás segített a dolgon.
Rossz kernel: Arch: 5-15-81-1 LTS
Ami még biztos, hogy jó: 5-10-90-1 LTS (lehet hogy az 5-15 eleje is megfelelő, de nem próbáltam).
Valamint az aktuális Nem LTS 6-os is működik.
Új hozzászólás Aktív témák
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Ozeki Kft.
Város: Debrecen