openSUSE Leap 42.2 Beta 3

openSUSE, SUSE, SLES

Megjelent az openSUSE Leap 42.2 harmadik bétája. Benne:

  • VirtualBox 5.1.4
  • KDE Plasma 5.8.0
  • Firefox 49
  • Thunderbird 45.3.0
  • stb.

Részletek a bejelentésben.

( gyarakilaszlo | 2016. 10. 07., p – 19:07 )

0.23-nál léátható keresőt hogyan lehet előcsalni? Milyen billentyű vagy billentyűkombináció szükséges hozzá?

A fenti videó a sima KDE-s demó videó, nem Süsü-specifikus (és így hiányzik róla a Süsüs branding), gondolom csak azért tették be a hírbe, mert mókoltak a kiadási ütemtervvel, hogy bekerülhessen (lásd itt: https://news.opensuse.org/2016/09/22/new-leap-beta-adds-plasma-5-8-beta/)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

( uid_16313 | 2016. 10. 07., p – 22:14 )

Az egyre inkább elterjedő, érintőképernyős-okostelefonos világban egyre elavultabbnak tűnnek a klasszikus desktop környezetek.

--
robyboy

Az érintőképernyő felesleges és semmit sem javít a produktivitáson, csak folyamatosan törölgetni kell.
Nem tudom te melyik világban élsz, de nekem sokkal inkább a különböző tabletek és telefonok parasztvakítós, de használhatatlan (és kikapcsolhatatlan) megoldásai tűntek mindig is borzalmasan avultnak (illetve ez nem jó szó, soha nem is találták ki rendesen).

FathoM

Szvsz a GNOME Shell a legjobban shortcutolt "mainstream" felület. Nagyon sokáig KDE/Slackware user voltam, aztán lustaságból tettem egy próbát default CentOS-el a produktivitásra használt PC-men, és gyakorlatilag nem is kell egeret használni, megnyomom a Win gombot, elkezdek gépelni, enter, közben tematizálom a virtuális desktopokat, amik között ugyancsak shortcutokkal váltogatok, gyakorlatilag a "tálcahasználatról" is leszoktam azóta.

Abban a korban, ahol egy workstationon alap az i7, es a minimum 16 GB RAM, nem igazan erzem ezen a teruleten a lightweight ablakkezelok letjogosultsagat. Es direkt megjegyeztem, hogy mainstream feluletekrol beszelek. Na, az openbox nem az. :) Arrol mar nem is beszelve, hogy a GNOME Shell ootb production-ready, mig az openbox nem. Amennyivel tobbet fogyaszt a KDE/GNOME, annyival tobb emberi eroforrast is takaritanak meg es annyival jobb is leulni elejuk. Emellett van egy teljesen konzisztens desktopjuk is, nem pedig ossze-vissza mukodo es kinezo alkalmazasok kavalkadja.

Simán tudok a laptopomon 5-10 virtuális géppel többet futtatni azért mert az asztali környezet nem eszi meg a memóriát. Egyébként nekem az a nem mind1, hogy egy terminál fél másodperc alatt indul el, vagy azonnal, a gombnyomás pillanatában. Egyszerűen bosszant, ha a dolgok 2016-ban nem azonnal történnek. Mondjuk az igaz, hogy konkrétan a KDE és a Gnome is évekkel ezelőtt volt a kezem alatt. Pár éve még mindkettőnek kellett egy picike idő, mire akár a legkisebb programot is elindították, ezért kerestem egy olyan ablakkezelőt és egy olyan terminált, aminél nincs ilyen gond. Szerintem napi szinten nyerek ezzel öt-tíz percet :D Ahogy te is szereted az egeret _nem_ használni, én is így vagyok vele. De a környezet se akadályozzon semennyire se.

Persze tudom, hogy a modern programozók már egy egyszerű hőmérséklet szabályzást is internetes kapcsolatot igénylő, dran-n-drop izével "programoznak" le. De nekem az a természetes, hogy ezt meg lehet csinálni egy primitív mikrovezérlővel vagy maximum egy Arduinoval. Őskövület vagyok :D

+1

