Rilasciato KDE 4.4.0

[Blallo]

STo cercando arnative ad amarok e digikam per esempio, ma senza troppi successi

hai provato Exile? (almeno per quanto riguarda amarok)

[Bart]

Purtroppo non conosco bene la questione PolicyKit e mi piacerebbe tanto capire del perché il team di Slackware riscontra così tante difficoltà nell'implementarlo...

Non incontra difficoltà a farlo, semplicemente non vuole farlo.

[puzuma]

Questa cosa non mi piace,tant è che con slackware uso XFCE e con squeeze sono passato a GNOME.

strana scelta: i tool che non ti piacciono in KDE sono stati inseriti in GNOME molto prima ed è stato uno dei motivi per cui GNOME è stato tolto dalla slackware.

Staremo a vedere se anche per usare LInux saremo costretti a comprare un computer ogni anno..

Il mio portatile compie tra poco 5 anni, ho installato KDE 4.4.0 appena Alien ha messo a disposizione i suoi pacchetti e non ho avuto nessun problema nè di stabilità nè di performance.

Poi non capisco sta cosa del SO dentro il SO, io continuo ad amministrare le cose esattamente come facevo con KDE 1.0 e non trovo tutte 'ste difficoltà.

Non è che la vostra è solo paura del nuovo ?

[refused]

Quoto puzuma.
E se il team di slackware decide di non pacchettizzare una libreria instabile non credo sia per farlo diventare "di nicchia".
Non vedo dove stiano tutti questi problemi, ho aggiornato a 4.4.0 e uso il mio laptop anche a lavoro. Successfully.

[Trotto@81]

strana scelta: i tool che non ti piacciono in KDE sono stati inseriti in GNOME molto prima ed è stato uno dei motivi per cui GNOME è stato tolto dalla slackware.

Gnome è stato tolto perchè la pacchettizzazione era troppo gravosa vista la dispersività e l'enorme quantità di pacchetti da installare.
KDE invece è ben organizzato da questo punto di vista.

[Savius]

Non incontra difficoltà a farlo, semplicemente non vuole farlo.

Grazie per la risposta Bart! Solo ora mi sorrge un'altra domanda: "Cos'hanno le PolicyKit che danno così fastidio al team di sviluppo di Slackware?" Scusa l'ignoranza... ^^''

[ksniffer]

Staremo a vedere se anche per usare LInux saremo costretti a comprare un computer ogni anno..

Io lo uso su un vecchio Athlon XP 2600 (2 GHz di CPU) e 1.5 GByte di RAM di 5 anni fa, forse 6 e con gli effetti grafici disabilitati (ho una ATI Radeon 9250) va bene non è per nulla lento. Sull'eeepc 1000HE ho gli effetti grafici abilitati e va bene, ma lì c'è una scheda grafica Intel ed è supportatissima da Xorg e kernel.
Certo si tira dietro molte dipendenze KDE, ma sta diventando sempre più comodo, poi se proprio non piace ci sono altri DE .

[ksniffer]

Certo! Ma è nato prima, è fatto da un gruppo che, per quanto possa essere discutibile, ha sempre cercato di fare del suo meglio. Il punto di tutto questo, e concludo perché la mia era solo una mera considerazione: se io creo un sito che parla di Slackware o di qualunque altra cosa attinente a questo ambito, o lo segnalo nella sezione apposita oppure lo lascio nella firma. Se l'annnuncio IN ITALIANO fosse reperibile SOLO sul sito kde-it e fosse stato linkato da una persona estranea a quel sito allora non avrei fiatato ma dato che è stato il creatore e gestore stesso del sito a proporre quel link e alla luce delle considerazioni fatte poco fa, ho storto un po' il naso perché l'ho vista più come pubblicità che come redirect ad una notizia.

Dico solo: informarsi prima e non limitarsi e avere preconcetti. Nessun moderatore in giro? Questa cosa è OT.

KDE 4.4.0 è un grande ambiente Desktop .

[panda84]

As a result, the KDE 4.4.0 Slackware packages (the ones I built) miss certain features that require authorization through PolKit: for instance there is no font installer, and it is impossible to change the computer's time and date in KDE 4.4.0.

Non vorrei dire una baggianata, ma quei moduli sono stati in sola lettura sin dall'arrivo di KDE 4.0. L'unico modo per utilizzarli era usare kdesu o, che alla fine è la stessa cosa, avviare il modulo da root. Dato che avviare una intera interfaccia grafica da root non è una cosa ottimale dal punto di vista della sicurezza è stato scelto di disattivare tutto in toto, lasciando la possibilità di fare modifiche solo a chi era consapevole dei rischi.

Per quanto riguarda PolicyKit si può essere d'accordo su alcune critiche, ma al momento mi pare sia l'unico strumento in Linux che permette alle interfacce grafiche di effettuare singole azioni privilegiate senza diventare root in toto.

[Bart]

Non incontra difficoltà a farlo, semplicemente non vuole farlo.

Grazie per la risposta Bart! Solo ora mi sorrge un'altra domanda: "Cos'hanno le PolicyKit che danno così fastidio al team di sviluppo di Slackware?" Scusa l'ignoranza... ^^''

Sinceramente non ne so molto nemmeno io. Da quanto ho letto in giro sembra sia legato a problemi di stabilità.

[Blallo]

http://it.wikipedia.org/wiki/PolicyKit

[Mario Vanoni]

http://it.wikipedia.org/wiki/PolicyKit

PolicyKit è un componente del sistema operativo che controlla i vasti sistemi di privilegi nei sistemi Unix-like. Fornisce un modo organizzato per i processi non privilegiati per comunicare con quelli privilegiati. In contrasto al sistema sudo, PolicyKit non fornisce i permessi di root all'intero processo, ma consente invece un livello di controllo più accurato della politica di sistema centralizzato. Viene sviluppato dal progetto freedesktop.org

Domanda:
- il Super-User (root) con /bin/su - fa tutto
- con sudo un utente normale puo` fare qualcosa, ma chi decide che lo possa fare?
- chi decide alla fin fine che cosa possa fare PolicyKit?

Lo decide il sysadm con permesso di root,
o lo decide a puro caso l'interfaccia PolicyKit?

Dare ad un utente permessi eseguibli da root,
nella mia umile opinione, e` poco prudente (idiosincrasia),
se l'utente vuole qualcosa, chieda al sysadm di farlo!

E lasciare le decisioni ad un DE environment ...

[Trotto@81]

Deve cambiare politica KDE, perchè è sbagliato dare permessi che non competono ad un utente normale.

[panda84]

Deve cambiare politica KDE, perchè è sbagliato dare permessi che non competono ad un utente normale.

Scusa, stai dicendo che per cambiare l'ora devo chiamare il sysadmin? Stai dicendo che chiedere la password di root, come veniva fatto prima con "kdesu" o con "su -", ma in maniera più sicura e meno raffazzonata "è sbagliato"?

PolicyKit è un framework... è un framework che tra l'altro permette al sysadmin di scrivere regole del tipo "non lasciare che ad un utente normale sia permesso di fare questo", che permette regole del tipo "all'utente normale può essere permesso di fare questo se inserisce una data password", oppure ancora "all'utente normale è permesso installare font anche senza inserire alcuna password".

Tutto questo non è possibile con il vecchio sistema. PolicyKit permette nuove possibilità, non è che preclude quelle precedenti...

Per favore, argomentate più nello specifico quando parlate contro qualcosa!


Per rafforzare il concetto:
PRIMA DI POLICYKIT:
a) kdesu avvia un intera interfaccia grafica come root chiedendo la password relativa.

CON POLICYKIT:
a) la scelta predefinita è che l'utente può effettuare un'azione se ha la password di root, ma con il vantaggio di non avviare un'intera interfaccia come root;
b) è possibile dire: "questo, questo e ques'altro utente NON possono fare questa azione MAI, tizio e caio solo se mettono la password, mentre sempronio può farlo anche se non inserisce la password";
c) si può sempre usare kdesu se a uno piacciono i metodi vecchi.

Ora, posso capire le motivazioni relative al fatto che PolicyKit sia ancora instabile o difficile da pacchettizzare, ma le altre argomentazioni ancora mi sfuggono, visto che è solo una possibilità in più e pure molto più configurabile (e per certi versi anche più sicura)...

[Mario Vanoni]

Scusa, stai dicendo che per cambiare l'ora devo chiamare il sysadmin? l

Mi pare ovvio, l'ora del sistema e` costante,
altrimenti ogni utente mette la _sua_ ora, chi poi ha ragione/torto?