Link alla notizia: http://www.hwupgrade.it/news/sicurezza-software/linux-scoperto-bug-critico-in-attivita-da-9-anni_65271.html

Un bug che consente l'escalation dei privilegi è stato scoperto di recente su Linux, ma sarebbe in attività da ben nove anni. La patch ufficiale è già stata rilasciata

Click sul link per visualizzare la notizia.

Purtroppo il problema è che il quality-testing è calato terribilmente nel mondo opensource, per via della crisi economica :cry:

Purtroppo il problema è che il quality-testing è calato terribilmente nel mondo opensource, per via della crisi economica :cry:

:sofico:

Il problema non credo sia la crisi economica, ma che Linux e qualità sono proprio due cose avulse :D

Il problema non credo sia la crisi economica, ma che Linux e qualità sono proprio due cose avulse :D

Dieci anni fa non era così. Le prime Ubuntu erano competitive con XP.

Poi la crisi economica. I miglioramenti di Windows.
E un kernel BLOATED, come ammesso dallo stesso Torvalds.

Escalation dei privilegi da locale, mica da remoto, come giustamente scritto nel testo dell'articolo....

https://access.redhat.com/security/cve/cve-2016-5195

Ma meglio soffermarsi al titolone bomba...

L'avra infilato Microsoft !!!!! :asd:

scoprono un bug e "Purtroppo il problema è che il quality-testing è calato terribilmente nel mondo opensource, per via della crisi economica".
Sono curioso sul quanto sia inteso tuo rapporto con il mondo opensource per sparare ste svirgolate anche sui thread linux.

Sono curioso sul quanto sia inteso tuo rapporto con il mondo opensource per sparare ste svirgolate anche sui thread linux.

Cioè vuoi il mio curriculum? :sofico:

Mah, io francamente trovo curiose tutte queste lamentele sulla presunta riduzione qualitativa del software opensource.

Anzitutto dietro a questa etichetta c'è tutto e il contrario di tutto, quindi dire una cosa del genere è un po' come fare di tutta l'erba un fascio, in secondo luogo a me pare invece esattamente l'opposto.
Mai come in questi anni si sta assistendo a una migliore organizzazione del lavoro nel mondo open, il che va di pari passo con l'importanza e la criticità che tanti progetti open stanno assumendo nel mondo dell'IT; pensiamo a progetti supercritici come i vari orchestrator (Ansigle, Puppet, Chef, giusto per citare i principali), intere suite IaaS (es OpenStack) ma anche ai tanti progetti storici su cui si basa l'ossatura stessa delle architetture applicative da quasi vent'anni (pensiamo ai millemila progetti dell'Apache software foundation, HTTPD e Tomcat in primis).

Suggerisco (ma non auguro) a coloro che affermano il contrario di farsi un giro su qualche progetto basato sui blasonati polpettoni proprietari su cui purtroppo le aziende spesso decidono di buttare palate di soldi (scegliete voi, IBM, Oracle, SAP, Microsoft), tra requisiti fantasmagorici rispetto alle performance, ticket interminabili, workaround imbarazzanti, fatures indietro di almeno 10 anni rispetto alle controparti non commerciali... e auguri. :doh:

Il problema non credo sia la crisi economica, ma che Linux e qualità sono proprio due cose avulse :DScusa e su quali basi affermi tutto questo?
Stiamo parlando di cose serie (es instabilità del kernel, problemi su I/O, gestione risorse) o di quisquilie (tipo "ho installato l'ultima Ubuntu e Amule non parte")?

Stiamo parlando di un kernel che basta uno sbordamento ben cucinato e ti fa passare da utente normale a utente root con potere assoluto sulla macchina a me pare una cosa molto, molto seria ed anche abbastanza indifendibile :D

Ma del resto Linus Torvalds una volta se lo fece scappare che lui delle vulnerabilità di sicurezza se ne sbatte la fava quindi...

http://article.gmane.org/gmane.linux.kernel/706950

"scimmie masturbanti" ma va là :D

Se poi contiamo che su sistemi mission critical te lo scordi di aggiornare il kernel (noi abbiamo 50 sistemi in produzione con CentOs 5.4 e chissà quale versione di kernel? Boh 2.6 qualcosa?) che fai le aggiorni e ricompili tutti gli applicativi? E sì perché se speri che il nuovo kernel col bug fixato di 9 anni faccia girare gli applicativi senza ricompilare o crash random vivi nel mondo delle fiabe :Prrr:
Per sistemi tremendamente importanti ci si riduce al "back porting" che tristezza :p

Ok prendo i popcorn. Linux ha un problema, mi aspetto non meno di 200 messaggi e altrettanti paladini che si ergeranno in difesa del suddetto affermando quanto questo sia sempre e comunque migliore di qualsiasi cosa inventata nell'universo fino all'uscita del prossimo aggiornamento e altrettanti troll che non vedranno l'ora di tirarli scemi :sofico:

il più grande caso di privilege escalation locale su Linux di sempre.

ogni riferimento ad un frutto di stagione è puramente casuale. Giusto per difendere XNU.

Ok prendo i popcorn. Linux ha un problema, mi aspetto non meno di 200 messaggi e altrettanti paladini che si ergeranno in difesa del suddetto affermando quanto questo sia sempre e comunque migliore di qualsiasi cosa inventata nell'universo fino all'uscita del prossimo aggiornamento e altrettanti troll che non vedranno l'ora di tirarli scemi :sofico:

I paladini sono tutti impegnati nella preparazione del
*** LINUX DAY ***
http://www.linuxday.it/
di domani :)

Chissà se racconteranno di tutto questo!

Stiamo parlando di un kernel che basta uno sbordamento ben cucinato e ti fa passare da utente normale a utente root con potere assoluto sulla macchina a me pare una cosa molto, molto seria ed anche abbastanza indifendibile :D

Ah! In altre parole come l' "esegui come amministratore" di Windows ? :Prrr:
Notare che il bug esiste da 9 anni, ma che l'exploit in uso non è molto diffuso perche gli si deve abbinare minimo un altro exploit per entrare dentro da remoto.
Anche dopo questo io mi sento più sicuro con una distribuzione Linux che con Windows o altri SO più "opachi".

Stiamo parlando di un kernel che basta uno sbordamento ben cucinato e ti fa passare da utente normale a utente root con potere assoluto sulla macchina a me pare una cosa molto, molto seria ed anche abbastanza indifendibile :D

Ma del resto Linus Torvalds una volta se lo fece scappare che lui delle vulnerabilità di sicurezza se ne sbatte la fava quindi...

http://article.gmane.org/gmane.linux.kernel/706950

"scimmie masturbanti" ma va là :D

Se poi contiamo che su sistemi mission critical te lo scordi di aggiornare il kernel (noi abbiamo 50 sistemi in produzione con CentOs 5.4 e chissà quale versione di kernel? Boh 2.6 qualcosa?) che fai le aggiorni e ricompili tutti gli applicativi? E sì perché se speri che il nuovo kernel col bug fixato di 9 anni faccia girare gli applicativi senza ricompilare o crash random vivi nel mondo delle fiabe :Prrr:
Per sistemi tremendamente importanti ci si riduce al "back porting" che tristezza :p

Veramente non serve ricompilare un applicativo se aggiorni il kernel a meno che tu non abbia un kernel arcaico (tipo 2.4) di 20 anni fa'...
Il back porting è pratica usuale quando vuoi avere una patch fatta per un nuovo software su una vecchia versione. Non esiste solo su Linux, ovviamente, ma lo si fa su qualsiasi software.

Poi uno può spalare cacca quanto gli pare, fatto sta che Linux è ovunque e forse forse non è tutto sto colabrodo come viene dipinto in questo thread

Quanti milioni di righe di codice ci sono nel kernel Linux attuale?
E in Windows?

Sento parlare qui di riduzione della qualità su Linux, quando in realtà a me è sembrato Windows 10 un po' una distribuzione Linux quando l'ho installato per la prima volta alcuni mesi fa, per via del numero di imprecisioni, perdite di funzionalità, errori di digitazione, mancanze di help in linea, bug, e vari difetti che ho riscontrato... Solo alcune di queste cose sono state corrette ultimamente. Fra i vari bug, la calcolatrice che mi interpreta il segno meno come divisione (tipo fosse attiva la tastiera inglese), è il mio preferito. :D

Non mi soprende....
Linux è scritto da esseri umani.... gli umani sbagliano!

L'importante è che questi problemi vengano trovati e corretti!

Il problema non credo sia la crisi economica, ma che Linux e qualità sono proprio due cose avulse :D

A giudicare dalla firma, il commento e' certamente imparziale :asd:

Dieci anni fa non era così. Le prime Ubuntu erano competitive con XP.

Poi la crisi economica. I miglioramenti di Windows.
E un kernel BLOATED, come ammesso dallo stesso Torvalds.

mah! secondo me l'unico linux che poteva competere con xp era RED HAT. il problema e' che il sistema operativo deve essere considerato anche dal fattore software e ubuntu e varie erano anni dietro. il sistema si e' evoluto, e' finita l'era del cubo rotante col doppio maglio perforante. la gente vuole facilita' e funzionalita', nel mondo linux c'e' solo caos.

Se poi contiamo che su sistemi mission critical te lo scordi di aggiornare il kernel (noi abbiamo 50 sistemi in produzione con CentOs 5.4 e chissà quale versione di kernel? Boh 2.6 qualcosa?) che fai le aggiorni e ricompili tutti gli applicativi? E sì perché se speri che il nuovo kernel col bug fixato di 9 anni faccia girare gli applicativi senza ricompilare o crash random vivi nel mondo delle fiabe :Prrr:
Per sistemi tremendamente importanti ci si riduce al "back porting" che tristezza :p

Ma quali applicativi devi ricompilare?
Conosce veramente poco come funziona Linux e cosa sia un kernel, mi pare di capire delle sue affermazioni.

Il software per antonomasia ha dei bug, nell'open source quando questi bug vengono scoperti vengono fixati quasi immediatamente. Windows ha bug di cui si e' a conoscenza da anni e non sono stati ancora fixati.

Si informi.
Saluti.

mah! secondo me l'unico linux che poteva competere con xp era RED HAT. il problema e' che il sistema operativo deve essere considerato anche dal fattore software e ubuntu e varie erano anni dietro. il sistema si e' evoluto, e' finita l'era del cubo rotante col doppio maglio perforante. la gente vuole facilita' e funzionalita', nel mondo linux c'e' solo caos.

...che nel mondo linux ci sia solo caos, è un tuo punto di vista che è esattamente opposto al mio...
...al seguente link, potrai trovare distribuzioni che funzionano benissimo:

http://distrowatch.com/

...

il migliore e' quello che ricompila gli applicativi, vince lui :)

seriamente, e' un bug che funziona da locale, da solo da remoto non fa niente... Ora, se qualcuno ha accesso a un sistema in locale ho gia' un problema molto serio, non sto a preoccuparmi del bug.

https://github.com/hfiref0x/UACME

:rotfl:

Ma quali applicativi devi ricompilare?
Conosce veramente poco come funziona Linux e cosa sia un kernel, mi pare di capire delle sue affermazioni.
Se cambiano le API e/o le ABI, il codice già compilato non funziona.

E non sono casi rari, perché è il problema principale che affligge l'aggiornamento (modding) dei telefonini Android, dove il produttore ha rilasciato driver closed che smettono di funzionare passando a un nuovo kernel.
Il software per antonomasia ha dei bug, nell'open source quando questi bug vengono scoperti vengono fixati quasi immediatamente. Windows ha bug di cui si e' a conoscenza da anni e non sono stati ancora fixati.

Si informi.
Saluti.
S'informi lei: anche in ambito open source ci sono bug che rimangono a vegetare per ANNI. Se poi si ha anche la sfortuna di avere a che fare con mantainer permalosi (come quello di libc), ci si becca pure degli insulti...

Comunque spero che dopo questa notizia gli affezionati alla famigerata "Legge di Linus" (che legge non è) si mettano l'anima in pace.

Se cambiano le API e/o le ABI, il codice già compilato non funziona.

E non sono casi rari, perché è il problema principale che affligge l'aggiornamento (modding) dei telefonini Android, dove il produttore ha rilasciato driver closed che smettono di funzionare passando a un nuovo kernel.

S'informi lei: anche in ambito open source ci sono bug che rimangono a vegetare per ANNI. Se poi si ha anche la sfortuna di avere a che fare con mantainer permalosi (come quello di libc), ci si becca pure degli insulti...

Comunque spero che dopo questa notizia gli affezionati alla famigerata "Legge di Linus" (che legge non è) si mettano l'anima in pace.

Esiste pure una "Legge di Linus"? :D

Purtroppo sì (https://it.wikipedia.org/wiki/Legge_di_Linus)

Ma del resto Linus Torvalds una volta se lo fece scappare che lui delle vulnerabilità di sicurezza se ne sbatte la fava quindi...

http://article.gmane.org/gmane.linux.kernel/706950

"scimmie masturbanti" ma va là :D

...vabbe` pero` mentire sul contenuto degli stessi link che posti mi sembra imbarazzante; nel post c'e` scritto tutt'altro. C'e` scritto che chi si occupa delle issue di sicurezza non va considerato piu` importante di chi si occupa di tutte le altre issues e che tutti i bug hanno la stessa dignita`.

To me, security is important. But it's no less important than everything *else* that is also important!

Linus

https://github.com/hfiref0x/UACME

:rotfl:

Sembra che si stiano dando da fare per risolverli in win10 almeno :p

Microsoft countermeasures

Methods fixed:

1 - Windows 8.1 release and above, still work on Windows 7;
2 - Windows 10 starting from earlier preview builds;
3 - Windows 10 TH2 starting from 1055X builds;
4 - Windows 10 starting from first preview builds, earlier OS versions got KB3045645/KB3048097 fix;
5 - Windows 10 starting from 10147 build;
6 - Windows 10 starting from 10147 build;
7 - Windows 10 starting from 10147 build;
8 - Windows 8.1 release and above, still work on Windows 7;
9 - Windows 10 starting from 10147 build;
10 - Windows 10 TH2 starting from build 10548;
11 - Windows 10 starting from first preview builds, earlier OS versions got KB3045645/KB3048097 fix;
12 - Windows 10 TH2 starting from 10565 build;
13 - Windows 10 RS1 starting from public 14316 build;
14 - Windows 10 TH2 starting from 10548 build;
15 - Windows 10 RS1 starting from public 14316 build;
16 - Windows 10 RS1 starting from public 14316 build;
17 - Windows 10 RS1 starting from public 14371 build;
18 - Windows 10 RS1 starting from public 14371 build;
19 - Windows 10 RS1 starting from public 14376 build.
** 20, 21, 22, 23 are not fixed as at 12 October 2016.

il problema è tutta la roba che gira su linux e che non è possibile aggiornare facilmente secondo me :(

Se cambiano le API e/o le ABI, il codice già compilato non funziona.

E non sono casi rari, perché è il problema principale che affligge l'aggiornamento (modding) dei telefonini Android, dove il produttore ha rilasciato driver closed che smettono di funzionare passando a un nuovo kernel.

S'informi lei: anche in ambito open source ci sono bug che rimangono a vegetare per ANNI. Se poi si ha anche la sfortuna di avere a che fare con mantainer permalosi (come quello di libc), ci si becca pure degli insulti...

Comunque spero che dopo questa notizia gli affezionati alla famigerata "Legge di Linus" (che legge non è) si mettano l'anima in pace.

Tutto vero, senza dimenticarci però che ci sono hack che scardinano la password di amministratore di windows funzionanti da xp (ed ancora validi), hack che innalzano un account user locale ad amministratore da vista fino ad anniversary.
Nessun sistema è immune a ciò, mi sono anche meravigliato di come sia facile fare il reset della password di OSX in solo 2 minuti avendo accesso alla macchina senza nessun hack o software esterno.
Quindi ?

Quindi è ovvio che qualunque s.o. abbia bug.

Comunque forse dovremmo ritornare ad un piccolissimo dettaglio: 9 anni.

E meno male che il codice è lì ben visibile.

E' quello il punto che volevo sottolineare prima. Milioni di occhi... chiusi. :D

Adesso però mi avete fatto venire il dubbio.

Gestisco 2 server con ubuntu server 14.04, kernel 3.13.

Mi basta fare apt-get upgrade o devo ricompilare?

E' quello il punto che volevo sottolineare prima. Milioni di occhi... chiusi. :D
Questa è una battuta molto poco felice però:
quelle stesse righe di codice sono state vista sia dai programmatori MS, sia da quelli Intel, sia a quelli IBM.
L'unica soluzione a questo problema è: se tutti i programmatori delle maggiori compagnie IT non hanno vista prima il bug, figuriamoci quanti ce ne sono da decenni sui software closed scritti da una sola parte di essi.
Non credi?

...che nel mondo linux ci sia solo caos, è un tuo punto di vista che è esattamente opposto al mio...
...al seguente link, potrai trovare distribuzioni che funzionano benissimo:

http://distrowatch.com/

...

sai qual'e' il problema??? che quelli che ragionano come te non calcolano il fattore newbie, la gente vuole fare tutto e subito e sappiamo bene che questo con linux non esiste. la gente sente dire che per aprire i pacchetti RAR ci vuole winrar e su linux non lo trovano perche' ha un altro nome, e non hanno nessuna intenzione di imparare ( questo giusto per dirne una delle tante ). ma poi l'ho visto e pagato a mie spese, linux e' un casino anche se sto pensando a un ritorno.

Com'è possibile che ci siano 10000 distribuzioni linux quanto l'uso dello stesso è limitato all'1-2% (più o meno non ricordo) ?

Quante distribuzioni sono effettivamente seguite con aggiornamenti/supporto?
il 10% ?

Non è che il problema è anche l'eccessiva frammentazione?

Com'è possibile che ci siano 10000 distribuzioni linux quanto l'uso dello stesso è limitato all'1-2% (più o meno non ricordo) ?

Quante distribuzioni sono effettivamente seguite con aggiornamenti/supporto?
il 10% ?

Non è che il problema è anche l'eccessiva frammentazione?

che la frammentazione sia uno dei punti dolenti di linux non si discute. ma i problemi veri stanno da altra parte.

Com'è possibile che ci siano 10000 distribuzioni linux quanto l'uso dello stesso è limitato all'1-2% (più o meno non ricordo) ?

Quante distribuzioni sono effettivamente seguite con aggiornamenti/supporto?
il 10% ?

Non è che il problema è anche l'eccessiva frammentazione?

No, la maggior parte delle distribuzioni, soprattutto quelle più piccole, altro non sono che il rebrand delle maggiori distribuzioni esistenti e con una differente selezione di pacchetti preinstallata + eventuale DE personalizzato, e, di conseguenza, sfruttano i repository delle distribuzioni su cui sono basate... e sempre di conseguenza ricevono dunque gli aggiornamenti

sai qual'e' il problema??? che quelli che ragionano come te non calcolano il fattore newbie, la gente vuole fare tutto e subito e sappiamo bene che questo con linux non esiste. la gente sente dire che per aprire i pacchetti RAR ci vuole winrar e su linux non lo trovano perche' ha un altro nome, e non hanno nessuna intenzione di imparare ( questo giusto per dirne una delle tante ). ma poi l'ho visto e pagato a mie spese, linux e' un casino anche se sto pensando a un ritorno.

Linux Mint! Una volta installata non ha bisogno di nient'altro per un utente medio.:-)
La prova del nove è mio padre che sta utilizzando Ming da un paio di mesi senza problemi.

Ho solo dovuto installare Skype ,che comunque è nei repository e un programma a cui teneva particolarmente che ho fatto girare sotto wine.

...vabbe` pero` mentire sul contenuto degli stessi link che posti mi sembra imbarazzante; nel post c'e` scritto tutt'altro. C'e` scritto che chi si occupa delle issue di sicurezza non va considerato piu` importante di chi si occupa di tutte le altre issues e che tutti i bug hanno la stessa dignita`.

A dire la verità lui "refuses to bother with the whole security circus".

Ora, che MS abbia sempre avuto una sottovalutazione dell'aspetto sicurezza è noto (ricordo ancora con raccapriccio le dichiarazioni da Vispa Teresa al tempo della presentazione delle ActiveX) e che ci abbiano messo troppo tempo per capirlo e rimediare è pure vero.
Ma le ActiveX erano del 1996, quando "sicurezza informatica" era una cosa da pochi strambi fissati, e MS ha cominciato con Vista a mettere delle belle pezze di sicurezza nel 2007, ma lo sviluppavano dal 2001.

Qui Torvalds parla di "circo della sicurezza", con netto tono spregiativo ed evidente sottovalutazione, nel 2008!
Ed allora era già chiaro a tutti cosa fosse la sicurezza informatica e perchè fosse importante.
E' piuttosto evidente che riteneva le critiche alla sicurezza più un fastidio che una cosa di primaria importanza.
Direi che è oggettivamente una toppata non da poco, e lo era anche otto anni fa, nonostante il tentativo finale di mitigare la sua posizione.

mah! secondo me l'unico linux che poteva competere con xp era RED HAT. il problema e' che il sistema operativo deve essere considerato anche dal fattore software e ubuntu e varie erano anni dietro. il sistema si e' evoluto, e' finita l'era del cubo rotante col doppio maglio perforante. la gente vuole facilita' e funzionalita', nel mondo linux c'e' solo caos.

Questo è un problema, serissimo (e concordo che l'unico Linux che potrei consigliare per l'uso casalingo è Red Hat o, almeno per gli utenti evoluti, il suo clone non supportato CentOS).
L'altro ormai chiaro problema è che l'unico vantaggio di Linux è rimasto la gratuità, importante fin che si vuole ma chi ha voglia di "risparmiare" 150 euro di licenza Windows per infilarsi in ... Linux? E non sto a rimarcarne tutti i difetti perchè non voglio suscitare flame.

Adesso ormai è pure chiaro che, purtroppo, nei fatti l'open source non garantisce neppure da bug di sicurezza gravi e incancreniti.
A differenza di quanto mi diceva, convinto, un collega dieci anni fa ("Ma c'è davvero gente che va a controllare il codice open?", "Ma certo che c'è, scherzi?"), stiamo scoprendo un'altro svantaggio dell'affidare lo sviluppo ed il controllo da una "community" nei fatti "irresponsabile" sul software distribuito e largamente basata sul volontariato (si, certo, c'è Red Hat, IBM, Intel ecc., sarei curioso di sapere per esempio quanto IBM lo fa convintamente e a beneficio della "community" e quanto per mantenere "un piede dentro", metti che ...).

A dire la verità lui "refuses to bother with the whole security circus".

Ora, che MS abbia sempre avuto una sottovalutazione dell'aspetto sicurezza è noto (ricordo ancora con raccapriccio le dichiarazioni da Vispa Teresa al tempo della presentazione delle ActiveX) e che ci abbiano messo troppo tempo per capirlo e rimediare è pure vero.
Ma le ActiveX erano del 1996, quando "sicurezza informatica" era una cosa da pochi strambi fissati, e MS ha cominciato con Vista a mettere delle belle pezze di sicurezza nel 2007, ma lo sviluppavano dal 2001.

Qui Torvalds parla di "circo della sicurezza", con netto tono spregiativo ed evidente sottovalutazione, nel 2008!
Ed allora era già chiaro a tutti cosa fosse la sicurezza informatica e perchè fosse importante.
E' piuttosto evidente che riteneva le critiche alla sicurezza più un fastidio che una cosa di primaria importanza.
Direi che è oggettivamente una toppata non da poco, e lo era anche otto anni fa, nonostante il tentativo finale di mitigare la sua posizione.

Leggete la sua biografia. Lo sviluppo di Linux è iniziato "per caso", e comunque sempre perché si divertiva a smanettare col codice a basso livello, cercando di utilizzare meglio le risorse. Tutta la questione sicurezza è venuta fuori solo quando hanno introdotto il supporto alle reti (mica l'ha fatto da solo eh).

Il resto è un tentativo di implementazione dello standard POSIX, laddove possibile. Ma il punto è che 'sto kernel non è mai nato "da kernel". Non è che lui una mattina si è svegliato e ha deciso di scriverne uno. Stava semplicemente giocando con MINIX e sviluppando un emulatore di terminale. Sono tutte cose che trovate scritte, nero su bianco.

A dire la verità lui "refuses to bother with the whole security circus".

Ora, che MS abbia sempre avuto una sottovalutazione dell'aspetto sicurezza è noto (ricordo ancora con raccapriccio le dichiarazioni da Vispa Teresa al tempo della presentazione delle ActiveX) e che ci abbiano messo troppo tempo per capirlo e rimediare è pure vero.
Ma le ActiveX erano del 1996, quando "sicurezza informatica" era una cosa da pochi strambi fissati, e MS ha cominciato con Vista a mettere delle belle pezze di sicurezza nel 2007, ma lo sviluppavano dal 2001.

Qui Torvalds parla di "circo della sicurezza", con netto tono spregiativo ed evidente sottovalutazione, nel 2008!
Ed allora era già chiaro a tutti cosa fosse la sicurezza informatica e perchè fosse importante.
E' piuttosto evidente che riteneva le critiche alla sicurezza più un fastidio che una cosa di primaria importanza.
Direi che è oggettivamente una toppata non da poco, e lo era anche otto anni fa, nonostante il tentativo finale di mitigare la sua posizione.

Il contesto, se non lo capisci finisci con lo sputtanarti. :rolleyes:

Nello specifico se si considera la breve frase che citi NEL CONTESTO DEL POST COMPLETO di Torvalds :read: si comprende ( SE si ha una comprensione accettabile dell'inglese scritto)
che "security circus" non era riferito alla sicurezza del SO, ma a quelli che per varie ragioni si focalizzano eccessivamente sulla sicurezza, trascurando altri aspetti altrettanto importanti ( tipo la stabilità del sistema, non a caso cita come esempio di bug "altrettanto importanti" quelli che causano crash del sistema).

In poche parole "security CIRCUS" non significa "sicurezza del sistema operativo"
e NEL CONTESTO del messaggio a cui ti riferivi la cosa era estremamente chiara:
Btw, and you may not like this, since you are so focused on security, one
reason I refuse to bother with the whole security circus is that I think
it glorifies - and thus encourages - the wrong behavior.

It makes "heroes" out of security people, as if the people who don't just
fix normal bugs aren't as important.

In fact, all the boring normal bugs are _way_ more important, just because
there's a lot more of them. I don't think some spectacular security hole
should be glorified or cared about as being any more "special" than a
random spectacular crash due to bad locking.

Security people are often the black-and-white kind of people that I can't
stand. I think the OpenBSD crowd is a bunch of masturbating monkeys, in
that they make such a big deal about concentrating on security to the
point where they pretty much admit that nothing else matters to them.

To me, security is important. But it's no less important than everything
*else* that is also important!

Linus

CentOS per uso domestico....
Se vuoi trollare almeno cerca di essere credibile...

Originariamente inviato da ronin789
...che nel mondo linux ci sia solo caos, è un tuo punto di vista che è esattamente opposto al mio...
...al seguente link, potrai trovare distribuzioni che funzionano benissimo:

http://distrowatch.com/

...

sai qual'e' il problema??? che quelli che ragionano come te non calcolano il fattore newbie, la gente vuole fare tutto e subito e sappiamo bene che questo con linux non esiste. la gente sente dire che per aprire i pacchetti RAR ci vuole winrar e su linux non lo trovano perche' ha un altro nome, e non hanno nessuna intenzione di imparare ( questo giusto per dirne una delle tante ). ma poi l'ho visto e pagato a mie spese, linux e' un casino anche se sto pensando a un ritorno.

...
fai come faccio io... te lo installi linux in dual boot con win 10 e, a seconda dello umore, avvii o linux o win 10
...

CentOS per uso domestico....
Se vuoi trollare almeno cerca di essere credibile...

Stai riferendoti a me? Noi CentOS lo installiamo sui nostri server e sui sistemi che distribuiamo... poi per me in azienda con Linux son troppo fissati e ci costringono ad usare una CentOS anche sui nostri desktop almeno fosse un Ubuntu :cry:
(Windows con Visual Studio ce l'hanno solo alcuni privilegiati in azienda :D).

Comunque:


Se cambia il kernel è molto probabile che anche la vecchia libc non funzioni più ergo DEVI ricompilare oh se devi ricompilare tutto! E se come nel nostro caso hai driver proprietari che ci siamo scritti noi?
... quindi molti sistemi restano con kernel vecchi ed insicuri per sempre!
Linus Torvalds stesso dichiara che "i bug di sicurezza NON sono più importanti degli altri"
Usando linguaggi come C/C++ NON ci sono sistemi operativi sicuri (sì anche Windows e MacOS avranno sempre bug se basta uno "sbordamento" per scalare i privilegi e accedere alla memoria del kernel)


P.S. A chi diceva "si informi": io su Linux in C su sistemi embedded real time ci lavoro da 15 anni quindi dire che non so come funziona è un po' un'esagerazione... vorrei non saperlo, ma purtroppo lo so :Prrr:

Il contesto, se non lo capisci finisci con lo sputtanarti. :rolleyes:

Nello specifico se si considera la breve frase che citi NEL CONTESTO DEL POST COMPLETO di Torvalds :read: si comprende ( SE si ha una comprensione accettabile dell'inglese scritto)
che "security circus" non era riferito alla sicurezza del SO, ma a quelli che per varie ragioni si focalizzano eccessivamente sulla sicurezza, trascurando altri aspetti altrettanto importanti ( tipo la stabilità del sistema, non a caso cita come esempio di bug "altrettanto importanti" quelli che causano crash del sistema).

In poche parole "security CIRCUS" non significa "sicurezza del sistema operativo"
e NEL CONTESTO del messaggio a cui ti riferivi la cosa era estremamente chiara:

Guarda che "il contesto" l'avevo compreso perfettamente ed è inutile che ricopi tutto il messaggio, che avevo letto interamente.
E ribadisco che uno che, con evidente fastidio, dice che "ci sono cose altrettanto importanti" è uno a cui della sicurezza gliene importa una beata fava.
Nel 2008.

In pratica, Linux è stato fatto da uno smanettone, per hobby ("I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones"), e tale è rimasta la mentalità della "comunità Linux".
Il che spiega una marea di cose.

CentOS per uso domestico....
Se vuoi trollare almeno cerca di essere credibile...

Certo che rispondere facendo finta di non aver visto la frase "almeno per gli utenti evoluti" non fa fare bella figura. Sappilo.

CentOS è un sistema robusto, esiste anche in installazione desktop, si basa sull'unica distribution contemporaneamente diffusa e veramente professionale ed ha una interfaccia semplice da usare e non troppo diversa da quella di Windows (o di qualsiasi GUI decente), che nonostante sia uno standard non tutte le distribuzioni hanno per default.

Se poi uno vuole soffrire ulteriormente ed usare Unity, perchè Ubuntu è il Linux "per uso desktop/domestico", faccia pure. Cavoli suoi. Ma certo non lo consiglierei a nessuno, come non consiglierei per esempio Arch o SUSE. Al massimo, Mint.

Ma, al super-massimo, gli direi: lascia perdere, lascia perdere pure CentOS, spendi 150 euro per Windows e vivi tranquillo con un prodotto professionale fatto apposta per te e non per gli smanettoni.

Guarda che "il contesto" l'avevo compreso perfettamente ed è inutile che ricopi tutto il messaggio, che avevo letto interamente.
E ribadisco che uno che, con evidente fastidio, dice che "ci sono cose altrettanto importanti" è uno a cui della sicurezza gliene importa una beata fava.
Nel 2008.


Ma poi non capisco perché sto Torvalds ce l'ha sempre con le scimmie a volte ubriache a volte sotto crack:

"The thing that has always disturbed me about O_DIRECT is that the whole interface is just stupid, and was probably designed by a deranged monkey on some serious mind-controlling substances."--Linus

(traggo dal manuale di un comando a caso dell'API C:
https://linux.die.net/man/2/open)

ah e malloc è apparentemente bacata su Linux:
http://www.amaryllistechnology.com/man/htmlman3/malloc.3.html


In pratica, Linux è stato fatto da uno smanettone, per hobby ("I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones"), e tale è rimasta la mentalità della "comunità Linux".
Il che spiega una marea di cose.

Infatti il problema non è Linux, ma la gente che lo usa e pensare che alternative anche gratuite esistono (no non parlo di Cosmos che è in pre-alpha) come per esempio le varie incarnazioni di BSD, Haiku OS ecc...

La mia impressione è che Linux fu trascinato dagli eventi un OS che manco si sapeva come stava in piedi (a suon di accrocchi) che è finito per essere usato ovunque.

La domanda resta perché?
Forse Google si è resa conto della cappellata di basare Android su Linux: https://github.com/fuchsia-mirror/magenta ?

P.S. perché su Cent OS deve essere del gruppo "audio" per sentire beh... l'audio? Ha senso?

Questa è una battuta molto poco felice però:
quelle stesse righe di codice sono state vista sia dai programmatori MS, sia da quelli Intel, sia a quelli IBM.
Appunto. E' la battuta di uno che sa cosa significhi sviluppare codice, e che considera ridicola la formulazione della "legge" di cui sopra. :fagiano:
L'unica soluzione a questo problema è: se tutti i programmatori delle maggiori compagnie IT non hanno vista prima il bug, figuriamoci quanti ce ne sono da decenni sui software closed scritti da una sola parte di essi.
Non credi?
Non c'è una relazione fra le due cose, perché non sai quanti e chi hanno avuto accesso al codice closed. Che ovviamente è "open" per gli addetti ai lavori (come pure alle aziende esterne che ne hanno accesso).
http://yarchive.net/comp/linux/gcc_vs_kernel_stability.html

kernel space != user space
Non si tratta solo di kernel space: i problemi ci sono anche in user space.

Un'applicazione può smettere di funzionare passando da una distro a un'altra perché, ad esempio, non trova più libncurse, che è stata divisa in due librerie.

Oppure perché la libreria che gli serve c'è, ma è di una versione diversa, ovviamente incompatibile con quella che si aspetta.

Questo rimanendo in user space, ma altri s.o. garantisco API e ABI stabili anche in kernel space.
La mia impressione è che Linux fu trascinato dagli eventi un OS che manco si sapeva come stava in piedi (a suon di accrocchi) che è finito per essere usato ovunque.

La domanda resta perché?
Forse Google si è resa conto della cappellata di basare Android su Linux: https://github.com/fuchsia-mirror/magenta ?
Secondo me il motivo è questo (https://github.com/fuchsia-mirror/magenta/blob/master/LICENSE):

"The Magenta Kernel (kernel/...) is under the MIT License, a copy of which may be found in kernel/LICENSE"

Come ripeto da un pezzo, l'industry sta progressivamente abbandonando la famigerata GPL, in favore di licenze commercial-friendly.

Non c'è una relazione fra le due cose, perché non sai quanti e chi hanno avuto accesso al codice closed. Che ovviamente è "open" per gli addetti ai lavori (come pure alle aziende esterne che ne hanno accesso).


Per forza di cose il codice closed è meno visionato (come numero di persone) di quello open.
La differenza è che se un bug sfugge alla prima release del codice difficilmente sarà rilevato dopo in assenza di moduli o chiamate nuove che ne faranno uso ( a meno che il bug non provochi anche instabilità), con codice open ci sarà sempre qualcuno che avrà voglia di spulciare per curiosità e/o passione.
Di suo il codice closed permette maggior sicurezza perchè i bug "nascosti" non possono essere sfruttati se non per coincidenze fortuite, mentre in quelle open sono sempre in chiaro, bisogna solo leggere per trovarle (impossibile con il closed, se non per gli autori stessi).
Per esempio tra win e linux possono eeserci 100 falle ogni 1, ma le falle di windows magari non verranno mai sfruttate, quelle di linux sono in attesa di essere trovate.

Ps Dato un numero sufficiente di occhi, tutti i bug vengono a galla
Se ti riferisci a questa di legge, è giustissima, il bello è che non dice se i bug verranno pachati o sfruttati.

sai qual'e' il problema??? che quelli che ragionano come te non calcolano il fattore newbie, la gente vuole fare tutto e subito e sappiamo bene che questo con linux non esiste. la gente sente dire che per aprire i pacchetti RAR ci vuole winrar e su linux non lo trovano perche' ha un altro nome, e non hanno nessuna intenzione di imparare ( questo giusto per dirne una delle tante ). ma poi l'ho visto e pagato a mie spese, linux e' un casino anche se sto pensando a un ritorno.

Se ad un newbie gli dai un PC windows i pacchetti RAR manco li apre se non installa winrar, e se non sa che il coso che apre i RAR si chiama winrar, anche windows diventa uncasinochemmammamia.

Ma poi non capisco perché sto Torvalds ce l'ha sempre con le scimmie a volte ubriache a volte sotto crack:

"The thing that has always disturbed me about O_DIRECT is that the whole interface is just stupid, and was probably designed by a deranged monkey on some serious mind-controlling substances."--Linus

O_DIRECT è abbastanza controverso. Dovrebbe abilitarti ad aprire file bypassando cache e tutto il resto, ma diventa impossibile da usare perché dipende dall'hardware e sei costretto a leggere e scrivere file a blocchi di dimensioni parti ad un settore, cosa abbastanza assurda e decisamente poco portabile.


(traggo dal manuale di un comando a caso dell'API C:
https://linux.die.net/man/2/open)


Ti riferisci al flag ASYNC_IO? Un bug abbastanza banale di cui ti viene anche fornito il workaround e, probabilmente, non si può sistemare facilmente senza riarrangiare parte del codice, oppure forse non si può proprio fare. Più che un bug è una limitazione aggirabile.


ah e malloc è apparentemente bacata su Linux:
http://www.amaryllistechnology.com/man/htmlman3/malloc.3.html

malloc è libc, non del kernel linux


Forse Google si è resa conto della cappellata di basare Android su Linux: https://github.com/fuchsia-mirror/magenta ?


Se google non avesse scelto il kernel linux a quest'ora lo stava ancora progettando android...
Tutto le baggianate tirate in ballo quando si parla di linux del kernel monolitico, bloated, e bla bla bla fanno tanto scena, ma intanto il kernel linux può essere compilato tanto per stare in 50 megabyte, con valanghe di driver al seguito per hardware generico come per un PC, e tanto stare in 500 kbyte selezionando accuratamente quello che serve, come accade sui router.


P.S. perché su Cent OS deve essere del gruppo "audio" per sentire beh... l'audio? Ha senso?

Certo che ha senso: se l'accesso ai file dei device è ristretto agli utenti del gruppo audio devi essere membro del gruppo audio per poter accedere ai device!

Guarda che "il contesto" l'avevo compreso perfettamente ed è inutile che ricopi tutto il messaggio, che avevo letto interamente.
E ribadisco che uno che, con evidente fastidio, dice che "ci sono cose altrettanto importanti" è uno a cui della sicurezza gliene importa una beata fava.
Nel 2008.
Verba volant, scripta manent. :read:
Il contenuto di quanto postato da Torvalds non è quello che dici tu.
Estrarre una breve frase dal suo contesto (che in questo caso era fondamentale per comprendere cosa si intendeva per "security CIRCUS") per poi attribuirle il contesto ed il significato che ti fa più comodo funziona solo se nessuno va a verificare alla fonte.

Per spiegare il concetto mooolto sinteticamente:
useresti un sistema operativo super-sicuro, senza falle di sicurezza, ma che ogni tanto va in crash facendoi perdere dati ed ore di lavoro?

Il succo del discorso di Torvalds era quello, concentrarsi su e glorificare solo l'aspetto della sicurezza è un comportamento sbagliato visto che non è l'unico aspetto importante per un sistema operativo.


In pratica, Linux è stato fatto da uno smanettone, per hobby ("I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones"), e tale è rimasta la mentalità della "comunità Linux".
Il che spiega una marea di cose.

È iniziato così, MA POI poi con il contributo fondamentale di un esercito di altri sviluppatori è diventato qualcosa di molto più grande.
La "mentalità della comunità Linux" è evidente in quello che ha prodotto: un sistema operativo usato in ogni genere di settore proprio per la sua superiorità qualitativa sotto TUTTI gli aspetti importanti.

O_DIRECT è abbastanza controverso. Dovrebbe abilitarti ad aprire file bypassando cache e tutto il resto, ma diventa impossibile da usare perché dipende dall'hardware e sei costretto a leggere e scrivere file a blocchi di dimensioni parti ad un settore, cosa abbastanza assurda e decisamente poco portabile.

Ti riferisci al flag ASYNC_IO? Un bug abbastanza banale di cui ti viene anche fornito il workaround e, probabilmente, non si può sistemare facilmente senza riarrangiare parte del codice, oppure forse non si può proprio fare. Più che un bug è una limitazione aggirabile.


No parlavo sempre di O_DIRECT vedi questo è un problema anche mio come uno può essere serio quando la butta sempre in caciara parlando di scimmie sotto crack?


malloc è libc, non del kernel linux


Sarà pure come dici, ma la stessa malloc dichiara che il bug è di Linux (del kernel) non di malloc:

By default, Linux follows an optimistic memory allocation strategy. This means that when malloc() returns non-NULL there is no guarantee that the memory really is available. This is a really bad bug. In case it turns out that the system is out of memory, one or more processes will be killed by the infamous OOM killer

(noto che nelle recenti versione di "man malloc" hanno cambiato un po' la frase e non è più un "really bad bug" della serie "non è un baco è una feauture" ci ho provato a farlo con un mio cliente una volta... non era contento affatto :eek: )


Se google non avesse scelto il kernel linux a quest'ora lo stava ancora progettando android...


A parte che Google non ha progettato Android ma ha aquisito la start up che lo stava realizzando e quindi ormai l'idea di usare un kernel linux pathcato + una VM Java era ben radicata e definita nel progetto.

Io credo se Google e le altre corporation investissero soldi in un OS serio faremmo veramente passi avanti enormi...

@cdimauro sicuramente la licenza GPL è uno dei problemi di Linux per uso commerciale, ma ce sono anche altri uno è Linus Torvalds stesso che ha un carattere ecco un po' particolare, ma anche altri membri della community hanno "problemi".
Anche il modo in cui vengono fatte le cose "per tentativi" quanti sottosistemi audio sono esistiti in Linux io ricordo: OSS, Alsa, PulseAudio...

Stendiamo un lato pietoso su X tecnologia che risale a quando? Anni '70?


Tutto le baggianate tirate in ballo quando si parla di linux del kernel monolitico, bloated, e bla bla bla fanno tanto scena, ma intanto il kernel linux può essere compilato tanto per stare in 50 megabyte, con valanghe di driver al seguito per hardware generico come per un PC, e tanto stare in 500 kbyte selezionando accuratamente quello che serve, come accade sui router.


Qui stiamo parlando di un discorso tecnico non "alla fine funzionicchia" e in 50 Megabyte dai siamo serii cosa ci fai? Se sei fortunato forse ti funziona a linea di comando, ma appena hai già un sistema esotico come i portatili Lenovo di cui parlavamo la settimana scorsa beh tanti auguri a farlo bootare!

Fare un kernel monolitico negli anni '90 era una baggianata e lo è sempre stato, probabilmente il meglio sta nel mezzo infatti Mac OSX e Windows sono kernel ibridi, BeOs / Haiku OS non è del tutto chiaro se siano completamente microkernel nemmeno loro...

Cosmos? Non rientra nelle normali definizioni wikepedia lo metterebbe con Singularity in "language-based system":

https://en.wikipedia.org/wiki/Language-based_system


Certo che ha senso: se l'accesso ai file dei device è ristretto agli utenti del gruppo audio devi essere membro del gruppo audio per poter accedere ai device!

No, non ce l'ha: stiamo parlando di un desktop (poi concordo che CentOS/ Red Hat Enterprise Linux non sono pensate per desktop, ma per server senza manco GUI) come può aver senso che l'utente non possa manco ascoltarsi un po' di musica?

Linus Torvalds stesso concorda su questo: come diavolo si aggiunge una stampante su Linux?

http://www.zdnet.com/article/linus-torvalds-snarls-at-opensuse-desktop-linuxs-security/

qui ha ragione la troppa sicurezza è un male! Infatti ha senso solo nel kernel e in pochi altri posti "sensibili"... io mi diverto a dire Linux è così sicuro che se non hai la password di root non puoi fare niente :Prrr:

Per forza di cose il codice closed è meno visionato (come numero di persone) di quello open.
La differenza è che se un bug sfugge alla prima release del codice difficilmente sarà rilevato dopo in assenza di moduli o chiamate nuove che ne faranno uso ( a meno che il bug non provochi anche instabilità), con codice open ci sarà sempre qualcuno che avrà voglia di spulciare per curiosità e/o passione.
Di suo il codice closed permette maggior sicurezza perchè i bug "nascosti" non possono essere sfruttati se non per coincidenze fortuite, mentre in quelle open sono sempre in chiaro, bisogna solo leggere per trovarle (impossibile con il closed, se non per gli autori stessi).
Per esempio tra win e linux possono eeserci 100 falle ogni 1, ma le falle di windows magari non verranno mai sfruttate, quelle di linux sono in attesa di essere trovate.

Ps Dato un numero sufficiente di occhi, tutti i bug vengono a galla
Se ti riferisci a questa di legge, è giustissima, il bello è che non dice se i bug verranno pachati o sfruttati.

Hai presente la crittografia ? Quella dove TUTTO ruota intorno alla sicurezza?
È li che è emerso per primo che la "security by obscurity" degli algoritmi è inferiore dall'usare algoritmi aperti, visionabili, analizzabili da tutti e sopratutto verificabili da tutti.

Poi anche nel settore del software si è visto da decenni che il codice chiuso non è più sicuro, anzi, spesso ci sono falle note lasciate li a marcire per anni pensando che se si nasconde un merdone sotto il tappeto nessuno noterà il rigonfiamento e la puzza. :rolleyes:

I black hat da anni usano metodi e tool di ricerca di potenziali falle che prescindono dall'accesso al codice sorgente originale, mentre dall'altro lato non avere accesso ai sorgenti complica la vita a quelli che cercano la fonte del bug per poterlo correggere.
Per questo ad esempio, a distanza di anni da quando Microsoft ha capito (a forza di bastonate) che la sicurezza è importante, continua comunque ad avere molti più problemi.

Per forza di cose il codice closed è meno visionato (come numero di persone) di quello open.
La differenza è che se un bug sfugge alla prima release del codice difficilmente sarà rilevato dopo in assenza di moduli o chiamate nuove che ne faranno uso ( a meno che il bug non provochi anche instabilità), con codice open ci sarà sempre qualcuno che avrà voglia di spulciare per curiosità e/o passione.
Entrambe le cose, su software closed e open, non dimostrano nulla: sono solo speranze.
Di suo il codice closed permette maggior sicurezza perchè i bug "nascosti" non possono essere sfruttati se non per coincidenze fortuite, mentre in quelle open sono sempre in chiaro, bisogna solo leggere per trovarle (impossibile con il closed, se non per gli autori stessi).
Per esempio tra win e linux possono eeserci 100 falle ogni 1, ma le falle di windows magari non verranno mai sfruttate, quelle di linux sono in attesa di essere trovate.
Assolutamente d'accordo. :)
Ps Dato un numero sufficiente di occhi, tutti i bug vengono a galla
Se ti riferisci a questa di legge, è giustissima, il bello è che non dice se i bug verranno pachati o sfruttati.
Questa "legge" non soltanto non è una legge, ma non è nemmeno "giusta", visto che esprime soltanto un'altra speranza.

A parte questo, scendendo nel più tecnico nonché formale, questa "legge", così formulata, si potrebbe benissimo applicare al famigerato "problema dell'arresto (stop/halt)", che è un teorema (quindi dimostrato formalmente) della teoria della computabilità.

Ora, che una speranza abbia la forza di smontare un teorema (ripeto: formalmente dimostrato) mi pare leggermente esagerato, no? :D
O_DIRECT è abbastanza controverso. Dovrebbe abilitarti ad aprire file bypassando cache e tutto il resto, ma diventa impossibile da usare perché dipende dall'hardware e sei costretto a leggere e scrivere file a blocchi di dimensioni parti ad un settore, cosa abbastanza assurda e decisamente poco portabile.
Se O_DIRECT è POSIX, beh, ci sono s.o. POSIX-compliant che la implementano (correttamente).
Ti riferisci al flag ASYNC_IO? Un bug abbastanza banale di cui ti viene anche fornito il workaround e, probabilmente, non si può sistemare facilmente senza riarrangiare parte del codice, oppure forse non si può proprio fare. Più che un bug è una limitazione aggirabile.
Se è un bug dovrebbe essere già stato corretto, secondo le affermazioni (non tue, sia chiaro) di chi sostiene che: "appena si scopre un bug in un codice open source viene subito corretto". E di conseguenza non dovrebbero esistere nemmeno i workaround: non c'è bisogno, perché tanto c'è subito il fix. :flower:
malloc è libc, non del kernel linux
Come già detto da fano, nonché riportato nella descrizione, la malloc si affida al kernel, e se questo gli restituisce un puntatore non nullo... altro non può fare che accettarlo e usarlo.
Certo che ha senso: se l'accesso ai file dei device è ristretto agli utenti del gruppo audio devi essere membro del gruppo audio per poter accedere ai device!
E al gruppo video per accedere alla GUI? C'è pure un gruppo keyboard per poter usare la tastiera? :stordita:
La "mentalità della comunità Linux" è evidente in quello che ha prodotto: un sistema operativo usato in ogni genere di settore proprio per la sua superiorità qualitativa sotto TUTTI gli aspetti importanti.
O semplicemente perché è il più supportato (fra i s.o. open), e dunque è comodo poterlo sfruttare. :fagiano:
Qui stiamo parlando di un discorso tecnico non "alla fine funzionicchia" e in 50 Megabyte dai siamo serii cosa ci fai? Se sei fortunato forse ti funziona a linea di comando,
Con 50MB ti fai un'ISO bootabile di AROS con tanto di interfaccia grafica e applicazioni annesse. :cool:
Hai presente la crittografia ? Quella dove TUTTO ruota intorno alla sicurezza?
È li che è emerso per primo che la "security by obscurity" degli algoritmi è inferiore dall'usare algoritmi aperti, visionabili, analizzabili da tutti e sopratutto verificabili da tutti.

Poi anche nel settore del software si è visto da decenni che il codice chiuso non è più sicuro, anzi, spesso ci sono falle note lasciate li a marcire per anni pensando che se si nasconde un merdone sotto il tappeto nessuno noterà il rigonfiamento e la puzza. :rolleyes:

I black hat da anni usano metodi e tool di ricerca di potenziali falle che prescindono dall'accesso al codice sorgente originale, mentre dall'altro lato non avere accesso ai sorgenti complica la vita a quelli che cercano la fonte del bug per poterlo correggere.
Per questo ad esempio, a distanza di anni da quando Microsoft ha capito (a forza di bastonate) che la sicurezza è importante, continua comunque ad avere molti più problemi.
Invece funziona meglio come ha scritto "Piedone", di cui condivido integralmente ciò ha scritto su questa parte.

La crittografia, invece, è una cosa completamente diversa.

Com'è anche vero che nessuno sano di mente metterebbe in giro lo schema dell'antifurto di casa sua, solo perché milioni di occhi potrebbero trovare eventuali falle nella sua sicurezza... :asd:

Entrambe le cose, su software closed e open, non dimostrano nulla: sono solo speranze.

Assolutamente d'accordo. :)

Questa "legge" non soltanto non è una legge, ma non è nemmeno "giusta", visto che esprime soltanto un'altra speranza.


Taglio il resto, ma dimentichi che non esistono solo leggi universali, ma anche leggi probabilistiche che solo leggi scientifiche a tutti gli effetti (hai presente le leggi di fisica quantistica?).
Quando Archimede disse: datemi un un punto di appoggio ed una leva sufficientemente lunga e vi sollevo il mondo in molti si misero a ridere.

Quella legge (che difatti non è una legge) dice Dato un numero sufficienti di occhi (che è un insieme compreso tra 1 e infinito) tutti i bug vengono a galla (su un insieme finito).
Tutto dipende da quante righe di codice sono presenti e da quanti la visionano.
Ma questo è un discorso più teorico che pratico.

che poi non c'è bisogno di formulare una legge scientifica per una cosa così ovvia.
La mia frase successiva:
Se ti riferisci a questa di legge, è giustissima, il bello è che non dice se i bug verranno pachati o sfruttati si riferisce a quella che definisci speranza (se un numero sufficiente di occhi cerca bug nel codice verranno trovati tutti, ma non sappiamo se i bug verranno trovati da chi vuole pachare o da chi vuole creare exploit, che è quello che succede tutti i giorni con tutti i tipi di software.)

Purtroppo non c'è niente che ti garantisca che un numero sufficiente di occhi possa trovare proprio TUTTI i bug di un software. Specialmente coi software che sono via via sempre più complicati.

Anche le leggi probabilistiche sono comunque... leggi. Dietro ci sono formule e teoremi.

Inoltre stai assumendo che tutti gli "occhi" siano uguali: non è così.

Purtroppo non c'è niente che ti garantisca che un numero sufficiente di occhi possa trovare proprio TUTTI i bug di un software. Specialmente coi software che sono via via sempre più complicati.

Anche le leggi probabilistiche sono comunque... leggi. Dietro ci sono formule e teoremi.

Inoltre stai assumendo che tutti gli "occhi" siano uguali: non è così.
Ma un insieme infinito di occhi è composto da diversi sottoinsiemi infiniti di occhi (quindi ci sarà comunque un sottinsieme infinito di occhi che ci vede doppio di quello normale e trovarà i bug anche che se il sottinsieme orbo non sarà in grado di trovare nemmeno il proprio pisello per urinare).
La legge è sempre valida per occhi che cercano bug tendenti ad infinito.
Per il resto questo stesso assunto ci dice che per quanti occhi (di un insieme finito) possano cercare bug non è certo che li trovino tutti (e qua torniamo alla tua speranza ), quindi non sono sufficienti.

Ma appunto perchè il kernel di Linuxe monolitico composto da milioni di righe di codice (driver di schede video morte da secoli, porte seriali*, porte parallele), io non credo che nemmeno Linus Torvalds lo comprenda tutto!

Questo è un altra cosa che va contro la "Legge di Linus" :D

* ma con2 driver bacato visto che non supporta RS485 ed ho dovuto fare kludge io a livello utente

Ma appunto perchè il kernel di Linuxe monolitico composto da milioni di righe di codice (driver di schede video morte da secoli, porte seriali*, porte parallele), io non credo che nemmeno Linus Torvalds lo comprenda tutto!

Questo è un altra cosa che va contro la "Legge di Linus" :D

* ma con2 driver bacato visto che non supporta RS485 ed ho dovuto fare kludge io a livello utente

Capisco il tuo punto di vista, ma un kernel monolitico non porta solo svantaggi, come un microkernel non porta solo vantaggi.
Per l'open di massa (come è linux) è preferibile un kernel monolitico piuttosto che un microkernel.
Io non sto parlando di efficenza o bug, ma di gestione dello sviluppo.
Ogni software può essere scritto meglio, ma a furia di migliorarlo (per quante risorse di uomini e mezzi tu abbia) sarà in perenne beta.
Un os moderno a microkernel non può che essere proprietario e sviluppato in modo closed.

O semplicemente perché è il più supportato (fra i s.o. open), e dunque è comodo poterlo sfruttare. :fagiano:
E' anche il più supportato, altro aspetto non da poco, ma non l'unico.
Di solito non è che un sistema operativo diventa il più supportato così per caso, deve avere sufficienti caratteristiche positive da attirare una community di sviluppatori di buona qualità.



La crittografia, invece, è una cosa completamente diversa.

Com'è anche vero che nessuno sano di mente metterebbe in giro lo schema dell'antifurto di casa sua, solo perché milioni di occhi potrebbero trovare eventuali falle nella sua sicurezza... :asd:

I principi di base sono gli stessi, non a caso chi progetta un BUON antifurto parte dall'idea che i possibili intrusi conoscano come è fatto, ma che non conoscano i codici di accesso, quelli fanno parte dei parametri dell'implementazione, non dell'algoritmo/progetto (algoritmo nel caso di software e progetto in caso di hardware).

Avendo avuto a che fare con lo sviluppo di software per sistemi domotici, relativi sistemi di allarme ed analisi di prodotti di fornitori e della concorrenza
non ti dico quanti di essi sono delle pachianate assurde proprio perchè si basano sulla "security by obscurity"
(pieni zeppi di dettagli implementativi vulnerabili, basati sul "tanto nessuno lo saprà mai").

Capisco il tuo punto di vista, ma un kernel monolitico non porta solo svantaggi, come un microkernel non porta solo vantaggi.
Per l'open di massa (come è linux) è preferibile un kernel monolitico piuttosto che un microkernel.
Io non sto parlando di efficenza o bug, ma di gestione dello sviluppo.
Ogni software può essere scritto meglio, ma a furia di migliorarlo (per quante risorse di uomini e mezzi tu abbia) sarà in perenne beta.
Un os moderno a microkernel non può che essere proprietario e sviluppato in modo closed.
Haiku è l'esempio più eloquente, ma ce ne sono altri.
E' anche il più supportato, altro aspetto non da poco, ma non l'unico.
Di solito non è che un sistema operativo diventa il più supportato così per caso, deve avere sufficienti caratteristiche positive da attirare una community di sviluppatori di buona qualità.
Sulle caratteristiche / feature nulla da dire, ma questo deriva dal supporto che ha ricevuto e dagli sviluppatori che hanno scritto un sacco di codice.

In ogni caso in tutto ciò continua a sfuggirmi, da questo:

"la sua superiorità qualitativa sotto TUTTI gli aspetti importanti"

che avevi scritto, dove sarebbe dimostrata la superiorità qualitativa (e cosa intendi con ciò).
I principi di base sono gli stessi, non a caso chi progetta un BUON antifurto parte dall'idea che i possibili intrusi conoscano come è fatto, ma che non conoscano i codici di accesso, quelli fanno parte dei parametri dell'implementazione, non dell'algoritmo/progetto (algoritmo nel caso di software e progetto in caso di hardware).

Avendo avuto a che fare con lo sviluppo di software per sistemi domotici, relativi sistemi di allarme ed analisi di prodotti di fornitori e della concorrenza
non ti dico quanti di essi sono delle pachianate assurde proprio perchè si basano sulla "security by obscurity"
(pieni zeppi di dettagli implementativi vulnerabili, basati sul "tanto nessuno lo saprà mai").
L'unica similitudine in questo caso riguarda esclusivamente il meccanismo che fa uso di codici.

Per il resto, se pubblichi l'intero schema qualcuno potrebbe trovare il modo di aggirare o eliminare il blocco che fa uso dei codici.

La similitudine, infatti è la seguente: il meccanismo dei codici sta all'algoritmo di criptazione, come il resto del sistema d'allarme sta al resto della piattaforma software.

E' anche il più supportato, altro aspetto non da poco, ma non l'unico.
Di solito non è che un sistema operativo diventa il più supportato così per caso, deve avere sufficienti caratteristiche positive da attirare una community di sviluppatori di buona qualità.

Credo che, soprattutto nei primi anni, un gran peso l'abbia avuto la GPL.



I principi di base sono gli stessi, non a caso chi progetta un BUON antifurto parte dall'idea che i possibili intrusi conoscano come è fatto, ma che non conoscano i codici di accesso, quelli fanno parte dei parametri dell'implementazione, non dell'algoritmo/progetto (algoritmo nel caso di software e progetto in caso di hardware).

Avendo avuto a che fare con lo sviluppo di software per sistemi domotici, relativi sistemi di allarme ed analisi di prodotti di fornitori e della concorrenza
non ti dico quanti di essi sono delle pachianate assurde proprio perchè si basano sulla "security by obscurity"
(pieni zeppi di dettagli implementativi vulnerabili, basati sul "tanto nessuno lo saprà mai").

Credo che il punto sia questo: un algoritmo sicuro rimane tale pure se lo conoscono nel dettaglio tutti, in quanto di solito la sicurezza è data dalle caratteristiche matematiche dello stesso. Il problema sta nell'implementazione, che potrebbe contenere approssimazioni e/o errori. A quel punto, chi mi dice che la community lo noti prima dei malintenzionati?
Abbiamo già rimosso Heartbleed?

Haiku è l'esempio più eloquente, ma ce ne sono altri.

.
Non ho capito?
Forse confermi quello che ho scritto indicando haiku come os open a microkernel in pre beta da 15 anni?

Verba volant, scripta manent. :read:


Appunto.
Basta andare a leggere e si capisce la sottovalutazione di Torvalds sull'importanza della sicurezza.



È iniziato così, MA POI poi con il contributo fondamentale di un esercito di altri sviluppatori è diventato qualcosa di molto più grande.
La "mentalità della comunità Linux" è evidente in quello che ha prodotto: un sistema operativo usato in ogni genere di settore proprio per la sua superiorità qualitativa sotto TUTTI gli aspetti importanti.

Linux è usato in tutti i settori MENO quello principale, il desktop, dove ha percentuali da prefisso telefonico.

Linux è usato così tanto, ma solo nei settori dove la "human interface" non è veramente importante, semplicemente perchè C'E' GIA' ed è GRATUITO, non è necessario reinventarsi un SO da zero.

La mentalità della comunità Linux è quella per cui fra dieci anni sarai ancora qui a chiederti come mai dal 2017 al 2027 nessun'anno è stato "l'anno di Linux".

La mentalità della comunità Linux è quella per cui non sto neppure a perdere tempo a discutere con un linaro, so già che vive fuori dal mondo e che continuerà a non saper distinguere tra software professionale e software da smanettoni (che non è la totalità in Linux ma è tanta parte). E dato che nel campo del software professionale ci lavoro da 34 anni, e da quindici nella sicurezza IT, credo proprio di avere le basi per capirlo.

Quindi, divertiti con Linux, se ti diverte. Mica voglio rompere il giocattolo a nessuno.
Io mi fermo qui.

Non ho capito?
Forse confermi quello che ho scritto indicando haiku come os open a microkernel in pre beta da 15 anni?
Il microkernel è pronto da un pezzo. Se non ricordo male, è "soltanto" tutto il resto che è in beta.

quanti ricordi sto linux,

na volta per cofigurare l ethernet su gnome certi bestemmioni molti molti anni fa
Mi ha sempre dato l impressione di un so incompleto poco molto poco user friedly

magari mi sbaglio oggi è migliorato

Il microkernel è pronto da un pezzo. Se non ricordo male, è "soltanto" tutto il resto che è in beta.

Forse non mi è chiara la differenza tra monolitico e micro kernel.
Nel primo c'è tutto il brodo "primordiale" pronto ad essere usato, nel secondo ci sono gli attrezzi per cucinare a cui vanno aggiunti da fuori tutti gli ingredienti.
Quindi un microkernel da solo inizializza ed utilizza solo un numero ristretto di chiamate, mentre la totalità è demandata a moduli (?) che avviano ed inizializzano funzionalità hardware e logiche aggiuntive.
Credo quindi che un microkernel da solo sia del tutto inutile perchè deve essere coadiuvato dal layer successivo.
Che sia definitivo il microkernel, ma che non lo siano i moduli successivi significa che la totalità del kernel non è pronto.
Se la guida è direttiva senza che ci siano iniziative esterne il microkernel è fattibile ed auspicabile, ma nel mondo open si creano solo revisioni su revisioni dei vari moduli portando ad un perenne beta o peggio ancora alpha.

Il micro-kernel offre soltanto una serie (molto) limitata di servizi & API, lasciando tutto il resto a moduli che girano in user-space.

Quindi è molto più facile da scrivere e mantenere, rispetto ai classici kernel monolitici.

E' ovvio che quello che non va nel micro-kernel deve comunque essere implementato in user-space.

Forse non mi è chiara la differenza tra monolitico e micro kernel.
Nel primo c'è tutto il brodo "primordiale" pronto ad essere usato, nel secondo ci sono gli attrezzi per cucinare a cui vanno aggiunti da fuori tutti gli ingredienti.
Quindi un microkernel da solo inizializza ed utilizza solo un numero ristretto di chiamate, mentre la totalità è demandata a moduli (?) che avviano ed inizializzano funzionalità hardware e logiche aggiuntive.
Credo quindi che un microkernel da solo sia del tutto inutile perchè deve essere coadiuvato dal layer successivo.
Che sia definitivo il microkernel, ma che non lo siano i moduli successivi significa che la totalità del kernel non è pronto.
Se la guida è direttiva senza che ci siano iniziative esterne il microkernel è fattibile ed auspicabile, ma nel mondo open si creano solo revisioni su revisioni dei vari moduli portando ad un perenne beta o peggio ancora alpha.

Ma questa non è colpa del microkernel in sé. Semmai il problema sta nel modello di sviluppo. Il design a microkernel è sicuramente più "elegante" rispetto al pappone monolitico, oltre che, come ha già detto cdimauro, più facile da mantenere.

Ma questa non è colpa del microkernel in sé. Semmai il problema sta nel modello di sviluppo. Il design a microkernel è sicuramente più "elegante" rispetto al pappone monolitico, oltre che, come ha già detto cdimauro, più facile da mantenere.
Modello di sviluppo?
Capisco il tuo punto di vista, ma un kernel monolitico non porta solo svantaggi, come un microkernel non porta solo vantaggi.
Per l'open di massa (come è linux) è preferibile un kernel monolitico piuttosto che un microkernel.
Io non sto parlando di efficenza o bug, ma di gestione dello sviluppo.
Ogni software può essere scritto meglio, ma a furia di migliorarlo (per quante risorse di uomini e mezzi tu abbia) sarà in perenne beta.
Un os moderno a microkernel non può che essere proprietario e sviluppato in modo closed.
Che io reputo imputabile all'approccio OPEN.
Certamente un microkernel sarà più semplice, più sicuro e stabile, ma in uno sviluppo open dove tutti si scrivono i propri moduli (che magari fanno crashare i moduli di un'altro servizio e/o periferica perchè nel frattempo riscritti da altri) preferisco l'approccio monolitico che mi sembra più semplice da gestire (sviluppo e stesura con relative modifiche).
Ho usato apposta il termine Brodo Primordiale per indicare il minestrone che è il monolitico.
Per sviluppare un os su microkernel non si può utilizzare il modello open per le inefficienze proprie delle forza di tale modello.
Spero di essermi fatto capire anche se ho espresso la mia opinione in modo contorto.

E' l'esatto contrario: con una piattaforma basata su micro-kernel anche la gestione dei moduli diventa più semplice e testabile. Infatti se un modulo non risponde più, il (micro)kernel può benissimo farlo ripartire.

L'unico vantaggio di un kernel monolitico è che la comunicazione fra kernel e moduli è più veloce, perché non si deve passare da kernel space a user space, e viceversa.

Allora prima di tutto partiamo dalle basi che cos'è un microkernel?
https://en.wikipedia.org/wiki/Microkernel

Questo è come è stato sviluppato Haiku OS:
https://en.wikipedia.org/wiki/Haiku_(operating_system)#Technology

in realtà Haiku pecca forse di troppa modestia quella che loro chiamano Alpha 3, Linux Torvalds l'avrebbe tranquillamente chiamato kernel 2.0 :D

Funziano già molte cose (alcune che con questa semplicità su Linux te le scordi):


Haiku OS ha sempre la GUI funzionante (non ci sono schermi neri su Haiku) se il driver della GPU non esiste viene usato il driver generico VESA
Non ci sono diecimila sottosistemi audio
Multi threading pervasivo (cosa che Windows inizia ad avere forse da Windows 10?)


Quindi perché non riescono a "finirlo"? Perché sono in 3 gli sviluppatori non perché Haiku OS è un microkernel (che poi loro stessi mi corressero dicendo che effettivamente è un kernel ibrido)... son tutti a patchare Linux?

https://github.com/hfiref0x/UACME

:rotfl:

Però:
Admin account with UAC set on default settings required.

Gliel'ho già fatto notare in un altro thread, ma tanto continua lo stesso a riportare ciclicamente lo stesso link (che peraltro testimonia come Microsoft sia costantemente impegnata nel sistemare le falle, visto che ne sono rimaste poche).

/OT

Però:
Certo e guarda caso è la situazione di default, a cui quindi vanno incontro la maggior parte di utenti (cosa che non si verifica con implementazioni di sudo per windows).

Come quelli di Lindows.

(che peraltro testimonia come Microsoft sia costantemente impegnata nel sistemare le falle, visto che ne sono rimaste poche).
Non sono d'accordo visto che quelle che ritieni siano poche sono lì da mesi e mesi.

L'elenco è abbastanza lungo, e mi pare che ne siano rimaste poche ormai.

L'elenco è abbastanza lungo, e mi pare che ne siano rimaste poche ormai.
Solo perchè tu quel link lo conosci da poco, mentre io lo osservo da taaanto tempo (dal 2007 circa, partendo dal link del ricercatore iniziale) e infatti devo sempre intervenire personalmente nel setup di tantissimi utenti windows, spiegando loro che UAC è a tutti gli effetti un tentativo riuscito male di reimplementare una ruota da tradizionale e funzionale letteratura informatica.

Oltre a quelli poi, come si sarà notato, ce ne sono altri inerenti win7 e win8.x che non sono mai stati sistemati.

E di nuovo: non è l'UAC il problema, ma la creazione di account di amministratore!

E di nuovo: non è l'UAC il problema, ma la creazione di account di amministratore!
No, è proprio tutto il sistema degli account/privilegi/UAC, nell'intero insieme hanno creato un bel casino e, come già detto infinite volte, con sistemi sudo per windows non c'è verso che tutti quegli "hack" funzionino.
Ti informo poi che, a parte quel link inerente la backdoor, i sistemi nix non hanno mai avuto tutte quelle patch inerenti account/token/privilegi che si sono succeduti negli anni nei windows, tante delle quali responsabili dei fallimenti di IE8/9/10/ecc. nel security contest dei browser.

Rispondi a questo: cosa succede se usi UAC con un account normale?

Rispondi a questo: cosa succede se usi UAC con un account normale?
Che non hai problemi con quella backdoor ma hai problemi con altre vulnerabilità che spesso ti trovi quando vai ad analizzare i singoli bollettini di tantissimi update MS.

Cmq, pure quest'anno MS con Edge le ha prese più di tutti gli altri, è così ogni anno, è un sistema intrinsecamente meno sicuro, c'è poco da fare.

Certo e guarda caso è la situazione di default, a cui quindi vanno incontro la maggior parte di utenti (cosa che non si verifica con implementazioni di sudo per windows).

Vero, infatti reputo sia stato un errore il cambiamento da Vista a 7 (su Vista di default UAC partiva da un livello più alto).

Che non hai problemi con quella backdoor ma hai problemi con altre vulnerabilità che spesso ti trovi quando vai ad analizzare i singoli bollettini di tantissimi update MS.
Lascia perdere eventuali ALTRE vulnerabilità. Ho chiesto cosa succede in condizioni normali. Grazie.
Cmq, pure quest'anno MS con Edge le ha prese più di tutti gli altri, è così ogni anno, è un sistema intrinsecamente meno sicuro, c'è poco da fare.
Edge è un'applicazione, che uso molto raramente. Io uso Opera.

E questo è un altro discorso. :read:

Vero, infatti reputo sia stato un errore il cambiamento da Vista a 7 (su Vista di default UAC partiva da un livello più alto).
Il problema più grosso è che si potrebbe risolvere facilmente (parlo della backdoor specifica, non dei frequenti altri buchi del sistema UAC/integrity come si vede da continue e frequenti patch) non rendendo DI DEFAULT una ben precisa impostazione.

Lascia perdere eventuali ALTRE vulnerabilità.
Le altre vulnerabilità sono pure ben peggio di una backdoor lasciata lì ottusamente da MS quando sa che si potrebbe sistemare con la modifica di una semplice impostazione. Io parlo della stragrande maggior parte di utenti di windows che si ritrovano di DEFAULT una cazzata monumentale by design from MS :D

Edge è un'applicazione,
Che, come tutti i browser "integrati" MS si basa su UAC e integrity levels

Io uso Opera.
Non me ne potrebbe fregar de meno, io parlo della mediocre MS e delle sue mosse "intelligenti" e di mediocre competenza.

Who cares. O parli del s.o. o delle applicazioni. E io ho fatto una precisa domanda a cui continui a girare attorno.

Ripeto: account normale + UAC - backdoor et similia. Cosa succede? :read:

Who cares.
Cazzi tuoi se non ti importa, rimane il fatto che una si basa su un'altra.

E io ho fatto una precisa domanda a cui continui a girare attorno.
Non ci ho girato attorno, da quanto ho scritto si è capito che è necessario un account standard, ma guarda che il ritardatario sei sempre tu, il vicentino c'era già arrivato :)

Ma, detto questo, il fatto che per sfangarla serva un'impostazione NON DI DEFAULT rende una backdoor più che pericolosa di DEFAULT (anzi, più di un'impostazione visto che per aver la miglior sicurezza un niubbo è costretto a compiere passe non soliti per lui e la stragrande maggioranza di utenti windows abituati ancora all'era pre-kernel nt).

Non ho parlato di account standard, ma normale. Dunque NON di amministratore.

Non serve particolare intelligenza per capire la differenza fra le due cose.

Non ho parlato di account standard, ma normale. Dunque NON di amministratore.
Ho usato la nomenclatura che era solita usare MS (post XP, prima l'account standard, cioè non admin, era chiamato limited; cmq è così che l'ho sempre chiamato anche perché abituato ai nix), cioè account standard=account normale/non admin.

E io avevo già specificato prima che parlavo di account non di amministratore, visto che i problemi con UAC sorgono con quelli di amministratore, come peraltro avevamo già discusso.

E io avevo già specificato prima che parlavo di account non di amministratore,
Sì ma l'avevo capito già secoli fa ma non cambia la sostanza oggettiva della cagata di MS che di default, per la maggior parte di utenza Win, lascia praticamente una backdoor aperta (e, a dirla tutta, ne ho parlato inizialmente io perfino su questo stesso forum anni fa)

Se si parla di concetti tecnici, è importante avere una certa conoscenza ed esperienza prima di esprimersi.

Il fatto che uno lavi i pavimenti delle stanze server di un'azienda, non lo rende un'esperto di server e sistemi operativi

Adesso di spiego qualche fondamento di sistemi operativi. Nota che parlo di ambito server, dato che il bug ha senso su sistemi interfacciati con l'esterno, e che quando si discute di kernel lo si fa in ambiti piú ristretti (sui desktop, entrano in gioco molte piú componenti, e le falle del kernel sono solo una parte).

Stiamo parlando di un kernel che basta uno sbordamento ben cucinato e ti fa passare da utente normale a utente root con potere assoluto sulla macchina a me pare una cosa molto, molto seria ed anche abbastanza indifendibile :D

Ci sono vulnerabilità di ogni livello su tutti i sistemi operativi; se prendi in esame qualsiasi O/S, vedrai ogni anno qualche dozzina (esatto, mediamente una al mese) di vulnerabilità corrette.

La gran parte delle vulnerabilità sono solo potenziali. La particolarità di questa falla è che in certe condizioni (non in qualsiasi condizione; purtroppo le molte scimmie urlanti di questo post non sono in grado di leggere...) è possible sfruttarla.

È importante capire che bucare un sistema operativo - *ogni* sistema operativo - è puramente una questione di risorse (tempo e denaro). È di fatto impossibile che qualsiasi software di milioni di righe di codice non abbia vulnerabità o bug in genere.

Detto ciò, su basi puramente numeriche, il kernel Linux non è piú vulnerabile di altri.


Ma del resto Linus Torvalds una volta se lo fece scappare che lui delle vulnerabilità di sicurezza se ne sbatte la fava quindi...
http://article.gmane.org/gmane.linux.kernel/706950


Come spiegato sopra, le S.U. non leggono o non comprendono quello che leggono. Torvalds scrive, da manager, che la sicurezza è una parte importante, esattamente come le tante altre. È anche importante non identificare Torvalds con Linux, dato che alcune aziende che lavorano con Linux, eg. Redhat, architettano il loro O/S in maniera molto conservativa (vedi RedHat 6, con il kernel 2.6), che è l'unico modo di sviluppare un sistema operativo orientato alla sicurezza e stabilità (a scapito del supporto HW e delle feature dei kernel moderni).

Se poi contiamo che su sistemi mission critical te lo scordi di aggiornare il kernel

I sistemi mission critical hanno team di professionisti che se ne occupano, che sono professionisti appunto perché si devono fare questi lavori con precisione.
È chiaro che se metti i server in mano a chi lava i pavimenti, diventa un circo, ma non ha nulla a che vedere con gli O/S.

Indipendentemente dall'O/S, qualsiasi server va riavviato varie volte l'anno.

che fai le aggiorni e ricompili tutti gli applicativi? E sì perché se speri che il nuovo kernel col bug fixato di 9 anni faccia girare gli applicativi senza ricompilare

News flash per le S.U.: i software nei sistemi Linux sono in genere sono distribuiti in forma di package (certo, ci sono le eccezioni, ma sono sistemi non comunemente usati nei server), non di codice sorgente, incluso il kernel. L'unica parte che si ricompila sono i moduli, operazione tra l'altro automatica.

E sì perché se speri che il nuovo kernel col bug fixato di 9 anni faccia girare gli applicativi senza ricompilare o crash random vivi nel mondo delle fiabe :Prrr:

Il kernel di per sè ha poco a che vedere, da questo punto di vista, con i crash applicativi. Ci sono un paio di cose importanti da capire:

- i kernel moderni, indipendentemente dall'O/S, messi su server in genere sono molto solidi; vanno avanti per mesi e mesi;
- crash del kernel, e crash applicativi sono cose separate; se un'applicazione va in crash, il sistema va avanti;
- i bug che tipicamente possono causare incompatibilità con applicativi sono nelle librerie piuttosto che nel kernel.

Per sistemi tremendamente importanti ci si riduce al "back porting" che tristezza :p

Altra news flash per le S.U.: il backporting è una pratica molto ben accetta, perché è prassi implicita nella strategia di un produttore che porta avanti varie versioni allo stesso tempo. Se non esistesse il backporting, la tua azienda dovrebbe spendere un botto di risorse per aggiornare tutti i sistemi.

Non credere che backporting su Windows o Mac o quel che è non esista. La ragione per cui le S.U. credono che non esista è che i bollettini degli aggiornamenti sono piuttosto opachi (per varie ragioni).

quanti ricordi sto linux,

na volta per cofigurare l ethernet su gnome certi bestemmioni molti molti anni fa
Mi ha sempre dato l impressione di un so incompleto poco molto poco user friedly

magari mi sbaglio oggi è migliorato

Mah, in realtà al giorno d'oggi non fai nulla su nessun O/S - il DHCP ti dà l'indirizzo, e lo stack lo accetta beato :-)

Trovo l'"User friendliness", in senso moderno, un concetto sopravvalutato. Alla fine fine, quello che fa il 1500% degli utenti è... (rullo di tamburi)... navigare sul web, scrivere documenti, e magari connettere una stampante.

Detto ciò, è importante notare che, per forza di eventi, GNU/Linux è generalmente indietro in ambito drivers. Quindi è possibile (o probabile) che l'ultimo modello di stampante non funzioni :-|.

Per forza di cose il codice closed è meno visionato (come numero di persone) di quello open.

Mica tanto vero. Gli occhi che sono capaci di guardare sono pur sempre limitati, specialmente nella sicurezza, che è ambito per specialisti, dove i bug sono molto dispendiosi da rilevare.

Per esempio tra win e linux possono eeserci 100 falle ogni 1, ma le falle di windows magari non verranno mai sfruttate, quelle di linux sono in attesa di essere trovate.

Si e no. Leggere il codice è solo uno dei vari strumenti (per esempio il fuzzying) usato degli esperti.

Ps Dato un numero sufficiente di occhi, tutti i bug vengono a gallaSe ti riferisci a questa di legge, è giustissima, il bello è che non dice se i bug verranno pachati o sfruttati.

Sbagliatissimo. Chi lavora con software sa che è impossibile avere un software di milioni di righe che non abbia bug.
A peggiorare le cose, il fatto che nel software in genere si introduce nuovo codice costantemente, e con nuovo codice si introducono nuovi bug.

L'unico modo di avere software il piú stabile possibile è di non evolvere il codice (o di farlo in maniera limitata), ma purtroppo nel mondo reale non è possibile (as esempio, quando i Fano di turno si lamentano che CentOS ha il kernel 2.6... :rolleyes: )

Adesso di spiego qualche fondamento di sistemi operativi. Nota che parlo di ambito server, dato che il bug ha senso su sistemi interfacciati con l'esterno, e che quando si discute di kernel lo si fa in ambiti piú ristretti (sui desktop, entrano in gioco molte piú componenti, e le falle del kernel sono solo una parte).

Ci sono vulnerabilità di ogni livello su tutti i sistemi operativi; se prendi in esame qualsiasi O/S, vedrai ogni anno qualche dozzina (esatto, mediamente una al mese) di vulnerabilità corrette.

La gran parte delle vulnerabilità sono solo potenziali. La particolarità di questa falla è che in certe condizioni (non in qualsiasi condizione; purtroppo le molte scimmie urlanti di questo post non sono in grado di leggere...) è possible sfruttarla.


Anche se vi piace dire che sto bug (che ricordiamolo esiste da 9 anni!) funziona solo in locale basta aggiungere che un'applicazione che per esempio - a sua volta - permette sql injection ed eccoti la tua bella shell su cui eseguire il tuo bel giochino :D


È importante capire che bucare un sistema operativo - *ogni* sistema operativo - è puramente una questione di risorse (tempo e denaro). È di fatto impossibile che qualsiasi software di milioni di righe di codice non abbia vulnerabità o bug in genere.


Certo soprattutto se scrive un OS con tecnologie degli anni '70 (e qui ci mettiamo anche Windows alla fine il core NT tanto nuovo non è) con C/C++ è facilissimo bucarlo se trovi lo "sbordamento" giusto o magari se uno è così furbo da riscriversi le sue stringhe (HeartBleed ricordate?).


Detto ciò, su basi puramente numeriche, il kernel Linux non è piú vulnerabile di altri.


Ah beh questo non è che mi consola poi molto


Come spiegato sopra, le S.U. non leggono o non comprendono quello che leggono. Torvalds scrive, da manager, che la sicurezza è una parte importante, esattamente come le tante altre. È anche importante non identificare Torvalds con Linux, dato che alcune aziende che lavorano con Linux, eg. Redhat, architettano il loro O/S in maniera molto conservativa (vedi RedHat 6, con il kernel 2.6), che è l'unico modo di sviluppare un sistema operativo orientato alla sicurezza e stabilità (a scapito del supporto HW e delle feature dei kernel moderni).


Abbiamo già appurato che come il 99% delle cose che dice Linus Torvalds non ha senso...


I sistemi mission critical hanno team di professionisti che se ne occupano, che sono professionisti appunto perché si devono fare questi lavori con precisione.
È chiaro che se metti i server in mano a chi lava i pavimenti, diventa un circo, ma non ha nulla a che vedere con gli O/S.

Indipendentemente dall'O/S, qualsiasi server va riavviato varie volte l'anno.


Ma come? Linux non si vanta di NON dover essere mai riavviato? Questa del riavvio una volta all'anno mi è nuova... comunque se usi roba vetusta come Cent OS il kernel nuovo o i back porting te li scordi! Certo possiamo metterci a compilare il kernel e poi passare la giornata a convicere "initrd" a non mostrare uno schermo nero... been there done that (and it was not fun) :D


News flash per le S.U.: i software nei sistemi Linux sono in genere sono distribuiti in forma di package (certo, ci sono le eccezioni, ma sono sistemi non comunemente usati nei server), non di codice sorgente, incluso il kernel. L'unica parte che si ricompila sono i moduli, operazione tra l'altro automatica.


Automatica in che senso? Noi abbiamo dei driver proprietari e non si ricompilano proprio per niente in automatico (:D) cioè se dici che do make e NON compilano allora sì è automatico... poi passi la giornata a capire come deve essere totalmente riscritto il tuo driver per farlo andare col nuovo kernel. Guarda secondo me se aggiorni il kernel alla cieca al 99% ti becchi la gloriosa schermata nera di quando Linux "automaticamente" non riconosce più la scheda video :D


Il kernel di per sè ha poco a che vedere, da questo punto di vista, con i crash applicativi. Ci sono un paio di cose importanti da capire:

- i kernel moderni, indipendentemente dall'O/S, messi su server in genere sono molto solidi; vanno avanti per mesi e mesi;
- crash del kernel, e crash applicativi sono cose separate; se un'applicazione va in crash, il sistema va avanti;
- i bug che tipicamente possono causare incompatibilità con applicativi sono nelle librerie piuttosto che nel kernel.


Non nel mio caso visto che è un sistema embedded frega sega del kernel pathcato se la mia applicazione crasha! Ti dico di più nel mondo ideale io tutta la bratta di Linux manco la vorrei (wpa_supplicant ma che c*zz'è?), ma solo il minimo necessario e la mia applicazione nulla di più!
(si ha abbiamo provata a ritagliarlo Linux... e abbiamo passati i successivi 10 anni ad aggiungerci pezzi! E' gonfio e non vi è nulla da fare...)


Altra news flash per le S.U.: il backporting è una pratica molto ben accetta, perché è prassi implicita nella strategia di un produttore che porta avanti varie versioni allo stesso tempo. Se non esistesse il backporting, la tua azienda dovrebbe spendere un botto di risorse per aggiornare tutti i sistemi.


Ma dai chi vuoi che me lo fa il backporting per Cent OS 5.4? Che dopo 2 anni manco si trovavono più i pacchetti nel sito ufficiale :D


Non credere che backporting su Windows o Mac o quel che è non esista. La ragione per cui le S.U. credono che non esista è che i bollettini degli aggiornamenti sono piuttosto opachi (per varie ragioni).

Solo che lì me lo fa la Microsoft o Apple non un branco di Scimmie Urlanti :Prrr:

Haiku è l'esempio più eloquente, ma ce ne sono altri.

Sulle caratteristiche / feature nulla da dire, ma questo deriva dal supporto che ha ricevuto e dagli sviluppatori che hanno scritto un sacco di codice.

In ogni caso in tutto ciò continua a sfuggirmi, da questo:

"la sua superiorità qualitativa sotto TUTTI gli aspetti importanti"

che avevi scritto, dove sarebbe dimostrata la superiorità qualitativa (e cosa intendi con ciò).
Ricordati che si parla del kernel. Poi molto dipende da cosa gli si aggiunge attorno.
Ma basta considerare quanti port stabili ha su differenti architetture, quanto sia versatile (da sistemi embedded a supercomputer usando fondamentalmente lo stesso kernel).
I suoi unici competitori sono sistemi operativi closed source con tutte le limitazioni che ne conseguono in termini di versatilità.
Inoltre basta ricordare che nonostante l'ampio successo commerciale su desktop, Windows ha dovuto continuamente inseguire Linux sul lato sicurezza e di come lo stesso kernel che gira su desktop e server giri su smartphone mentre si è visto che salti mortali ha fatto Microsoft(anche li insegundo e non raggiungendo).

L'unica similitudine in questo caso riguarda esclusivamente il meccanismo che fa uso di codici.

Per il resto, se pubblichi l'intero schema qualcuno potrebbe trovare il modo di aggirare o eliminare il blocco che fa uso dei codici.

Ricorda che se non sei uno che fa tutto da se, c'e' sempre un soggetto esterno che ha gli schemi del tuo sistema d'allarme o ha accesso ad esso anche se pensi di tener tutto segreto. ;)
Per questo è bene progettare il tutto pensando che un ipotetico ladro possa avere accesso agli schemi.

Credo che il punto sia questo: un algoritmo sicuro rimane tale pure se lo conoscono nel dettaglio tutti, in quanto di solito la sicurezza è data dalle caratteristiche matematiche dello stesso. Il problema sta nell'implementazione, che potrebbe contenere approssimazioni e/o errori. A quel punto, chi mi dice che la community lo noti prima dei malintenzionati?
Abbiamo già rimosso Heartbleed?

Hearbleed ha fatto notizia proprio perchè è un caso raro.

Appunto.
Basta andare a leggere e si capisce la sottovalutazione di Torvalds sull'importanza della sicurezza.

Se scrivi quanto sopra, di fatto stai ammettendo di avere una pessima comprensione della lingua inglese. :rolleyes:


Linux è usato in tutti i settori MENO quello principale, il desktop, dove ha percentuali da prefisso telefonico.

Forse per te i desktop sono il settore principale, ma se guardi server, dispositivi mobili ed embedded il quadro cambia. ;)
Inoltre il motivo per cui si usa WIndows sui desktop non sta nella qualità del S.O. ma nell'ecosistema (essenzialmente il software applicativo disponibile e la retrocompatibilità con software già in uso da decenni).

Linux è usato così tanto, ma solo nei settori dove la "human interface" non è veramente importante, semplicemente perchè C'E' GIA' ed è GRATUITO, non è necessario reinventarsi un SO da zero.

Lo sai vero, che Android gira su kernel Linux, vero ? ;)
Li la UI mi sembra un tantino rilevante.

La mentalità della comunità Linux è quella per cui fra dieci anni sarai ancora qui a chiederti come mai dal 2017 al 2027 nessun'anno è stato "l'anno di Linux".

La mentalità della comunità Linux è quella per cui non sto neppure a perdere tempo a discutere con un linaro, so già che vive fuori dal mondo e che continuerà a non saper distinguere tra software professionale e software da smanettoni (che non è la totalità in Linux ma è tanta parte). E dato che nel campo del software professionale ci lavoro da 34 anni, e da quindici nella sicurezza IT, credo proprio di avere le basi per capirlo.

Quindi, divertiti con Linux, se ti diverte. Mica voglio rompere il giocattolo a nessuno.
Io mi fermo qui.

Quindi dopo 34 anni di esperienza nel settore fai ancora confusione tra kernel e distribuzioni ? :rolleyes:

Se proprio vuoi giocarti la carta del "non riesco a convincerti con argomentazioni tecniche e quindi ricorro al LEI NON SA CHi SONO IO"
io posso solo rispondere con (falsa :Prrr: ) umiltà che ho "solo" un esperienza pluridecennale nello sviluppo software per sistemi operativi quali Windows (e prima ancora MS-DOS), Windows CE, Linux (Eh! Si, pure quello), Mac OS/X, Android, iOS più varie piattaforme proprietarie embedded e naturalmente baremetal.
Non stai parlando con un pivello o con un "linaro".

Ricordati che si parla del kernel. Poi molto dipende da cosa gli si aggiunge attorno.
Ma basta considerare quanti port stabili ha su differenti architetture, quanto sia versatile (da sistemi embedded a supercomputer usando fondamentalmente lo stesso kernel).
I suoi unici competitori sono sistemi operativi closed source con tutte le limitazioni che ne conseguono in termini di versatilità.
Ma tutto ciò non ha nulla a che vedere con la "qualità" di cui parlavi prima. Si tratta di feature/caratteristiche, peraltro ottenuto grazie alla diffusione & manovalanza di cui ha goduto Linux in tutti questi anni.

La qualità della code base è quella di cui si lamenta lo stesso Torvalds. Non io. ;)
Inoltre basta ricordare che nonostante l'ampio successo commerciale su desktop, Windows ha dovuto continuamente inseguire Linux sul lato sicurezza e di come lo stesso kernel che gira su desktop e server giri su smartphone mentre si è visto che salti mortali ha fatto Microsoft(anche li insegundo e non raggiungendo).
Proprio perché abbiamo visto la storia di Microsoft, e di Android che è basato su Linux, non depone certo a favore di quest'ultimo.

E' da notare che in entrambi i casi le prime versioni del kernel fossero fork di quelli utilizzati in ambito desktop. Solo che Microsoft in poco tempo (WP 8) è passata al normale kernel, mentre Google ha impiegato diversi anni per ricongiungere il suo fork.

Inoltre WP è stato sempre molto più parco di risorse rispetto ad Android, anche dopo il passaggio alla versione 8.

Android adesso va bene soltanto perché anche nella fascia bassa ci sono dispositivi con GB di memoria e parecchi core.
Ricorda che se non sei uno che fa tutto da se, c'e' sempre un soggetto esterno che ha gli schemi del tuo sistema d'allarme o ha accesso ad esso anche se pensi di tener tutto segreto. ;)
Per questo è bene progettare il tutto pensando che un ipotetico ladro possa avere accesso agli schemi.
Sì, ma non cambia di una virgola quello che avevo detto prima: nessun folle pubblicherebbe l'intero schema d'allarme. Qui vige la security-through-obscurity proprio per cercare di mettere il più possibile i bastoni fra le ruote ai malintenzionati, che se li avessero farebbero certamente meno fatica a trovare falle sfruttabili.

Ho fatto l'esempio già diverse volte qui. Mettiamo che esistano due centrali nucleari col software di controllo del nocciolo direttamente accessibile da internet. Della prima avresti tutti gli schemi e il codice sorgente a disposizione, mentre della seconda assolutamente niente (e messaggi offuscati da terminale).
Da terrorista, preferiresti attaccare la prima o la seconda?

Sì, ma non cambia di una virgola quello che avevo detto prima: nessun folle pubblicherebbe l'intero schema d'allarme. Qui vige la security-through-obscurity proprio per cercare di mettere il più possibile i bastoni fra le ruote ai malintenzionati, che se li avessero farebbero certamente meno fatica a trovare falle sfruttabili.

Ho fatto l'esempio già diverse volte qui. Mettiamo che esistano due centrali nucleari col software di controllo del nocciolo direttamente accessibile da internet. Della prima avresti tutti gli schemi e il codice sorgente a disposizione, mentre della seconda assolutamente niente (e messaggi offuscati da terminale).
Da terrorista, preferiresti attaccare la prima o la seconda?

Se fossero entrambi accessibii da internet non farebbe differenza.
Denuncerei e farei licenziare i responsabili per negligenza criminale
perché avrebbero violato uno dei principi cardine della sicurezza di tali impianti.
Più che i terroristi il pericolo verrebbe da script kiddie che fanno danni a caso.

Ovviamente se si seguisse la security by obscurity nel secondo caso lo scopriremmo (forse) solo dopo che un patetico script kiddie ha mandato in fusione del nocciolo qualche reattore.

Il problema sta nell'implementazione, che potrebbe contenere approssimazioni e/o errori. A quel punto, chi mi dice che la community lo noti prima dei malintenzionati?


Nessuno, così come nessuno può assicurartelo nel caso del closed source. Soprattutto in un mondo in cui la sicurezza ha smesso di essere affare di curiosi e smanettoni ed è diventata arma in mano a grosse organizzazioni criminali e governi, i quali hanno fondi, specialisti, mezzi e spesso pure l'accesso ai sorgenti dei software closed source.

La differenza tra i due modelli, è che accesso al codice open ce l'hanno pure i ricercatori di sicurezza solitari e/o amatoriali. Ma anche quelli professionali spessissimo non hanno accesso ai sorgenti closed, cosa che invece accade per l'open.

Complessivamente l'open presenta un miglior punto di equilibrio tra buoni e cattivi.

Poi c'è il caso Linux, a cui bisogna aggiungere che si paga lo scotto di: architettura monolitica, uso di linguaggi bug prone, poca focalizzazione sulla sicurezza fin dall'inizio.

Guarda OpenBSD se vuoi capire che livello qualitativo ( in termini di sicurezza ) si può raggiungere con l'opensource.


Abbiamo già rimosso Heartbleed?

Eccezione che conferma la regola, ovvero un caso tanto unico ed eclatante da essere immediatamente catapultato agli onori delle cronache.

Nessuno, così come nessuno può assicurartelo nel caso del closed source. Soprattutto in un mondo in cui la sicurezza ha smesso di essere affare di curiosi e smanettoni ed è diventata arma in mano a grosse organizzazioni criminali e governi, i quali hanno fondi, specialisti, mezzi e spesso pure l'accesso ai sorgenti dei software closed source.

La differenza tra i due modelli, è che accesso al codice open ce l'hanno pure i ricercatori di sicurezza solitari e/o amatoriali. Ma anche quelli professionali spessissimo non hanno accesso ai sorgenti closed, cosa che invece accade per l'open.

Complessivamente l'open presenta un miglior punto di equilibrio tra buoni e cattivi.

Rimane comunque un discorso "teorico". Fermo restando che, in caso di software closed, l'unica via è e rimane il reverse engineering, che non è esattamente come poter leggere i sorgenti.

Poi c'è il caso Linux, a cui bisogna aggiungere che si paga lo scotto di: architettura monolitica, uso di linguaggi bug prone, poca focalizzazione sulla sicurezza fin dall'inizio.

Si paga lo scotto di Torvalds. Non mi pare che OpenBSD sia scritto in C#, eh... :D



Eccezione che conferma la regola, ovvero un caso tanto unico ed eclatante da essere immediatamente catapultato agli onori delle cronache.
Perché era un bug gravissimo, in un componente come OpenSSL, e per il numero di potenziali vittime. Mica perché era un caso raro.

Inoltre teniamo sempre presente che già 10 anni fa gli sviluppatori di Linux si erano accorti di questo "Dirty COW" ed avevano provato a porvi rimedio, ma il fix fu rimosso per altri problemi che introduceva.

Rimane comunque un discorso "teorico". Fermo restando che, in caso di software closed, l'unica via è e rimane il reverse engineering, che non è esattamente come poter leggere i sorgenti.

Non teorico ma statistico. Il reverse engineering puo' sembrare una cosa complicata, ma ci sono specialisti e strumenti per cui e' pane quotidiano.

E questo senza considerare il fatto che i sorgenti closed non sono affatto closed per talune entita'. Entita' che hanno incentivi economici e/o ideologici a sfruttarli a fini negativi.


Si paga lo scotto di Torvalds. Non mi pare che OpenBSD sia scritto in C#, eh... :D


Ovvio che e' scritto in C, ma se fosse scritto in Rust gli sviluppatori faticherebbero vari ordini di grandezza meno per mantenere gli stessi standard di sicurezza.

Chiaro che il discorso e' u po' campato in aria, visto che all'epoca o sceglievi C o C++ nella pratica. Cosi' come all'epoca i microkernel erano un disastro ( tranne rare eccellenze come Qnx Neutrino ), cosa assolutamente non vera oggi. I lavori di Liedtke ( L3 e L4 ) hanno completamente cambiato le carte in tavola.


Perché era un bug gravissimo, in un componente come OpenSSL, e per il numero di potenziali vittime. Mica perché era un caso raro.


Era anche un caso raro. Stiamo parlando, in questo thread, di un certo bug che, per quanto grave, e' pur sempre exploitabile solo da locale. Discorso ben diverso per Heartbleed.


Inoltre teniamo sempre presente che già 10 anni fa gli sviluppatori di Linux si erano accorti di questo "Dirty COW" ed avevano provato a porvi rimedio, ma il fix fu rimosso per altri problemi che introduceva.

Ovvio. Se si mantiene un'architettura monolitica e' questo il prezzo da pagare. Non puoi cambiare allegramente tutto quello che ti passa davanti, pena un disastro in termini di compatibilita' e regressioni.

E non ci piove che la comunita' Linux dovrebbe lavorare su questo punto, anche se ritengo che qualunque kernel non micro non e' minimamente da considerare ( compresi i pseudo-microkernel aka ibridi ).

Uso linux dal 97/98, slackware 3.2.
la qualita' si e' abbassata, e di molto.
linux e' partito dall'essere un sistema per un certo target (server e sistemi che abbisognano di robustezza) ad essere stato forzato a diventare un sistema desktop per tutti, a discapito della semplicita' della struttura, della stabilita' e della compattezza.
ormai da almeno 10 anni linux non e' piu' un sistema che si e' scavato una nicchia nei server e vuole rimanere stabile e pulito, ma e' andato dietro a windows, cercando di scimmiottarlo e di portarsi in casa dei suoi utenti.

infatti sento molti molti sysadmin, specialmente dopo systemd, dire che sono passati, in parte o in tutto, a bsd.


Ovvio che e' scritto in C, ma se fosse scritto in Rust gli sviluppatori faticherebbero vari ordini di grand


C e C++ se ben usati non sono assolutamente insicuri.
il problema e' che se si mette insieme codice scritto da 20 anni da uno con quello scritto oggi da un altro e con qualita' molto diverse (basta dare un'occhiata ai sorgenti, alcuni sono ben scritti, altri sembrano dei dump di /dev/urandom), finisci per trovarti, in un punto o nell'altro, qualcosa che non va.
sempre tenendo conto che spesso i contributi finiscono nel kernel senza essere verificati in maniera decente. guarda tutti i moduli che ha il kernel, ce ne sono a decine di assolutamente assurdi e inutili, ma che in molte distro vengono infilati nel kernel di default, che quasi nessuno cambia.

Rust e' bello finche' vuoi, ma i suoi problemi li ha, e comunque se milioni di righe di codice delle cazzate grosse come case le fai comunque.
io per sviluppare un kernel non penserei ad altro che a C.

Non stai parlando con un pivello o con un "linaro".

Con un pivello non no so, con un "linaro" certamente si.
Nel merito, non vale la pena rispondere.
Ci risentiamo tra dieci anni.

Stammi bene.

Non teorico ma statistico. Il reverse engineering puo' sembrare una cosa complicata, ma ci sono specialisti e strumenti per cui e' pane quotidiano.

E questo senza considerare il fatto che i sorgenti closed non sono affatto closed per talune entita'. Entita' che hanno incentivi economici e/o ideologici a sfruttarli a fini negativi.

Le entità che hanno direttamente accesso al codice sorgente, possono in*ularci pure con Linux, tranquillo. :D

Il reverse engineering sarà pure pane quotidiano degli specialisti, ma comunque rimane un livello di difficoltà superiore.


Ovvio che e' scritto in C, ma se fosse scritto in Rust gli sviluppatori faticherebbero vari ordini di grandezza meno per mantenere gli stessi standard di sicurezza.

Chiaro che il discorso e' u po' campato in aria, visto che all'epoca o sceglievi C o C++ nella pratica. Cosi' come all'epoca i microkernel erano un disastro ( tranne rare eccellenze come Qnx Neutrino ), cosa assolutamente non vera oggi. I lavori di Liedtke ( L3 e L4 ) hanno completamente cambiato le carte in tavola.

Boh, non so, appena ci sarà un OS scritto in Rust, ne riparleremo. :D

Sul resto concordo.


Era anche un caso raro. Stiamo parlando, in questo thread, di un certo bug che, per quanto grave, e' pur sempre exploitabile solo da locale. Discorso ben diverso per Heartbleed.


Ovvio. Se si mantiene un'architettura monolitica e' questo il prezzo da pagare. Non puoi cambiare allegramente tutto quello che ti passa davanti, pena un disastro in termini di compatibilita' e regressioni.

E non ci piove che la comunita' Linux dovrebbe lavorare su questo punto, anche se ritengo che qualunque kernel non micro non e' minimamente da considerare ( compresi i pseudo-microkernel aka ibridi ).

Il problema di Dirty COW è che è sfruttabile in, praticamente, OGNI distro attualmente in circolazione; e comunque rimane parecchio grave, non minimizziamolo.

La comunità oggi può fare poco, secondo me. O qualcuno si sveglia e decide di dare un violenta ripulita al kernel, oppure si continuerà a rattoppare il possibile, aggiungendo moduli ecc ecc.

Ma l'andazzo lo decide comunque Torvalds, quindi boh, chissà.

Se fossero entrambi accessibii da internet non farebbe differenza.
Sicuro? Quindi eventuali hacker impiegherebbero lo stesso tempo a farle saltare? :fiufiu:
Denuncerei e farei licenziare i responsabili per negligenza criminale
perché avrebbero violato uno dei principi cardine della sicurezza di tali impianti.
Più che i terroristi il pericolo verrebbe da script kiddie che fanno danni a caso.
Non è questo il punto. Era soltanto un esempio per mostrare le differenze in termini di sicurezza fra security through obscurity e l'open source.
Ovviamente se si seguisse la security by obscurity nel secondo caso lo scopriremmo (forse) solo dopo che un patetico script kiddie ha mandato in fusione del nocciolo qualche reattore.
Appunto: forse. That's it! :cool:

Sicuro? Quindi eventuali hacker impiegherebbero lo stesso tempo a farle saltare? :fiufiu:
No nel primo caso il sistema verrebbe modificato a furor di popolo e quindi non cisarebbe stato il problema. ;)

Non è questo il punto. Era soltanto un esempio per mostrare le differenze in termini di sicurezza fra security through obscurity e l'open source.

Solo che era basato su presupposti errati, entrambe le alternative erano dannatamente insicure per gli standard richiesti per gli impianti nucleari e quella in cui si seguiva la security by obscurity non sarebbe stata evidenziata e corretta.

Appunto: forse. That's it! :cool:

Forse nel senso che una fusione del nocciolo cancellerebbe le tracce, molto utile per chi ha realizzato il sistema "di insicurezza", ma decisamente negativo per chi avrebbe preferito un impianto DAVVERO sicuro. ;)

Con un pivello non no so, con un "linaro" certamente si.
Nel merito, non vale la pena rispondere.
Ci risentiamo tra dieci anni.

Stammi bene.

Se fosse la descrizione di una scena mancherebbe solo
"sbatte rumorosamente la porta mentre esce". :rolleyes:

No nel primo caso il sistema verrebbe modificato a furor di popolo e quindi non cisarebbe stato il problema. ;)

Solo che era basato su presupposti errati, entrambe le alternative erano dannatamente insicure per gli standard richiesti per gli impianti nucleari e quella in cui si seguiva la security by obscurity non sarebbe stata evidenziata e corretta.

Forse nel senso che una fusione del nocciolo cancellerebbe le tracce, molto utile per chi ha realizzato il sistema "di insicurezza", ma decisamente negativo per chi avrebbe preferito un impianto DAVVERO sicuro. ;)
Continui a girarci attorno per non volerlo ammettere: mi ricordi Fonzie quando deve dire "ho sbbbbbbaglllllattttttttt". :D

A parte gli scherzi, il nocciolo (non del reattore :asd:) è che un malfattore che volesse far danni avrebbe sicuramente la vita più facile con un sistema aperto anziché con uno chiuso (incluso il concetto di reverse engineering).

Sic et simpliciter. :read:

Al di là del titolo senzionalistico è positivo che il tutto sia stato rimediato.
Del resto in ambito opensource esiste trasparenza, a differenza dell'ambito proprietario, dove accadono cose simili, però non si dice ...
La complessità dei software non consentirà mai di realizzare soluzioni esenti da rischi ma speriamo che con il tempo sia possibile ridurne o almeno limitarli nel tempo.

Continui a girarci attorno per non volerlo ammettere: mi ricordi Fonzie quando deve dire "ho sbbbbbbaglllllattttttttt". :D

A parte gli scherzi, il nocciolo (non del reattore :asd:) è che un malfattore che volesse far danni avrebbe sicuramente la vita più facile con un sistema aperto anziché con uno chiuso (incluso il concetto di reverse engineering).

Sic et simpliciter. :read:

Il mio punto è che nel primo caso con lo schema accessibile il problema sarebbe stato eliminati alla radice ben prima che qualcuno potesse farne uso, mentre nel secondo sarebbe reastato li, pronto per essere trapanato dal primo script kiddie che capita ben prima che da qualche cyberterrorista desideroso di causare un incidente nucleare.

Inoltre basta guardare come funzionano concretamente le cose per vedere come la security by obscurity sia illusoria, sia nell'ambito del software che in altri settori.

Nota inoltre che anche la licenza GPL permette di limitare l'accesso ai sorgenti se si ritiene utile la cosa, ma con il vincolo di permetterne l'accesso alle entita legali utilizzatrici a cui viene concesso l'uso.
Ma non si tratta di "security by obscurity" perché le entità legali clienti hanno sempre pieno accesso.

Il motivo per cui l'accesso ai sorgenti di Linux è totalmente aperto è perché complessivamente ha più senso nel caso specifico e guardacaso poi per quel che riguarda il supporto a lungo termine sono i moduli closed source a creare i problemi maggiori.

Non vi viene il dubbio che sono gli stessi malintenzionati a introdurre volutamente bug dentro al kernel Linux? Tanto visto come controllano bene le cose passa tutto senza problemi :D

Un po' di tempo fa ce ne era stato un altro che per sbaglio faceva sì che le chiavi super sicure di SSH fossero tutte cifrate con "viva-la-foca" ricordate? Anche lì se ne erano accorti dopo quanto? 5 - 6 anni?

Del resto vedete c'entrano sempre ste scimmie:
https://www.peereboom.us/assl/assl/html/openssl.html

se uno "butta" del codice così dentro al kernel, ma chi ci capisce qualcosa?
Io resto della mia idea OK il C era l'unica cosa che esisteva negli anni '90 quando Torvalds fece Linux (ed essendo una copia spudurata di Unix non è che potesse usare altro che il C e tecnologie degli anni '70), ma oggi se non altro per una questione di sicurezza andrebbe seriamente superato.

Rust - oggettivamente - mi sembra quasi più incasinato del C:

1. Hanno di nuovo fatto "pasticci" con il tipo stringa: ce ne sono almeno 3 - 4
2. Ci sono i puntatori: SEGFAULT appena ti gira dall'altra parte
3. Se ricordo bene ci sono 3 - 4 modi diversi per passare un "oggetto" ad una funzione (mutabile, non mutabile, ?)


alla fine UTF-16 usato da C# e Java non è poi così male, io resto dell'idea che i caratteri Cinesi non sono davvero caratteri, ma "immagini" quindi chissene se non sono rappresentabili! S'imparassero ad usare l'alfabeto (non dico quello "giusto" quello latino, va bene anche quello arabo, ma basta con sti ideogrammi :eek:)

Il mio punto è che nel primo caso con lo schema accessibile il problema sarebbe stato eliminati alla radice ben prima che qualcuno potesse farne uso, mentre nel secondo sarebbe reastato li, pronto per essere trapanato dal primo script kiddie che capita ben prima che da qualche cyberterrorista desideroso di causare un incidente nucleare.

Inoltre basta guardare come funzionano concretamente le cose per vedere come la security by obscurity sia illusoria, sia nell'ambito del software che in altri settori.
E questo bug scoperto dopo NOVE anni dove lo metti? Mi pare evidente che l'essere open e il codice visto da milioni di occhi non sia servito.

Quanto al caso del codice chiuso, prima il bug sfruttabile lo devi trovare, e non è certo cosa facile.
Nota inoltre che anche la licenza GPL permette di limitare l'accesso ai sorgenti se si ritiene utile la cosa, ma con il vincolo di permetterne l'accesso alle entita legali utilizzatrici a cui viene concesso l'uso.
Ma non si tratta di "security by obscurity" perché le entità legali clienti hanno sempre pieno accesso.
Se un codice è coperto da GPL, chiunque può reclamare il diritto all'accesso ai sorgenti.
Il motivo per cui l'accesso ai sorgenti di Linux è totalmente aperto è perché complessivamente ha più senso nel caso specifico
Beh, se usa la GPL è giocoforza che i sorgenti siano sempre disponibili.
e guardacaso poi per quel che riguarda il supporto a lungo termine sono i moduli closed source a creare i problemi maggiori.
Causa API e/o ABI instabili.

Per quanto riguarda Rust, all'epoca (quasi 5 anni fa) scrissi un commento sul forum di programmazione.it (http://programmazione.it/index.php?entity=eitem&idItem=48306&idPage=1), ma non so se qualcosa sia cambiata da allora.

Spero che abbiano introdotto delle keyword a misura di essere umano, allora. :D

Riguardo al documento di cui hai postato il link, sono senz'altro d'accordo sull'uso di UTF-8 per quanto riguarda lo storage.

Mentre sono contrario nell'uso all'interno di un linguaggio programmazione, dove preferisco nettamente l'approccio introdotto con Python 3.3, che prevede la memorizzazione interna come byte (per testo Latin-1), UTF-16 o UTF-32 a seconda dei dati, con conversione automatica e trasparente fra questi formati.
Questo perché le operazioni di calcolo della lunghezza, scansione / ricerca, nonché indicizzazione di una stringa sono assolutamente comuni e verrebbero enormemente penalizzate adottando UTF-8 internamente, contrariamente al tentativo di minimizzazione attuato nel documento.
Evidentemente chi ha scritto il documento non è un programmatore Python, e dunque non sa quanto comuni siano queste operazioni. E non ha nemmeno idea di come internamente siano implementate e gestite le stringhe in Python 3.3+.

Infine, sono contrario all'imposizione dell'uso del solo carattere LF (\n) come marcatore di fine stringa. E' una decisione che fu presa dai creatori di Unix & del linguaggio C esclusivamente per risparmiare un byte, semplificando le operazioni di ricerca del marcatore, e di fatto senza differenziare file testuali e binari.
L'ASCII prevede fin dalla sua origine l'uso di CR quale "ritorno carrello" (per posizionarsi sulla prima colonna) e LF per avanzare di una riga.

E questo bug scoperto dopo NOVE anni dove lo metti? Mi pare evidente che l'essere open e il codice visto da milioni di occhi non sia servito.
Dovresti sapere benissimo che il problema della correttezza del codice non ha una soluzione in generale, ed il problema dell'assenza di exploit è più complesso di questo.
L'approccio open source non è la soluzione al problema, non lo può essere, è invece un approccio che si è dimostrato più efficace rispetto ad altre alternative in un numero più vasto di casi.
Sia per il discorso di più occhi che tengono sotto controllo la qualità del codice, lo correggono e lo fanno evolvere, sia perchè ci sono minori incentivi a trascurare le fonti di problemi a medio e lungo termine.

Si parla tano di quel bug perchè è un caso molto meno frequente rispetto a qual che succede con sistemi closed source, vedi nuovamente Windows ed il numero ancora maggiore di exploit di quel tipo in quantitàe persistenza nell'ecosistema.

Quanto al caso del codice chiuso, prima il bug sfruttabile lo devi trovare, e non è certo cosa facile.

E' ampiamente dimostrato nei fatti che con software closed source le bug sfruttabili sono molte di più, in parecchi casi si è arrivati al punto che la stessa bug banale si ripresentava più volte nonostante i patch perche questi non correggevano la fonte originale del problema
(in particolare Internet Explorer ed il suo codice di parsing degli URL).
Il motivo è che con la scusa del "tanto i malfattori non vedranno mai il codice" spesso ci si ferma a "il bug non sembra presentarsi più" ed altrettanto spesso anche di fronte a segnalazioni multiple in assenza di codice malevole che ne faccia uso non le si da sufficiente priorità.


Se un codice è coperto da GPL, chiunque può reclamare il diritto all'accesso ai sorgenti.

Beh, se usa la GPL è giocoforza che i sorgenti siano sempre disponibili.

No. Come spiegato qui:
https://www.gnu.org/licenses/gpl-faq.en.html#GPLRequireSourcePostedPublic
Does the GPL require that source code of modified versions be posted to the public?

The GPL does not require you to release your modified version, or any part of it. You are free to make modifications and use them privately, without ever releasing them. This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization.

But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program's users, under the GPL.

Thus, the GPL gives permission to release the modified program in certain ways, and not in other ways; but the decision of whether to release it is up to you.

Notare che "utente" è l'entita legale utente, non una persona qualsiasi che usa quel software per conto dell'entità legale.

Causa API e/o ABI instabili.

Le API possono cambiare, succede anche con Windows, nel caso di Linux per la massima portabilità e supporto a lungo termine si consiglia di rilasciare i sorgenti, se invece si sceglie l'approccio closed-source l'onere sta al manutentore che lavora per l'azienda che li realizza.
Del resto un sacco di periferiche che funzionavano su XP non sono più state supportate da Vista in su perchè i produttori non rilasciavano i driver aggiornati o Microsoft si era stufata di supportare certi dispositivi per conto suo.

Le ABI sono legate all'hardware su cui gira il tutto, e visto che Linux supporta un sacco di architetture diverse è ovvio che un modulo kernel compilato per x86 ha problemi su ARM, idem per ecosistemi hardware in cui per vari moditivi non vi è un unica ABI.

In altre parole nel caso peggiore con i moduli closed source si ricade nel caso "Windows"
mentre se sono open source ci sono molte più possibilitàdi supporto e manutenzione a lungo termine.

Si, Ok.. Ma python si colloca in un segmento particolare in cui il text-processing e' fondamentale.. e non e' sempre possibile adottare questa strategia in tutti i contesti oltre ad avere dei lati negativi... se faccio un append a centinaia di MB in Latin-1 di un carattere non-BMP python dovra' riallocare tutta la memoria per UTF-32 e trasformare-copiare i dati nella nuova stringa, e questo puo' non essere accettabile in molti contesti.
In molti non so, perché anche i test / statistiche che hanno riportato brevemente c'è la presenza più caratteri non ASCII.

Diciamo che il caso che hai citato è molto più teorico che pratico, in quanto normalmente c'è una certa mistura di caratteri che non stanno in Latin-1 e/o UTF-16.

Peraltro la scelta di usare Latin-1 come codifica base / di partenza, anziché ASCII, contribuisce a minimizzare notevolmente l'uso di UTF-16 o, peggio, UTF-32 in diversi paesi del mondo. Al contrario di UTF-8, che va bene soltanto per testi puramente ASCII.
Inoltre anche gli internals si complicano visto che devono gestire questi tre casi separatamente. In questo modo oltre a spendere tempo macchina si alloca pure quattro volte la memoria iniziale per un 'singolo' carattere non-BMP. E comunque anche loro dicono (riferendosi soprattutto al C++) che ci sono delle eccezioni nell'utilizzo di UTF-8
Te ne dico una sugli internal di Python: qualunque "namespace" (variabili di modulo, classe, istanza di oggetto) è basato sui dizionari, le cui chiavi sono di di tipo stringa in questo caso. Per cui immaginare quanto siano usate le stringhe internamente, anche quando nel tuo codice stai usando altri tipi di dato.
Comunque l'articolo e' stato ispirato da una discussione su Stackoverflow del creatore di Boost.Locale, quindi non proprio lo scemo del villaggio. E anche gli altri che hanno scritto/ contribuito all' articolo non mi sembrano degli sprovveduti.
Ho apprezzato l'analisi, ma da pythonista di lunga data nonché esperto della sua VM, ho trovato i riferimenti a Python non pertinenti / oggettivi sulla reale situazione. Tutto qui.
Le loro motivazioni in particolare mi sembrano abbastanza valide:

Tutte cose che anche con UTF-32 non vengono risolte. Che poi molti (la maggior parte?) non si curino di questi dettagli non rende la discussione invalida.
Ehm. No. UTF-32 risolve praticamente tutti i problemi, a parte il concetto / percezione di "carattere", come puoi leggere dal documento.
Sugli internal di python non mi pronuncio perche' non li conosco. Ma anche levando la parte a riguardo(che e' una minima parte) tutto l'impianto resta valido. (in ogni caso il discorso del triplice encoding interno c'e')
L'impianto è sicuramente valido, ma per me la soluzione rimane l'adozione di un tipo stringa come quello di Python per quanto riguarda le API dei s.o. (e purtroppo Windows è stato pioniere nel bene e nel male, come descritto) e internamente ai linguaggi.

Peraltro con Python è comunque possibile operare ugualmente con byte grezzi, che poi fino alla versione 2.x era proprio il tipo stringa predefinito. Questo per chi vuole la massima libertà / flessibilità, e qui ci rientra l'eventuale gestione di UTF-8 a la Rust.
La sintassi di Rust puo' piacere o non piacere, ma ritengo la lunghezza stringata delle keywords un non problema(o almeno, non mi ci focalizzo piu' di tanto). E' solo una questione di abitudine, e alla lunga avere piu' spazio per i nomi dei metodi/interfacce/moduli rende il codice piu' leggibile. Sicuramente Rust ha una curva di apprendimento ripida e ha come target un certo tipo di programmatori.
Sicuramente, come tutti i nuovi linguaggi, si deve perdere tempo ad apprenderli.

Ma ho dato un'occhiata al linguaggio, e le obiezioni che ho posto all'epoca sono le stesse: nulla è cambiato da quel punto di vista.
EDIT:

Comunque vista la natura di Rust di operare a 'basso livello', sicuramente l'approccio 'a la python' non mi sembra la via corretta. UTF-8 in questo caso credo sia la scelta piu' sensata.
Con Python, come già detto, si possono fare entrambe le cose: usi i bytearray, e fai esattamente le stesse cose di Rust. ;)

Dovresti sapere benissimo che il problema della correttezza del codice non ha una soluzione in generale, ed il problema dell'assenza di exploit è più complesso di questo.
Già: c'è il famigerato problema dell'arresto. :D
L'approccio open source non è la soluzione al problema, non lo può essere, è invece un approccio che si è dimostrato più efficace rispetto ad altre alternative in un numero più vasto di casi.
Sia per il discorso di più occhi che tengono sotto controllo la qualità del codice, lo correggono e lo fanno evolvere, sia perchè ci sono minori incentivi a trascurare le fonti di problemi a medio e lungo termine.
Vabbé, e il bug di OpenSSH dove lo mettiamo?

Sono chiare dimostrazioni dell'ovvietà: l'avere a disposizione il codice visionabile non è una garanzia di "qualità".
Si parla tano di quel bug perchè è un caso molto meno frequente rispetto a qual che succede con sistemi closed source, vedi nuovamente Windows ed il numero ancora maggiore di exploit di quel tipo in quantitàe persistenza nell'ecosistema.
Mi pare normale: è (era) il sistema più diffuso, e dunque il più ricercato dai malintenzionati.
E' ampiamente dimostrato nei fatti che con software closed source le bug sfruttabili sono molte di più, in parecchi casi si è arrivati al punto che la stessa bug banale si ripresentava più volte nonostante i patch perche questi non correggevano la fonte originale del problema
(in particolare Internet Explorer ed il suo codice di parsing degli URL).
Il motivo è che con la scusa del "tanto i malfattori non vedranno mai il codice" spesso ci si ferma a "il bug non sembra presentarsi più" ed altrettanto spesso anche di fronte a segnalazioni multiple in assenza di codice malevole che ne faccia uso non le si da sufficiente priorità.
Come sai, i bug non sono tutti uguali. E vengono corretti in base alle priorità.

Anche Linux ha ancora tanti bug aperti. Anche da parecchi anni. Perché non vengono corretti?
No. Come spiegato qui:
https://www.gnu.org/licenses/gpl-faq.en.html#GPLRequireSourcePostedPublic

Notare che "utente" è l'entita legale utente, non una persona qualsiasi che usa quel software per conto dell'entità legale.
Appunto: basta che chi riceve il binario faccia richiesta dei sorgenti. E quindi può essere chiunque.
Le API possono cambiare, succede anche con Windows, nel caso di Linux per la massima portabilità e supporto a lungo termine si consiglia di rilasciare i sorgenti, se invece si sceglie l'approccio closed-source l'onere sta al manutentore che lavora per l'azienda che li realizza.
Del resto un sacco di periferiche che funzionavano su XP non sono più state supportate da Vista in su perchè i produttori non rilasciavano i driver aggiornati o Microsoft si era stufata di supportare certi dispositivi per conto suo.
Mai negato che ci possano essere cambiamenti maggiori / radicali al driver model, mi pare. Ma all'interno di un driver model c'è stabilità.
Le ABI sono legate all'hardware su cui gira il tutto, e visto che Linux supporta un sacco di architetture diverse è ovvio che un modulo kernel compilato per x86 ha problemi su ARM, idem per ecosistemi hardware in cui per vari moditivi non vi è un unica ABI.
Hai dimenticato anche i casi in cui compili il kernel con certi parametri (uno a caso: SMP o non-SMP), per cui un driver compilato per la stessa architettura non funziona.

O, viceversa, un driver che richiede un kernel compilato con certi parametri non funziona su un kernel a cui mancano.
In altre parole nel caso peggiore con i moduli closed source si ricade nel caso "Windows"
mentre se sono open source ci sono molte più possibilitàdi supporto e manutenzione a lungo termine.
Non mi pare proprio: vedi sopra.

Avevo letto bene il tipo stringa di rust non è venuto!


Strings are always valid UTF-8. This has a few implications, the first of which is that if you need a non-UTF-8 string, consider OsString. It is similar, but without the UTF-8 constraint. The second implication is that you cannot index into a String:


let s = "hello";

println!("The first letter of s is {}", s[0]); // ERROR!!!


Quindi abbiamo 3 tipi diversi di stringhe una che assomiglia al "char *" del C, questa che sembra un oggetto, ma è incompleta visto che manca l'operatore [ ] (e mica l'ho capito perché vogliono costringere al kludge di usare chars() per ottenere l'array di caratteri!) e infine quella dell'OS (in Linux quella specie di UTF-8[1] che supporta solo ASCII in Windows UFT-16). Insomma un pasticcio come in C il programmatore inesperto si troverà a passare una stringa al C senza fare le opportune conversioni e a beccarsi i caratteri "speciali" codificati sbagliati...

Riguardo alle stringhe "compresse" oltre che in Python esistono anche nell'ultima versione di Java (anche non hanno fatto il salto ad UTF-32 ci sono solo Latin1 e UCS2) e si sta pensando di implementarle anche in C#:

https://github.com/dotnet/coreclr/issues/7083

invece l'esperimento dentro CoreFxLabs chiamato Utf8String va ucciso a suon di baccate è la via del C / Rust confusione e null'altro :eek:

[1] il tipo char * in C non ha definito l'encoding nelle versioni moderne di Linux dovrebbe essere sempre UTF-8, ma nella realtà beh non si sa quale encoding usa Linux :p anche un semplice carattere "è" rischia di essere rappresentano come bratta (e tipicamente lo è)!

Vabbhe a dirla tutto per parlare di Rust bisognerebbe parlarne in un thread apposito.

Quello che volevo dire è che un linguaggio deve essere potente, ma anche semplice da usare se no anche il programmatore "esperto" rischia di cascare in delle trappole.

Riguarda [ ] ho parlato apposta di operatore mica volevo l'accesso diretto al puntatore char * interno come in C! Volevo poter fare semplicemente l'iterazione come in Java / C# su una stringa avendo l'illusione che fosse un array di caratteri (frega nulla se Rust deve fare la conversione tra UTF8 / UFT32 ogni volta se hanno sbagliato a definire char e stringhe come cose diverse...).

Sì la conversione tra la stringa Rust e quella dell'OS sottostante dovrebbe essere fatto a livello di unsafe call come beh fa C# con il marshalling.

Sei sicuro che in codice unsafe non puoi tranquillamente fare una conversione tra str e char * del C senza prima forza l'encoding del sistema? Secondo me anche un programmatore esperto finirà per cascarci magari sul suo PC Linux che usa UTF-8 ed è configurato correttamente (che c*lo) poi gli funzionerà pure, ma su quello dell'utente no (altro Linux o Windows che vorrebbe UTF-16 o magari qualche strana codepage relitto del DOS!).

Su questa cosa non ci hanno proprio ragionato dai e poi sono usciti col kludge del OSString così uno continua a chiedersi, ma quale tipo string devo usare? Boh...

Ma come? Linux non si vanta di NON dover essere mai riavviato

Mah, a meno che l'IA non abbia fatto un salto di qualità, dubito che un kernel possa "vantarsi". :boh:

Intendi forse che io abbia scritto questo? Mah, se rileggi vedrai che non ho scritto nulla di ciò.
O intendi che la comunità dei programmatori/amministratori Linux sostenga questo?
Nessuna persona sana di mente si sognerebbe di sostenere che un qualsiasi O/S non vada mai riavviato. :read:

Data questa e tutto il resto di confusioni/inesattezze/esagerazio del post, capirai bene che non è possibile fare una discussione precisa con persone che soffrono di disturbi dell'attenzione. Buon lavaggio :-)

Certo che rispondere facendo finta di non aver visto la frase "almeno per gli utenti evoluti" non fa fare bella figura. Sappilo.

CentOS è un sistema robusto, esiste anche in installazione desktop, si basa sull'unica distribution contemporaneamente diffusa e veramente professionale ed ha una interfaccia semplice da usare e non troppo diversa da quella di Windows (o di qualsiasi GUI decente), che nonostante sia uno standard non tutte le distribuzioni hanno per default.

Se poi uno vuole soffrire ulteriormente ed usare Unity, perchè Ubuntu è il Linux "per uso desktop/domestico", faccia pure. Cavoli suoi. Ma certo non lo consiglierei a nessuno, come non consiglierei per esempio Arch o SUSE. Al massimo, Mint.

Ma, al super-massimo, gli direi: lascia perdere, lascia perdere pure CentOS, spendi 150 euro per Windows e vivi tranquillo con un prodotto professionale fatto apposta per te e non per gli smanettoni.

e adesso vinci il premio nobel.

Certo che rispondere facendo finta di non aver visto la frase "almeno per gli utenti evoluti" non fa fare bella figura. Sappilo.

CentOS è un sistema robusto, esiste anche in installazione desktop, si basa sull'unica distribution contemporaneamente diffusa e veramente professionale ed ha una interfaccia semplice da usare e non troppo diversa da quella di Windows (o di qualsiasi GUI decente), che nonostante sia uno standard non tutte le distribuzioni hanno per default.

Se poi uno vuole soffrire ulteriormente ed usare Unity, perchè Ubuntu è il Linux "per uso desktop/domestico", faccia pure. Cavoli suoi. Ma certo non lo consiglierei a nessuno, come non consiglierei per esempio Arch o SUSE. Al massimo, Mint.

Ma, al super-massimo, gli direi: lascia perdere, lascia perdere pure CentOS, spendi 150 euro per Windows e vivi tranquillo con un prodotto professionale fatto apposta per te e non per gli smanettoni.

Guarda che Ubuntu non è solo con Unity, ci sono anche le varianti con altri DE... tra cui GNOME (ovvero quello predefinito di CentOS)

Le distribuzioni basate su Ubuntu sono in assoluto le migliori per gli utenti alle prime armi, non tanto perché sia migliore di suo paragonata a CentOS ma per il fatto che molti programmi vengono distribuiti in pacchetti .deb (ad esempio sulle rpm-based ad esempio per spotify, vlc e steam ti devi affidare a repo esterni non ufficiali in quanto non presenti quelli ufficiali) ed offre una maggiore facilità d'installazione dei driver video

Se poi consideriamo le procedure di upgrade da terminale per aggiornare alla versione successiva direi che ogni dubbio viene tolto sul suo scopo
https://wiki.centos.org/TipsAndTricks/CentOSUpgradeTool
https://liquidat.wordpress.com/2014/07/17/howto-upgrading-centos-6-to-centos-7/
e, sopratutto basta guardare la sezione HowTo e come sia piena di guide specifiche per server e co.
https://wiki.centos.org/HowTos

CentOS è una distribuzione per il settore enterprise(e non a caso CentOS è l'acronimo di Community ENTerprise Operating System) dove solitamente vi è presente il sistemista che si occupa della manutenzione e sa dove mettere le mani, punto... se poi uno vuole fare o improvvisarsi sistemista anche a casa ed usarla in ambito desktop/domestico, scelta sua e libero di farlo... ma evitiamo di farla passare per tale

Si, ma in molti contesti questo e' inaccettabile come comportamento di default anche se si presenta raramente. Per alcuni linguaggi il fatto di avere performance predicibili e' quasi piu' importante di avere l'implementazione piu' veloce di defau;t. (che poi basta una libreria per ovviare)
Qui non stiamo parlando di scrivere un s.o., per cui questo tipo di comportamento è accettabile, visto che è estremamente comune. Ma ne parlo meglio dopo.
Ma perche'?? UTF-8 e' stato creato proprio per estendere ASCII. Usarlo solamente in contesti in cui si deve codificare ASCII non ha il minimo senso.
Perché... non è quello di cui stavo parlando in quel preciso contesto, dove mi riferivo al fatto che l'adozione del Latin-1 come base (in pratica per rappresentare tutti i caratteri Unicode da \u00 a \uFF), che sono in assoluto i più frequenti, consente di usare molto spesso un solo byte per carattere.

Per contro, con UTF-8 con un solo byte riesci a rappresentare soltanto il set ASCII (da \u00 a \u7F), e dunque basta un qualunque altro carattere per sforare e richiedere almeno un altro byte.

Ora, se tieni conto che col Latin-1 copri le esigenze di tutte le americhe, e buona parte dell'Europa, capisci che la soluzione adottata da Python 3.3 non sia affatto così malvagia. Tutt'altro. Ed ha un enorme vantaggio rispetto a quella UTF-8, perché si rivela più densa. Peccato che nel documento non abbiano fatto anche dei test usando Latin-1 come codifica (ove possibile).

Dulcis in fundo, se vai a vedere il modo in cui è stata ideato l'UTF-8, ti rendi conto che il comitato che l'ha realizzato ha impiegato una codifica abbastanza dispersiva, visto che si sarebbe potuto fare di molto meglio (in particolare racchiudere la maggioranza dei casi in 2 soli byte, anziché 2 e 3 byte attuali. E racchiudere tutti i code point in soli 3 byte massimi, anziché 3 o 4 byte). E oltre a essere dispersiva / meno densa, è pure di più difficile da de/codificare.
Ehm no, gli esempi tratti dall'articolo che ho quotato dicono proprio il contrario. Senza contare che UTF-32 usa un sacco di spazio.
Non mi pare di aver detto in contrario sul maggior spazio usato da UTF-32, ma gli esempi che hai riportato dall'articolo non si applicano, e mi spiego meglio.

I 3 punti che hai citato riguardano il problema di input & renderizzazione dei glifi, che non è strettamente legato alla codifica utilizzata. Ma certamente possiamo dire che certe codifiche aiutano in questi compiti, e sicuramente è quello che UTF-8 non fa, mentre codifiche a lunghezza fissa, invece, aiutano.
Ripeto. Su un linguaggio che opera di basso livello (ma anche semplicemente che non abbia un'astrazione elevata come in python) non puoi avere questo comportamento 'opaco' in cui le stringhe trasformano automagicamente la loro rappresentazione interna. In questo python non e' peggio ne meglio di Rust. Si rivolge solo a un'utenza differente. Anche adottare una soluzione del genere per le API del SO mi sembra poco azzeccata, visto che in questo modo taglieresti automaticamente il settore bassa latenza/realtime per quel SO.
Rust non è affatto un linguaggio di basso livello, visto che anch'esso fa uso della riallocazione di zone di memoria. Esempio: il tipo Vec, che essendo dinamico esegue in maniera trasparente il ridimensionamento del buffer di memoria utilizzato.

Finché mi parli di C, dove la gestione della memoria la devi realizzare a manina, e hai sostanzialmente tutto sotto controllo, ti do ragione. Ma Rust che ha oggetti dinamici e garbage collection, direi proprio di no: non è un linguaggio di basso livello, ma al contrario è abbastanza di alto livello.

Quindi, come vede, condivide lo stesso comportamento di Python e di altri linguaggio.

E per inciso, il comportamento delle stringhe di Python 3.3 non è affatto opaco. Tutt'altro. Risulta, invece, ben definito e sai esattamente cosa capita quando gestisci stringhe ASCII, Latin-1, UTF-16, e UTF-32. Questo a basso livello, visto che per il programmatore tutto ciò risulta perfettamente trasparente.

Ma rispetto a Rust ha l'innegabile vantaggio di poter eseguire le operazioni di cui sopra (lunghezza e accesso casuale) di gran lunga più velocemente, perché tutte le codifiche (anche l'UTF-16 / UCS-2) sono a lunghezza fissa.
L'unica cosa era al limite UTF-8... Se poi non studi un linguaggi perche' non ti piacciono le keywords de gustibus, per me questo aspetto riveste un'importanza piu' che secondaria rispetto ai concetti che il linguaggio ingloba. Senza contare che anche in python le keywords mi sembrano abbastanza stringate, quindi si, penso sia proprio abitudine.
Non c'è paragone fra Python e Rust: anche le keyword più semplici in Python sono leggibili.

Comunque è solo quello: è che in generale, e come già detto nel vecchio commento, le scelte di Rust (di cui le keyword sono solo un esempio) è un linguaggio poco leggibile, e per un linguaggio nuovo, pensato per la sicurezza, questo mi pare un grosso, madornale, errore da parte dei progettisti.
Beh anche con Rust ti puoi scrivere (se non c'e' gia') una libreria che ha lo stesso identico comportamento delle stringhe di python. Ma avere un tipo cosi' opaco a la python alla base di un linguaggio di basso livello non ha senso.
Vedi sopra. Poi un conto è una libreria, e un conto avere dei tipi predefiniti che sono first citizen in Python, con tutti i vantaggi del caso.

Comunque c'è da dire che se c'è una cosa per cui Python è famoso, è l'immediatezza e la flessibilità nella manipolazione di stringhe e testi in generale, in cui eccelle. Questo è uno dei suoi domini, e avendolo usato da 12 anni ormai, posso dire con assoluta certezza che le operazioni di cui sopra sono decisamente comuni, e dunque meritano di essere velocizzate.

Rust non offre la stessa flessibilità, ma è anche vero che è nato per altro, e dunque confrontare i due linguaggi basandosi soltanto su questo particolare lascia il tempo che trova.

Lasciamo che vengano utilizzati in base alle loro peculiarità.

Appunto: basta che chi riceve il binario faccia richiesta dei sorgenti. E quindi può essere chiunque.

No. Perchè non sempre l'utente è "chiunque".

Ricorda che GPL ed LGPL sono state scritte con la consulenza di avvocati statunitensi che hanno ben presenti certe problematiche commerciali e come in certi casi vengono aggirate.

In pratica la GPL obbliga a permettere che le entità legali utilizzatrici abbiano un modo ragionevolmente semplice di accedere ai sorgenti e poterli analizzare o compilare da se.

Quindi se l'azienda A fa un lavoro sotto licenza GPL "per se" lo puo tenere completamente segreto eccetto che a personale autorizzato dell'azienda stessa, se lo fa per un azienda "B" lo può tenere segreto al resto del mondo eccetto che a rappresentanti legali autorizzati di A e B
(questo include hardware con quel software in forma embedded, ecc.).
E' solo se rilasci gli eseguibili "a tutte le entital legali che lo vogliono" che sei obbligato a rendere anche i sorgenti accessibili a tutti.

Per questo ad esempio Linux viene usato anche in applicazioni militari senza che nessuno si ponga problemi (solo le entità legali clienti possono accedere ai sorgenti e praticamente lo richiedono tutti quelli che hanno i mezzi per dargli un occhiata ed essere sicuri che non ci siano ovetti di Pasqua sgraditi).
Per rendere l'idea, in certi casi il cliente vuole persino l'accesso ai sorgenti del firmware delle testate dei missili aria-aria e cose simili per essere al riparo da "sorprese"
e per il fornitore non è un problema (le versioni export usano firmware ed hardware "downgraded" nelle parti in cui si vuole mantenere massima segretezza).

Non a caso uno dei motivi per cui l' F-22 non è stato esportato è che la sua avionica era stata sviluppata senza tenere in minima considerazione l'eventualità di esportazione dell'aereo ( quando poi gli sarebbe tornato comodo venderne a Giappone ed Australia, non potevano farlo perchè avrebbero dovuto riscrivere tutta l'avionica :stordita: ) .

@LMCH: ma infatti cosa cambia da quello che ho detto prima? :D

@Bellaz89: OK, quindi tu dividi il core del linguaggio (e i relativi tipi primitivi) dalla libreria standard. Va bene, perché anche in Python sono separati (la libreria standard puoi reimplementarla come vuoi).

str è un tipo primitivo in Rust, ma non è mutabile, come lo sono pure le stringhe in Python.

Per cui, e per essere chiari, non è che una stringa cambi automaticamente la rappresentazione interna in Python: una volta costruita rimane sempre con quella particolare codifica. Il "cambio di tipo" avviene quando viene generata una nuova stringa, ossia quando, ad esempio, c'è un'operazione di concatenazione fra stringhe che hanno una diversa rappresentazione interna, per cui la nuova stringa avrà ovviamente la codifica più "grossa" delle due, in grado di contenere i caratteri di entrambi.

Riguardo alla garbage collection, visto che hai distinto core e libreria standard, ovviamente quel che avevo scritto cade nel primo caso.

Non credo che con python si possa non avere il supporto alle stringhe dinamiche(ed un sacco di altra roba) senza trasformare il linguaggio pesantemente al contrario di Rust.
Come già detto prima, le stringhe in Python sono immutabili, e dunque non sono dinamiche: una volta create rimangono esattamente come sono (a meno di ottimizzazioni che una VM può operare in specifici casi, ma dipende strettamente dall'implementazione. Ad esempio CPython ottimizza un solo caso particolare riciclando la stessa stringa, e dunque "mutandola". Ma il mio WPython, pur derivando da CPython, non lo fa, e dunque le stringhe create rimangono immacolate).

Oltre alle stringhe ci sono anche altri tipi primitivi che, invece, sono mutabili / dinamici (liste, dizionari, e set).
&str e' un puntatore a un'area di memoria che senza libreria standard non ha metodi predefiniti, le stringhe di python , sono degli oggetti (come tutto del resto in python) che hanno metodi predefiniti e che hanno metadati come qualsiasi altro oggetto di python. Quindi si, sono due cose molto differenti.
Quello di Rust è soltanto un modo elegante per definire funzioni aventi come primo parametro implicito un dato del tipo specificato.

Comunque è vero ciò che dici su Python, ma questo al solito dipende dall'implementazione. In PyPy, ad esempio, spesso non hai a che fare con oggetti, ma direttamente coi tipi primitivi presenti in altri linguaggi; causa lavoro del JITer.
Infatti il problema e' quando avviene l'append o invocato un altro metodo che puo' generare un comportamento simile.
Non c'è alcuna operazione di append per le stringhe in Python, ma solo la concatenazione, che partendo da due stringhe immutabili ne genera una terza, anch'essa immutabile.

Se ti riferisci all'operatore +=:
s = 'Hello'
s += ' '
s += 'world!'
print(s) # Stampa Hello world!
opera come ho descritto, e dunque vengono generate 3 stringhe diverse dalle concatenazioni, e l'ultima rimane assegnata alla variabile s.

C'è un solo, specifico, caso (questo! :D) in cui CPython (e dunque QUESTA implementazione) opera un'operazione di ridimensionamento in-place, ma si verifica esclusivamente se la stringa contenuta in s ha UN solo riferimento, e il successivo bytecode da eseguire è uno store che salva il contenuto nella variabile in cui è contenuta la stringa.
Questo sostanzialmente garantisce che la stringa rimanga "immutabile" per tutti i successivi utilizzi. E' una sorta di micro-implementazione di un cosiddetto "string builder", realizzato per chi non sa come usare correttamente Python in questi casi.
Rust non ha la garbage collection indipendentemente dall'usare la libreria standard o no, al contrario di python dove e' sempre necessaria
Dalla documentazione di Rust.

Module std::rc (https://doc.rust-lang.org/std/rc/index.html):

"Unsynchronized reference-counted boxes (the Rc<T> type) which are usable only within a single thread.

The Rc<T> type provides shared ownership of an immutable value. Destruction is deterministic, and will occur as soon as the last owner is gone. It is marked as non-sendable because it avoids the overhead of atomic reference counting."

Struct std::sync::Arc (https://doc.rust-lang.org/std/sync/struct.Arc.html):

"An atomically reference counted wrapper for shared state. Destruction is deterministic, and will occur as soon as the last owner is gone. It is marked as Send because it uses atomic reference counting."

Questo è esattamente ciò che succede coi PyObject di CPython.

Sono comunque oggetti che possono allocare memoria dinamicamente attraverso i loro metodi, al contrario di &str di Rust che e' solo un puntatore.
Non cambia il discorso: un oggetto &str devi usarlo in qualche modo, per cui ti capiterà di allocare & deallocare memoria con qualche chiamata a funzione della libreria standard.

Anche in kernel space si alloca e dealloca memoria quando serve, perché non puoi lavorare soltanto manipolando puntatori già allocati.
Per come e' fatto python credo che comunque anche Pypy si porti dietro dei metadati riferiti alla stringa stessa. E' praticamente impossibile non averli per linguaggi dinamici.
Il JITer è in grado di intercettare certe operazioni e usare dati primitivi, per cui in teoria può farlo anche con le stringhe (ed eliminando la mole di metadati che normalmente si portano dietro), ma non sono al corrente di come funzioni in questi casi.
Ok, quindi da questo punto di vista python e' piu di alto livello di quanto pensassi (ergo ancora meno adatto a fare compiti di basso livello)
Non è mai stato pensato per questo, e va benissimo così. :) Anzi, meno male! :D
Anche usando la libreria std non e' obbligatorio usare ne Rc, ne Arc(NB anche questi non sono tipi base di Rust), che sono la controparte di shared_ptr per C++, ma questo non fa di quest'ultimo un linguaggio con garbage collection a differenza di python.
Nemmeno il C++ lo è, da questo punto di vista. Il punto è che se usi la libreria, e come sai gli shared pointer sono ormai MOLTO diffusi, allora fai uso di garbage collection.

Non credo che un oggetto Rc sia stato messo lì nella libreria standard per fare la bella statuina. ;)
Inoltre non mi sembra neanche che la deallocazione sia sempre deterministica in CPython 3, quindi il comportamento di PyObject non e' uguale a Rc
Direttamente dal repository di CPython (https://hg.python.org/cpython/file/v3.6.0b2/Include/object.h) (l'ultimo tag è per la 3.6 in lavorazione, ma questo codice non è sostanzialmente cambiato):
The macros Py_INCREF(op) and Py_DECREF(op) are used to increment or decrement
reference counts. Py_DECREF calls the object's deallocator function when
the refcount falls to 0; for
objects that don't contain references to other objects or heap memory
this can be the standard function free().
[...]
#define Py_DECREF(op) \
do { \
PyObject *_py_decref_tmp = (PyObject *)(op); \
if (_Py_DEC_REFTOTAL _Py_REF_DEBUG_COMMA \
--(_py_decref_tmp)->ob_refcnt != 0) \
_Py_CHECK_REFCNT(_py_decref_tmp) \
else \
_Py_Dealloc(_py_decref_tmp); \
} while (0)


#define _Py_Dealloc(op) ( \
_Py_INC_TPFREES(op) _Py_COUNT_ALLOCS_COMMA \
(*Py_TYPE(op)->tp_dealloc)((PyObject *)(op)))
#endif
A parte _Py_Dealloc, le altre macro presenti sono usate soltanto per questioni di debug (e.s.: per conteggiare il numero di chiamate).

Dunque, come vedi, se il reference count arriva a zero, l'oggetto viene liberato. A meno che non parliamo di oggetti complessi che hanno riferimenti ad altri e che, in catena, non possono essere liberati perché ancora usati da qualche parte. Ma questo vale ugualmente anche per gli altri linguaggi.

Il discorso era se &str di Rust e str di Python fossero la stessa cosa, e la risposta e no.
Sì, ok, ma dimmi tu che ci fai soltanto con un puntatore a un'area di memoria che rappresenta una file di caratteri. Ben poco. Perché le stringhe, nella mia modesta esperienza, sono manipolate.

E considerato che Rust non prevede nemmeno l'operazione di indicizzazione, viene fuori che anche soltanto per scorrere una stringa dev'essere creato un iteratore. E, dunque, serve allocare della memoria allo scopo.

Per non parlare del fatto che la rappresentazione utilizzata sia UTF-8. Prova a immaginare cosa dovresti fare per controllare semplicemente se l'ultimo carattere sia un '/'. Controllo, questo, abbastanza comune in routine che si occupano di gestire un filesystem o API di file & cartelle.
Lascio a te pensare a come fare a risolvere in maniera efficiente, nonché consistente, una cosa che in Python si risolve banalmente.
A meno di casi particolari in cui il compilatore riconosce un determinato pattern, qualcosa si devono portare dietro. Secondo me l'ottimizzazione maggiore e' che alcune operazioni possono essere concatenate insieme evitando di fare ogni volta la dereferenziazione e il checktype dell'oggetto usato velocizzando l'esecuzione. Pero' non credo che in generale (ovvero. a meno di casi particolari) un compilatore Python possa segar via i tutti metadati.
Beh, almeno il tipo va mantenuto, ovviamente.
Si, ma non e' il linguaggio ad avere questa feature.
Nemmeno in Python è obbligatorio avere il reference counting: questo è soltanto un dettaglio implementativo. Implementazioni diverse possono funzionare in maniera completamente diversa (PyPy ne è un esempio).
Non ti puntano neanche la pistola in testa per usarlo...
Sì, OK, tutto quello che vuoi, ma se le stringhe non ti costringe a usarle nessuno, e idem gli smart pointer, i Vec, ecc. ecc. poi mi spieghi nella vita reale di tutti i giorni come lo scrivi il codice: coi soli tipi primitivi usati nudi e crudi?

A naso non penso che per progetti non banali tu possa andare avanti alacremente.
Mai negato che avesse il reference count. Pero' come dice anche la documentazione, per oggetti con riferimenti ciclici non ci si puo' basare solo su RC. Quindi la garbage collection che viene fuori non e' deterministica e quindi diversa da Rc di Rust.
Dalla descrizione del primo esempio di Rc:

"If our requirements change, and we also need to be able to traverse from Owner → Gadget, we will run into problems: an Rc<T> pointer from Owner → Gadget introduces a cycle between the objects. This means that their reference counts can never reach 0, and the objects will remain allocated: a memory leak. In order to get around this, we can use Weak<T> pointers."

Ancora una volta, è esattamente ciò che succede in Python nelle medesime situazioni. E anche Python, da tempo, mette a disposizione un "weak pointer" (weakref) per risolvere, allo stesso modo, il problema.

OK, mi sembra che si sia chiarito tutto.

Soltanto un paio di appunti. Intanto per accedere direttamente a un byte devi passare a usare codice unsafe, per l'appunto. Inoltre, visto che str è una stringa UTF-8, così facendo non accedi a un carattere, ma un byte; ovviamente a meno che tu non sia sicuro che str contenga soltanto caratteri ASCII. In Python, invece, sei sempre sicuro di accedere a un carattere (che coincide con un byte se la stringa è contiene ASCII o Latin-1).

Scusate l'intromissione. :D
Ho dato un'occhiatina velocissima a Rust e penso che, "stilisticamente", abbia tutte le potenzialità per diventare più brutto del C++. :D

Detto ciò, mi sorge spontanea una domanda: perché dovrei usare codice unsafe in Rust, per usarlo alla C, quando posso usare direttamente il C? Tanto per dire che sto usando un linguaggio nuovo?
E in cosa, a questo punto, Rust sarebbe migliore e/o diverso dal C++?

Beh, con Rust l'idea è proprio quello di cercare di usare il meno possibile codice unsafe. :fagiano:

Un po' come C#, dove hai ugualmente la possibilità di manipolare puntatori usando blocchi unsafe, per l'appunto, ma si cerca di evitare il più possibile (mai fatto in diversi anni: ho sempre trovato dei workaround. Finora!).

Sulla bruttezza del linguaggio, concordo. :D D'altra parte non amo anche il C++ per simili motivazioni.

Beh, con Rust l'idea è proprio quello di cercare di usare il meno possibile codice unsafe. :fagiano:

Forse sono idealista o inesperto, ma secondo me allora devi proprio togliere la possibilità di usare codice unsafe, in un linguaggio come Rust. E per un motivo semplice: da quello che ho capito, questo finirà in mano di gente che ha sempre lavorato col C/C++, fondamentalmente. Se dai la possibilità di usarlo "alla C", secondo me ci saranno tanti blocchi unsafe, soprattutto se i workaround vengono visti come qualcosa di "inutilmente complicato". Insomma, stiamo parlando di gente che a volte si scorda di mettere un semplicissimo '\0' per chiudere una stringa in C, non ce li vedo ad adattarsi al nuovo stile di programmazione "safe". E ripeto, se devi usarlo alla C/C++, tanto vale usare il C++. :D

Un po' come C#, dove hai ugualmente la possibilità di manipolare puntatori usando blocchi unsafe, per l'appunto, ma si cerca di evitare il più possibile (mai fatto in diversi anni: ho sempre trovato dei workaround. Finora!).

Ma va detto che la forza del C# è anche/soprattutto sul framework che c'è dietro, non tanto il linguaggio in sé.

Sulla bruttezza del linguaggio, concordo. :D D'altra parte non amo anche il C++ per simili motivazioni.
Il C++ è un superset del C, quindi, ad un certo punto, si può chiudere un occhio. Anche sul C si possono dare tante giustificazioni, per diversi motivi (per me, nel 2016, potrebbero pure introdurre il tipo stringa, almeno la gente la smetterà di confondersi con i char * ), ma questo è un linguaggio nuovo di zecca, e boh, è brutto a partire dalle keywords.

Ormai con C i giochi sono fatti, e non ha senso complicarlo più di quel che è. C va bene così perché, nonostante le aggiunte, rimane un linguaggio abbastanza snello e semplice. Se vuoi complicarti la vita passa a C++, che diventato un mammut essendo stato parecchio esteso nel corso degli anni.

Non so se Rust possa avere le carte in regola per soppiantare uno dei due. Queste son cose che si possono scoprire soltanto lavorandoci giornalmente, e sviluppando la mentalità del programmatore Rust.

Per il resto è chiaro che l'unsafe lo userai soltanto se realmente costretto, che comunque è un bel passo avanti rispetto al C, dove lavori quasi sempre "unsafe".

Mentre "castrare" il C++ usandone soltanto la parte "safe" non so quanto possa pagare, per chi è abituato a usarlo a tutto tondo.

Ormai con C i giochi sono fatti, e non ha senso complicarlo più di quel che è. C va bene così perché, nonostante le aggiunte, rimane un linguaggio abbastanza snello e semplice. Se vuoi complicarti la vita passa a C++, che diventato un mammut essendo stato parecchio esteso nel corso degli anni.

Non so se Rust possa avere le carte in regola per soppiantare uno dei due. Queste son cose che si possono scoprire soltanto lavorandoci giornalmente, e sviluppando la mentalità del programmatore Rust.

Per il resto è chiaro che l'unsafe lo userai soltanto se realmente costretto, che comunque è un bel passo avanti rispetto al C, dove lavori quasi sempre "unsafe".

Mentre "castrare" il C++ usandone soltanto la parte "safe" non so quanto possa pagare, per chi è abituato a usarlo a tutto tondo.

Concordo, ma cerco di spiegarmi meglio. Alla fine, una delle obiezioni che vengono fuori col C è quella legata alle stringhe. Manca semplicemente il tipo stringa. Hanno già tutte le funzioni per manipolarle (string.h), solo che si lavora con array di caratteri. Io non penso sia chissà che problema, ma ripeto, visto che viene sempre fuori 'sta cosa, tanto vale aggiungerla.
Poi il mio discorso non era legato al linguaggio in sé, ma a chi lo userà: Bellaz89 ha scritto che Rust ti costringerà a programmare in maniera sicura, quindi ad adattarti ad un diverso stile di programmazione: il problema è che ti lascia una porticina da cui scappare (a meno che io non abbia capito niente, e ci sta), e qualcuno potrebbe usarla.

Ricordo che c'è gente che si è riscritta la malloc(), chissà per quale motivo... :D

Prestazioni. :cool: Ho certe ideucce che mi passano per la mente per migliorare la de/allocazione degli oggetti in Python, che non passano dalla normale malloc, ma usando direttamente alcune funzioni del s.o. sottostante.

Quanto al tipo string da aggiungere al C, si potrebbe anche fare, ma... dopo tutto questo tempo ha senso? Ormai C++ lo sta soppiantando, anche perché dopo il tipo string ti verrebbe voglia di aggiungere altra roba, e così via.

Prestazioni. :cool: Ho certe ideucce che mi passano per la mente per migliorare la de/allocazione degli oggetti in Python, che non passano dalla normale malloc, ma usando direttamente alcune funzioni del s.o. sottostante.

Basta che con una memcpy() sbagliata non fai saltare mezzo mondo, sai com'è... :D

Quanto al tipo string da aggiungere al C, si potrebbe anche fare, ma... dopo tutto questo tempo ha senso? Ormai C++ lo sta soppiantando, anche perché dopo il tipo string ti verrebbe voglia di aggiungere altra roba, e così via.
Non so, ma C++ non mi piace proprio. Lo vedo come qualcosa di inutilmente sovraingegnerizzato. :stordita:

Basta che con una memcpy() sbagliata non fai saltare mezzo mondo, sai com'è... :D
Tranquillo: niente memcpy. :cool:
Non so, ma C++ non mi piace proprio. Lo vedo come qualcosa di inutilmente sovraingegnerizzato. :stordita:
Idem. Ma, purtroppo, ci si deve lavorare se e quando serve. E in futuro dovrò lavorarci molto di più. :cry:

Idem. Ma, purtroppo, ci si deve lavorare se e quando serve. E in futuro dovrò lavorarci molto di più. :cry:

Ti hanno promosso? :D

Non esattamente, ma la situazione verrà definita in un mese meno un giorno. Per il momento preferisco tenere la bocca tappata e incrociare le dita. :fagiano:

Non esattamente, ma la situazione verrà definita in un mese meno un giorno. Per il momento preferisco tenere la bocca tappata e incrociare le dita. :fagiano:

In bocca al lupo.
Ho seguito dall'inizio e la questione sicurezza è un punto nevralgico di tutti gli os ormai.
Purtroppo ci sono retaggi del passato che impediscono una corretta visione della sicurezza (a livello os) e questo porta ad aggiungere pezze ogni qualvolta se ne presenta l'occasione i modi e la possibilità.
Non dimentichiamoci che praticamente tutti gli os (ed i linguaggi di programmazione) anche se in principio votati alla affidabilità non furono ideati immaginando l'accanimento estremo che c'è oggi nel cercare di bucare un os o applicazione.
Ma chi avrebbe la forza di scrivere un nuovo os, mandando in pensione una marea di applicativi utilizzati quotidianamente, e farlo adottare alle masse in modo diffuso.
Se poi consideriamo che la sicurezza informatica è presa sottogamba anche dalle istituzione siamo a cavallo.
Ps 10 gg fa anche il dvr di un mio amico è stato attaccato e fatto membro di una bobnet perchè l'account amministratore era quello di default (admin 123456), ormai non serve nemmeno più trovare le falle, basta cercare nel mucchio e qualcosa di non protetto lo trovi in un baleno.

In bocca al lupo.
Ho seguito dall'inizio e la questione sicurezza è un punto nevralgico di tutti gli os ormai.
Purtroppo ci sono retaggi del passato che impediscono una corretta visione della sicurezza (a livello os) e questo porta ad aggiungere pezze ogni qualvolta se ne presenta l'occasione i modi e la possibilità.
Non dimentichiamoci che praticamente tutti gli os (ed i linguaggi di programmazione) anche se in principio votati alla affidabilità non furono ideati immaginando l'accanimento estremo che c'è oggi nel cercare di bucare un os o applicazione.
Ma chi avrebbe la forza di scrivere un nuovo os, mandando in pensione una marea di applicativi utilizzati quotidianamente, e farlo adottare alle masse in modo diffuso.
Se poi consideriamo che la sicurezza informatica è presa sottogamba anche dalle istituzione siamo a cavallo.
Ps 10 gg fa anche il dvr di un mio amico è stato attaccato e fatto membro di una bobnet perchè l'account amministratore era quello di default (admin 123456), ormai non serve nemmeno più trovare le falle, basta cercare nel mucchio e qualcosa di non protetto lo trovi in un baleno.
Infatti. Il problema è che riscrivere completamente il software usando strumenti migliori è oggettivamente impossibile. Tranne per progetti amatoriali, dove ovviamente si può sperimentare.

P.S. Grazie!

Per la bruttezza/bellezza e' molto soggettiva la questione.

Il discorso di fondo e' che Rust a differenza di C/C++ che sono 'unsafe by default' ha un meccanismo tale per cui e' 'unsafe by request'. Cio' che dici e' vero. Nessuno mi vieta di abusare del codice 'unsafe' pero' l'idea e' che questo viene limitato il piu' possibile a differenza di C/C++ dove sei sempre obbligato a usare codice unsafe. E questo, per programmatori che sanno quello che fanno puo' risultare molto comodo.

Ma non puoi fare altrimenti visto che scrivere codice a basso livello porta inevitabilmente a scrivere una porzione di codice unsafe.

EDIT:

Non avevo visto la risposta che cdimauro ti aveva dato, che alla fine come senso e' uguale alla mia.

EDIT2:

Uno degli scopi del linguaggio e' per l'appunto razionalizzare i linguaggi C-C++ che per l'appunto sono nati negli anni 70-80. Ovviamente visto che informaticamente parlando e' la preistoria i linguaggi si sono 'evoluti' a forza di revisioni piu' o meno belle che hanno si aggiunto nuove features ai linguaggi, ma li hanno anche per cosi' dire 'sporcati'. Quindi quelli di Rust stanno tentando (vedremo se ce la faranno) di permettere una programmazione 'moderna' di C-C++, senza avere la loro 'verbosita' o 'ineleganza'. Poi beh, a me piacciono tantissimo gli Algebraic Data Types ( :D ), il pattern matching e il concetto di ownership/borrow, il tutto in un linguaggio di basso livello .

Ma infatti avevo capito, e se rileggi i miei ultimi post capirai che intendevo solo che non vorrei che diversi programmatori abusassero del codice 'unsafe', magari perché fossilizzati sulle proprie abitudini. A quel punto, diventerebbe ancor più un casino.

Bruttezza/bellezza, ovviamente la cosa è soggettiva, ci mancherebbe. :D

Io, ad esempio, credo che il C non sia così inelegante, il problema è che lascia troppe libertà nello stile. E pure nel K&R ci sono degli avvertimenti sul non approfittare della possibilità di ridurre tutto a poche righe di codice, ma illeggibili. Così come ritengo i puntatori, di per sé, degli strumenti potentissimi e utilissimi, ma se non li si padroneggia come si deve, vengono fuori porcate inenarrabili.

Sul Rust sono molto curioso, e, personalmente, preferirei vedere sparire il C++ piuttosto che il C, ma son punti di vista. :D

Sicuramente C ha mantenuto di piu' la sua 'purezza' in C11 rispetto ad esempio a C++17 (in quest'ultima revisione, a mio avviso, C++ e' stato abbastanza stravolto).

Inizio a sospettare che nemmeno Stroustrup sia più in grado di padroneggiare BENE C++. Per me, rimane di una complessità eccessiva. Che sia potente è indubbio, eh.

Poi opinione mia, non vedremo sparite C e C++ per mooolto tempo (in alcuni settori si utilizza ancora Fortran 77 per dire)

Su questo concordo, e sinceramente posso pure capire, specialmente lato C. Magari diventeranno sempre più di nicchia, ma resteranno.

Riguardo safe / unsafe in .NET girando in fondo l'applicazione dentro una Virtual Machine è possibile impedire ad un programma che usa codice unsafe di girare proprio (questo lo faremo in Cosmos) non so se questo è possibile in Rust credo di no essendo alla fine il risultato ottenuto un normale eseguibile.

Inoltre in .NET puoi backlistare certe operazioni che per quanto siano nella parte "safe" del linguaggio magari poi troppo safe non sono.
(Anche questo accadrà in Cosmos).

Riguarda all'assenza di stringhe nel C è una mancanza enorme che forse ai tempi in cui fu scritto non era stata pensata, ma praticamente tutte le funzioni dentro string.h sono unsafe da usare.

Ecco alcuni esempi:
http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/dangers-c.html

Anche le funzioni con la 'n' (strncpy, snprintf) sono bacate se la stringa è più lunga non fanno buffer overflow è vero, ma non mettono comunque il '\0' restituendo - quindi - una stringa non valida:

https://randomascii.wordpress.com/2013/04/03/stop-using-strncpy-already/
(no lasciate perdere la sua soluzione non è codice C valido e poi ammette che manco funziona con UTF-8 quindi a che serve? Scrivetela voi quella giusta dice! Deve essere quello che hanno pensato quando scrissero strncpy() :eek: )

La realtà dei fatti è che usare le stringhe senza allocare memoria è quasi impossibile anche se le funzioni con la 'n' funzionassero quello che io vorrei è un errore NON una stringa troncata!

Ah anche readlink() è bacata non mette il tappo nella stringa ritornata, infatti l'ho dovuta wrappare anch'essa in ReadLink()! Ma ha senso usare ancora oggi un linguaggio che devi creare una libreria di funzioni per rendere safe il runtime?

Aggiungo anche qualcosa di positivo il modo più safe di copiare una stringa è usare un Variable Lenght Array come destinazione:


static void
my_function(...)
{
[a lot of code]
/* I need to copy str in str2 easy! */
char str2[strlen(str) + 1];

/* always safe as 'str2' has the same size of 'str', '\0' is copied too!
strcpy(str2, str);
}


Purtroppo il suo uso è limitato per esempio un VLA non può essere una variabile statica quindi non può essere ritornato in maniera "safe", nè può essere una variabile di output...

Beh però è già qualcosa no?

Inizio a sospettare che nemmeno Stroustrup sia più in grado di padroneggiare BENE C++. Per me, rimane di una complessità eccessiva. Che sia potente è indubbio, eh.
È diventato sempre più un "linguaggio esteso da un comitato" quindi sono state fatte estensioni di cui non tutti sentivano l'esigenza, estensioni che sono dei compromessi tra approcci differenti ed al tempo stesso alcuni aspetti restano trascurati da anni ed anni (name mangling ed ABI relativa alle parti prettamente di C++ senza manco uno standard per identificare se si sta linkando una libreria compatibile oppure no sotto tali aspetti ... tranne usare name mangling incompatibili per essere certi che link di librerie sbagliate non abbiano successo ... con un sacco di messaggi di errore fuorvianti :stordita: ).

Riguarda all'assenza di stringhe nel C è una mancanza enorme che forse ai tempi in cui fu scritto non era stata pensata, ma praticamente tutte le funzioni dentro string.h sono unsafe da usare.
Il C essenzialmente è un linguaggio assembly di alto livello "sufficientemente portabile", per questo la cosa che in origine più si avvicinava ad un vero tipo di dato astratto stringa erano le sequenze di char convenzionalmente terminate da un char nullo su cui operano alcune funzioni di libreria dello standard originale.
Ma ovviamente tale "vicinanza" è molto relativa ( per il compilatore non esistono, vede solo array di char, char pointer e funzioni che ricevono in input e/o restituiscono char pointer).

Riguardo safe / unsafe in .NET girando in fondo l'applicazione dentro una Virtual Machine è possibile impedire ad un programma che usa codice unsafe di girare proprio (questo lo faremo in Cosmos) non so se questo è possibile in Rust credo di no essendo alla fine il risultato ottenuto un normale eseguibile.

Inoltre in .NET puoi backlistare certe operazioni che per quanto siano nella parte "safe" del linguaggio magari poi troppo safe non sono.
(Anche questo accadrà in Cosmos).

Riguarda all'assenza di stringhe nel C è una mancanza enorme che forse ai tempi in cui fu scritto non era stata pensata, ma praticamente tutte le funzioni dentro string.h sono unsafe da usare.

Ecco alcuni esempi:
http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/dangers-c.html

Anche le funzioni con la 'n' (strncpy, snprintf) sono bacate se la stringa è più lunga non fanno buffer overflow è vero, ma non mettono comunque il '\0' restituendo - quindi - una stringa non valida:

https://randomascii.wordpress.com/2013/04/03/stop-using-strncpy-already/
(no lasciate perdere la sua soluzione non è codice C valido e poi ammette che manco funziona con UTF-8 quindi a che serve? Scrivetela voi quella giusta dice! Deve essere quello che hanno pensato quando scrissero strncpy() :eek: )

La realtà dei fatti è che usare le stringhe senza allocare memoria è quasi impossibile anche se le funzioni con la 'n' funzionassero quello che io vorrei è un errore NON una stringa troncata!

Ah anche readlink() è bacata non mette il tappo nella stringa ritornata, infatti l'ho dovuta wrappare anch'essa in ReadLink()! Ma ha senso usare ancora oggi un linguaggio che devi creare una libreria di funzioni per rendere safe il runtime?

Aggiungo anche qualcosa di positivo il modo più safe di copiare una stringa è usare un Variable Lenght Array come destinazione:


static void
my_function(...)
{
[a lot of code]
/* I need to copy str in str2 easy! */
char str2[strlen(str) + 1];

/* always safe as 'str2' has the same size of 'str', '\0' is copied too!
strcpy(str2, str);
}


Purtroppo il suo uso è limitato per esempio un VLA non può essere una variabile statica quindi non può essere ritornato in maniera "safe", nè può essere una variabile di output...

Beh però è già qualcosa no?

Sì ma boh, non capisco come si possa dimenticare di chiudere una stringa. Ci vogliono 5 minuti a scrivere strcpy()... Mah.

Riguardo safe / unsafe in .NET girando in fondo l'applicazione dentro una Virtual Machine è possibile impedire ad un programma che usa codice unsafe di girare proprio (questo lo faremo in Cosmos)


Finche' non sbuca qualche vulnerabilita' nella VM. Tempo fa lessi proprio un articolo a riguardo, che comparava Singularity a L4 e gli autori di L4 facevano notare che la complessita' del solo garbage collector di .NET rendeva impossibile un'implementazione senza gravi vulnerabilita', sfruttabili per l'escape dalla VM.


non so se questo è possibile in Rust credo di no essendo alla fine il risultato ottenuto un normale eseguibile.

Ma Rust impone delle regole che garantiscono la safety delle operazioni svolte dal codice. Un programma simile semplicemente non compila.

Chiaro che bisogna vedere se queste regole hanno lacune e rendono il sistema aggirabile. Cosi' come e' ovvio che ci sono classi di bug che i progettisti di Rust non hanno considerato quando hanno creato queste regole.

Sì ma boh, non capisco come si possa dimenticare di chiudere una stringa. Ci vogliono 5 minuti a scrivere strcpy()... Mah.

E' più semplice di quanto sembra:


char grattachecca[3];
char *buffer_overflowo = "LUNGOLUNGOLUNGOLUNGOLUNGONE";

strcpy(grattachecca, buffer_overflowo);


Hai sbordato visto che hai richiesto 3 caratteri e ne hai scritto chissà quanti!
Il compilatore C non fiata, la strcpy cerca il primo tappo che trova e NON ha modo di sapere che grattachecca ha solo 3 caratteri di spazio: gli array in C "decadono" in puntatori quando passati alle funzioni quindi :D

Ora questo è un esempio sempliciotto in cui beh nessuno ci casca, ma pensa se la stringa viene passata alla funzione o letta da standard input... tu magari sei nella fretta mostruosa perchè devi consegnare o distratto dalle belle cosce della collega e bum!

Un bel baco che magari resta latente per 9 anni finchè di improvviso tutti i sistemi iniziano a morirti davanti agli occhi e tu ti trovi tutto solo a bestemmiare in ufficio alle 10 di sera :D

http://arstechnica.com/security/2016/10/trick-or-treat-google-issues-warning-of-critical-windows-vulnerability/

"fortuna" che uso chrome. :rolleyes:

http://arstechnica.com/security/2016/10/trick-or-treat-google-issues-warning-of-critical-windows-vulnerability/

"fortuna" che uso chrome. :rolleyes:non basta tenere UAC al massimo con utente standard?

non basta tenere UAC al massimo con utente standard?

non saprei. non entrano nel dettaglio (nemmeno sul sito di Google), solo che è una falla "0-day" grave e che permette di "uscire" dalla sandbox ed eseguire codice con privilegi elevati.
immagino voglia dire che l'UAC non serve a niente in questi casi. :stordita:
Adobe c'ha già messo la pezza. Chrome ha "aggirato" la falla, ma MS per ora non è intervenuta quindi il rischio c'è (e a leggere l'articolo, la falla è già stata usata e non è solo un "proof of concept").

non saprei. non entrano nel dettaglio (nemmeno sul sito di Google), solo che è una falla "0-day" grave e che permette di "uscire" dalla sandbox ed eseguire codice con privilegi elevati.
immagino voglia dire che l'UAC non serve a niente in questi casi. :stordita:
Adobe c'ha già messo la pezza. Chrome ha "aggirato" la falla, ma MS per ora non è intervenuta quindi il rischio c'è (e a leggere l'articolo, la falla è già stata usata e non è solo un "proof of concept").tutte le falle sull'UAC di cui ho memoria richiedono account amministratore + UAC standard

l'UAC serve solo se settato al massimo e bisogna usare un account standard , è l'unica cosa da non dimenticare su windows (e che ormai sta scritta pure sui muri :D )
grazie della segnalazione ;)

Stiamo parlando di un kernel che basta uno sbordamento ben cucinato e ti fa passare da utente normale a utente root con potere assoluto sulla macchina a me pare una cosa molto, molto seria ed anche abbastanza indifendibile :D

Eccoti due recenti local privilege escalation su Windows, a riprova del fatto che sei di un'ignoranza e incompetenza colossali:

https://www.symantec.com/security_response/vulnerability.jsp?bid=91121
https://www.symantec.com/security_response/vulnerability.jsp?bid=93556

Con questo non voglio attaccare Windows, ma come scrivevo, le persone competenti e/o informate sanno che di Local privilege escalation ne vengono trovati, e corretti, una manciata l'anno su ogni O/S, e che urlare all'eresia per una singola vulnerabilità è da scimmie, non da professionisti.

Per sistemi tremendamente importanti ci si riduce al "back porting" che tristezza :p

Ma guarda un po'! Entrambe le vulnerabilità hanno circa una decina d'anni, se non di piú, dato che è vulnerabile anche Vista.

Puoi riferire questo fatto a quell'incompetente che ho citato, che tra l'altro scrive "back porting" con virgolette e spazio (come se fosse una cosa dell'altro mondo...)?