Bár én nem programozok, csak néha túrom a gtkrc-t, meg a tint2, conky, autostart konfigokat(ha épp témát faragok magamnak, meg a "nagyérdeműnek"), arra jutottam röpke 10-15 év Linux használat után, hogy a legjobb nekem az Openbox, esetleg az Xfce.. A miértek:

- nem kell "félnem", hogy egy új release mivel veszik majd össze, mivel a funkcionalitáson, valamint a minimális függőségeken sem igen változtatnak, mivel nem akarnak a fejlesztők világot, desktop usage-t, vagy bármit "megváltani"..
- a fent említett minimális függőségeknek hála, nagyon kevés RAM is elég a használhatósághoz, vagyis egy öregebb gépen is elérem ugyanazokat a funkciókat, amiket egy erőművön.
- nincs háttérben futó, memóriazabáló, vagy processzorzabáló "szolgáltatás", ha éppenséggel pont belefutnék egy bugos verzióba. (avahi, balou, akonadi, zeitgeist, stb)
- nem okvetlen szükséges sem az magasságos pulseaudio(bár mostanában már egész tünetmentes), sem a systemd jelenléte.
- bármelyik disztrót használom (jelenleg openSUSE), mindenhol van belőle stabil verzió, minden disztrónál ugyanazok a lehetőségek várnak
- 3-4, de akár több éves konfigjaimat cuccolhatom mindenféle komolyabb változtatás nélkül disztróról disztróra, kiadásról kiadásra
- kis "ügyeskedéssel" ad-hoc window-tiling is előkaparható az Openboxból
- a pipemenüknek hála, az asztalon a jobbgomb nem csak egy egyszerű menüt csalhat elő, hanem akár rögtön kaphatok információt az e-maileimről, időjárásról, legutóbb használt fájlokról, rendszer erőforrás használatról, satöbbi satöbbi...
- kiválóan kezelhető mind egérrel, mind pedig pusztán billentyűzettel.

A csekély elérhető Openbox témát nem értem, mert csak a Deviantarton van egy rahedli esztétikus és használható téma. Kompozítornak használhatsz akármit, olvastam már olyat is, aki Compiz-Openbox sessiont kovácsolt magának, de olyat is, aki Kwinnel "gyógyította össze", persze a legelterjedtebb megoldás az xcompmgr, vagy a compton használata. Ablakdekorációk terén valóban lehet hátrány, ha valaki nem kedveli a lekerekítetlen, szögletes ablakkereteket. Utóbbiak Openbox helyett PekWM-et használnak.. :-D

openSUSE Leap 42.1

> nem kell "félnem", hogy egy új release mivel veszik majd össze [...] mivel nem akarnak a fejlesztők világot, desktop usage-t, vagy bármit "megváltani"..
RHEL klónok esetén ettől nem igazán kell tartani, máig GNOME classic felület az alapértelmezett.

> a fent említett minimális függőségeknek hála [...] öregebb gépen is elérem ugyanazokat a funkciókat, amiket egy erőművön.
Ez valakinek szempont, valakinek nem, nekem az elsődlegesen használt gépem egy Chromebook, ami mellett van egy PC-m CentOS-el, mindkettő i7/16G. Így a további szempontok is teljesen értelmetlenek rám nézve, ráadásul sem a pulseaudioval, sem a systemd-vel nincs problémám az ellenhype ellenére sem. :)

Nyilván más a leányzó fekvése, ha valaki "Linuxozik", ezer és egyféle hardveren, onnantól racionális szempont a hordozhatóság. Nekem Chrome OS, CentOS, OpenWrt userként nem.

Az azért megvan ugye, hogy nem mindenki bújik ki a világra a "mindkettő i7/16G"-vel?
Az, hogy neked erre telik magánügy, kb több milliónak meg nem. Értem én, hogy aki pc-zik az vegyen minimum ilyen gépet, de azért néha nem ártana visszább venni a szemléletből, mert könnyen kapsz egy "vérpistike" jelzőt. :P

"Simán tudok a laptopomon 5-10 virtuális géppel többet futtatni azért mert az asztali környezet nem eszi meg a memóriát."

Naaaa...
Ennyit eszik egy 64 bites frissen indított KDE úgy, hogy a háttérben már fut egy csomó minden a cups-tól kezdve a network managerig, kwallet, jópár widget (a tálca, óra, vágólap kezelő, system monitor, kde connect stb), meg még egy telegram kliens, konsole, és a system monitor. Meg még ami nem jut eszembe. (Természetesen ez nem mind kötelező.)

A CentOS GNOME-al, indulás után egy VM-re elegendő RAM-ot sem zabál fel. :) Btw nekem azonnal indul minden, KDE-ről nem tudok mit írni, 4-est használtam éles hardveren utoljára. A GNOME viszont a 3.6 - 3.8 környékéig tényleg képes volt néhol érdekesen viselkedni, ezért is hanyagoltam.

Itt van pár. Annyit magyarázatképp, hogy központi rendszer menedzsment rendszert fejlesztek és kell egy csomó tesztgép, amit szeretem, ha a laptopomon is tudok használni. Ezért van egy csomó virtuális gépem LXC-be telepítve. Nem csináltam semmit azért, hogy ezek ilyen kicsik. Ekkorák alap telepítés után. Mindegyiken van egy ssh szerver és annyi.

Az én asztali környezetem: az openbox 17Mb, az nm-applet 38Mb, a conky 2x7Mb, a workrave 45Mb, a tint2 pedig 16Mb memóriát eszik (most néztem meg ezeket), akkor helytálló, hogy egy tipikus asztali környezet 500Mb-ja és az enyém közti különbség elég nekem simán 10db LXC virtuális gépre. Persze ha Postgres-t és a rendszer menedzsment szervert is futtatom rajta, akkor kell neki akár 150Mb memória is :D

Szóval a kicsi VM-ek:

root@fractal13 <16:13:29><0> ~ # ps axufww
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 7084 0.0 0.0 32884 2880 ? Ss 16:13 0:00 [lxc monitor] /var/lib/lxc ubuntu
root 7094 0.2 0.0 34572 4600 ? Ss 16:13 0:00 \_ /sbin/init
root 7174 0.0 0.0 33132 3956 ? Ss 16:13 0:00 \_ /lib/systemd/systemd-journald
syslog 7345 0.0 0.0 255896 5252 ? Ssl 16:13 0:00 \_ /usr/sbin/rsyslogd -n
root 7351 0.0 0.0 59640 5508 ? Ss 16:13 0:00 \_ /usr/sbin/sshd -D
root 7353 0.0 0.0 30388 2868 ? Ss 16:13 0:00 \_ /usr/sbin/cron -f
root 7356 0.0 0.0 4472 1744 ? S 16:13 0:00 \_ /bin/sh /etc/init.d/ondemand background
root 7360 0.0 0.0 8712 736 ? S 16:13 0:00 | \_ sleep 60
root 7365 0.0 0.0 17160 2320 pts/2 Ss+ 16:13 0:00 \_ /sbin/agetty --noclear --keep-baud pts/2 115200 38400 9600 vt220
root 7366 0.0 0.0 17160 2324 pts/5 Ss+ 16:13 0:00 \_ /sbin/agetty --noclear --keep-baud console 115200 38400 9600 vt220
root 7367 0.0 0.0 17160 2348 pts/1 Ss+ 16:13 0:00 \_ /sbin/agetty --noclear --keep-baud pts/1 115200 38400 9600 vt220
root 7368 0.0 0.0 17160 2236 pts/0 Ss+ 16:13 0:00 \_ /sbin/agetty --noclear --keep-baud pts/0 115200 38400 9600 vt220
root 7369 0.0 0.0 17160 2288 pts/3 Ss+ 16:13 0:00 \_ /sbin/agetty --noclear --keep-baud pts/3 115200 38400 9600 vt220

RSS: 2880 4600 3956 5252 5508 2868 1744 736 2320 2324 2348 2236 2288

echo '2880 4600 3956 5252 5508 2868 1744 736 2320 2324 2348 2236 2288' | sed 's/\ / + /g' | bc

Ubuntu vivid minimal server sum: 39060k ~ 38Mb

======

root 9028 0.0 0.0 32884 2912 ? Ss 16:13 0:00 [lxc monitor] /var/lib/lxc ubitrusty
root 9046 0.8 0.0 33224 3620 ? Ss 16:13 0:00 \_ /sbin/init
root 9665 0.0 0.0 15264 216 ? S 16:13 0:00 \_ upstart-socket-bridge --daemon
root 11050 0.0 0.0 19480 176 ? S 16:13 0:00 \_ upstart-udev-bridge --daemon
root 11059 0.0 0.0 49276 3164 ? Ss 16:13 0:00 \_ /lib/systemd/systemd-udevd --daemon
root 11141 0.0 0.0 15280 200 ? S 16:13 0:00 \_ upstart-file-bridge --daemon
systemd+ 11146 0.0 0.0 255848 2916 ? Ssl 16:13 0:00 \_ rsyslogd
root 11281 0.0 0.0 12792 1904 pts/3 Ss+ 16:13 0:00 \_ /sbin/getty -8 38400 tty4
root 11289 0.0 0.0 12792 1972 pts/1 Ss+ 16:13 0:00 \_ /sbin/getty -8 38400 tty2
root 11291 0.0 0.0 12792 1920 pts/2 Ss+ 16:13 0:00 \_ /sbin/getty -8 38400 tty3
root 11330 0.0 0.0 23660 2256 ? Ss 16:13 0:00 \_ cron
root 11334 0.0 0.0 61380 5236 ? Ss 16:13 0:00 \_ /usr/sbin/sshd -D
root 11476 0.0 0.0 4448 1696 ? S 16:13 0:00 \_ /bin/sh /etc/init.d/ondemand background
root 11483 0.0 0.0 4348 660 ? S 16:13 0:00 | \_ sleep 60
root 11495 0.0 0.0 12792 1892 pts/7 Ss+ 16:13 0:00 \_ /sbin/getty -8 38400 console
root 11500 0.0 0.0 12792 1944 pts/0 Ss+ 16:13 0:00 \_ /sbin/getty -8 38400 tty1

RSS: 2912 3620 216 176 3164 200 2916 1904 1972 1920 2256 5236 1696 660 1892 1944

$ echo '2912 3620 216 176 3164 200 2916 1904 1972 1920 2256 5236 1696 660 1892 1944' | sed 's/\ / + /g' | bc

Ubuntu 14.04 minimal server sum: 32684 ~ 31Mb

======

root 10047 0.0 0.0 32884 2996 ? Ss 16:13 0:00 [lxc monitor] /var/lib/lxc centos1
root 10084 0.0 0.0 19292 2280 ? Ss 16:13 0:00 \_ /sbin/init
root 10443 0.0 0.0 4124 1448 pts/8 Ss+ 16:13 0:00 \_ /sbin/mingetty --nohangup console
root 11563 0.0 0.0 179568 2468 ? Sl 16:13 0:00 \_ /sbin/rsyslogd -i /var/run/syslogd.pid -c 5
root 11641 0.0 0.0 66276 2664 ? Ss 16:13 0:00 \_ /usr/sbin/sshd
root 11656 0.0 0.0 4124 1376 pts/0 Ss+ 16:13 0:00 \_ /sbin/mingetty --nohangup /dev/tty1
root 11659 0.0 0.0 4124 1308 pts/1 Ss+ 16:13 0:00 \_ /sbin/mingetty --nohangup /dev/tty2
root 11663 0.0 0.0 4124 1360 pts/2 Ss+ 16:13 0:00 \_ /sbin/mingetty --nohangup /dev/tty3
root 11668 0.0 0.0 4124 1412 pts/3 Ss+ 16:13 0:00 \_ /sbin/mingetty --nohangup /dev/tty4

RSS: 2996 2280 1448 2468 2664 1376 1308 1360 1412

echo '2996 2280 1448 2468 2664 1376 1308 1360 1412' | sed 's/\ / + /g' | bc

CentOS minimal server sum: 17312 ~ 16Mb

