- A hozzászóláshoz be kell jelentkezni
- 3996 megtekintés
Hozzászólások
Végre hallgathatok MP3 fájlokat
--
arch,debian,retropie,osmc,android,windows
- A hozzászóláshoz be kell jelentkezni
...alapból...
--
robyboy
- A hozzászóláshoz be kell jelentkezni
A cat foo.mp3 > /dev/dsp nem működött? :)
- A hozzászóláshoz be kell jelentkezni
Gondolom, működik, csak vacakul hangzik. :) Inkább
mpg123 foo.mp3
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Szuper Fedora 24-> 26-ra upgrade pöcröf. Semmi depend :)
Egy valami kezd az agyamra menni.
A KDE újabb 20 mp többletet produkál betöltéskor, az amúgy sem kevés töltési időhöz. :(
Nem egy villám a gépem, de ez kezd nagyon witzes lenni.
Pentium 2.4 4mag 8GB ram (667MHz)
--
Karesz
www.fotokaresz.hu
- A hozzászóláshoz be kell jelentkezni
Csinálj egy új usert, jelentkezz be abba, logoff, és új login. Ez a második ugyanolyan lassú mint a rendes useredé?
--
arch,debian,retropie,osmc,android,windows
- A hozzászóláshoz be kell jelentkezni
Csináltam egy szűz felhasználót azzal természetesen rövidebb az töltési idő. De még akkor is úgy érzem, hogy a korábbi KDE verziókhoz képest irreálisan sok. És még a videón a panel meg sem jelent.
A "terhelt" felhasználó az kb 2x ennyi idő :(
Mondjuk úgy , hogy a KDE 4fele ennyi időt molyolt az indulással.
--
Karesz
www.fotokaresz.hu
- A hozzászóláshoz be kell jelentkezni
Mit tud a KDE az Xfce-vel szemben, ami miatt ez előbbit érdemes használni? Ha az Xfce is sok lenne, akkor meg OpenBox.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Mondjuk az Xfce 4 másodperc (!) alat töltött be :)
--
Karesz
www.fotokaresz.hu
- A hozzászóláshoz be kell jelentkezni
És teljesen jól testre szabható. Nem az alapértelmezettet kell nézni, mert az ocsmány és használhatatlan. Szerintem csak demózzák vele, hogy lehet a panel rövidebb is a monitornál. Ráadásul megy Compizzal is, én úgy használom.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Arra az esetre, ha valakinek a 4.12-es sorozatú kernellel lenne egy rakás SELinuxos üzenete, ajánlom Daniel Walsh ezirányú megjegyzését:
As I have stated in other bugs like this. I believe the kernel has changed
where it used to check DAC_OVERRIDE first and DAC_READ_SEARCH Second, and if
either passed the access was allowed. The kernel changed to check
DAC_READ_SEARCH first. The problem is lots of our policy was created with the
privious kernels, so we have domains which had DAC_OVERRIDE but don't have
DAC_READ_SEARCH. We could do an experiment where we remove all DAC_OVERRIDES
in policy and Replace them with DAC_READ_SEARCH and see if everything continues
to work properly. This would increase the security of the system, since most
domains should never need DAC_OVERRIDE.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni