CERCA
PER MODELLO
FullScreen Chatbox! :)

Utente del giorno: con ben Thanks ricevuti nelle ultime 24 ore
Utente della settimana: megthebest con ben 7 Thanks ricevuti negli ultimi sette giorni
Utente del mese: megthebest con ben 40 Thanks ricevuti nell'ultimo mese

Pagina 85 di 191 primaprima ... 3575838485868795135185 ... ultimoultimo
Ultima pagina
Visualizzazione dei risultati da 841 a 850 su 1906
Discussione:

[ROM] CyanogenMod 9

Se questa discussione ti è stata utile, ti preghiamo di lasciare un messaggio di feedback in modo che possa essere preziosa in futuro anche per altri utenti come te!
  1. #841
    Senior Droid L'avatar di Bonvaz


    Registrato dal
    Jun 2011
    Messaggi
    566

    Ringraziamenti
    75
    Ringraziato 50 volte in 45 Posts
    Predefinito

    Quote Originariamente inviato da Gynlemon Visualizza il messaggio
    Meravigliosi



    Si
    quindi dipendono dal kernel che c'è su giusto?..non ho mai capito perchè il kernel che usa la cyanogenmod9 non si può installare su altre rom..vabeh,aspetto a passare a cm9 finchè il problema di drain del ekrnel non è a posto..
    SE TI SONO STATO UTILE è GRADITO UN THANKS

  2.  
  3. #842
    Senior Droid


    Registrato dal
    Dec 2011
    Messaggi
    523
    Smartphone
    LeEco Le Pro3 6/64GB

    Ringraziamenti
    31
    Ringraziato 51 volte in 48 Posts

  4. #843
    Banned


    Registrato dal
    May 2011
    Messaggi
    12,288

    Ringraziamenti
    667
    Ringraziato 4,133 volte in 3,084 Posts
    Predefinito

    Dalla serie.. o usi la mia CM9 cosi come te la distribuisco completa di kernel.. o sei libero di flasharti altre ROM.. quindi guerra aperta e distanze con sviluppatori per kernel per CM9.. ne fai uso?? bene non ti do nessun supporto e sono cazzi tuoi se qualcosa ti va storto...

    Da una parte hanno ragione ( troppi sviluppatori per kernel )
    Dall'altra no!! posso capire se il kernel CM9 fosse una specie di scudo per la batteria.. ma è uno scolapasta.. quindi se il team CM9 si sentono tanto fighi.. che ci mettessero davvero mani al kernel in maniera da non aver bisogno di nessun'altro kernel alternativo...


    e... se tutti boicottassero la CM9 ?? vedessero calare i download di botto?

    che ne dite voi??
    Ultima modifica di Gynlemon; 24-05-12 alle 21:55

  5. #844
    Senior Droid L'avatar di Bonvaz


    Registrato dal
    Jun 2011
    Messaggi
    566

    Ringraziamenti
    75
    Ringraziato 50 volte in 45 Posts
    Predefinito

    Quote Originariamente inviato da Gynlemon Visualizza il messaggio
    Dalla serie.. o usi la mia CM9 cosi come te la distribuisco completa di kernel.. o sei libero di flasharti altre ROM.. quindi guerra aperta e distanze con sviluppatori per kernel per CM9.. ne fai uso?? bene non ti do nessun supporto e sono cazzi tuoi se qualcosa ti va storto...

    Da una parte hanno ragione ( troppi sviluppatori per kernel )
    Dall'altra no!! posso capire se il kernel CM9 fosse una specie di scudo per la batteria.. ma è uno scolapasta.. quindi se il team CM9 si sentono tanto fighi.. che ci mettessero davvero mani al kernel in maniera da non aver bisogno di nessun'altro kernel alternativo...


    e... se tutti boicottassero la CM9 ?? vedessero calare i download di botto?

    che ne dite voi??
    quando dici che il kernel cm9 è uno scolapasta intendi che fa pena? XD ..comunque riesci a riassumermi un pò quello che ha postato kipe?non tropppo buono in inglese e sembra davvero un mattone da leggere XD..
    SE TI SONO STATO UTILE è GRADITO UN THANKS

  6. #845
    Banned


    Registrato dal
    May 2011
    Messaggi
    12,288

    Ringraziamenti
    667
    Ringraziato 4,133 volte in 3,084 Posts
    Predefinito

    Quote Originariamente inviato da Bonvaz Visualizza il messaggio
    quando dici che il kernel cm9 è uno scolapasta intendi che fa pena? XD ..comunque riesci a riassumermi un pò quello che ha postato kipe?non tropppo buono in inglese e sembra davvero un mattone da leggere XD..
    Beh ..nel post precedente credo che ho fatto una specie di sintesi.. comunque vedo di far lavorare Google Traduttore:

    Le decisioni egocentrici del team CM - perché ferito sviluppatori indipendenti e la comunità?
    Ci sono diversi kernel tweaks attuato da vari sviluppatori che richiedono / regolazione sostegno di qualche tipo di parametri. Come l'interfaccia di un dev di solito aggiunge alcune voci aggiuntive ai sysfs. Quando si scrive un GUI / frontend per questa interfaccia sysfs si legge semplicemente / scrive un valore da / per queste voci sysfs. Circa un anno fa uno dev team di CM (che è rimasto anonimo) ha cominciato a fare modifiche del kernel che sono là fuori da altri sviluppatori del kernel indipendente e di re-implementare li sotto un'interfaccia incompatibili. Il suo obiettivo era quello di unificare l'interfaccia sysfs tra diversi dispositivi in modo che quando l'attuazione di una GUI nel controllo ROM CM CM gli sviluppatori potrebbero utilizzare il gancio stesso sysfs. Questo significa meno lavoro per gli sviluppatori CM quanto potrebbero utilizzare lo stesso codice nella ROM tra diversi dispositivi senza modifiche. Tuttavia invece che significa anche che per ciascuno di tali dispositivi si sono ora due implementazioni incompatibili per la stessa funzionalità in cui maggior parte dei casi non possono essere contemporaneamente sia aggiunto al kernel. E mentre alcuni sviluppatori del kernel attaccato l'implementazione originale, gli altri ha adottato la versione CM per essere compatibile con i controlli ROM CM. Quindi, questa pratica di CM ha portato a una frammentazione ulteriore artificiale per i dispositivi con conseguente varie conseguenze negative per entrambi i kernel sviluppatori indipendenti e anche gli utenti comuni. per gli sviluppatori del kernel, ciò significa che sono costretti a prendere una decisione che l'attuazione di sostenere che praticamente mezzi per decidere quali strumenti grafici per rompere poiché questi sono normalmente compatibile solo con una implementazione. Il dev kernel originale di questi strappati-off tweaks sono colpiti più duramente dal momento che alcuni di loro hanno messo fuori applicazioni sul mercato per finanziare il loro lavoro. Così, quando gli altri sviluppatori del kernel adattare la CM sapore le loro applicazioni non funzioneranno più con questi kernel. D'altra parte vi è l'utente comune che ora ha l'ulteriore problema di tenere traccia cui sapore è implementato nel kernel sta usando e che GUI strumenti di lavorare con esso. Ciò si traduce in confusione non necessaria che porta di nuovo a persone che si lamentano per gli sviluppatori del kernel che questo o quello strumento GUI / ROM di controllo non funziona. Come si può vedere la CM decisioni ha fatto bene per lavoro fuori CM themself e sviluppatori del kernel comunque indipendenti ed essenzialmente tutta la comunità ottiene il lato corto del bastone. A febbraio ho contattato uno che dev CM che è stato reponsible per questi incompatibili re-implementazioni e gli ho spiegato il mio punto di vista, tuttavia non era disposto a collaborare. Così agli inizi di marzo Imoseyon, Francisco, Morfic e mi ha contattato i leader del team CM. Il Reponse del team CM era cordiale, sembravano essere disposti a cooperare e promesse sono state fatte per arrivare a questo problema risolto. Purtroppo è emerso chiaramente che queste promesse non erano sinceri visto che dopo averci dato un run-in giro per due mesi niente di tutto a tutti è successo ( http://h11.abload.de/img/cm11t89f.jpg ). Alla fine di questi di due mesi a scherzare con noi e di sprecare il nostro tempo la squadra ha fatto CM informarci che non solo essi non ripristinare le modifiche che hanno fatto per risolvere il caos e la confusione che ne derivarono, ma anche che per il futuro si riservano il diritto di modifiche del kernel da altri sviluppatori indipendenti là fuori e li re-implementare in interfacce incompatibili ( http://h11.abload.de/img/cm2evk65.jpg ). per gli sviluppatori del kernel, in pratica, questo significa che non si può rilasciare un nuovo tweak senza temere che le CM lo prende e reimplementa sotto un'interfaccia compatibile la creazione di un altro pasticcio. Così, per il futuro se si vuole implementare una nuova funzionalità rende più sicuri di utilizzare la stessa interfaccia sysfs che CM ha definito a standard. Se questo è inteso o no da CM, questo sarà il risultato finale pratico. E avendo quella minaccia sempre indugiando in background quando si rilascia un nuovo tweak non è semplicemente accettabile. Abbiamo cercato di evitare il dramma che viene fornito con pubblicamente critizing altri sviluppatori e ha mostrato un sacco di moderazione e pazienza nella elaborazione di un compromesso con il CM squadra in privato, tuttavia, come chiunque può vedere dalle comunicazioni pubblicate nostri sforzi hanno chiaramente raggiunto un vicolo cieco. sentiamo fortemente che questo sia un tema importante non solo per noi ma anche altri sviluppatori del kernel indipendenti e l'intera comunità e quindi, si senta responsabile per porre fine a questa pratica dannosa adottato dal team CM di creare ulteriore frammentazione non pertinente. Quindi ci rivolgiamo a voi - la comunità - per chiedervi di esprimere le vostre preoccupazioni al team CM.

  7. #846
    Senior Droid L'avatar di Bonvaz


    Registrato dal
    Jun 2011
    Messaggi
    566

    Ringraziamenti
    75
    Ringraziato 50 volte in 45 Posts
    Predefinito

    Quote Originariamente inviato da Gynlemon Visualizza il messaggio
    Beh ..nel post precedente credo che ho fatto una specie di sintesi.. comunque vedo di far lavorare Google Traduttore:

    Le decisioni egocentrici del team CM - perché ferito sviluppatori indipendenti e la comunità?
    Ci sono diversi kernel tweaks attuato da vari sviluppatori che richiedono / regolazione sostegno di qualche tipo di parametri. Come l'interfaccia di un dev di solito aggiunge alcune voci aggiuntive ai sysfs. Quando si scrive un GUI / frontend per questa interfaccia sysfs si legge semplicemente / scrive un valore da / per queste voci sysfs. Circa un anno fa uno dev team di CM (che è rimasto anonimo) ha cominciato a fare modifiche del kernel che sono là fuori da altri sviluppatori del kernel indipendente e di re-implementare li sotto un'interfaccia incompatibili. Il suo obiettivo era quello di unificare l'interfaccia sysfs tra diversi dispositivi in modo che quando l'attuazione di una GUI nel controllo ROM CM CM gli sviluppatori potrebbero utilizzare il gancio stesso sysfs. Questo significa meno lavoro per gli sviluppatori CM quanto potrebbero utilizzare lo stesso codice nella ROM tra diversi dispositivi senza modifiche. Tuttavia invece che significa anche che per ciascuno di tali dispositivi si sono ora due implementazioni incompatibili per la stessa funzionalità in cui maggior parte dei casi non possono essere contemporaneamente sia aggiunto al kernel. E mentre alcuni sviluppatori del kernel attaccato l'implementazione originale, gli altri ha adottato la versione CM per essere compatibile con i controlli ROM CM. Quindi, questa pratica di CM ha portato a una frammentazione ulteriore artificiale per i dispositivi con conseguente varie conseguenze negative per entrambi i kernel sviluppatori indipendenti e anche gli utenti comuni. per gli sviluppatori del kernel, ciò significa che sono costretti a prendere una decisione che l'attuazione di sostenere che praticamente mezzi per decidere quali strumenti grafici per rompere poiché questi sono normalmente compatibile solo con una implementazione. Il dev kernel originale di questi strappati-off tweaks sono colpiti più duramente dal momento che alcuni di loro hanno messo fuori applicazioni sul mercato per finanziare il loro lavoro. Così, quando gli altri sviluppatori del kernel adattare la CM sapore le loro applicazioni non funzioneranno più con questi kernel. D'altra parte vi è l'utente comune che ora ha l'ulteriore problema di tenere traccia cui sapore è implementato nel kernel sta usando e che GUI strumenti di lavorare con esso. Ciò si traduce in confusione non necessaria che porta di nuovo a persone che si lamentano per gli sviluppatori del kernel che questo o quello strumento GUI / ROM di controllo non funziona. Come si può vedere la CM decisioni ha fatto bene per lavoro fuori CM themself e sviluppatori del kernel comunque indipendenti ed essenzialmente tutta la comunità ottiene il lato corto del bastone. A febbraio ho contattato uno che dev CM che è stato reponsible per questi incompatibili re-implementazioni e gli ho spiegato il mio punto di vista, tuttavia non era disposto a collaborare. Così agli inizi di marzo Imoseyon, Francisco, Morfic e mi ha contattato i leader del team CM. Il Reponse del team CM era cordiale, sembravano essere disposti a cooperare e promesse sono state fatte per arrivare a questo problema risolto. Purtroppo è emerso chiaramente che queste promesse non erano sinceri visto che dopo averci dato un run-in giro per due mesi niente di tutto a tutti è successo ( http://h11.abload.de/img/cm11t89f.jpg ). Alla fine di questi di due mesi a scherzare con noi e di sprecare il nostro tempo la squadra ha fatto CM informarci che non solo essi non ripristinare le modifiche che hanno fatto per risolvere il caos e la confusione che ne derivarono, ma anche che per il futuro si riservano il diritto di modifiche del kernel da altri sviluppatori indipendenti là fuori e li re-implementare in interfacce incompatibili ( http://h11.abload.de/img/cm2evk65.jpg ). per gli sviluppatori del kernel, in pratica, questo significa che non si può rilasciare un nuovo tweak senza temere che le CM lo prende e reimplementa sotto un'interfaccia compatibile la creazione di un altro pasticcio. Così, per il futuro se si vuole implementare una nuova funzionalità rende più sicuri di utilizzare la stessa interfaccia sysfs che CM ha definito a standard. Se questo è inteso o no da CM, questo sarà il risultato finale pratico. E avendo quella minaccia sempre indugiando in background quando si rilascia un nuovo tweak non è semplicemente accettabile. Abbiamo cercato di evitare il dramma che viene fornito con pubblicamente critizing altri sviluppatori e ha mostrato un sacco di moderazione e pazienza nella elaborazione di un compromesso con il CM squadra in privato, tuttavia, come chiunque può vedere dalle comunicazioni pubblicate nostri sforzi hanno chiaramente raggiunto un vicolo cieco. sentiamo fortemente che questo sia un tema importante non solo per noi ma anche altri sviluppatori del kernel indipendenti e l'intera comunità e quindi, si senta responsabile per porre fine a questa pratica dannosa adottato dal team CM di creare ulteriore frammentazione non pertinente. Quindi ci rivolgiamo a voi - la comunità - per chiedervi di esprimere le vostre preoccupazioni al team CM.
    che delirio..peccato che stia accadendo questo..anche io avevo notato che i kernel cm9 iniziavano ad essere costruiti un pò troppo chiusi.....l'esempio del color control è lampante...
    SE TI SONO STATO UTILE è GRADITO UN THANKS

  8. #847
    Senior Droid


    Registrato dal
    Dec 2011
    Messaggi
    523
    Smartphone
    LeEco Le Pro3 6/64GB

    Ringraziamenti
    31
    Ringraziato 51 volte in 48 Posts
    Predefinito

    Praticamente e in parola povere il team CM sta cambiando completamente l'interfacciamento con le impostazioni del kernel, quindi i kernel dovranno essere appositamente sviluppati per la CM e solo per essa. Franco, glados e lean non saranno più compatibili con le impostazioni.
    L'unica vera cosa che disgusto di sto fatto è l'ulteriore frammentazione che viene a crearsi e che proprio non ci voleva.

  9. #848
    Senior Droid


    Registrato dal
    May 2011
    Messaggi
    489

    Ringraziamenti
    33
    Ringraziato 14 volte in 14 Posts
    Predefinito

    Che il kernel dia problemi è normale, sono nel pieno dello sviluppo ancora.
    Per le critiche sulla loro politica condivido con voi.
    Per il resto una volta rilasciata la rc o la stable è la migliore rom in assoluto. Peccato solo che siano lentissimi. Probabilmente uscirà jelly beam e non ci sarà ancora la stable.

    Rilasciata la nightly del 24

    Inviato dal mio Galaxy Nexus con Tapatalk 2
    Ultima modifica di gompaky; 25-05-12 alle 09:29
    Xiaomi Mi3 + MiBand: Miui 6 Android 4.4.4 - Stock
    Galaxy Nexus: Cyanogenmod 11 Android 4.4.4 - Stock CM11
    Optimus One: Cyanogenmod 7.2 Android 2.3.7 - Stock CM7.2
    Optimus Net: Cyanogenmod 7.2 Android 2.3.7 - kido

  10. #849
    Androidiano L'avatar di NandoTheKing


    Registrato dal
    Mar 2012
    Località
    Napoli
    Messaggi
    137
    Smartphone
    Samsung Galaxy Nexus

    Ringraziamenti
    4
    Ringraziato 4 volte in 4 Posts
    Predefinito

    Ragazzi nel week end vorrei flashare la CM9 sul Nexus, dopo aver visto i miracoli fatti sull huawei ideos di mia sorella mi sono convinto! Voglio chiedervi una cosa prima di procedere, vorrei fare un bel backup di tutti i dati prima di installarla, quale app mi consigliate?

    Inviato dal mio Galaxy Nexus usando Tapatalk

  11. #850
    Senior Droid L'avatar di glesius


    Registrato dal
    Apr 2012
    Località
    napoli
    Messaggi
    882

    Ringraziamenti
    18
    Ringraziato 155 volte in 151 Posts
    Predefinito

    Quote Originariamente inviato da NandoTheKing Visualizza il messaggio
    Ragazzi nel week end vorrei flashare la CM9 sul Nexus, dopo aver visto i miracoli fatti sull huawei ideos di mia sorella mi sono convinto! Voglio chiedervi una cosa prima di procedere, vorrei fare un bel backup di tutti i dati prima di installarla, quale app mi consigliate?

    Inviato dal mio Galaxy Nexus usando Tapatalk
    my backup oppure titanium.....

Pagina 85 di 191 primaprima ... 3575838485868795135185 ... ultimoultimo
Ultima pagina

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire risposte
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Torna su
Privacy Policy