Mivel mindenki így gondolkozik (a szoftverfejlesztők főképpen), azért kell egyre nagyobb és nagyobb és erősebb gép. Ami lehet, hogy neked csak párezer forint plusz kiadás 2-3 évente, de világszinten ezeknek a felesleges alkatrészeknek az előállítása és árammal ellátása már nagyon komoly tétel. Szerintem ha ki tudnánk számolni, hogy mennyivel több processzor mag eszik mennyivel több áramot a valóban indokoltnál, akkor mindketten dobnánk egy hátast. Épp ezért írtam, hogy így múlik el a világ dicsősége :P

En a terminalon kivul max egy bongeszot szoktam hasznalni, amiben altalaban dokumentumokat olvasok. Nekem mekkora nagy vsync kell? Es ha tul nagy lesz van e ra kenocs? :D
( https://hardforum.com/threads/how-vsync-works-and-why-people-loathe-it… - ennek a linknek a 90%-a azzal foglalkozik hogy milyen fontos ez jateknal, szoval akkor a vsync engem nem nagyon erint. :) )

Ha nincs vsync akkor tearing jelenik meg. Például görgetés vagy ablakmozgatás közben, vagy mégidegesítőbb ha videó nézés közben. Erre van aki érzékenyebb, például én, van aki észre se veszi. Egy furcsa villódzásként jelentkezik, és pont a modern LCD (az IPS is TFT, meg a VA és a TN is) jelent ez problémát, mivel alacsonyabb a frissítési frekvencia mint CRT (CRT 60Hz-n halál monitornak), illetve jellegéből fogva is, mivel a CRT nem egyből változik.
Játék alatt sokkal kevésbé probléma mint desktopon, illetve elég gáz is ha valami nem tudja (windows, osx, kde, gnome out-of-the-box vsync-el megy ha van GPU gyorsítás)

A Star Trekben jól nézett ki, hogy mindent a tabletjükön intéztek, de valójában ez egy agyrém. Persze megnyomni három bazi nagy gombot jó, de igazán produktívnak lenni kínszenvedés.
Ami nagyon gáz, hogy kocsikba is ilyet tesznek, aztán ahhoz, hogy bekapcsod a fűtést tapizhatod a kijelzőt, amit ráadásul nem is lehet odanézés nélkül kezelni.

( persicsb | 2016. 10. 08., szo – 14:48 )

18 hónap már long-term support? Nevetséges.

Miért várod el, hogy az upstream támogasson minden főverzió addig, amíg bármelyik disztró szállítja?

A bugfixelés a support időszak után a disztró felelőssége, amit csinálhat úgy, hogy új verzió jön ki a disztróból (pl. Süsü, kevésbé Debian) vagy hogy tartja a verziót és a fél világot backportolja, időnként egy-egy point releassel meg előrébb megy (RHEL). Ha ez a rendszer nem lenne (és nem működne), akkor mindenkinek minden verziót ~10 évig kellene támogatnia, mondván, hogy a RHEL-ben még ott van a támogatott KDE3, a hivatalosan production (tehát nem extended support!) periódusban levő RHEL5-ben...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

De pontosan erről beszélek, hogy nincs support időszak. Kiadnak egy verziót, szarnak a bugokra, csinálják a következőt, aztán ha javítják valami véletlen folytán, akkor szerencséd van, ha nem, akkor majd 1 év múlva valaki lezárja, hogy az adott verzió már nem támogatott, ha fennáll még a hiba az újban is, akkor jelentsd újra, és closed.
--
The Community ENTerprise Operating System

Ott indul a dolog, hogy amit kiadnak release-ként, az jóesetben egy beta, de lehet hogy alpha verzió címkével illetném. Időnként meg-megnézem virtuális gépben, hogy hogy hogy áll jelen esetben a kde5, és eddig nem nagyon tapasztaltam olyat, hogy 5 perc egyszerű felületen meg beállítások között kattingatás után ne jönne elő 10 hiba, segfault, összeomlás vagy nem válaszoló alkalmazás.
A bugfixekkel felhozzák egy beta vagy valami rc-közeli verzióra, ami még mindig nem 100-as, de már majdnem közel van a használhatóhoz, na és ott nincs is tovább bugfix, mert csinálják a következőt. Egyébként ezekben a bugfixekben sokszor jelentéktelen, egyszerű dolgokat javítanak, mélyen gyökerező problémát nem nagyon. Ez a verziók között eltelt idő is igazolja, pl. 5.6 vagy 5.7-nél, amikor kb hetente tolják kifele őket.

Ez nem csak a kde5-re igaz, hanem úgy kompletten a mai szoftverfejlesztési gyakorlatról az a véleményem, hogy teljesen rossz irány, borzasztó, hektikus, hogy kb. naponta, vagy pár naponta hajigálnak kifele új verziókat, teszteletlenül, eszetlenül verziót növelve. Én mindig annak a hve voltam, hogy igen legyen frissítve a rendszer, legyen friss a szoftver, újabb a driver. De egyre inkább úgy vagyok vele, hogy ha minden rendben, és nem muszáj, akkor ne piszkáljuk. Legyen az linux, windows, szerver vagy kliens, szoftver, szolgáltatás, driver, vagy akármi. Mert egyszerűen teljesen kiszámíthatatlan, hogy az adott frissítés mit fog elrontani, mi változott meg, mi nem lesz jó, ami addig ment, és egy 10 perces gyorsan lefrissítem és újraindítom dologból egy több órás, napos, vagy neadj isten több napos szopás lesz.
--
The Community ENTerprise Operating System

De pont erre vannak a disztribúciók, akik a kerneltől felfelé átveszik a QA, a támogatás és integrálás terhét az egyes projektek fejlesztőitől; a 13.2 (Leap előtti legutolsó nyíltSÜSÜ) a mai napig kap frissítéseket a KDE4-hez, pedig már azt a verziót azt hiszem az upstream nem támogatja.

Ennek a modellnek az egyetlen hátránya szvsz., hogy több disztró ugyanazt a maintainer feladatot látja el (bizonyos pontig... egy támogatott 3-as ágú KDE a RHEL-ben más tészta, azzal más már szvsz. nem foglalkozik), de ahogy össze-vissza átveszik egymástól a patcheket az is még belefér.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Nem konkrétan az opensusere gondolok, általánosságban mondom.

De ezt én nem is értem... Miért kell átvenni a fejlesztőtől? Ő ismeri a legjobban a kódot, a saját munkáját, valószínűleg ő tud benne a leggyorsabban és leghatékonyabban javítani is. Vagy akkor fejlesztő = aki előállítja az új feature-ökkel teli, használhatatlanul bugos kódot, a maintainer = próbál ebből valami használhatót csinálni, és más szarját takarítani?

Az meg a másik dolog, hogy mindenki feltalálja a spanyol viaszt. Nem lenne működő megoldás az, hogy minden disztró delegál egy embert, akik ugyanúgy ott ülnek a kde5 hq-ban a folyosó végén egy irodában, és együtt dolgoznak, együtt javítanak, a fejlesztőkkel együttműködve?

--
The Community ENTerprise Operating System

Sok esetben ott "ül" a RH-s/Novell-es alkalmazott az X szoftver virtuális fejlesztői irodájában. Az ő ismeri legjobban a kódot kitételben nem vagyok biztos, egyrészt a KDE minden alrendszerét/a KSC minden szoftverét teljes csapatok fejlesztik, ráadásul ezek egymásra épülnek. Vagyis hiába bugos mondjuk a Konsole, ha igazából a mögötte levő VT a hibás. Ill. hiába ad grafikus hibákat a képernyőn, ha arról valójában a KWin tehet.

Ill. ha még van is egy fejlesztő, akitől lehetne ezeket kérni, lehet, hogy már nem foglalkozik vele. Talán a legjobb példa: az Apache-os mod_auth_kerb. Fenn van a sourceforge-on a forrása, de ha lehúzod az apttal a disztróban levő forrást és átnézed a patcheket, gyakorlatilag már köze sincs az eredeti kódhoz... az eredeti még akkor készült, amikor épp volt a váltás az Apache 1 és 2 között, aztán a 2.2 környékén az auth alrendszert eléggé refactorálták, de addigra az eredeti fejlesztő valahol eltűnt és nem foglalkozik vele...
Néhány éve még aktívan fejlesztették az RH-nál is és mentek bele új feature-ök (az MS-fél S4U2Proxy nevű constraint delegation móka támogatása), azt azt hiszem a Debian alapú rendszerek már nem vették át. Aztán pár éve eljött az, hogy az egyik RH-s megunta a patchelést, a legfrissebb Apache auth API-ra és a GSSAPI-ra (amikor az auth_kerb készült még voltak Krb4 rendszerek, azokat is támogatja a mai napig - leszámítva, hogy mindenki anélkül fordítja :) ) építve csinált egy újat, ami lassan feature complete a régivel, jóval kevesebb kódból és sokkal stabilabban...

Szerk.: Na, a lényeget hagytam le: mind a fejlesztő, mind a maintainer folyamatosan fejleszt, bugfixál, a kérdés, hogy mikor és melyik branch van nála checkout-olva :)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

"Időnként meg-megnézem virtuális gépben, hogy hogy hogy áll jelen esetben a kde5, és eddig nem nagyon tapasztaltam olyat, hogy 5 perc egyszerű felületen meg beállítások között kattingatás után ne jönne elő 10 hiba, segfault, összeomlás vagy nem válaszoló alkalmazás."

Biztos csak szerencsém van, de napi szinten ezt használom, és nem találkozok ilyen hibákkal. Nem mondom hogy soha semmi (miben nincs hiba?), de amit írsz az nonszensz, így teljesen használhatatlan lenne. Arch alatt pár napja frissült a plasma, a legnagyobb hiba ami eddig feltűnt, hogy a tálcán lévő órán a dátum font méretét elcseszték. De működésben, stabilitásban semmi gondom vele (ahogy eddig sem volt).

Biztos mást/máshogy használunk hogy én nem futok hibákba. Igaz, hogy mondjuk az alap KDE-n kívül nem nagyon használok KDE appokat. Alap alatt értem magát a plasma desktopot (plusz pár widgetet, óra, notesz, network manager a tálcán stb), dolphint, kwin-t és pár core appot, mint pl a konsole és kwrite/kate. Activity-ket is használok. De pl a DKE PIM csomagból (kmail stb) semmit nem használok, vagy a KOffice-t (calligra?) sem, meg KDE-s browsert (rekonq?) sem. Amit használok, azzal viszont kb zéró problémám van, működik. A dolphinnál pl szerintem nem is létezik jobb file kezelő (bár a KIO bénább, mint a GVFS, de maga a program, a testreszabhatósága, tudása pazar).

