Linspire CNR, al via la beta

Avviato il beta testing pubblico del servizio gratuito per l'installazione e la gestione delle applicazioni Linux. E' accessibile attraverso un client open source disponibile anche per Ubuntu

San Diego (USA) - Il progettone con cui Linspire ambisce a standardizzare l'installazione e l'aggiornamento delle applicazioni sotto Linux, ha appena preso corpo con il lancio della prima beta pubblica di CNR.com.

CNR.com è un servizio Web 2.0 gratuito progettato per semplificare la ricerca, l'installazione e la manutenzione dei pacchetti software in formato Debian (DEB) e RPM. Per interagire con il servizio web-based, gli utenti devono scaricare un client open source oggi disponibile per le distribuzioni Linux Freespire, Linspire e Ubuntu. La versione finale del programma sarà rilasciata anche per Debian, Fedora e OpenSUSE.

Il servizio CNR.com dà accesso ad un vasto repository di software per Linux che permette agli utenti di cercare i programmi per nome, categoria, autore ecc., e di accedere a screenshot, recensioni, commenti. Nell'archivio sono incluse anche numerose applicazioni commerciali, che gli utenti possono acquistare direttamente dal client.
"CNR.com fornisce un certo numero di funzionalità interattive con cui gli utenti possono contribuire a creare una comunità", ha affermato Larry Kettler, president e CEO di Linspire. "Molti dei contenuti di CNR.com sono generati dalla comunità, inclusi screenshot, recensioni, voti, descrizioni e categorie".

Per accedere alle funzionalità base offerte dal servizio, quali l'installazione, la disinstallazione, l'aggiornamento e la ricerca delle applicazioni, non occorre alcuna registrazione. Chi si registra gratuitamente può accedere ad una più ampia gamma di risorse, quali forum, newsletter e servizio di assistenza base. Per poco meno di 50 dollari è poi possibile sottoscrivere un abbonamento annuale Premium che, fra le altre cose, dà diritto a forti sconti sull'acquisto delle applicazioni commerciali e ad un servizio di supporto di livello professionale. Una tabella che mostra la differenza fra il servizio gratuito e quello a pagamento è consultabile qui.
9 Commenti alla Notizia Linspire CNR, al via la beta
Ordina
  • > Son circa 6 o 7 anni che lo dico, prendendomi in
    > risposta fischi, pomodori marci e quant'altro da
    > parte della community Linux: sono (almeno) due le
    > grosse pecche di un sistema altrimenti
    > estremamente interessante (e che uso c.ca dal
    > '95):
    > 1) filesystem non strutturato in modo standard:
    > anche se la LSB (che segue FHS) c'è da un pò,
    > diverse distro hanno directories differenti (e
    > non nelle parti opzionali). Se usi una distro e
    > parli con uno che ne usa un'altra non sei mai
    > sicuro che lo stesso file lo trovi nello stesso
    > posto e/o che abbia lo stesso
    > nome.
    > Secondo me non c'è alcun motivo per avere lo
    > stesso file, rappresentante la stessa
    > funzionalità, in posti diversi e ad un minor
    > standard corrisponde un maggior casino (lo dico
    > da sistemista: in genere i programmatori, quando
    > dico 'ste cose, ululano per la "mancanza di
    > libertà" che secondo loro questo
    > comporta).
    > 2) sistemi di pacchettizzazione diversi (rpm,
    > deb ed altro), spesso anche con contenuti diversi
    > (a causa del p.to 1), per le diverse distro:
    > quando cerchi "un pacchetto" in realtà devi
    > cercarlo "per la tua distro" e "per la versione"
    > della tua distro (guarda invece la differenza con
    > un pacchetto "per Windows/XP" o "per MacOSX": è
    > una questione di versione, non di
    > sistema).
    > Per quel che mi riguarda il gestore dei
    > pacchetti di sistema dovrebbe lavorare su uno
    > standard unico, senza che abbia importanza la
    > diversa pacchettizzazione (quanto meno ci
    > dovrebbe essere uno standard minimo di
    > pacchettizzazione). Mi viene un parallelo con la
    > gestione delle e-mail: una mail segue i SUOI
    > standard, poi i MUA/MDA/ecc.ecc. fanno quel che
    > gli pare, ma il risultato è sempre lo stesso (AKA
    > non importa, in fondo, il "processo" quanto il
    > risultato).
    >
    > Il CRN ora sembra che sistemi il punto 2...
    > speriamo che prima o poi si possa avere "un unico
    > Linux" (giusto per dire: il problema dei dialetti
    > è una spina nel fianco di Unix da sempre) anche
    > se varie parti son curate da varie
    > organizzazioni: io mi aspetto che le differenze
    > siano a livello di "prodotto" non di
    > sistema.
    > Quando si riuscirà a parlare di "GNU/Linux" e
    > non di "Debian", "RedHat", "SuSE", "Mandriva"
    > ecc. ecc. faremo un balzo avanti non da poco
    > quanto a
    > diffusione.
    > NON mi auguro, con questo, che RH, SuSE/Novell &
    > co. spariscano: mi auguro solo di poter
    > installare "Linux" senza dovermi preoccupare (AKA
    > legare) ad un fornitore paricolare. Mi ci
    > legherò, come "fornitore di servizi", in caso mi
    > serva qualcosa di più (assistenza, documentazione
    > ecc. ecc.) ma non come "obbligo" derivato da una
    > scelta di
    > distro.
    > Infine, s


    Quoto in pieno. Chiaramente si possono usare i sistemi automatici per aggiornare il software come quelli messi a disposizione da SUSE oppure UBUNTU, sono utili quanto efficaci, ma NON SONO STANDARD. La posizione dei file di configurazione per i medesimi software è diversa(basti pensare ad APACHE che ognuno fa un pò quel cazzo che vuole con i file di configurazione, per cui l'unica soluzione è compilare a parte) e se si vuole installare il pacchetto di un'altra distribuzione bisogna traformare in maniera non sempre efficace, ed anche per quanto riguarda la retrocompatibilità non siamo messi tanto bene e se volete nemmeno con le informazioni fornite sulla posizione dei file stessi. Chiaramente molte volte basta un whereis o locate ma spesso non basta e tocca smadonnare.
    Mi sembra comunque, una critica costruttiva quella fatta da sky, ma qui mi ho l'impressione che gli utilizzatori di Linux assurgono sempre ad èlite di conoscitori d'ogni segreto. Datemi soluzioni, si soluzioniii.....
    non+autenticato
  • ma il servizio avvisi per l'aggiornamento automatico non era a pagamento?

    avevo letto che solo l'aggiornamento "manuale" era gratuito...
    ...sarà un errore o un ripensamento?
    non+autenticato
  • Ottima idea,
    riuscire a rendere le installazioni più facili come su Windowz (dove cmq non sono del tutto banali) anche su Linux e Linspire, significherebbe guadagnare una bella fetta d'utenza.
  • Son circa 6 o 7 anni che lo dico, prendendomi in risposta fischi, pomodori marci e quant'altro da parte della community Linux: sono (almeno) due le grosse pecche di un sistema altrimenti estremamente interessante (e che uso c.ca dal '95):
    1) filesystem non strutturato in modo standard: anche se la LSB (che segue FHS) c'è da un pò, diverse distro hanno directories differenti (e non nelle parti opzionali). Se usi una distro e parli con uno che ne usa un'altra non sei mai sicuro che lo stesso file lo trovi nello stesso posto e/o che abbia lo stesso nome.
    Secondo me non c'è alcun motivo per avere lo stesso file, rappresentante la stessa funzionalità, in posti diversi e ad un minor standard corrisponde un maggior casino (lo dico da sistemista: in genere i programmatori, quando dico 'ste cose, ululano per la "mancanza di libertà" che secondo loro questo comporta).
    2) sistemi di pacchettizzazione diversi (rpm, deb ed altro), spesso anche con contenuti diversi (a causa del p.to 1), per le diverse distro: quando cerchi "un pacchetto" in realtà devi cercarlo "per la tua distro" e "per la versione" della tua distro (guarda invece la differenza con un pacchetto "per Windows/XP" o "per MacOSX": è una questione di versione, non di sistema).
    Per quel che mi riguarda il gestore dei pacchetti di sistema dovrebbe lavorare su uno standard unico, senza che abbia importanza la diversa pacchettizzazione (quanto meno ci dovrebbe essere uno standard minimo di pacchettizzazione). Mi viene un parallelo con la gestione delle e-mail: una mail segue i SUOI standard, poi i MUA/MDA/ecc.ecc. fanno quel che gli pare, ma il risultato è sempre lo stesso (AKA non importa, in fondo, il "processo" quanto il risultato).

    Il CRN ora sembra che sistemi il punto 2... speriamo che prima o poi si possa avere "un unico Linux" (giusto per dire: il problema dei dialetti è una spina nel fianco di Unix da sempre) anche se varie parti son curate da varie organizzazioni: io mi aspetto che le differenze siano a livello di "prodotto" non di sistema.
    Quando si riuscirà a parlare di "GNU/Linux" e non di "Debian", "RedHat", "SuSE", "Mandriva" ecc. ecc. faremo un balzo avanti non da poco quanto a diffusione.
    NON mi auguro, con questo, che RH, SuSE/Novell & co. spariscano: mi auguro solo di poter installare "Linux" senza dovermi preoccupare (AKA legare) ad un fornitore paricolare. Mi ci legherò, come "fornitore di servizi", in caso mi serva qualcosa di più (assistenza, documentazione ecc. ecc.) ma non come "obbligo" derivato da una scelta di distro.
    Infine, secondo me, è un pò un controsenso che parlando di "open source" (quindi gente diversa che collabora allo sviluppo degli stessi pacchetti) si abbiano distribuzioni diverse spesso in contrasto tra di loro e comunque incompatibili.
    Se qualcuno ha qualcosa da eccepire sulla "non compatibilità" come l'ho descritta, mi faccia il piacere di installare un pacchetto rpm per SuSE10.0 su una Debian Etch (4.0) e poi ne riparliamo.
    885
  • - Scritto da: Sky
    > Son circa 6 o 7 anni che lo dico, prendendomi in
    > risposta fischi, pomodori marci e quant'altro da
    > parte della community Linux: sono (almeno) due le
    > grosse pecche di un sistema altrimenti
    > estremamente interessante (e che uso c.ca dal
    > '95):
    > 1) filesystem non strutturato in modo standard:
    > anche se la LSB (che segue FHS) c'è da un pò,
    > diverse distro hanno directories differenti (e
    > non nelle parti opzionali). Se usi una distro e
    > parli con uno che ne usa un'altra non sei mai
    > sicuro che lo stesso file lo trovi nello stesso
    > posto e/o che abbia lo stesso
    > nome.
    > Secondo me non c'è alcun motivo per avere lo
    > stesso file, rappresentante la stessa
    > funzionalità, in posti diversi e ad un minor
    > standard corrisponde un maggior casino (lo dico
    > da sistemista: in genere i programmatori, quando
    > dico 'ste cose, ululano per la "mancanza di
    > libertà" che secondo loro questo
    > comporta).
    > 2) sistemi di pacchettizzazione diversi (rpm,
    > deb ed altro), spesso anche con contenuti diversi
    > (a causa del p.to 1), per le diverse distro:
    > quando cerchi "un pacchetto" in realtà devi
    > cercarlo "per la tua distro" e "per la versione"
    > della tua distro (guarda invece la differenza con
    > un pacchetto "per Windows/XP" o "per MacOSX": è
    > una questione di versione, non di
    > sistema).
    > Per quel che mi riguarda il gestore dei
    > pacchetti di sistema dovrebbe lavorare su uno
    > standard unico, senza che abbia importanza la
    > diversa pacchettizzazione (quanto meno ci
    > dovrebbe essere uno standard minimo di
    > pacchettizzazione). Mi viene un parallelo con la
    > gestione delle e-mail: una mail segue i SUOI
    > standard, poi i MUA/MDA/ecc.ecc. fanno quel che
    > gli pare, ma il risultato è sempre lo stesso (AKA
    > non importa, in fondo, il "processo" quanto il
    > risultato).
    >
    > Il CRN ora sembra che sistemi il punto 2...
    > speriamo che prima o poi si possa avere "un unico
    > Linux" (giusto per dire: il problema dei dialetti
    > è una spina nel fianco di Unix da sempre) anche
    > se varie parti son curate da varie
    > organizzazioni: io mi aspetto che le differenze
    > siano a livello di "prodotto" non di
    > sistema.
    > Quando si riuscirà a parlare di "GNU/Linux" e
    > non di "Debian", "RedHat", "SuSE", "Mandriva"
    > ecc. ecc. faremo un balzo avanti non da poco
    > quanto a
    > diffusione.
    > NON mi auguro, con questo, che RH, SuSE/Novell &
    > co. spariscano: mi auguro solo di poter
    > installare "Linux" senza dovermi preoccupare (AKA
    > legare) ad un fornitore paricolare. Mi ci
    > legherò, come "fornitore di servizi", in caso mi
    > serva qualcosa di più (assistenza, documentazione
    > ecc. ecc.) ma non come "obbligo" derivato da una
    > scelta di
    > distro.
    > Infine, secondo me, è un pò un controsenso che
    > parlando di "open source" (quindi gente diversa
    > che collabora allo sviluppo degli stessi
    > pacchetti) si abbiano distribuzioni diverse
    > spesso in contrasto tra di loro e comunque
    > incompatibili.
    > Se qualcuno ha qualcosa da eccepire sulla "non
    > compatibilità" come l'ho descritta, mi faccia il
    > piacere di installare un pacchetto rpm per
    > SuSE10.0 su una Debian Etch (4.0) e poi ne
    > riparliamo.

    Non basta far passare il pacchetto dal comando rpm2deb ?
    non+autenticato
  • - Scritto da: Sparrow
    > Ottima idea,
    > riuscire a rendere le installazioni più facili
    > come su Windowz

    Le installazioni sono giß pi˙ facili! Sotto Debian apri synaptic, cerchi quello che vuoi, scegli dalla lista e lui scarica dalla rete e installa!

    Considerando che adesso c'é Ubuntu, che personalmente vedo come la prima vera soluzione linux desktop in grado di fare breccia, il meraviglioso mondo dei pacchetti DEB é a disposizione anche dei neofiti.

    Senza parlare di patch e updates! Debian/Ubuntu te li segnala, li scarichi quando vuoi... raramente ti chiede di riavviare un'applicazione se é stata aggiornata mentre era aperta... Mi sembra di vederlo windows, che non ti lascia spegnere il computer se ci sono patch da installare e ogni tanto ti presenta il pop-up "Mi riavvio tra 10 secondi..." 9... 8... 7... e tu (sempre se sei lÝ presente) tiri bestemmie mentre salvi il tuo lavoro!
  • perche' non impari ad usare gli update automatici? ah giusto... bisogna leggere la documentazione...
    non+autenticato
  • C'è un po' di confusione..
    non+autenticato
  • Sistemato, grazieOcchiolino

    - Scritto da: DVD16x
    > C'è un po' di confusione..
    non+autenticato