Apple, il kernel per ARM è open source

Assieme ai consueti rilasci open source, la casa di Cupertino pubblica anche una novità: un porting del proprio kernel per architettura ARM a 32 e 64 bit. E c'è già chi interpreta il tutto come un segnale dell'abbandono di Intel

Roma – Come avviene di consueto ad ogni sua major release , Apple ha rilasciato il codice sorgente del nuovo kernel XNU (acronimo ricorsivo che sta per XNU’s Not Unix), su cui gira la nuova versione del sistema operativo Darwin, macOS High Sierra.

Il codice è disponibile su GitHub , protetto dalla licenza Apple Public Source License , conforme alle specifiche del software libero, ma non a quelle della GNU General Public License, in quanto limita fortemente la possibilità di distribuire liberamente il codice, che sia stato modificato o non. Inoltre, la versione mobile del kernel rimane a codice chiuso .

La novità sostanziale di questo rilascio è la presenza di un porting del codice del kernel , costruito appositamente per l’architettura ARM , sia a 32 che a 64 bit.

apple intel arm

Come riportato da AppleInsider , Apple utilizza già un componente ARM all’interno dei propri MacBook: nello specifico si tratta del chip T1 che gestisce la Touch Bar e il Touch ID. Per questa ragione non è detto che Apple stia pianificando di abbandonare Intel per quanto riguarda la fornitura di microprocessori, sebbene nei giorni scorsi siano circolati rumor in tal senso e sebbene la strada intrapresa per i gadget mobile possa alimentare simili considerazioni (la GPU del chip A11 Bionic di iPhone 8 e iPhone X è stata progettata in-house ).

D’altra parte, l’onerosità dell’operazione potrebbe implicare un importante cambio di direzione per la casa di Cupertino, con risultati imprevedibili nel lungo termine.

Elia Tufarolo

Fonte Immagine

La tua email sarà utilizzata per comunicarti se qualcuno risponde al tuo commento e non sarà pubblicato. Dichiari di avere preso visione e di accettare quanto previsto dalla informativa privacy

  • 038bb22b5fb scrive:
    Non è DRY
    Facilitare il copia e incolla non è una grande idea. Copia e incolla è ammesso solo quando ci sono rischi di creare dipendenze circolari o ci si aspetta in futuro una divergenza nei requisiti. Altrimenti il codice da riutilizzare si mette in una libreria condivisa e si evita di duplicare codice che costringe a duplicare anche la manutenzione (e se non si fa doppia manutenzione ci si ritrova con pericolose inconsistenze).DRY è l'acronimo per don't repeat yourself.
  • xte scrive:
    Traduzione
    Non fate manco più copia&incolla da stackexchange&c, componete il vostro software senza saper scrivere codice, limitatevi a selezionare funzioni/metodi, strutture/classi e componetele come i mattoncini di lego. Il fatto che il hello world pesi 300Mb e faccia schizzare la cpu (recente, esacore, ...) al 100% poco importa, voi avete risparmiato tempo sia quello per imparare sia quello per ragionare.-- fine traduzioneNon sono contro nulla che semplifichi la vita, ma aggiungere strati su strati per far contenti gli ignoranti serve solo a complicare la vita, fingendo di fare il contrario. Il succo è che anche se a cert'uni piacciono gli operai modello Ford non si può stringere i tempi oltre un tot e sopratutto non si può semplificare senza innovare.
    • Emanuele scrive:
      Re: Traduzione
      Per quanto sono d'accordo con ciò che ha detto, forse le conviene aprire l'articolo e leggerlo. Gli obiettivi per cui è pensato sono altri...
      • prova123 scrive:
        Re: Traduzione
        Dagli un pò di tempo ... un pò alla volta ci arrivano anche loro.
      • xte scrive:
        Re: Traduzione
        Ho scritto una "traduzione" perché dopo aver letto e compreso l'articolo l'ho sintetizzato e portato all'estremo: obiettivo "estremizzato" creare un layer sopra un "mare" di sources che permetta di "programmare", assistiti da un software apposito di cui CodeCarbonCopy sarebbe un futuro componente chiave "di backend", senza toccare codice reale. Ovvero l'ennesimo passo che sognano tanti commerciali: software "descritti" in linguaggio umano e realizzati da qualche intelligenza artificiale.Per oggi il fare da "specie di ORM" per metodi/funzioni non ha altro senso IMO.
Chiudi i commenti