Pont mostanában sírtam (sírom) el az itteni blogomban, hogy milyen hibákba futok bele nap mint nap. Aminek persze jelentős része a Manjaro fos rolling frissítési megoldásai miatt is lehet, de van jópár ami abszolút KDE bug, mert más épp általam tesztelt KDE-s disztrónál is előjön. Jelenleg olyan mélyen most én sem használok
rajta sokmindent, persze fent vannak, a calligra ugyanúgy mint sokminden más. Nem ez okozza a problémát.

☆☼♫♪♫♪☼☆
AGA@
Fork portal és az egyik logóm :)

Lehet, hogy manjaro problémába futsz bele? Én pont azt tapasztalom, hogy kb. fél évvel ezelőttig rendszeresen futottam problémákba. Azóta alig-alig. Ezt úgy kell érteni, hogy öt-hat hetente egyszer valami kis hiba előjön, ami addig nem. De ha nem frissítek mindig (Arch64bit), akkor a jót meg lehet őrizni.....

Gondolom arra irányult volna a kérdés, hogy valszeg csak Manjaro hibáról van szó. Arról is. Az mhwd több verzió óta kifagy, a mostani frissítés botrányosan szarul lett kivitelezve, lekommunikálva (systemd userek és KDE-sek sorry, szívjatok pl.) Ettől függetlenül más KDE-t használó disztrónál is megtaláltam több hibát amit itt is.
De javul a dolog.

☆☼♫♪♫♪☼☆
AGA@
Fork portal és az egyik logóm :)

( akkos v | 2016. 10. 08., szo – 20:57 )

a Rick Astley-s lockscreen visz mindent. Hol lehet kérni hogy default legyen? :)