Link alla notizia: http://www.hwupgrade.it/news/sistemi/intel-il-bios-e-morto-lunga-vita-a-uefi-class-3-fine-supporto-nel-2020_72544.html

Intel ha annunciato durante l'evento UEFI Plugfest che terminerà il supporto al BIOS legacy nel 2020, richiedendo l'uso dello standard UEFI Class 3

Click sul link per visualizzare la notizia.

lunga vita ai bi..ops...mini sistemi operativi che gestiscono componenti sulla scheda madre di cui sappiamo poco o nulla :D :stordita:

Userò schede AMD e processori AMD per il mio prossimo PC.

basta Intel, il mio prossimo PC sarà basato su cpu IBM Power
anzi, vado a ripulire la Olivetti programma 101

Userò schede AMD e processori AMD per il mio prossimo PC.

doveva essere una battuta?


discorso sicurezza, continuo a pensare che è un NI questo aumento, più diventa complesso un componente più è facile abbia falle, UEFI poi penso rimanga una delle cose meno aggiornate in assoluto

niente più Hiren's BootCD?

E allora farò il mio Bios, con blackjack e squillo di lusso! Anzi, senza blackjack e senza bios!
Semicit. ;)

Scusate l'ignoranza, ma con i sistemi Class 3 si potranno ancora utilizzare sotto Windows i programmi a 32 bit e i vecchi videogame?

Bah! la "vendono" per questioni di sicurezza, efficienza, bla, bla, bla, .... ma la sintesi e vanno a chiudere il "recinto dei buoi" dopo che ci hanno raccolti tutti.

L'80% dei computer futuri DEVONO avere lo stesso ciclo di vita similmente agli smartphone:
- obsolescenza programmata
- 2 annetti massimo di supporto ed upgrade;
... se compri un fondo di magazzino capace che sei fuori specifiche dopo pochi mesi
- poi si sarà obbligati a cambiare; esempio:
... la banca accetta operazioni solo da nuova versione di browser
... nuova versione di browser gira solo su nuova versione di rom
... nuova versione di rom gira solo da una certa release di hardware
... etc etc

Non vedo un bel futuro:muro: ..... ma me lo vendono per il "mio" bene, per la "mia" sicurezza ....:doh:

Il supporto è finito da un pezzo,altro che 2020.
Cmq pure la mia vecchia mobo per 1155 ha bios Uefi.

Bah! la "vendono" per questioni di sicurezza, efficienza, bla, bla, bla, .... ma la sintesi e vanno a chiudere il "recinto dei buoi" dopo che ci hanno raccolti tutti.

L'80% dei computer futuri DEVONO avere lo stesso ciclo di vita similmente agli smartphone:
- obsolescenza programmata
- 2 annetti massimo di supporto ed upgrade;
... se compri un fondo di magazzino capace che sei fuori specifiche dopo pochi mesi
- poi si sarà obbligati a cambiare; esempio:
... la banca accetta operazioni solo da nuova versione di browser
... nuova versione di browser gira solo su nuova versione di rom
... nuova versione di rom gira solo da una certa release di hardware
... etc etc

Non vedo un bel futuro:muro: ..... ma me lo vendono per il "mio" bene, per la "mia" sicurezza ....:doh:

C'e' roba buona in giro, vedo...

Quali dispositivi potrebbero non essere più riconosciuti dopo il passaggio a UEFI 3?
Solo schede video e di rete?

ma in pratica quali device legacy non funzioneranno? le schede video vecchie? ormai con le integrate sono inutili. Altro? i lettori cd-dvd vecchi? i floppy? le schedine aggiuntive per usb o similari? Gli hd ide riciclati con adattatori o schedine pcie?

invece mi preoccupa di più il fatto che ci stiamo avvicinando al secure boot obbligatorio (uefi class 3+, a pag 8 http://www.uefi.org/sites/default/files/resources/Brian_Richardson_Intel_Final.pdf) come vagamente accennato nell’articolo. Sarà possibile far partire i vari fork android x86 e similari, anche da cd/usb come faccio adesso?
Suppongo che Win crackato non partirà più.
Palladium sta arrivando...

Scusate l'ignoranza, ma con i sistemi Class 3 si potranno ancora utilizzare sotto Windows i programmi a 32 bit e i vecchi videogame?
a quanto ho letto in giro, no.
niente sw a 32bit.

per cui scaffale. AMD rulez

....Non vedo un bel futuro:muro: ..... ma me lo vendono per il "mio" bene, per la "mia" sicurezza ....:doh:

che poi invece è venuto fuori che UEFI è molto + insicuro del vecchio BIOS...

Quali dispositivi potrebbero non essere più riconosciuti dopo il passaggio a UEFI 3?
Solo schede video e di rete?

no, a quanto capisco tutte le periferiche. del resto il bios serve proprio ad avviare l'hw e fornire interfaccia fra questo ed il SO, per cui se le periferiche erano progettate x interfacciarsi ed essere avviate dal bios, e questo viene tolto, sostanzialmente non funzioneranno +.

Nessuno spauracchio di Palladium: i processori Intel saranno UEFI Classe 3, e non 3+. E in ogni caso Secure Boot attivato NON implica nessun Palladium.

Per il resto sono le solite polemiche inutili. Il BIOS è un rudere che va pensionato, mentre UEFI è finalmente un firmware moderno e di gran lunga migliore.

Non ci sono limiti nel far partire s.o. / software di basso livello. Tutt'altro.

Anzi, grazie a UEFI e a i suoi servizi è di gran lunga più semplice implementare un s.o., anche "basilare".

...
Per il resto sono le solite polemiche inutili. Il BIOS è un rudere che va pensionato, mentre UEFI è finalmente un firmware moderno e di gran lunga migliore....
Anzi, grazie a UEFI e a i suoi servizi è di gran lunga più semplice implementare un s.o., anche "basilare".
con tutti i bug e i rootkit associati... :rolleyes:

C'è addirittura un progetto di nome coreboot che mira a rendere open source il BIOS.

https://it.wikipedia.org/wiki/Coreboot

C'è addirittura un progetto di nome coreboot che mira a rendere open source il BIOS.

https://it.wikipedia.org/wiki/Coreboot
Progetto che purtroppo non ha futuro e che comunque già non supporta nuovo hardware da 5-6 anni.
Da qualche anno sia Intel che AMD hanno inserito all'interno dei loro processori dei sottosistemi che prevengono il boot su schede madri sprovviste di un bios da loro firmato. Questo anche perchè l'utente non possa eludere i meccanismi di "sicurezza" (backdoors e porte di accesso con privilegio superiore a quello dell'OS) che hanno inserito nei loro dispositivi.

Progetto che purtroppo non ha futuro e che comunque già non supporta nuovo hardware da 5-6 anni.
Da qualche anno sia Intel che AMD hanno inserito all'interno dei loro processori dei sottosistemi che prevengono il boot su schede madri sprovviste di un bios da loro firmato. Questo anche perchè l'utente non possa eludere i meccanismi di "sicurezza" (backdoors e porte di accesso con privilegio superiore a quello dell'OS) che hanno inserito nei loro dispositivi.
Sì, certo, come no. Il solito complottismo spicciolo internettiano...
con tutti i bug e i rootkit associati... :rolleyes:
I bug e i rootkit pre-esistevano a UEFI, ed esistono ancora a prescindere da UEFI. :mc:

I bug e i rootkit pre-esistevano a UEFI, ed esistono ancora a prescindere da UEFI. :mc:

...che quindi non apporta nessun vantaggio reale e solo nuovi limiti lacci e laccioli x l'utente.
come volevasi dimostrare. :rolleyes:

Ma si potrà ancora fare il boot da CD o chiavetta USB? Io quando l'ho dovuto fare, diverso tempo fa, mi ricordo che ho dovuto prima disattivare il secure boot, se non sarà più disattivabile, ci sarà un'altro modo?

...che quindi non apporta nessun vantaggio reale e solo nuovi limiti lacci e laccioli x l'utente.
come volevasi dimostrare. :rolleyes:
I vantaggi ci sono, e li conosceresti se avessi studiato come funziona l'UEFI, invece di attaccarti a complottismi e leggende metropolitane.
Ma si potrà ancora fare il boot da CD o chiavetta USB?
Sì, assolutamente. E in maniera molto più semplice e funzionale rispetto al BIOS legacy, visto che l'UEFI consente di realizzare anche applicazioni (chiamate applicazioni UEFI) senza avere alcun bisogno di dover caricare un intero s.o. o anche soltanto un bootloader.

Ma anche realizzare semplici s.o. è di gran lunga più semplice, visto che offre già diverse funzionalità di base.
Io quando l'ho dovuto fare, diverso tempo fa, mi ricordo che ho dovuto prima disattivare il secure boot, se non sarà più disattivabile, ci sarà un'altro modo?
Quello del secure boot è un altro discorso, che è trasversale all'UEFI.

Comunque al momento è disabilitabile, per cui il problema non si pone.

Scusate l'ignoranza, ma con i sistemi Class 3 si potranno ancora utilizzare sotto Windows i programmi a 32 bit e i vecchi videogame?

Da quello che ho letto in giro non sarà piú possibile usare os a 32 bit.

Ma usando un os a 64 bit sarà possibile immagino continuare ad usare tutto il sw e i driver a 32 bit.

Altrimenti sarebbe un autogoal.

Quello del secure boot è un altro discorso, che è trasversale all'UEFI.

Comunque al momento è disabilitabile, per cui il problema non si pone.

Ok grazie, speriamo che lo rimanga sempre.

Da quello che ho letto in giro non sarà piú possibile usare os a 32 bit.

Ma usando un os a 64 bit sarà possibile immagino continuare ad usare tutto il sw e i driver a 32 bit.

Altrimenti sarebbe un autogoal.
Non lo è, infatti: è sempre possibile tornare alla modalità a 32 bit da quella a 64 bit.

Nel caso, basterebbe un'applicazione UEFI a 64 bit che si occupi da fungere da boot loader per il s.o. a 32 bit, preparandogli l'ambiente, caricando il kernel, tornando alla modalità a 32 bit, e infine passandogli il controllo.

Alla faccia dell'inutilità dell'UEFI...
Ok grazie, speriamo che lo rimanga sempre.
Questo dipende dai produttori di schede madri, che decidono come realizzare il firmware UEFI.

Bah! la "vendono" per questioni di sicurezza, efficienza, bla, bla, bla, .... ma la sintesi e vanno a chiudere il "recinto dei buoi" dopo che ci hanno raccolti tutti.

L'80% dei computer futuri DEVONO avere lo stesso ciclo di vita similmente agli smartphone:
- obsolescenza programmata
- 2 annetti massimo di supporto ed upgrade;
... se compri un fondo di magazzino capace che sei fuori specifiche dopo pochi mesi
- poi si sarà obbligati a cambiare; esempio:
... la banca accetta operazioni solo da nuova versione di browser
... nuova versione di browser gira solo su nuova versione di rom
... nuova versione di rom gira solo da una certa release di hardware
... etc etc

Non vedo un bel futuro:muro: ..... ma me lo vendono per il "mio" bene, per la "mia" sicurezza ....:doh:

Esattamente.

Conosco bene il problema, perchè io stesso mi ostino (volutamente) a usare il mio Macbook 2008 con OS X 10.6.

Ma la cosa più comica è che queste grandi compagnie che inneggiano alla sicurezza, ci stanno bellamente prendendo per il culo.

Esempio personale:
Microsoft sostiene che Skype, essendo passato all'architettura cloud, è necessario avere la versione almeno 7.0 per funzionare.
Sull'ultima versione che posso installare, la 6.15, Microsoft mi impedisce il login perchè la mia versione è troppo vecchia.

Ebbene, mi è bastato cambiare UNA SINGOLA stringa nel file "info.plist", scrivendo "7.0" per far sì che Microsoft mi consenta l'accesso. ALLA FACCIA DELLA SICUREZZA!
Tutto ciò che controllano è una stringa. Fatto questo, tutto funziona come prima. Se fosse stata una reale questione di sicurezza o di compatibilità, non sarebbe stato così facile. RIDICOLI.

Sì, certo, come no. Il solito complottismo spicciolo internettiano...

I bug e i rootkit pre-esistevano a UEFI, ed esistono ancora a prescindere da UEFI. :mc:


Se non è obsolescenza programmata ciò che ho appena riportato, come la vuoi chiamare? Svista?
Adesso voglio vedere se inneggerete ancora ai complottisti o se finalmente vi leverete il prosciutto dagli occhi.

Esattamente.

Conosco bene il problema, perchè io stesso mi ostino (volutamente) a usare il mio Macbook 2008 con OS X 10.6.

Ma la cosa più comica è che queste grandi compagnie che inneggiano alla sicurezza, ci stanno bellamente prendendo per il culo.

Esempio personale:
Microsoft sostiene che Skype, essendo passato all'architettura cloud, è necessario avere la versione almeno 7.0 per funzionare.
Sull'ultima versione che posso installare, la 6.15, Microsoft mi impedisce il login perchè la mia versione è troppo vecchia.

Ebbene, mi è bastato cambiare UNA SINGOLA stringa nel file "info.plist", scrivendo "7.0" per far sì che Microsoft mi consenta l'accesso. ALLA FACCIA DELLA SICUREZZA!
Tutto ciò che controllano è una stringa. Fatto questo, tutto funziona come prima. Se fosse stata una reale questione di sicurezza o di compatibilità, non sarebbe stato così facile. RIDICOLI.
Finché non ti funzionerà più perché hanno tolto di mezzo le vecchie API e sostituite con le nuove.
Se non è obsolescenza programmata ciò che ho appena riportato, come la vuoi chiamare? Svista?
Si chiama aggiornamento della piattaforma. Le vecchie API al momento sono utilizzabili, ma quando il passaggio alle nuove sarà completo, non funzioneranno più.

Questo perché il mantenimento di vecchie API (codice, in generale) ha un COSTO, che verrà eliminato quando ci sarà solo il nuovo codice.
Adesso voglio vedere se inneggerete ancora ai complottisti o se finalmente vi leverete il prosciutto dagli occhi.
Più che altro dimostri di non avere idea di come si realizzi del software di una certa complessità.

Quanto all'eliminazione del vecchio BIOS e la presenza del solo UEFI, dove starebbe l'obsolescenza programmata? Il BIOS è nato nell'81, quando IBM commercializzò il suo PC: sono passati più di 36 (TRENTASEI) anni, per cui a buon ragione si può parlare di obsolescenza. Quanto sia "programmata" dopo quasi 40 anni, beh, ci sarebbe solo da ridere a sostenere una tesi del genere.

Bah! la "vendono" per questioni di sicurezza, efficienza, bla, bla, bla, .... ma la sintesi e vanno a chiudere il "recinto dei buoi" dopo che ci hanno raccolti tutti.

L'80% dei computer futuri DEVONO avere lo stesso ciclo di vita similmente agli smartphone:
- obsolescenza programmata
- 2 annetti massimo di supporto ed upgrade;
... se compri un fondo di magazzino capace che sei fuori specifiche dopo pochi mesi
- poi si sarà obbligati a cambiare; esempio:
... la banca accetta operazioni solo da nuova versione di browser
... nuova versione di browser gira solo su nuova versione di rom
... nuova versione di rom gira solo da una certa release di hardware
... etc etc

Non vedo un bel futuro:muro: ..... ma me lo vendono per il "mio" bene, per la "mia" sicurezza ....:doh:


Premesso che un telefono android dopo 2 anni smette di ricevere update di sicurezza, ma le app supportano ancora kitkat di 4 anni fa quindi presubilmente telefoni di almeno 5 anni fa:

- cosa c'entra tutto questo con un bios?

Qui si parla di incomlatibilità con hw pre uefi.

Quindi presumo pci.

Probabilmente nel 2020 non esisteranno piú mobo con slot pci in ambito consumer.

Finché non ti funzionerà più perché hanno tolto di mezzo le vecchie API e sostituite con le nuove.

Si chiama aggiornamento della piattaforma. Le vecchie API al momento sono utilizzabili, ma quando il passaggio alle nuove sarà completo, non funzioneranno più.

Questo perché il mantenimento di vecchie API (codice, in generale) ha un COSTO, che verrà eliminato quando ci sarà solo il vecchio.


Benissimo, allora perchè non mi lasci la possibilità di continuare a usare le vecchie API finchè queste sono disponibili?
Perchè è questo il punto fondamentale.

Capisco perfettamente la necessità di aggiornare le API, non poter supportare sistemi e piattaforme vecchie di decine di anni, ma perchè mi devi tagliare fuori a prescindere?

Non pretendo di certo che Microsoft mi continui a supportare OS X 10.6, so di stare usando tecnologia "vecchia" e me ne assumo i rischi. Se ho dei problemi me li tengo.
Ma se mi vogliono impedire anche questo, tra l'altro in maniera così goffa, è chiaro che il primo pensiero è che lo facciano apposta per mandare avanti il mercato. Che per carità, rientra perfettamente nel modello consumistico delle nostre civiltà occidentali.


Più che altro dimostri di non avere idea di come si realizzi del software di una certa complessità.


Mi dispiace deluderti, ma per lavoro sviluppo software di una certa complessità.
Con la differenza che sono software scientifici e non commerciali, quindi non sono addentro alle logiche del marketing.

Se qualcuno non ha capito questo, o peggio, se fa finta di non capirlo, allora ogni discorso è inutile, e tanto vale andare a "prostituirsi" intellettualmente e dichiarare "forfait", mettendosi nudi e inermi alla mercè del sistema che vuole controllare tutto e tutti, fingendo luridamente e ipocritamente di proteggerci.
Questo non è risibilmente giudicabile come "complottismo" (non aderisco ad alcuna teoria specifica), ma semplicemente come "realismo".

Allora parliamo solo un attimino dell'UEFI Class 3, magari con molte crocette.
E abbiniamo questo "piacevolissimo" progresso lungimirante e brillante, ad esempio, sempre parlando di Intel (leggasi CIA, NSA, etc.), a MiniX e a Intel ME.
Tralaltro, risulta ai più quali problemi di sicurezza, oltre che di "privacy", possono introdurre certi "sistemi" occulti di gestione da remoto dell'hardware altrui.
Solo uno sprovveduto o un furbetto può far finta, anche in questo caso, di ignorare la corrispondenza di questo accostamento tra UEFI e Intel ME ed altro connesso, che persegue fini comuni, anche se con strade diverse.

Allora, mi domando: se io smonto il disco fisso dal mio Portatile o dal Desktop Brandizzato, lo sostituisco con un disco vergine compatibile, SSD, Sata3 o come altro mi pare, posso avere il diritto di installare quello che "haz..." mi pare? Per fare ciò che più mi aggrada (nel rispetto dei diritti altrui)?
Come mi aiuta UEFI in tutte le Classi a venire in ciò?
E se desidero togliere proprio del tutto ogni disco fisso, abolendo ogni sistema operativo installato come fisso, posso avere il diritto di inserire la chiavetta USB o il DVD che più mi piace con il sistema operativo "live" che desidero? Ad esempio Linux o WindowsPE?
Posso ad esempio utilizzare liberamente Tails 3.3 o successivi, senza che il "Sistema" di potere si infastidisca? Senza che UEFI si metta a ringhiare, come bravo cane rognoso degli interessi del potere?

Allora ecco la domanda, rivolta specialmente a coloro che da queste righe pontificano con sufficienza nei riguardi di altri interlocutori, in difesa assoluta dell'UEFI Class 3 con più crocette, come sacerdoti sublimi del sapere informatico:
Quale grado di maggiore libertà garantisce questo UEFI a chi vuole usare con libertà gli strumenti informatici in hardware e software?
Si prega di spiegare con parole chiare, meglio se con citazione di articoli seri e di link esaurienti in materia ed espliciti in merito al concetto di "libertà" d'uso del mondo informatico, ovviamente entro i limiti legittimi della legge.
Legge che comunque si spera non venga scritta dagli stessi detentori del potere, che pagano sottobanco spudoratamente politici, parlamentari, ministri e capi di governo per renderli complici dei propri disegni di monopolio totale, in barba alla "democrazia".

Concludo affermando che mentre scrivevo questo intervento, la pagina del Forum si è sbiancata con errore 504 e mi ha negato ogni successivo login.
Ho dovuto utilizzare Win10PESE live su un altro PC con altro ID per pubblicare queste righe, dopo pochi minuti.

Benissimo, allora perchè non mi lasci la possibilità di continuare a usare le vecchie API finchè queste sono disponibili?
Perchè è questo il punto fondamentale.

Capisco perfettamente la necessità di aggiornare le API, non poter supportare sistemi e piattaforme vecchie di decine di anni, ma perchè mi devi tagliare fuori a prescindere?

Non pretendo di certo che Microsoft mi continui a supportare OS X 10.6, so di stare usando tecnologia "vecchia" e me ne assumo i rischi. Se ho dei problemi me li tengo.
Ma se mi vogliono impedire anche questo, tra l'altro in maniera così goffa, è chiaro che il primo pensiero è che lo facciano apposta per mandare avanti il mercato. Che per carità, rientra perfettamente nel modello consumistico delle nostre civiltà occidentali.
T'avevo già scritto perché esattamente nella parte che hai quotato, e ti ha risposto anche Antonio sull'argomento.
Mi dispiace deluderti, ma per lavoro sviluppo software di una certa complessità.
Con la differenza che sono software scientifici e non commerciali, quindi non sono addentro alle logiche del marketing.
Non c'entra niente il marketing. Qui si tratta di software completamente diversi: hai un'interfaccia che devi esporre all'esterno tramite delle API, e la devi gestire.

Non ha nulla a che vedere con un software che lanci per farti i calcoli di fluidodinamica che non sa nemmeno cosa significhi implementare delle API da far utilizzare dei client.

A meno che non sviluppi delle librerie per i tuoi progetti che poi utilizzino altri software, e allora anche lì ti poni il problema di realizzare delle API, e di come gestirle nella loro evoluzione, specialmente se a un certo punto hai accumulato tanta roba "legacy" che le API hanno bisogno di una seria ristruttuzione, e vai a finire come il qui presente caso di Skype (o altro. Vedi le API di Google, Facebook, ecc.).

ah, quindi tu pensavi che UEFI fosse ESENTE da BUG? :asd:
No, lui pensava che il BIOS fosse esente da bug, mentre UEFI "ovviamente" è una coltura realizzata da Intel per far pascolare allegramente i bug. :rotfl:

Se qualcuno non ha capito questo, o peggio, se fa finta di non capirlo, allora ogni discorso è inutile, e tanto vale andare a "prostituirsi" intellettualmente e dichiarare "forfait", mettendosi nudi e inermi alla mercè del sistema che vuole controllare tutto e tutti, fingendo luridamente e ipocritamente di proteggerci.
Questo non è risibilmente giudicabile come "complottismo" (non aderisco ad alcuna teoria specifica), ma semplicemente come "realismo".
Quando avrai DIMOSTRATO che quel sistema di cui parli funziona apposta per controllare tutto e tutti ne riparleremo. Nel frattempo rimane bollato come complottismo.
Allora parliamo solo un attimino dell'UEFI Class 3, magari con molte crocette.
E abbiniamo questo "piacevolissimo" progresso lungimirante e brillante, ad esempio, sempre parlando di Intel (leggasi CIA, NSA, etc.), a MiniX e a Intel ME.
Ma anche no: non funziona come la macedonia, dove metti tutto assieme.

UEFI non ha NULLA a che vedere con l'IME. Ma proprio nulla! Sono due cose completamente diverse e indipendenti.

Infatti puoi avere un sistema col vecchio BIOS e IME, o viceversa un sistema con UEFI e senza IME.
Tralaltro, risulta ai più quali problemi di sicurezza, oltre che di "privacy", possono introdurre certi "sistemi" occulti di gestione da remoto dell'hardware altrui.
I problemi di sicurezza ci sono a prescindere, che un sistema sia open o closed.
Solo uno sprovveduto o un furbetto può far finta, anche in questo caso, di ignorare la corrispondenza di questo accostamento tra UEFI e Intel ME ed altro connesso, che persegue fini comuni, anche se con strade diverse.
Più che altro solo uno sprovveduto può mettere assieme entrambe le cose.
Allora, mi domando: se io smonto il disco fisso dal mio Portatile o dal Desktop Brandizzato, lo sostituisco con un disco vergine compatibile, SSD, Sata3 o come altro mi pare, posso avere il diritto di installare quello che "haz..." mi pare? Per fare ciò che più mi aggrada (nel rispetto dei diritti altrui)?
Come mi aiuta UEFI in tutte le Classi a venire in ciò?
UEFI non ti può aiutare per queste cose, perché ciò che chiedi è l'interoperabilità fra le due piattaforme. Se le due piattaforme condividono un insieme di caratteristiche comuni, probabilmente lo scambio riuscirà. Se ci saranno delle incompatibilità, allora no.

L'UEFI non c'entra in tutto ciò, a meno che una piattaforma sia legacy e l'altra sia solamente UEFI, ad esempio, per cui lo scambio non funzionerà.
E se desidero togliere proprio del tutto ogni disco fisso, abolendo ogni sistema operativo installato come fisso, posso avere il diritto di inserire la chiavetta USB o il DVD che più mi piace con il sistema operativo "live" che desidero? Ad esempio Linux o WindowsPE?
Posso ad esempio utilizzare liberamente Tails 3.3 o successivi, senza che il "Sistema" di potere si infastidisca? Senza che UEFI si metta a ringhiare, come bravo cane rognoso degli interessi del potere?
Certamente: basta che Linux, Windows PE, e Tails 3.3 sia basati su UEFI.
Allora ecco la domanda, rivolta specialmente a coloro che da queste righe pontificano con sufficienza nei riguardi di altri interlocutori, in difesa assoluta dell'UEFI Class 3 con più crocette, come sacerdoti sublimi del sapere informatico:
Ma più che altro il sapere non si compra al mercato: o ce l'hai o non ce l'hai. E non c'entra nulla la religione, perché non si diventa automaticamente sacerdoti di qualcosa se uno studia l'argomento: si chiama "semplicemente" conoscenza.

Poi ci sono le capre ignoranti che pretendono di pontificare non avendo studiato, per l'appunto, e purtroppo di questo ne è pieno internet, come purtroppo sottolineò il buon Umberto Eco.
Quale grado di maggiore libertà garantisce questo UEFI a chi vuole usare con libertà gli strumenti informatici in hardware e software?
Si prega di spiegare con parole chiare, meglio se con citazione di articoli seri e di link esaurienti in materia ed espliciti in merito al concetto di "libertà" d'uso del mondo informatico, ovviamente entro i limiti legittimi della legge.
Legge che comunque si spera non venga scritta dagli stessi detentori del potere, che pagano sottobanco spudoratamente politici, parlamentari, ministri e capi di governo per renderli complici dei propri disegni di monopolio totale, in barba alla "democrazia".
La maggiore libertà di UEFI è rappresentata dalla possibilità di avere a disposizione un'infrastruttura già bella e pronta per realizzare applicazioni anche complesse SENZA dover necessariamente lanciare un s.o., oppure per realizzare s.o. senza dover implementare un mucchio di codice prima di avere finalmente il sistema a disposizione.

Ma questo l'avevo già scritto prima: bastava leggere.
Concludo affermando che mentre scrivevo questo intervento, la pagina del Forum si è sbiancata con errore 504 e mi ha negato ogni successivo login.
Ho dovuto utilizzare Win10PESE live su un altro PC con altro ID per pubblicare queste righe, dopo pochi minuti.
E' noto da ANNI che il forum verso le 4 è in manutenzione / backup, e dà questi problemi.

Deluso dal sistema UEFI per le sue dimensioni (in termini di codice), che comportano maggiori probabilità di errori, cosidetti sistemi per migliorare la sicurezza, che vengono usati come piede di porco, per impedire all'utente la possibilità di installare sistemi operativi alternativi, ecc.
Qualcuno dirà che certi approcci non erano presenti nelle specifiche come obbligatori, almeno negli standard precedenti, peccato però che nei fatti certi produttori di PC di marca impedissero possibilità di scelta e che, anche quando questa fosse presente, trattandosi di un passo in più, molti non sono a conoscenza di come ovviare al problema.

Negli anni passati, quando aspettavo la venuta dell'UEFI, non ero a conoscenza di queste problematiche.

Mi dispiace deluderti, ma per lavoro sviluppo software di una certa complessità.
Con la differenza che sono software scientifici e non commerciali, quindi non sono addentro alle logiche del marketing.

Non c'entra nulla il marketing. La questione e' il modello che scegli per il tuo software.

Io ho sviluppato (e continuo a lavorarci) una libreria che verra' presentata a Valuetools2017, che analizza dei determinati modelli "matematici". Si tratta dunque di un software scientifico.
Essendo, appunto, una libreria, ho dovuto realizzare una API per permettere la descrizione del modello da analizzare o, eventualmente, dei client. E qui sta l'inghippo. Fintanto che modifico "il motore" senza intaccare minimamente la API, un client scritto oggi potra' essere usato anche con le prossime versioni della libreria. Ma se per qualche motivo saro' costretto a toccare l'interfaccia, le cose cambieranno.
Ora, nel mio caso si tratta di una libreria che ognuno usa localmente, quindi, al massimo, si rimane con la versione vecchia. Ma se girasse sui miei server? A quel punto, l'aggiornamento dei client sarebbe necessario, a meno che io non decida di mantenere anche la vecchia versione online, ma mica puo' durare in eterno.

Come vedi, la questione e' tecnica, il marketing non c'entra niente.

Mauro però non è che ho tanto capito la quesione di come UEFi renda più facile fare OS open source cioè ci sarebbero 2 cose interessanti:


Una Console fatta in maniera decente che non richiede la modalità 16 bit protetta per essere usata (ed è pure Unicode finalmente)
GOP che sembrerebbe meglio di VESA


ma quando io faccio ExitBootServices() tutto è non più accessibile? Ciò proprio quando il mio OS prende il controllo? Possibile? Mi manca di sicuro un pezzo se non ne capisco il senso!

Anche perché temo che con la scusa le schede video rimuovano la vecchia modalità VGA testuale (relitto del passato solo x86 e Z80 l'avevano :D) e pure l'hack chiamato VESA ed a quel punto io come ci disegno nello schermo?

Mauro
Cesare! :)
però non è che ho tanto capito la quesione di come UEFi renda più facile fare OS open source cioè ci sarebbero 2 cose interessanti:


Una Console fatta in maniera decente che non richiede la modalità 16 bit protetta per essere usata (ed è pure Unicode finalmente)
GOP che sembrerebbe meglio di VESA


GOP non l'ho ancora approfondito, ma devo ancora finire di leggere il malloppo che (manco a farlo apposta :asd:) sto macinando in questo periodo ("Beyond BIOS. Developing with the Unified Extensible Firmare Interface")
ma quando io faccio ExitBootServices() tutto è non più accessibile? Ciò proprio quando il mio OS prende il controllo? Possibile? Mi manca di sicuro un pezzo se non ne capisco il senso!
Dipende tutto da come decidi di implementare il tuo s.o..

Com'è riportato nel libro in questione (pag. 80-81, sezione "Transitioning to an OS Kernel"), se chiami ExitBootServices vuol dire che hai deciso di prendere il pieno controllo del sistema, e quindi ti rimangono a disposizione soltanto gli UEFI Runtime Services (descritti nel capitolo 5, pag. 83-101), che sono veramente poca roba (ci sono una manciata di API. Utili, per carità, ma è pochissimo).

La furbata, IMO, sta nel fatto di NON chiamare ExitBootServices, e quindi continuare a usare tutte le (numerose!) API a disposizione in questo stadio, che ti permettono perfino di leggere e scrivere file coi filesystem supportati da UEFI (FAT12/16/32, ed El Torito -> supporti ottici).

Tutto ciò è comodissimo perché ti consente di evitare di implementare tutta questa roba, visto che ce l'hai già, e dedicarti esclusivamente alla progettazione & implementazione della struttura del s.o. (API & annesse strutture dati).

POI, se i servizi UEFI ti dovessero star stretti, potresti benissimo implementare quello che ti serve e chiamare ExitBootServices.
Anche perché temo che con la scusa le schede video rimuovano la vecchia modalità VGA testuale (relitto del passato solo x86 e Z80 l'avevano :D) e pure l'hack chiamato VESA ed a quel punto io come ci disegno nello schermo?
Accedendo direttamente al framebuffer della GPU. :D

A parte gli scherzi, è uno scenario plausibile che venga rimosso il vecchio BIOS, e devo ancora vedere quale rimpiazzo offre UEFI (tra l'altro sono fermo alla 2.3 e mi devo aggiornare con le nuove funzionalità della 3.0), visto che ti permette di avere console testuali e grafiche, per cui un modo per lavorare con la scheda video ce l'ha già integrato.

Deluso dal sistema UEFI per le sue dimensioni (in termini di codice), che comportano maggiori probabilità di errori, cosidetti sistemi per migliorare la sicurezza, che vengono usati come piede di porco, per impedire all'utente la possibilità di installare sistemi operativi alternativi, ecc.
Quello che scrivi è semplicemente falso. Informati.
Qualcuno dirà che certi approcci non erano presenti nelle specifiche come obbligatori, almeno negli standard precedenti,
Anche in quelli attuali.
peccato però che nei fatti certi produttori di PC di marca impedissero possibilità di scelta e che, anche quando questa fosse presente, trattandosi di un passo in più, molti non sono a conoscenza di come ovviare al problema.
E' un problema dei produttori. UEFI è uno standard che prevede un certo insieme di funzionalità. Poi ognuno ci può costruire sopra quello che vuole.
Negli anni passati, quando aspettavo la venuta dell'UEFI, non ero a conoscenza di queste problematiche.
Infatti non sono problematiche di UEFI, ma del produttori di firmware (e, in ultima analisi, del produttore di schede madri, per essere precisi, visto che è lui che decide come personalizzare il firmware base fornito da AMI, Phoenix, etc.).
Non c'entra nulla il marketing. La questione e' il modello che scegli per il tuo software.

Io ho sviluppato (e continuo a lavorarci) una libreria che verra' presentata a Valuetools2017, che analizza dei determinati modelli "matematici". Si tratta dunque di un software scientifico.
Essendo, appunto, una libreria, ho dovuto realizzare una API per permettere la descrizione del modello da analizzare o, eventualmente, dei client. E qui sta l'inghippo. Fintanto che modifico "il motore" senza intaccare minimamente la API, un client scritto oggi potra' essere usato anche con le prossime versioni della libreria. Ma se per qualche motivo saro' costretto a toccare l'interfaccia, le cose cambieranno.
Ora, nel mio caso si tratta di una libreria che ognuno usa localmente, quindi, al massimo, si rimane con la versione vecchia. Ma se girasse sui miei server? A quel punto, l'aggiornamento dei client sarebbe necessario, a meno che io non decida di mantenere anche la vecchia versione online, ma mica puo' durare in eterno.

Come vedi, la questione e' tecnica, il marketing non c'entra niente.
*

Ho visto che si è parlato di obsolescenza programmata, ma sono l'unico al quale la scheda madre del Pc funziona ancora egregiamente dopo quasi 10 anni di onorato servizio? Pensate che ha resistito ad urti, cadute del case etc...

Ho visto che si è parlato di obsolescenza programmata, ma sono l'unico al quale la scheda madre del Pc funziona ancora egregiamente dopo quasi 10 anni di onorato servizio? Pensate che ha resistito ad urti, cadute del case etc...
spesso l'obsolescenza è sw...
nel senso che non aggiornano/correggono bachi.
x gli smartphone x es è praticamente solo a livello sw che viene implementata l'obsolescenza.
UEFI mi pare un buon modo x portarla anche su PC, vista la maggior complessità e quindi la maggior probabilità che vi si riscontrino bachi (che basta non correggere x rendere obsoleto un oggetto che "elettricamente" funziona ancora benissimo.

Casomai è l'esatto contrario. Chi realizza firmware sono pochissime aziende, e i loro prodotti te li ritrovi poi in centinaia e centinaia di milioni di pezzi. Per cui si tratta di roba di gran lunga più testata e matura rispetto ai vari boot loader et similia.

Un firmware è uno dei codici più mission-critical (al pari di scheduler e filesystem), e dunque molto più oggetto di attenzioni e test rispetto ad altre tipologie di codice.

Cesare! :)


Ops!


GOP non l'ho ancora approfondito, ma devo ancora finire di leggere il malloppo che (manco a farlo apposta :asd:) sto macinando in questo periodo ("Beyond BIOS. Developing with the Unified Extensible Firmare Interface")


Se ricordo bene è la stessa cosa funziona solo prima di chiamare ExitBootServices() e quindi non puoi usarlo nel tuo OS.


Dipende tutto da come decidi di implementare il tuo s.o..

Com'è riportato nel libro in questione (pag. 80-81, sezione "Transitioning to an OS Kernel"), se chiami ExitBootServices vuol dire che hai deciso di prendere il pieno controllo del sistema, e quindi ti rimangono a disposizione soltanto gli UEFI Runtime Services (descritti nel capitolo 5, pag. 83-101), che sono veramente poca roba (ci sono una manciata di API. Utili, per carità, ma è pochissimo).

La furbata, IMO, sta nel fatto di NON chiamare ExitBootServices, e quindi continuare a usare tutte le (numerose!) API a disposizione in questo stadio, che ti permettono perfino di leggere e scrivere file coi filesystem supportati da UEFI (FAT12/16/32, ed El Torito -> supporti ottici).

Tutto ciò è comodissimo perché ti consente di evitare di implementare tutta questa roba, visto che ce l'hai già, e dedicarti esclusivamente alla progettazione & implementazione della struttura del s.o. (API & annesse strutture dati).


Si potrà fare un "misto" cioè far continuare a "girare" UEFI per avere accesso alla Console e GOP, ma per dire scriversi il tuo "driver" per leggere / scrivere dischi NTFS? O mi bloccherebbe totalmente l'accesso all'hardware sottostante?


Accedendo direttamente al framebuffer della GPU. :D


Mi chiedo appunto se sia possibile farlo con UEFI che ha il pieno controllo dell'hardware.


A parte gli scherzi, è uno scenario plausibile che venga rimosso il vecchio BIOS, e devo ancora vedere quale rimpiazzo offre UEFI (tra l'altro sono fermo alla 2.3 e mi devo aggiornare con le nuove funzionalità della 3.0), visto che ti permette di avere console testuali e grafiche, per cui un modo per lavorare con la scheda video ce l'ha già integrato.

Non riesco a trovare un documento della versione 3.0 sarebbe bello se dessero a disposizione più servizi a run-time così da fare il lavoro che il BIOS aveva promesso 30 anni fa: astrarre totalmente l'hardware!
Anche il fatto di avere i driver in UEFI sembrava una f*cata poi credo proprio perché è stato implementato male non sono mai stati usati...

Se ricordo bene è la stessa cosa funziona solo prima di chiamare ExitBootServices() e quindi non puoi usarlo nel tuo OS.
Non è un problema: non avrei intenzione di fare a meno dei boot services. Sono troppo comodi. :p
Si potrà fare un "misto" cioè far continuare a "girare" UEFI per avere accesso alla Console e GOP, ma per dire scriversi il tuo "driver" per leggere / scrivere dischi NTFS? O mi bloccherebbe totalmente l'accesso all'hardware sottostante?
Sì, è possibile. Era uno degli obiettivi di UEFI, quello di mettere a disposizione dei driver per tutti i s.o..
Mi chiedo appunto se sia possibile farlo con UEFI che ha il pieno controllo dell'hardware.
L'UEFI rimane pur sempre al servizio dell'applicazione UEFI, per cui dovrebbe essere possibile.

Il mio problema è che al momento non ho avuto modo di sperimentare, e quindi sporcarmi e toccare con mano come funziona concretamente il tutto, anche se il desiderio è enorme.
Non riesco a trovare un documento della versione 3.0 sarebbe bello se dessero a disposizione più servizi a run-time così da fare il lavoro che il BIOS aveva promesso 30 anni fa: astrarre totalmente l'hardware!
Esattamente.
Anche il fatto di avere i driver in UEFI sembrava una f*cata poi credo proprio perché è stato implementato male non sono mai stati usati...
Come dicevo prima, non ho ancora sperimentato per capire quali sarebbero le problematiche che sono scaturite coi driver UEFI.

Io purtroppo ho capito così: se UEFI controlla l'hardware tu non puoi scrivere un driver nella maniera "classica" cioè accedendo alle I/O port ecc... forse è possibile farlo alla UEFI, ma se hai realizzato ormai un OS da più di 10 anni (il caso di Cosmos) con la vecchia filosofia e vuoi comunque mantenere la compatibilità con hardware no UEFI non puoi / vuoi farlo.

Riguardo la Console sembra sia possibile accederci anche anche dopo ExitBootServices() usando le "Global Variables" ce ne sono 3 che sono i classici stdin, stderr e stdout quindi quello si dovrebbe poter fare non so se puoi fare cose "fiche" con quegli handle come cambiare il colore di sfondo, "giocare" con il cursore, ecc... cose che la classe Console di C# mi richiederebbe in ogni caso :p
Purtroppo non dicono molto su come vanno usati questi path quindi boh?

Anche per GOP sembra sia possibile avere almeno l'accesso al LFB, ma anche in questo caso non ho capito come...

Ma perché GOP lo hanno limitato ai BootServices? Io non la capisco sta limitazione i complottisti dicono che l'hanno fatto apposta per favorire Windows (che ha i driver nativi), ma io a sta cosa meschina non ci credo...
Cosa ne pensi?

Io purtroppo ho capito così: se UEFI controlla l'hardware tu non puoi scrivere un driver nella maniera "classica" cioè accedendo alle I/O port ecc... forse è possibile farlo alla UEFI, ma se hai realizzato ormai un OS da più di 10 anni (il caso di Cosmos) con la vecchia filosofia e vuoi comunque mantenere la compatibilità con hardware no UEFI non puoi / vuoi farlo.
Su questo devo approfondire, ma comunque, se ci pensi bene, un eventuale limite del genera avrebbe senso, visto che lo scopo di UEFI è fare le veci del vecchio BIOS, provvedendo però a mettere sul piatto parecchi comodi strumenti per inizializzare l'ambiente e caricare il kernel (o il boot loader; che però IMO non serve più con l'UEFI: al massimo lo installa una sola volta come applicazione UEFI).
Riguardo la Console sembra sia possibile accederci anche anche dopo ExitBootServices() usando le "Global Variables" ce ne sono 3 che sono i classici stdin, stderr e stdout quindi quello si dovrebbe poter fare non so se puoi fare cose "fiche" con quegli handle come cambiare il colore di sfondo, "giocare" con il cursore, ecc... cose che la classe Console di C# mi richiederebbe in ogni caso :p
Purtroppo non dicono molto su come vanno usati questi path quindi boh?
No, i servizi console non sono disponibili dopo ExitBootServices(): non sono elencati nei runtime services.
Anche per GOP sembra sia possibile avere almeno l'accesso al LFB, ma anche in questo caso non ho capito come...
Sì, mi sono documentato e confermo che è possibile accedere al LFB.
Ma perché GOP lo hanno limitato ai BootServices? Io non la capisco sta limitazione i complottisti dicono che l'hanno fatto apposta per favorire Windows (che ha i driver nativi), ma io a sta cosa meschina non ci credo...
Cosa ne pensi?
No, assolutamente. Il motivo è semplice: GOP è l'equivalente dei servizi VGA/VESA, ed è nato per sostituirli. Ma questo esclusivamente in funzione di lanciare il s.o..

UEFI non nasce per scrivere s.o., ma per facilitarne l'inizializzazione e l'avvio. Purtroppo. Anche se a me piacerebbe che lo arricchissero, visto che alla fine tanti s.o. devono reinventarsi sempre la ruota per fare esattamente le stesse cose.