Hirdetés
- Megjött a Cherry legfrissebb, taktilis karakterisztikájú kapcsolója
- 8 bővítőhelyes Jonsbo "akvárium", akár kábeleket rejtő alaplapokhoz is
- 4K felbontású, 240 Hz-es OLED monitorokkal köszönti az őszt a Lenovo
- Ismét egy teljesen friss egérrel gyarapította kínálatát a Pulsar
- Legalább 20 éves lemaradásban vannak a kínai litográfiai cégek?
- Ismét egy teljesen friss egérrel gyarapította kínálatát a Pulsar
- Megjött a Cherry legfrissebb, taktilis karakterisztikájú kapcsolója
- Most Kína tiltotta ki a nemrég exportengedélyt kapott AI gyorsítókat?
- Milyen billentyűzetet vegyek?
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Mini PC
- ASUS ROG Ally
- Xiaomi Mi Box androidos médialejátszó 4K és HDR támogatással
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Azonnali notebookos kérdések órája
-
PROHARDVER!
Ubuntu Linux Összefoglaló
Hivatalos Ubuntu dokumentáció
Amennyiben kérdésed lenne, kérünk, add meg a szükséges adatokat a hiba minél pontosabb leírása mellett:
-számítógép típusa, hardverek pontos megnevezése (különösképp videókártya, vagy hálózati egységek)
-a használt rendszer pontos neve, verziója, a grafikus felület
-mikor és hogyan jelentkezett hiba, mi váltotta ki (program telepítés, frissítés, ...)
-eddigi próbálkozások a megoldásra (ha voltak ilyenek)
A hardverinformációkat legegyszerűbben úgy gyűjtheted össze, ha megnyitod a Terminál nevű programot a menüben. Ide írd be a következő parancsokat (mindkettő után nyomj Enter-t):
lspci
lsusb
Új hozzászólás Aktív témák
-
válasz
gyulank #19600 üzenetére
Nincsen visszafrissítési lehetőség, ez alapból ellentmondásos is.
Például azt tudod tenni ilyen esetekben, hogy készítesz egy visszaállítási pontot a kiinduló állapotról, majd ha meggondoltad magad, akkor pár percig hátradőlve várakozva visszaállítod a rendszert.
Ilyen fejlesztési stádiumban levő rendszerek esetében a napi szintű mentést egyébként is érdemes betartani, mert ami ma jó, az holnap könnyedén tönkremehet egy frissítéstől. A javításig pedig mégiscsak egy nagyjából működő rendszert kéne használni. -
válasz
gyulank #19595 üzenetére
A 15.04-es kiadás még erősen fejlesztési szakaszban van, egyáltalán nem érdemes komolyabban használni. A második béta kiadástól (március 26.) lehet értelme a váltásnak ha már nagyon izgulsz, de persze még akkor is több probléma jelentkezhet mint a stabil kiadás után (amikor még mindig rengeteg kisebb-nagyobb hiba van a rendszerben). A megfigyeléseim szerint az utolsó 1-2 hétben valami csoda folytán minden komolyabb hiba elhárul, és nagyjából használhatóvá válik a rendszert.
-
válasz
lev258 #19590 üzenetére
Ez nem bug, hanem egyszerűen most frissítették a Syslinuxot 4.05-ről 6.03-ra. A kettő között átvariálták a binárisok típusát. Idézet az 5.0-ás verzió changelogjából:
Changes in 5.00
com32: Switched from the COM32 object format to ELF as it is a much more powerful format that allows undefined symbols to be resolved at runtime and dynamic loading of module dependencies, which means modules now become shared object files instead of statically linked binaries - reducing both disk space and runtime memory consumption.
Vagyis már 2012 vége óta inkompatibilisek egymással, ez pedig most jött elő a 14.04-es és 14.10-es kiadás között. -
válasz
ubyegon2 #19545 üzenetére
Ez a tároló tesztelőknek van. Mármint azoknak akik jelenteni, illetve javítani tudják a problémákat. El nem tudom képzelni, hogy egy átlag LTS felhasználónak mi szüksége lenne rá. Bár jó nem mondom, pl. egy Systemback segítségével ellehet játszadozni vele, de egyáltalán nem érdemes hosszabb távra gondolkodni benne.
-
válasz
ubyegon2 #19543 üzenetére
Ha nem gurukról van szó, akkor hogyan jön ide ez a PPA?
=== WARNING ===
Make sure you know what you are doing! You are getting bleeding edge snapshots!
You should have a stable experience most of the time, but there will be problems!
Nagy élmény lehet átlagos felhasználóknak ez a PPA. Gondolom az összes LTS felhasználó ilyen teszttárolókat használ. -
válasz
Atlantisz48 #19533 üzenetére
Eleve nem is igen látok ezekben a PPA-kban Trusty-hez 3.14-es csomagokat. Így kicsit elég nehéz lenne velük arra frissíteni. Ráadásul mi értelme van az LTS-nek ha te ilyen tárolókból frissítesz? Elolvastad pl. ezt?
=== *WARNING* ===
The packages here have been deemed not ready for general use, they have known bugs and/or regressions, sometimes of a critical nature...(#19534) ubyegon2: Mutasd benne azt a rengeteg 3.14-es csomagot.
-
válasz
Atlantisz48 #19531 üzenetére
Az első probléma nyilván az, hogy az a videó nem Ubuntu 14.04-hez készült...
-
válasz
Rimuru #19393 üzenetére
Na, mivel régen néztem és több géppel ezelőtt (régebbi UEFI szabvánnyal), lecsekkoltam megint. Úgy tűnik, hogy most már rendesen bootol UEFI módban is dd-vel felírt módon, úgyhogy az tényleg elég univerzális megoldásnak mondható most már.
Sajnos ettől függetlenül az ISO szabvány nem túl jó, és a használható fájlméretkorlát miatt nálam megmarad esetlegesen használható kompatibilis módnak. -
válasz
szundybence #19376 üzenetére
Szerintem az egy nagy határ k@ki, örül az ember neki ha egyszer normálisan működik. Bár ez egyébként az összes Ubuntus (értsd, Canonical által írt) Python programra jellemző, legalábbis ahogy én elnéztem. De amúgy jó ha jó, amikor éppen nem ír ki semmi hibát és még el is indul a felírt cucc. De én többet nem fogom használni, az biztos. Eleget szenvedtem már vele.
-
válasz
szundybence #19374 üzenetére
Mi a jó megoldás? Attól függ, hogy mi a cél. Én ha csak felakarom rakni a notimra a legfrissebb Ubuntut, akkor fogok egy pendrive-ot (esetleg memóriakártyát vagy külső vinyót, mindegyikre volt már példa) és rámásolom a telepítő tartalmát, majd feltelepítem a rendszert. Ha régebbi gépre kell, akkor meg a dd-t használom én is. Ha a Systemback segítségével készített képet akarok kiírni (ez jellemzőbb), akkor meg a Systembacket használom. Na mondjuk annyi előnyöm mindenképpen van, hogy tudom, hogy mi kell ahhoz, hogy sima fájlmásolás után hagyományos BIOS-szal is elinduljon a telepítő.
-
válasz
Rimuru #19372 üzenetére
Nem hiszem, hogy ez az ISO-n múlna (legfeljebb a tartalmán), inkább azon, hogy ha a pendrive fájlrendszere ISO, akkor azt olvassa-e az UEFI. Elképzelhető, hogy most már van olyan ami kezeli és látja a .efi fájlt rajta (hiszen nyilván azt kell betölteni a rendszerindításhoz), de nálam eddig nem volt jó. Bár nekem igazából mindegy, számomra a sima fájlmásolás is kitűnő (egyébként Windowshoz is optimális). Általános telepítőt meg úgyis a Systemback segítségével kreálok (alapvetően az is másol, de lekezeli a nagy fájlokat is (4 GiB-os méretkorlát), és kompatibilis az UEFI-vel meg a hagyományos BIOS-szal is). Sőt, most majd még memóriakártya-foglalatban levő memóriakártyára is lehet majd írni vele.
-
válasz
N0zer0 #19369 üzenetére
Viszont mostanság már UEFI-s gépek vannak, azok meg nem olvassák az ISO fájlrendszert, így nem tudják UEFI módban betölteni a telepítőt (ami nyilván szükséges). Ergo manapság már a dd nem feltétlenül jó megoldás, habár egy egyszerű fájlkezelő is megteszi a FAT32 fájlrendszer társaságában.
-
válasz
szundybence #19237 üzenetére
Mármint arra gondolsz, hogy te mindenképpen fizetni szeretnél érte, vagy arra, hogy az ingyenes megoldások sz@rok? Előbbire legalább ott van az adakozási lehetőség.
-
válasz
szundybence #19232 üzenetére
Ha a Systemback segítségével akarod megoldani, akkor kelleni fog egy kisebb partíció (minimum 300 MiB) a /boot csatolási pont alá a 2.0-ás penről (+ az UEFI-hez is ha az van, az egy 100-as a /boot/EFI alá), a többi meg mehet a másikról. Kb. így néz ki a dolog.
-
válasz
szundybence #19230 üzenetére
A /boot könyvtár alatt találod a Linux kernelnek azt a részét ami alapból és teljes egészében betöltődik a központi memóriába. Ahhoz, hogy működjön a dolog, ebben kell lennie a vezérlőhöz és az eszközhöz drivernek, kezelnie kell a partíciós táblát és a fájlrendszert. Ha mindez megvalósul és látja a rendszer partícióinak többi részét, akkor betöltődhet a rendszer. Nyilván ha bármi feltétel modulban van a root fájlrendszern, már nem fogmenni a dolog, és a GRUB kiírja, hogy a root partíció nem található.
Vagyis itt nem a boot-szektorrol van szó, a lényeg a kernel betöltődésén van. -
válasz
szundybence #19225 üzenetére
Alapesetben működik a dolog (én már igen sokszor véghezvittem mert nekem van Ubuntum külső vinyón), de nyilván egy külső vezérlővel ami nem deríti fel az eszközt a számítógép bekapcsolásakor, nem fog menni. Ahhoz már előbb be kell tölteni a kernelt (az felderíti az eszközt, látni fogja a partíciókat), vagyis telepített rendszer esetén külön '/boot' partícióra van szükség ami bootolható. Igazából sebességben ezzel sem vesztenél semmit még akkor sem ha az egy pendrive lenne 2.0-ás USB-n.
-
válasz
szundybence #19032 üzenetére
Pedig a forrásból szépen kivehető, hogy mit csinál mikor rendszert frissít.
De arra akartam utalni, hogy csak simán az apt-get van használva a Systembackben is (azokat az utasításokat csak látod), vagyis ha ezek a parancsok nem szedik le (persze nem is kell nekik), akkor nem tudom, hogy miért távolítódik el.
-
válasz
szundybence #19028 üzenetére
Ezeket a parancsokat kéne megnézni (ezért írtam őket), hogy a kiadásukkor elakarják-e távolítani ezt a nyelvi csomagot. Ha nem, akkor jó kérdés, hogy mi szedi le. Itt megnézheted, hogy a Systemback sem végez különösebb varázslatot, csak keress rá a supgrade szóra.
-
válasz
szundybence #19026 üzenetére
Nem tudom, én ezzel a jelenséggel még nem találkoztam, és ahogy nézem nincs is semmi olyan ami indokolná, hogy a Firefox (vagy egyéb más csomag) frissítésekor automatikusan eltávolítódjanak a nyelvi csomagok.
De akkor ezek szerint azt mondod, hogy miután kiadtad ezt a parancsot:sudo apt-get install firefox-locale-hu
Ezek közül valamelyik el is távolítaná?
sudo apt-get dist-upgrade
sudo apt-get autoremove -
válasz
fredooo #19020 üzenetére
Az LTS rendszerek valóban stabilabbak lehetnek önmagukban, és persze hosszabb távon támogatottak. De ez a rengeteg külső tároló eléggé belerondít ebbe a képbe. Mármint hogyan lenne stabilabb ha ugyanúgy újabb - visszaportolt, külsőleg támogatott és kevésbé tesztelt - csomagokat használsz? Nyilván egy-két PPA belefér ha valami nincs bent a tárolóban, de alapból még a kernel frissítésével sem kell törődni, csak ha valódi indok van rá. Az LTS rendszer stabilitását a jól bejáratott stabil rendszermag is adja. Idővel persze adnak az LTS-ekhez újabb kerneleket az újabb hardverek támogatása miatt, de azokat tesztelik a későbbi - LTS-ek közötti - kiadásokban.
Mivel ezek a rendszerek már öt évig támogatottak, még a PPA-kban sem lesznek hozzájuk végig friss csomagok. Ennyi idő baromi hosszú a számítástechnikában, az újabb szoftverek egyszerűen már majd nem lesznek kompatibilisek a túl régi rendszerekkel (nyilván ezért érdemes lehet újabb LTS-re váltani).
Meg őszintén szólva nem is tudom, hogy ezt most pontosan miért írtad be, vagy legalábbis miért így. Az rendben van, hogy neked ez így bejön, de nyilván senki sem fogja mindezt utánad csinálni úgy ahogy írod, akármennyire is zseniális. Én speciel egyáltalán nem ilyen rendszert használok, márpedig a leírásod eléggé specifikusan megmondja, hogy mit is kéne csinálnom, hogy pontosan ugyanolyanom legyen mint neked (nemhogy senki másnak).(#19022) fredooo: Frankó, de az újabb nem mindig jobb vagy stabilabb. Mégis miért jó az ha a Unity mindig a legújabbra frissül? Főleg daily build???
-
válasz
szundybence #18988 üzenetére
A firefox-locale-hu csomag legyen telepítve, kb. ennyi.
-
-
válasz
szundybence #18917 üzenetére
Hogy mi van? Nem teljesen értem a kérdést, de:
thunar /könyvtár/elérési/útvonala/amit/meg/szeretnél/nyitni
-
válasz
nolika #18870 üzenetére
Az a vinyó gyorsabb mint ami egy átlag notiban van. Azokra meg telepítenek mindenféle operációs rendszert. Szóval ennyiből nyugodtan futtathatod róla. Pendrive-ról meg ugye nem túl szerencsés teljes értékű oprendszert futtatni, mert egy átlag SSD-nél lényegesen gyorsabban tönkremegy alatta.
-
Egyébként tervezek írni ehhez kapcsolódóan egy új programot, illetve már hozzá is láttam pár napja. A grafikus alkalmazásokat egyre nehezebb normálisan elindítani root jogosultságokkal. A gksu-val elégedetlen vagyok az utóbbi pár kiadás óta, ráadásul nem az alaptelepítés része már. A pkexec pedig nem jó általános használatra. (A sudo meg ugye alapból kizárva.)
Lényegét tekintve nekem fontos lenne a környezeti változók normális szabályozhatósága, a normális megjelenés a képernyő-billentyűzet használata mellett is, valamint jó lenne ha nem feltétlenül kérne mindig jelszót, hanem lehetne ilyen megerősítős ablak is mint amilyen általánosságban minden más rendszerben van (akár időre, akár az aktuális munkafolyamatra korlátozva). Azért lássuk be, bármennyire is biztonságos (vagy csak vélten az) az állandó jelszókéregetés, nehéz eleget tenni annak, hogy legyen jó hosszú és bonyolult a jelszó, miközben könnyen és sokszor begépelhető is. -
válasz
honda 1993 #18787 üzenetére
Igen, mert nem kérdés volt az, hanem hibaüzenettel kilépett az adott program. Visszakaptad a promptot, majd kiadtad a yes és y parancsokat. Mivel nem léteznek ilyen parancsok, kaptál még két hibaüzenetet. Ennyi történt.
-
válasz
honda 1993 #18784 üzenetére
Ez egyszerű, ugyanis sosem kérdezi meg ezt tőled, legfeljebb hibaüzenetben közli, hogy root jogosultságokra lenne szükség. Erre van ugyanis a sudo meg a jelszavad begépelése.
-
válasz
#39417856 #18707 üzenetére
Próbáld a szokásos acpi_osi=Linux és acpi_backlight=vendor kernelparamétereket a fényerőállításhoz. A monitor kikapcsolását a Rendszerbeállítások -> Fényerő és zárolás alatt lehet állítani. A normális lejátszóprogramok (pl. VLC) természetesen futásuk közben automatikusan megakadályozzák a monitor halványítását és kikapcsolását. Persze a böngészőben lejátszott videókon ez nem segít.
-
válasz
God Vazzeg #18676 üzenetére
Nem nagyon lesz már ezzel gond ha végre elfelejtik a 32-bites programokat (és procikat). Akik 64-biten fejlesztenek azokat még megértem, hogy 32-bites kiadást nem készítenek. Mármint ennek valós technikai okai is vannak, nem csak elvből hagyják ki. Én is tapasztaltam, de még szükség van mindkettőre, mert ahogy néztem a felhasználók kb. harmada még 32-biten van (Systemback letöltésekkel mérve). De igazából fordított esetben, ahol 32-bit a cél, sokkal könnyebb 64-eset is fordítani.
-
válasz
szundybence #18669 üzenetére
Maga a Canonical is ezt teszi, hivatalosan. Akkor mi miért ajánlgatnánk mást? Ráadádul most már van olyan zárt alkalmazás aminek csak 64-bites változata létezik. És amíg a 64-bites rendszereken a 32-bites programok elmennek, addig ez fordítva már nem igaz.
-
válasz
spammer #18635 üzenetére
Ha egyáltalán kompatibilis (az Intel előszeretettel tiltotta az olcsóbb procikban régebben), és kilátásban van a memóriafejlesztés (ami miatt még bőven jó a 32-bites is, hiszen alapértelmezett a PAE kernel), akkor megfontolandó lehet a 64-bites, igen. Szoftveresen nem kell szívni vele, sőt, a 64-bites telepítőkép az ajánlott már hivatalosan is. Nem beszélve arról, hogy lassan be is szüntetik a 32-bites kiadásokat az Ubuntunál.
De általánosan még mindig igaz az, hogy a 64-bites programok kicsit nagyobbak, több helyet foglalnak el a RAM-ban, valamint még mindig van olyan zárt program amiből nincs 64-bites változat, ezért egy-egy library-ből (mint függőségek) 32-bitest is telepíteni kell (még több helyet foglalnak). -
válasz
toth_janika #18574 üzenetére
Van neki grafikus felülete is, de ahhoz nyilván ne a terminálosat (console) használd.
-
válasz
PistiSan #18537 üzenetére
Ez egy grafikus alkalmazás? Mert akkor nyilván azért nem indul el az rc.local fájlba írással.
A /etc/sudoers fájlban (vagy a /etc/sudoers.d-ben egy külön fájlban) létre kell hozni hozzá egy bejegyzést, hogy ne kérjen jelszót, majd a gksu paranccsal indítva belehet tenni az indítópultba. -
válasz
szundybence #18524 üzenetére
Sikerült megoldanom a problémát úgy, hogy szép is és jó is legyen. Tehát egy frissítés után (az 1.1.1.201-es verzióra) nálad is működnie kell.
Köszi, hogy szóltál róla, és persze elnézést a kellemetlenségért. -
válasz
szundybence #18521 üzenetére
Gyakorlatilag arról van szó, hogy külön függvényekben van megoldva a szimbolikus linkek klónozása. Az egyik direkten ezt csinálja úgy, hogy a másik segítségével olvassa a forráslink tartalmát. Az inline utasítás arra jó, hogy ne függvényhívás történjen (ami a sűrűség miatt költségesebb), hanem ahelyett fordításkor behelyettesítődik a függvény tartalma (persze nem forráskód szintjén). Ezáltal ugyan nő a tárgykód mérete (ebben az esetben elhanyagolható mértékben), viszont nő a sebesség is.
Elméletileg a forráskód jó, és az esetek nagyobb részében ténylegesen is jól funkcionál. Gyakorlatilag meg ez van... -
válasz
szundybence #18518 üzenetére
Egyelőre úgy tűnik, hogy megint az inline utasítás miatt van a probléma. Elég fura a viselkedése, ugyanúgy mint múltkor. Csak éppen akkor nullázta a kiolvasott útvonalat (nullptr, ezért kaptam szegmentációs hibát létrehozáskor), most meg hozzácsap némi értelmetlen információt. Hogy miért azt csak a GCC fejlesztői tudhatják, én nem olvasok assembly kódot.
Persze természetesen a Systembackben tudom korrigálni a problémát, holnap agyalok rajta. Az inline utasítás elhagyása egy elég egyszerű és gyors megoldás lenne, de némileg csökkenti a sebességet. Ez kicsit akkor is irritál ha egyébként elhanyagolható a különbség. -
válasz
szundybence #18513 üzenetére
Neked egyébként ugyanúgy 32-bites rendszered van?
Amúgy vicces a te terminálos tesztelésed, mert a lényeg, a hibakimenet át lett irányítva valahova. Ez tuti, mert az mkfs hibakimenetbe beküldi a legelején a verziószámát, és ezt sem mutatta nálad.
Amúgy egyelőre úgy tűnik, hogy csak a 32-bites rendszereket érinti (már ha neked is az van), de azon belül sem mindegyik szimbolikus linket (amiket véletlenszerűen néztem azokkal minden rendben volt). Logikai hibát nem látok a kódban, de a GCC máskor is megviccelt már pont a link klónozásos inline függvénynél. Akkor szegmentációs hiba volt néhány linknél, de csak GCC 4.9-el. Viszont debug információkkal vagy inline nélkül nem jelentkezett. Kész rejtély volt, ezért írtam át a kódot. -
válasz
szundybence #18509 üzenetére
Nekem is kiírta ugyanezt a hibaüzenetet 32-bites Ubuntu 14.04-el. De kiírta a konkrét okát is:
/usr/sbin/grub-probe: error while loading shared libraries: libudev.so.1: cannot open shared object file: No such file or directory
grub-install: error while loading shared libraries: liblzma.so.5: cannot open shared object file: No such file or directoryAminek az oka az, hogy szemét került a libudev.so.1 szimbolikus link végére. Ennek utána járok, és amilyen gyorsan csak lehet javítom a problémát.
-
válasz
szundybence #18504 üzenetére
Az a helyzet, hogy nem is írta ki, hogy egyáltalán próbálta volna telepíteni a rendszerbetöltőt. Mindjárt csinálok az elmondottak alapján egy tesztet.
-
válasz
szundybence #18498 üzenetére
Igen, ez a legutóbbi fejlesztésem. Ugye sudo paranccsal nem indítunk grafikus alkalmazásokat, mivel ha a felhasználó könyvtárában van a hitelesítéshez a fájl, akkor ha annak a tulajdonosa a root felhasználó lesz, akkor nem tudsz utána a grafikus felületbe bejelentkezni. Erre számos példát lehetne mondani, sokszor olvastam róla én is.
Ha véletlen nem lenne telepítve a gksu csomag, akkor ezzel a paranccsal indítsd:/usr/lib/systemback/sbsustart systemback gtk+
Ellenben a sima
gksu systemback
is megteszi.
-
válasz
Aethelstone #18496 üzenetére
Annyit mondhatok még ezzel kapcsolatban, hogy a Systemback létrehoz egy szkriptet, majd a chroot segítségével futtatja az átmásolt/telepített rendszeren. Az utolsó parancs ebben a grub-install, ami nulla értékkel tér vissza ha minden rendben (nem volt hiba jelentve, ugye valami ilyet ír ki) volt (meg néhány eseten akkor is ha nem), illetve ettől nagyobb számmal ha valami problémás. A Systemback kiolvassa ezt a számot, és ha nem nulla, akkor kiírja ezt a hibaüzenetet. Ettől még a rendszer rendben átmásolódott, csak ugye elég jó eséllyel nem indul el magától.
-
válasz
Aethelstone #18492 üzenetére
Mint mondtam, valószínűleg kézzel sem menne, de esetleg úgy is már kiírná, hogy mi a baja, szóval célszerű lehet megpróbálni (vagy terminálból futtatni a Systembacket). Nem csak a Systembacknél történhet meg ez a dolog, hanem a gyári Ubuntu telepítőnél is ugyanúgy ki szokta írni (ebben az esetben is kiírná), hogy nem megy neki a GRUB telepítése.
-
válasz
szundybence #18485 üzenetére
UEFI-s telepítés vagy hagyományos? Ha hagyományos, akkor mi a beállítás (automatikus, eszköz vagy partíció)? Próbáld meg úgy is, hogy terminálból futtatod a Systembacket, akkor a GRUB telepítésénél kiírtak után hátha okosabbak leszünk.
(#18490) ubyegon2: Valóban azt jelenti, de nem olyan egyszerű a dolog. Gyakorlatilag a Systemback is ugyanazt csinálja mint mikor kézzel telepítesz, szóval jó eséllyel úgy sem menne a dolog. Viszont valamit csak oda kellett írnom ha már automatikusan nem megy.
-
Használjátok az Opera fejlesztői verzióját? Ugye a Chromiumra épül és nagyon jó. De nálam az utóbbi időben egyre lassabb lett. Tulajdonképpen időbe telt amíg elkezdett végrehajtani egy utasítást, például egy fül megnyitását vagy bezárását. Szövegbevitelnél is meg-meg akadt. Mintha az eseményciklusok egyre lassabban hajtódtak volna végre.
Most egyelőre megint jó gyors lett miután töröltem a session.db fájlt, ami az idők folyamán kicsit nagyobbra nőt már (60-70 MiB). Kíváncsi vagyok, hogy lesz-e vele megint gond és mennyi idő után.(#18480) SzJoco_: GNOME-ban sok a grafikusan beállítható dolgok száma? Ne viccelj már, alig lehet valamit is állítani. Ez egyrészről az erőssége neki, de egyben a hátránya is. Ha sok beállítási lehetőségre vágysz, akkor inkább rakd fel a KDE-t. Na ott szó szerint elveszel a beállítástengerben. Annak meg az az egyik erőssége, ami egyben a hátránya is.
-
válasz
tothjozsi96 #18275 üzenetére
Ilyen menü eddig is volt, anélkül nem is nagyon lehet megoldani a rendszerindítást. Legfeljebb csak nem látszódik alapból. Ugye Ubuntu esetében indításkor mikor megjelenik alul a kis billentyűzet vagy mi, akkor kell nyomni egy gombot, hogy előjöjjön.
(#18276) jános: Nem olvastam róla konkrétan semmit, de jó eséllyel ugyanaz a helyzet mint a 14.04-ben. Így adott esetben megfontolás kérdése, hogy mit célszerű tenni.
-
válasz
tothjozsi96 #18269 üzenetére
Pontosan mit értesz azalatt, hogy van neki saját boot loader menüje? A kezdetektől fogva van neki Syslinux menüje, UEFI-hez pedig van GRUB menü. Vagy te mire gondolsz, milyen egyéb menüre?
-
válasz
lionhearted #18089 üzenetére
Sőt, én még kézzel fel is tudok tölteni PPA-ba. Bár manapság már automatikusan is megy a dolog, közvetett módon.
-
válasz
legenda007 #18086 üzenetére
Biztosan tudod használni hozzá ezt a programot, de még egyszer mondom, ez a PPA nem tartalmaz a 14.04-es Ubuntu kiadáshoz semmilyen csomagot. Vagyis ezt a tárolót nem tudod arra használni, hogy onnan telepítsd a boot-repair-t. Ez nem jelenti azt, hogy más forrásból, vagy máshogyan nem tudod feltenni. Habár amúgy egy kicsit már régen volt frissítve...
-
válasz
legenda007 #18084 üzenetére
Akkor miért veszel fel olyan PPA-t ami nem tartalmaz hozzá semmilyen csomagot? Mi nem tudunk ehhez a tárolóhoz hozzáférni, és nem tudunk 14.04-gyel kompatibilis csomagokat elhelyezni benne.
-
válasz
legenda007 #18082 üzenetére
Nem sikerül telepíteni az Ubuntu 12.04-re, vagy mi a probléma vele?
-
válasz
lev258 #18068 üzenetére
A BIOS-ban úgy jár az idő ahogy az be van neki állítva vagy kézzel vagy az operációs rendszer által. Az Ubuntu leszinkronizálja az időt, majd beállítja a CMOS-ban is az UTC-t. A Windows pedig indul, nem szinkronizál semmit, és a rendszeridő kiolvasása utáni kijelzett idő máris nem egyezik meg a valósággal, hiszen ő nem korrigálja az eltolódással, helyinek veszi alapból.
-
válasz
Mtbsrác #18066 üzenetére
Az Ubuntu UTC-t használ, a Windows meg helyi időt. Azt nem tudom, hogy a Windowsnál hogyan lehet beállítani, hogy az is UTC-t használjon, de Ubuntunál a /etc/default/rcS fájlban kell átírni a UTC=yes-t UTC=no-ra. Így akkor nem lesz majd ez a több órás eltérés közöttük.
-
válasz
trane95 #17932 üzenetére
Ha optikai lemezről van szó, akkor elképzelhető, hogy rosszul lett kiírva rá a telepítőkép, és ezért nem talál bootolható eszközt. Ez igaz akkor is ha egyéb, USB-s eszközről szeretnél próbálkozni, főleg, hogy az XP telepítője onnan hivatalosan nem is indítható (pl. pendrive-ról).
Szóval kérd el a hozzávaló (vagy külön megvásárolt) hivatalos, hologramos XP telepítőlemezt, majd telepítsd fel a rendszert. -
válasz
trane95 #17930 üzenetére
... elkezdett lassulni, egyebek. Pár funkció elvesztése révén követeli tőlem, hogy XP-je lehessen, de a pendrive boot, a CD, illetve a telepítendő rendszer cseréje sem orvosolta a problémát.
De mégis milyen problémát nem orvosoltak ezek? A lassulást, a funkciók elvesztését, vagy nem tudod telepíteni a rendszert (ez csak amolyan következtetés)?
Ubuntu x10-es kiadás nem létezik.
Az Ubuntu semmilyen esetben sem gátolja meg más rendszerbetöltők betöltését azelőtt még mielőtt egyáltalán a sajátja betöltődne. A BIOS-on vagy annak beállításain nem változtat. A BIOS boot menüje tőle teljesen független, ott kitudod választani, hogy mely eszközről szeretnél indítani.
Az Ubuntu nem keverendő össze a Windowszal, amely ténylegesen megakadályozhatja más rendszerek vagy telepítők elindulását ha UEFI-ről van szó. -
válasz
Thocy a ZAGY #17618 üzenetére
Szerintem nem csak ettől függetlenül jön jól a Systemback, hanem ilyenkor is éppen ugyanolyan hasznos. Attól, hogy valaki kinőtt a kísérletezgetős korszakából és egy stabil használható rendszert szeretne amit nem kell piszkálni, még ugyanúgy megesik, hogy egy frissítés után nem indul el a rendszer, vagy éppen ilyen költöztetős esetek is előfordulnak. Főleg ha az idő is szorít és produktívnak kéne lenni, ki a rossebnek van kedve rendszertelepítésekkel meg beállításokkal szórakozni? Én is már úgy vagyok vele, hogy jó pár kiadás óta csak frissítek, újra már régen telepítettem a rendszert. A mostani legalább a negyedik gépét tapossa, plusz azokat amelyeken párhuzamosan használom áttelepítés után.
-
válasz
#33253120 #17615 üzenetére
Attól még ugyanúgy érdemes lehet pár dolgot beállítani, hiszem a normál telepítés semmivel sem ad többet mintha a Systemback segítségével végeznél egy rendszertelepítést vagy -másolást (ez inkább fordítva igaz). De legalább annyival hátrább lettél, hogy mindent telepíthetsz és állíthatsz be megint. Ez valóban elősegíti azt, hogy a lehető leghamarabb produktívvá váljon a gép...
-
Természetesen a Systemback alkalmas a feladatra. A rendszermásolás funkciót és a célpartíciókat kiválasztva automatikusan végrehajtható a feladat úgy, hogy aztán el is induljon az átmásolt rendszer. Persze pár dolgot esetleg érdemes lehet az SSD miatt beállítani, bár nem feltétlen szükséges.
-
válasz
Ultrazord #17328 üzenetére
Az a rekurzív chmod parancs nem volt túl szerencsés, de már mindegy. Próbáld meg azt, hogy törlöd a .Xauthority és a .ICEauthority fájlokat, hátha. Ezek amúgy is automatikusan létrejönnek, csak lehessen írni őket. Ha így sem jó, akkor egész biztosra vehető, hogy valami más okozza a problémát.
-
válasz
Ultrazord #17325 üzenetére
Akkor gondolom három lehetséges oka lehet neki:
- Nem azt a parancsot adtad ki mint amire én gondoltam, ezért nem is történt meg az a változtatás ami esetleg javította volna a problémát.
- Nem, vagy nem csak a felhasználó- és csoportneveket kell a sajátodra állítani (chmod).
- Nem a jogosultságokkal van a gond, hanem valami mással. -
válasz
Ultrazord #17320 üzenetére
Ha megnyomod az általad nevezett billentyűkombinációt, akkor kiírja, hogy tty1. Szóval nem igazán értem, hogy mi a kérdés. Amint látod ez egy parancssoros felület, Ubuntun alapból a hetediken (utolsón) fut a grafikus. Miután az utóbbin nem tudsz bejelentkezni, 1-6-ig próbálkozhatsz.
A rendszer frissítése normál esetben nem okoz ilyen hibát, de még csak a felhasználói könyvtáradban sem matat a csomagkezelő. Legfeljebb a terminálba bepötyögött utasításaid mentődnek el ami összeköthető a frissítéssel. -
-
válasz
Ultrazord #17316 üzenetére
Próbálkozz a
sudo chown -R felhasználóneved:felhasználóneved /home/felhasználóneved
paranccsal mondjuk tty1-en bejelentkezve. Az egyik lehetséges okot épp abban a hozzászólásban taglaltam amire válaszoltál. De teljesen mindegy, a lényeg, hogy jó eséllyel rootként matattál a saját könyvtáradban, amitől elállítódtak egyes elemek jogosultságai, ami miatt aztán nem tudsz grafikus felületen bejelentkezni.
-
válasz
Ultrazord #17308 üzenetére
Nem a jelszót kell megváltoztatni, hanem a jogosultságokat kell rendbe rakni. Például ha a ~/.Xauthority fájlodat nincs jogod írni, akkor elég nehezen tudsz grafikusan bejelentkezni. Ezért nem szokás (illetve szokásnak sajnos szokás, de nagyon nem ajánlott) sudo-val grafikus alkalmazásokat indítgatni, mert az ezzel jár. Aztán fogalmad sincs, hogy miért nem tudsz bejelentkezni, pedig jó jelszót adsz meg.
-
válasz
lordjancso #17087 üzenetére
Ha telepíted a gksu-t akkor az jó megoldás, hiszen nemcsak, hogy grafikusan kéri a jelszót, de megoldja azt is, hogy a root felhasználó ne ténykedjen a normál felhasználó könyvtárában. Hátránya, hogy alapból blokkolja a képernyőt, így tableten nem feltétlenül ideális (de persze megoldható a dolog, csak elég ronda).
A gksu azért nem az alaptelepítés része már, mert leváltotta a policykit. Viszont a pkexec parancs csak azokkal az alkalmazásokkal működik amelyek fel lettek rá készítve (pl. Synaptic, GParted), vagyis amelyek normál használatuk során is root jogosultságot igényelnek. Tehát pl. a Nautilushoz már nem lesz jó, mert a környezeti változók törlése miatt nem tud kommunikálni az X szerverrel, vagy éppen azt sem tudja, hogy melyik képernyőn nyissa meg az ablakot. -
válasz
lordjancso #17081 üzenetére
Aki a sudo-t javasolja önmagában grafikus programokhoz, az nyilván nem tudja, hogy miért nem jó megoldás. De ettől még a használata után ugyanúgy előfordulhat, hogy nem fogsz tudni bejelentkezni grafikusan a saját rendszeredbe, mint ahogyan arról már számtalanszor olvashattunk másoktól.
-
válasz
lordjancso #16932 üzenetére
System Settings (unity-control-center) -> Text Entry -> Show current input source in the menu bar, jelöld be. Amúgy a linkelt oldalon ez nagyon szépen látszik az egyik képen is (te meg tudsz angolul ugye).
-
Ha valakit még érdekel itt, akkor megjelent a Systemback 1.0.1-es verziója is. Ez a Qt5/C++ port második főbb kiadása, pár újítással.
De bake ha belegondolok, hogy honnan indult még innen, sosem gondoltam volna anno, hogy ez lesz belőle.
Ami persze nem olyan sok, de amikor elkezdtem, akkor még nemigazán konyítottam a programozáshoz.
Új hozzászólás Aktív témák
A topik célja: Segítségnyújtás az Ubuntut és variánsait használók és az ezekkel még csak ismerkedők számára
Kérdés előtt olvasd el a topik összefoglalóját!
Haladó Linuxos kérdések topikja.
Linux felhasználók OFF topikja
Shell script kérdésekkel látogassatok el a topikjába
- Vélemény Ubuntu 20.04 LTS
- Bemutató Linux a mindennapokban
- Bemutató Ubuntu 16.04 LTS kezdőknek, gyakorlatiasan, objektíven
- Hír Megjelent az Ubuntu 16.04 LTS
- BestBuy topik
- Ismét egy teljesen friss egérrel gyarapította kínálatát a Pulsar
- Megjött a Cherry legfrissebb, taktilis karakterisztikájú kapcsolója
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- Sorozatok
- Battlefield 6
- Most Kína tiltotta ki a nemrég exportengedélyt kapott AI gyorsítókat?
- Milyen billentyűzetet vegyek?
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- További aktív témák...
- Játékkulcsok a legjobb áron: Steam
- Jogtiszta Windows - Office & Vírusirtó licencek- Azonnal - Számlával - Garanciával - Nint.hu
- Windows 10/11 Home/Pro , Office 2024 kulcsok
- Vírusirtó, Antivirus, VPN kulcsok
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- GYÖNYÖRŰ iPhone 13 mini 256GB Blue -1 ÉV GARANCIA - Kártyafüggetlen, MS3180
- HIBÁTLAN iPhone 13 Pro 128GB Graphite -1 ÉV GARANCIA - Kártyafüggetlen, MS3025
- Bowers/Wilkins Px7 S2 fejhallgatók
- HIBÁTLAN iPhone XS Max 64GB Gold -1 ÉV GARANCIA - Kártyafüggetlen, MS2898, 100% Akkumulátor
- BESZÁMÍTÁS! ASRock B450M R5 3500X 16GB DDR4 512GB SSD RX 5700 XT 8GB Zalman N4 ADATA 600W
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest