[Aggiornata] Tre milioni di spazzolini elettrici smart utilizzati come rete botnet per un attacco DDoS

[ZeroSievert]

Comunque a quelli che dicono "a cosa serve lo spazzolino smart?".

https://beebom.com/colgates-plaqless...que-real-time/

Non ne ero a conoscenza, ma esistono spazzolini che:

- dicono in tempo reale se ti stai lavando correttamente i denti
- ti fanno la mappatura dello stato della dentatura
- vedono se ci sono problemi (e.g. accumulo placca) e ti suggeriscono quando intervenire.


Bisogna vedere quanto siano effettivamente efficaci questi dispositivi. Ma se funzionassero non e' un'applicazione per niente stupida.

Meglio spendere qualcosa in piú per un dispositivi di medicina preventiva che piangere dopo dal dentista che ti deve rifare la bocca (con il portafoglio che piange con te).

Ovviamente problemi come quello della news sono incidenti di percorso che possono accadere.

[386DX40]

Mi chiedo se avessimo davvero bisogno di un sistema che ci dicesse che il lavaggio dei denti non è corretto o se invece il troppo "smart" non ci stia facendo dipendere da assurdi sistemi complessi per le più banali delle operazioni che l' essere umano era già capace di svolgere. Se fosse un film di fantascienza non sarebbe male come sceneggiatura che il rendere l' essere umano non più capace di far nulla sia un' enorme fonte di futuro guadagno per dispositivi di cui nessuno aveva bisogno quando le cose le si sapeva già fare. Tra l' altro alcuni di questi dispositivi le cose le fanno peggio: mi hanno regalato un orologio da polso di ultima generazione per fitness o come si chiamano che uso solo come orologio da polso e pur aggiornato all' ultimo firmware riesce a sbagliare l'ora dopo un paio di settimane pur non spegnendolo di quasi 3>5 minuti buoni e il motivo pare ovvio.

[ZeroSievert]

Originariamente inviato da 386DX40

Mi chiedo se avessimo davvero bisogno di un sistema che ci dicesse che il lavaggio dei denti non è corretto o se invece il troppo "smart" non ci stia facendo dipendere da assurdi sistemi complessi per le più banali delle operazioni che l' essere umano era già capace di svolgere. Se fosse un film di fantascienza non sarebbe male come sceneggiatura che il rendere l' essere umano non più capace di far nulla sia un' enorme fonte di futuro guadagno per dispositivi di cui nessuno aveva bisogno quando le cose le si sapeva già fare.

Scusa eh, ma come fai a dire che ti stai lavando bene i denti se non sei un dentista e non hai strumenti di verifica (a parte il checkup annuale/semestrale dove ti mandano via in 30 minuti)?

Poi ci sono utenti come megamitch sopra che hanno esigenze particolari. Si devono attaccare perchè IOT=brutto?

Ma anche se fosse una semplice ottimizzazione che permette di vivere qualche anno in piú con i denti a posto perchè deve essere cassata? Tutti invecchiamo e da certe condizioni non si ritorna piú indietro..

Se pensi che questo per te non sia di particolare rilevanza ok. Ma il mondo e' bello perchè e' vario. E per molti sulla salute non si scherza.

EDIT:

tra le altre cose in posti come gli USA, un singolo impianto dentale puo' costare tra il 1500$-5000$. In Italia 600-1200eur. Se questo sistema riesce a salvare qualche dente, potrebbe far risparmiare diversi soldi.

[386DX40]

Originariamente inviato da ZeroSievert

Scusa eh, ma come fai a dire che ti stai lavando bene i denti se non sei un dentista e non hai strumenti di verifica (a parte il checkup annuale/semestrale dove ti mandano via in 30 minuti)?

Poi ci sono utenti come megamitch che hanno esigenze particolari. Si devono attaccare perchè IOT=brutto?

Purtroppo di ben altri problemi di salute ne ho abbastanza e non ci ho mai scherzato. Ma basta essere andati dal dentista qualche volta per sapere (e poi dimenticare) come ci si dovrebbe lavare i denti. Il progresso tecnico ben volentieri aiuta, gli spazzolini elettrici mi hanno stupito per come riescano a migliorare la pulizia a seconda delle proprie esigenze odontoiatriche ma per quanto da sola la persona possa pulirsi più o meno bene non cercherei di trovare motivazioni a innovazioni che forse innovazioni non sono. Persino i dentifrici dopo decadi e decadi hanno creato assurde aspettative di risolvere problemi che sono dovuti ad altro e che il mezzo di frizione non può in alcun modo risolvere.

[ZeroSievert]

Originariamente inviato da 386DX40

...

Mi spiace per i tuoi problemi di salute

Originariamente inviato da 386DX40

[...] Ma basta essere andati dal dentista qualche volta per sapere (e poi dimenticare) come ci si dovrebbe lavare i denti. [...]

Eh appunto. Come dici anche te le istruzioni del medico si possono anche dimenticare visto che le sedute sono dilatate nel tempo. Io ad esempio sono pessimo con la memoria cinetica anche se cerco di fare del mio meglio. Un dispositivo del genere se funziona potrebbe aiutarmi (anche se fortunatamente -per ora- non ho mai avuto particolari problemi dentali).

Sono limitato? Puo' darsi (ma sfido a trovare qualcuno che e' perfetto in quello che fa a 360° 24/24). Ma ho imparato a convivere con i miei limiti (almeno di quelli a cui sono a conoscenza).

EDIT:

Detto questo magari questi spazzolini smart sono la solita scemenza commerciale. Lungi da me difenderli a spada tratta. Ma vorrei verificare la cosa piu' approfonditamente prima di formulare un giudizio.

[386DX40]

Originariamente inviato da ZeroSievert

Mi spiace per i tuoi problemi di salute

Grazie

Originariamente inviato da ZeroSievert

Eh appunto. Come dici anche te le istruzioni del medico si possono anche dimenticare visto che le sedute sono dilatate nel tempo. Io ad esempio sono pessimo con la memoria cinetica anche se cerco di fare del mio meglio. Un dispositivo del genere se funziona potrebbe aiutarmi (anche se fortunatamente -per ora- non ho mai avuto particolari problemi dentali).

Sono limitato? Puo' darsi (ma sfido a trovare qualcuno che e' perfetto in quello che fa a 360° 24/24). Ma ho imparato a convivere con i miei limiti (almeno di quelli a cui sono a conoscenza).

EDIT:

Detto questo magari questi spazzolini smart sono la solita scemenza commerciale. Lungi da me difenderli a spada tratta. Ma vorrei verificare la cosa piu' approfonditamente prima di formulare un giudizio.

Infatti anche io credo che nel mezzo di tante innovazioni qualcosa si possa salvare ma è evidente che in un sistema consumistico questa continua logica dell' innovazione perenne sia un attimo discutibile o superflua. Se dovessero creare una forchetta che ci dice se "stiamo mangiando bene" inizierei a chiedermi se forse il problema è che abbiamo dimenticato come si dovrebbe mangiare e non necessariamente bisognerebbe spendere centinaia di euro l' anno per riscoprire boh come si deve bollire la pasta.

[marcram]

Quello che può essere una stupidata per qualcuno, può essere utile per un altro.

Per dire, anche il temporizzatore delle luci delle scale è un'inutilità... Basta ricordarsi di spegnere le luci, no?
O il tasto "quote" del forum: basterebbe copiare il testo da quotare ed incollarlo...

Sono tutte comodità di cui si può ANCHE fare a meno, ma se si rivelano utili e valide per qualcuno, perché devono essere denigrate?
Spesso la concezione di inutilità sta nell'ignoranza riguardo il prodotto (non sempre, naturalmente...)

[386DX40]

Non credo nessuno voglia denigrare innovazioni varie, semplicemente se l' ennesimo dispositivo che magari costa una buona fetta di stipendio ricorda che tutto sommato ci si potrebbe forse esser dimenticati di come curare i denti, qualche domanda me la farei prima di passare il bancomat all' ennesima chiamata all' acquisto. Sono certo che la comodità sia la maggior fonte di guadagno commerciale ma ogni tanto bisognerebbe valorizzare le capacità che già abbiamo e che sono gratuite.

[marcram]

Originariamente inviato da 386DX40

Non credo nessuno voglia denigrare innovazioni varie, semplicemente se l' ennesimo dispositivo che magari costa una buona fetta di stipendio ricorda che tutto sommato ci si potrebbe forse esser dimenticati di come curare i denti, qualche domanda me la farei prima di passare il bancomat all' ennesima chiamata all' acquisto. Sono certo che la comodità sia la maggior fonte di guadagno commerciale ma ogni tanto bisognerebbe valorizzare le capacità che già abbiamo e che sono gratuite.

Sì, sono d'accordo, ognuno valuta quanto è importante per lui quella comodità, e in questo caso questi spazzolini hanno anche un bel costo, quindi ovviamente ci pensi due volte prima di prendertene uno.

Però stai un po' sminuendo la questione: certamente, sappiamo come lavarci i denti. Ma non siamo in grado di valutare se, ad esempio, comincia ad accumularsi della placca su un lato nascosto. Quindi, magari, questi spazzolini sono in grado di valutarne la presenza e insistere nella zona. O avvisarti che dovresti andare a fare un controllo.
Non è una cosa che sappiamo fare semplicemente passando lo spazzolino manuale e guardandoci il sorriso allo specchio...

E' come, non so, la macchinetta per misurare la pressione: potresti dire che la pressione dovresti già capire da te quando ce l'hai un po' alta, quando è troppo bassa, ecc...
Ma queste macchinette te lo dicono con precisione, anche quando non te ne accorgi o non sei in grado di stabilirlo, e ti avvertono anche se hai anomalie sul battito...

[giuliop]

Originariamente inviato da ZeroSievert

E perche' non avrebbe senso?

In breve perché Java ed efficienza, che è la caratteristica fondamentale quando si parla di microcontroller che andranno in uno spazzolino, fanno a pugni; maggiori dettagli sotto.

Originariamente inviato da ZeroSievert

Tu cosa avresti usato?

Sicuramente partirei dal linguaggio che il produttore del microcontroller usa e in cui fornisce esempi/librerie/etc., che tipicamente, e non a caso, è C, o al massimo C++.

Originariamente inviato da ZeroSievert

E' una versione di Java specificatamente pensata per i dispositivi embedded.

Questo, di nuovo, non è rilevante: il fatto che sia pensato per i dispositivi embedded non la rende automaticamente una scelta sensata.
* Potrei capire se avessi diversi SBC con diversi microcontroller [relativamente] potenti che devono gestire una GUI e far girare applicazioni importanti, ma in uno spazzolino, che ha spazio limitato e che va a batteria, l'efficienza dovrebbe essere la priorità - anche perché se c'è bisogno di prestazioni c'è sempre il supercomputer che praticamente tutti abbiamo in tasca, con cui lo spazzolino può facilmente comunicare.

Originariamente inviato da ZeroSievert

E Java:

- E' conosciuto da moltissimi sviluppatori. Ergo e' piu' semplice assumere qualcuno che lo sappia usare.

Questo è un non sequitur, per dire che è più semplice trovare sviluppatori non basta che sia conosciuto da molti, dovrebbe essere conosciuto da un numero maggiore di sviluppatori di quanti conoscano le possibili alternative; e se lo confronti a C o C++, questo semplicemente non è vero.

Senza considerare che partire dalla disponibilità dei programmatori per scegliere quale tecnologia utilizzare generalmente non è una buona idea: dovresti sempre prima scegliere la migliore tecnologia per risolvere il tuo problema e poi, a seconda della tecnologia scelta, cercare gli sviluppatori che ti servono.

Originariamente inviato da ZeroSievert

- E' abbastanza semplice e quindi puoi arrivare a un risultato velocemente se non devi fare cose esoteriche o con performance estreme. Quindi time-to-market piu' breve.

Anche questo non segue, che Java sia semplice non implica che sia semplice usarlo per queste problematiche: se per esempio, come è tipico, le librerie sono pensate per essere usate in C, devi nel caso migliore interfacciartici, o peggio sei costretto a svilupparne internamente di equivalenti in Java, o ancora acquistarne di terze parti; e che sia semplice non implica che le alternative sarebbero necessariamente più dispendiose, in termini di tempo: anche questo è da dimostrare.

* E cosa non meno importante, la [presunta] semplicità è contrastata dal fatto che Java richiede una VM, che è uno strato di software aggiuntivo intrinsecamente meno efficiente e che è necessario compensare con maggiori risorse (hardware più complesso per farla girare, batteria di più capace/ingombrante per sopperire al maggiore consumo), e quindi maggiori costi, rispetto alle alternative più efficienti.

Originariamente inviato da ZeroSievert

- E' "battery-included" ed e' molto orientato al networking. Non devi impazzire con le dipendenze ne con le licenze.

Questo mi sembra più uno svantaggio che un vantaggio, portarsi dietro tutto il bagaglio di Java (sempre ammesso che sia disponibile) per questo tipo di networking sarebbe solo un inutile fardello.

Originariamente inviato da ZeroSievert

- Oracle fornisce un servizio clienti ufficiale/training/tutorial etc.

Questo lo fa qualsiasi produttore di microcontroller serio: Microchip/Atmel, ST, Texas, NXP, Cypress/Infineon, per citare i più famosi, hanno tutti documentazione e supporto al cliente esaustivi.
E Oracle si ferma a Java, per tutto quello che riguarda il microcontroller devi comunque basarti sulla documentazione e il supporto del produttore.

Originariamente inviato da ZeroSievert

- Il codice e' portabile su tutte le piattaforme supportate dalla JVM

Spazzolini multipiattaforma? Uhm.. OK.

Originariamente inviato da ZeroSievert

Ha quindi molto senso IMHO che un'azienda non-IT o una piccola realta' abbia usato questo strumento per un dispositivo che si connette alla rete.

Il problema fondamentale del tuo argomento è che stai facendo cherry picking: consideri solo i lati positivi (sempre ammesso che lo siano) senza soppesarli con quelli negativi.

Originariamente inviato da ZeroSievert

Poi che non piaccia il linguaggio (a me Java , per quel poco che l'ho visto, non piace e non lo uso) o che ci possano essere alternative e' un altro discorso.

Non è una questione di gusti ma del fatto che esistano alternative che permettono di risparmiare sui costi e risorse ed essere più efficienti.

Originariamente inviato da ZeroSievert

Che si debba stroncare uno strumento se non si sanno esattamente i requisiti del prodotto in questione mi sembra un poco presuntuoso.
Anche perche', da quello che mi sembra, oltre a sapere che questi dispositivi sono spazzolini che si connettono alla rete non si sanno molte altre informazioni.

Ma che non conosciamo i requisiti in dettaglio non vuol dire che non ci si possa fare un'idea di quale sia la migliore architettura/piattaforma per lo scopo. Prendo giusto Wikipedia (link specifico al linguaggio, ma parla anche della piattaforma):

* "In informatica Java è un linguaggio di programmazione ad alto livello, orientato agli oggetti e a tipizzazione statica, che si appoggia sull'omonima piattaforma software di esecuzione, specificamente progettato per essere il più possibile indipendente dalla piattaforma hardware di esecuzione (tramite compilazione in bytecode prima e interpretazione poi da parte di una JVM) (sebbene questa caratteristica comporti prestazioni in termini di computazione inferiori a quelle di linguaggi direttamente compilati come C e C++ ovvero dunque perfettamente adattati alla piattaforma hardware)."

(Giuro, non l'ho scritta io all'uopo )

Ovvero, sacrifichi prestazioni, e di conseguenza efficienza - che normalmente sono la parte più importante in un microcontroller che sta in uno spazzolino - in cambio della portabilità.

Originariamente inviato da ZeroSievert

EDIT:

Aggiungo tra i vantaggi che probabilmente su NetBeans e' possibile fare qualsiasi cosa inerente al ciclo di sviluppo del prodotto. Dalla scrittura del codice al deployment. Ed e' un vantaggio non da poco per un team piccolo fare tutto con un singolo tool, anche se meno flessibile, invece che con N diversi.

Qui mi sembra che tu stia partendo da una serie di assunti (che con le alternative si debbano necessariamente usare strumenti diversi, che scrivere codice con NetBeans sia necessariamente più semplice, che il team sia piccolo) senza basi.

Originariamente inviato da ZeroSievert

Scusa eh, ma come fai a dire che ti stai lavando bene i denti se non sei un dentista e non hai strumenti di verifica (a parte il checkup annuale/semestrale dove ti mandano via in 30 minuti)?

Non capisco il senso di questa domanda, stai dicendo "come fai a capire se stai facendo bene una cosa a parte controllare periodicamente che tu la stia facendo bene?".
È il dentista che ti deve dire come stai andando e quanto tempo deve passare da un controllo all'altro. Poi chiaramente c'è il dentista più o meno bravo/attento/premuroso etc., ma a questo punto dovresti confrontarlo con l'efficacia dello spazzolino.

Originariamente inviato da ZeroSievert

Poi ci sono utenti come megamitch sopra che hanno esigenze particolari. Si devono attaccare perchè IOT=brutto?

Brutta domanda tendenziosa, che assume che l'IoT (che fra l'altro mi sembra c'entri poco e niente) sia la soluzione ai problemi e che l'unico motivo per cui non possa essere ritenuto utile siano i gusti; un po' come dire, "perché dovrei comprare uno spazzolino smart, dobbiamo tutti buttare i soldi in stupidaggini inutili?".

[ZeroSievert]

Originariamente inviato da giuliop

...

Scusa ma a me sembra che tu stia confondendo le acque per ribaltare l'onere della prova. Sei tu che devi dimostrare come Java sia una scelta sbagliata per questa applicazione, non io che devo dimostrare come sia la scelta giusta (cosa che tra l'altro non ho mai scritto).

Io mi sono limitato a dare una lista, sicuramente non esaustiva, di caratteristiche che potrebbero aver portato l'azienda produttrice a scegliere Java invece che altro.

Quanto queste abbiano influito nelle scelte o se le decisioni siano state prese correttamente non possiamo dirlo ne io ne te, visto che non sappiamo niente delle specifiche del progetto.

Originariamente inviato da giuliop

... grande cherry-picking sulle caratteristiche di C++ e Java ...

Per dirla come te, il fatto che C++ sia piu' diffuso o sia piu' veloce e' irrilevante se Java e' sufficiente sotto questi due punti di vista per l'applicazione scelta. Le caratteristiche positive e negative di uno strumento si valutano nel complesso e non prendendo solo quello che fa piu' comodo.

Se Java nel suo complesso rispetta meglio le specifiche di progetto, a noi ignote, e garantisce un time-to-market piu' rapido, allora e' lo strumento piu' giusto da usare rispetto ad altre soluzioni. Fine.

E il fatto che poi tu sminuisca alcuni punti di forza di Java(diffusione, semplicita', supporto, portabilita', immediatezza d'uso) aggrappandoti a casi specifici mi sembra solo una grande arrampicata sugli specchi.

Tra le altre cose, tu stai suggerendo di usare un linguaggio non-memory safe rispetto a uno che in generale lo e' su un dispositivo IoT. Questo e' irrilevante?

Inoltre, per quanto ne sappiamo potrebbero esistere (come anche no) una o piu' minuscole aziendine sconosciute che forniscono a tutti i big del settore i pacchetti software per spazzolini da denti smart per le piu' disparate funzioni. E magari tali pacchetti sono distribuiti in forma binaria closed-source. E visto che tutti i produttori di spazzolini hanno diverse piattaforme hardware, usare Java e' necessario per garantire la portabilita' del codice. E' ovviamente una supposizione campata per aria, ma non e' che casi del genere siano proprio rari. E in questo caso l'uso di C/C++ va a farsi benedire.

Originariamente inviato da giuliop

Ma che non conosciamo i requisiti in dettaglio non vuol dire che non ci si possa fare un'idea di quale sia la migliore architettura/piattaforma per lo scopo. Prendo giusto Wikipedia (link specifico al linguaggio, ma parla anche della piattaforma):

Non e' che non si sanno i requisiti in dettaglio. Non si sa proprio niente.
Sapere quali siano le caratteristiche tecniche e le specifiche di un dato dispositivo e' l'ABC per dare un giudizio corretto sulle decisioni prese. Altrimenti si perde tempo filosofeggiando sul niente. Se la pensi diversamente, scusa ma penso che tu non abbia la competenza necessaria a dare un qualsivoglia tipo di giudizio tecnico.

Tra le altre cose 'embedded' vuol dire tutto e nulla. Il termine copre dispositivi con prestazioni e memoria differenti di ordini di grandezza. Con supporto software e periferiche diversissime tra di loro e, ovviamente, destinazioni d'uso completamente differenti. Che IC c'e' sullo spazzolino? Un PIC8 da 20 MHz o un ARM Cortex A76 quad-core da 2.4 GHz? (o una delle tantissime sfumature che stanno tra questi due estremi?). Che algoritmi servono? Quanto sono pesanti? Esistono soluzioni COTS sulla piattaforma scelta che rispondono ai requisiti? In che linguaggio sono? Quanto e' semplice l'integrazione? Etc. Etc.

Originariamente inviato da giuliop

Ovvero, sacrifichi prestazioni, e di conseguenza efficienza - che normalmente sono la parte più importante in un microcontroller che sta in uno spazzolino - in cambio della portabilità.

Questo te lo sei inventato. Fonte? E comunque qui non mi sembra proprio si stia parlando di semplici spazzolini elettrici per cui una semplice programmazione bare-metal e' sufficiente (vedi EDIT in fondo)

Originariamente inviato da giuliop

Non capisco il senso di questa domanda, stai dicendo "come fai a capire se stai facendo bene una cosa a parte controllare periodicamente che tu la stia facendo bene?".
È il dentista che ti deve dire come stai andando e quanto tempo deve passare da un controllo all'altro. Poi chiaramente c'è il dentista più o meno bravo/attento/premuroso etc., ma a questo punto dovresti confrontarlo con l'efficacia dello spazzolino.

Hai detto bene: periodicamente. Mentre con uno spazzolino del genere, potenzialmente si puo' fare un controllo continuo (in approssimazione giornaliera). Ovvero puoi, sempre potenzialmente, rilevare e correggere problemi senza aspettare 6-12 mesi del prossimo controllo.

E no, anche se fosse utile alla tua salute dentale, ho fortissimi dubbi che qualunque dentista ti suggerirebbe visite giornaliere. Per la sua e la tua sanita' mentale.

Originariamente inviato da giuliop

Brutta domanda tendenziosa, che assume che l'IoT (che fra l'altro mi sembra c'entri poco e niente) sia la soluzione ai problemi e che l'unico motivo per cui non possa essere ritenuto utile siano i gusti; un po' come dire, "perché dovrei comprare uno spazzolino smart, dobbiamo tutti buttare i soldi in stupidaggini inutili?".

Non ho proprio capito il senso di quello che hai scritto. In generale mi sembra che tu mi abbia messo in bocca cose che non ho mai detto.
Mi sembra abbastanza semplice il messaggio che volevo fare passare a 386 ovvero:

- quello che pensi sia utile/serva a te != quello che e' utile/serve al resto del mondo. E non capire sul momento l'utilita' di un oggetto su cui si hanno poche informazioni non e' una scusa per sparare a zero su questo.

EDIT:

Tra le altre cose, leggo su internet che alcuni di questi dispositivi possono anche fare qualche tipo di imaging del cavo orale unito al tracking 3D in realtime. Di conseguenza suppongo non abbiano processori cosi' mosci.
Anche perche' senno' non sarebbero tanto differenti da un normale spazzolino elettrico. E anche la supposizione che, se fosse necessaria maggiore potenza di calcolo, sia preferibile appoggiarsi al cellulare per queste applicazioni, rimane una supposizione. Esempio stupido: se non hai il cellulare a portata oppure e' scarico.

[raxas]

per la lavanda gastrica non c'è nulla di smart?
chiedo per un amico che si ingolfa di cibo

COMUNQUE LA DISCUSSIONE SI E' FATTA INTERESSANTE

Io spero negli esiti ragionevolmente IT

[giuliop]

Originariamente inviato da ZeroSievert

Scusa ma a me sembra che tu stia confondendo le acque per ribaltare l'onere della prova. Sei tu che devi dimostrare come Java sia una scelta sbagliata per questa applicazione, non io che devo dimostrare come sia la scelta giusta

Cosa che, infatti, ho fatto. Ora modifico il messaggio sopra con asterischi in grassetto per marcare il mio argomento, prova a rileggere.

Originariamente inviato da ZeroSievert

(cosa che tra l'altro non ho mai scritto).

Oh, l'hai scritto eccome.
Hai elencato una serie di premesse e hai tirato queste conclusioni:

Originariamente inviato da ZeroSievert

Ha quindi molto senso IMHO che un'azienda non-IT o una piccola realta' abbia usato questo strumento per un dispositivo che si connette alla rete.

Finché ti limiti a dubitare l'onere della prova rimane a me, ma l'onere di provare i controargomenti è tuo, e solo tuo.

Originariamente inviato da ZeroSievert

Io mi sono limitato a dare una lista, sicuramente non esaustiva, di caratteristiche che potrebbero aver portato l'azienda produttrice a scegliere Java invece che altro.

E io ti ho mostrato che questa lista non è un buon argomento per affermarlo; ora se vuoi continuare a sostenerlo, devi portare argomenti più convincenti.

Originariamente inviato da ZeroSievert

Quanto queste abbiano influito nelle scelte o se le decisioni siano state prese correttamente non possiamo dirlo ne io ne te, visto che non sappiamo niente delle specifiche del progetto.

OK; in quale modo le specifiche di progetto possono fare in modo che, per esempio, Java sia più efficiente?

Originariamente inviato da ZeroSievert

Per dirla come te, il fatto che C++ sia piu' diffuso o sia piu' veloce e' irrilevante se Java e' sufficiente sotto questi due punti di vista per l'applicazione scelta.

OK, a questo punto ne stai facendo una questione di questione di giudizio di valore, certamente insindacabile. La mia risposta, sempre un giudizio di valore e altrettanto insindacabile, è che è demenziale accontentarsi del sufficiente e avere costi maggiori se è possibile avere una soluzione decisamente migliore a costi minori. Sei libero di non essere d'accordo.

Originariamente inviato da ZeroSievert

Le caratteristiche positive e negative di uno strumento si valutano nel complesso e non prendendo solo quello che fa piu' comodo.

Ma "quello che fa piu' comodo" a chi?
Non è chiaro che avere una soluzione che usa meno risorse e costa meno dovrebbe fare comodo al produttore dello spazzolino?

Originariamente inviato da ZeroSievert

Se Java nel suo complesso rispetta meglio le specifiche di progetto, a noi ignote, e garantisce un time-to-market piu' rapido, allora e' lo strumento piu' giusto da usare rispetto ad altre soluzioni. Fine.

Dovresti spiegare cosa vuol dire "nel suo complesso rispetta meglio le specifiche di progetto", perché sinceramente faccio fatica a capirlo.

Originariamente inviato da ZeroSievert

E il fatto che poi tu sminuisca alcuni punti di forza di Java(diffusione, semplicita', supporto, portabilita', immediatezza d'uso) aggrappandoti a casi specifici mi sembra solo una grande arrampicata sugli specchi.

Casi specifici come quello di un microcontrollore che deve finire in uno spazzolino?

Originariamente inviato da ZeroSievert

Tra le altre cose, tu stai suggerendo di usare un linguaggio non-memory safe rispetto a uno che in generale lo e' su un dispositivo IoT. Questo e' irrilevante?

Non è irrilevante ma che non lo sia non vuol dire che non sia lo strumento migliore per lo scopo, è sempre questione di soppesare i pro e i contro.

Originariamente inviato da ZeroSievert

Inoltre, per quanto ne sappiamo potrebbero esistere (come anche no) una o piu' minuscole aziendine sconosciute che riforniscono a tutti i big del settore i pacchetti software per spazzolini da denti smart per le piu' disparate funzioni. E magari tali pacchetti sono distribuiti in forma binaria closed-source. E visto che tutti i produttori di spazzolini hanno diverse piattaforme hardware, usare Java e' necessario per garantire la portabilita' del codice. E' ovviamente una supposizione campata per aria, ma non e' che casi del genere siano proprio rari. E in questo caso l'uso di C/C++ va a farsi benedire.

"come anche no"

Originariamente inviato da ZeroSievert

Non e' che non si sanno i requisiti in dettaglio. Non si sa proprio niente.
Sapere quali siano le caratteristiche tecniche e le specifiche di un dato dispositivo e' l'ABC per dare un giudizio corretto sulle decisioni prese. Altrimenti si perde tempo filosofeggiando sul niente. Se la pensi diversamente, scusa ma penso che tu non abbia la competenza necessaria a dare un qualsivoglia tipo di giudizio tecnico.

Perdona anche tu la sincerità, ma io invece mi sono fatto l'idea che sia invece tu che non hai la competenza necessaria per dare giudizi, da "a me Java , per quel poco che l'ho visto, non piace e non lo uso" a quell'elenco di punti che fanno pensare che esperienza di sviluppo su microcontrollori, a differenza di me*, tu non ne abbia proprio.
Mi sbaglio?

* Giusto per mostrare che non mi invento niente, da una veloce ricerca sul forum: 1, 2, 3.

Originariamente inviato da ZeroSievert

Tra le altre cose 'embedded' vuol dire tutto e nulla. [...]

Originariamente inviato da ZeroSievert

Tra le altre cose, leggo su internet che alcuni di questi dispositivi possono anche fare qualche tipo di imaging del cavo orale unito al tracking 3D in realtime. Di conseguenza suppongo non abbiano processori cosi' mosci.

A me sembra che tu stia continuamente cercando di spostare i paletti, stiamo ancora parlando di quei [supposti] "Tre milioni di spazzolini elettrici smart utilizzati come rete botnet per un attacco DDoS", oppure di robe professionali che costano chissà cosa, e che dubito fortemente possano essere così diffusi?

Originariamente inviato da ZeroSievert

Questo te lo sei inventato. Fonte?

Il paragrafo sopra...?

Veramente stai mettendo in dubbio che una VM sia più lenta del codice nativo?

Originariamente inviato da ZeroSievert

E comunque qui non mi sembra proprio si stia parlando di semplici spazzolini elettrici per cui una semplice programmazione bare-metal e' sufficiente (vedi EDIT in fondo)

Ah, quindi ora Java non sarebbe semplicemente sufficiente, ma necessario?

Originariamente inviato da ZeroSievert

Hai detto bene: periodicamente. Mentre con uno spazzolino del genere, potenzialmente si puo' fare un controllo continuo (in approssimazione giornaliera). Ovvero puoi, sempre potenzialmente, rilevare e correggere problemi senza aspettare 6-12 mesi del prossimo controllo.

E questo, come già detto, dovrebbe essere il tuo dentista a dirtelo.

Originariamente inviato da ZeroSievert

E no, anche se fosse utile alla tua salute dentale, ho fortissimi dubbi che qualunque dentista ti suggerirebbe visite giornaliere. Per la sua e la tua sanita' mentale.

Ma molto più probabilmente semplicemente perché, nella stragrande maggioranza dei casi, non è necessario.

Originariamente inviato da ZeroSievert

Non ho proprio capito il senso di quello che hai scritto. In generale mi sembra che tu mi abbia messo in bocca cose che non ho mai detto.
Mi sembra abbastanza semplice il messaggio che volevo fare passare a 386 ovvero:

- quello che pensi sia utile/serva a te != quello che e' utile/serve al resto del mondo. E non capire sul momento l'utilita' di un oggetto di cui si hanno poche informazioni non e' una scusa per sparare a zero su questo.

Su questo siamo perfettamente d'accordo, è la retorica che non mi è piaciuta.

Originariamente inviato da ZeroSievert

Anche perche' senno' non sarebbero tanto differenti da un normale spazzolino elettrico. E anche la supposizione che, se fosse necessaria maggiore potenza di calcolo, sia preferibile appoggiarsi al cellulare per queste applicazioni, rimane una supposizione.

Uhm, quindi la maggior parte della gente ha un supercomputer in tasca, ma che sia meglio sfruttare quello che sia al posto di usarne un altro è "una supposizione".
OK

Originariamente inviato da ZeroSievert

Esempio stupido: se non hai il cellulare a portata oppure e' scarico.

Altri esempi altrettanto stupidi: se uno non ha Internet, oppure lo spazzolino è scarico.

[ZeroSievert]

Originariamente inviato da giuliop

Cosa che, infatti, ho fatto. Ora modifico il messaggio sopra con asterischi in grassetto per marcare il mio argomento, prova a rileggere.

Assolutamente no. Su un sistema di cui non conosci:

• Funzionalita'
• Prestazioni
• Consumi
• Memoria
• Algoritmi
• Pacchetti software disponibili

(quindi in pratica di cui non conosci niente)

hai stabilito che la metrica fondamentale sia la bruta velocita' d'esecuzione. E da qui hai detto che C/C++ e' il linguaggio migliore (perche' non assembly hand-tuned mi chiedo allora..).

Quindi sei partito da un'assunzione arbitraria per arrivare alla tua conclusione. Questa per me non e' una dimostrazione (che non puoi fornire per mancanza di informazioni).

Tra le altre cose questa delle prestazioni cade malamente se si fa una minima ricerchina. IMHO non hai molto ben presente cosa sia possibile fare oggi con qualche centinaio di mW.

Qua ad esempio vengono dichiarati 8-12 W di consumo durante l'uso di un generico spazzolino elettrico. Per confronto, qui il consumo di un Rpi Zero sotto stress e' dichiarato essere 0.83 W.

Un Rpi zero e' equipaggiato con un SoC ARM da 1 GHz e 512 MB di RAM. Quindi una bestiolina del genere impatterebbe di appena il 6-10% il consumo dello spazzolino. Limare molto di piu' i consumi del processore non aumenterebbe particolarmente l'autonomia.

Avere un SoC con potenza simile o anche decisamente inferiore al Rpi potrebbe non rendere necessario l'utilizzo esclusivo del C++ per la programmazione del sistema di controllo dello spazzolino. E a quel punto, con il parametro delle prestazioni piu' rilassato, altre considerazioni, tra cui quelle che ho fatto io, potrebbero avere un peso maggiore. Tipo che se trovi quello che ti vende le librerie in Java per il tuo prodotto eviti lo sviluppo in-house delle stesse e risparmi un sacco di tempo e soldi. O magari ti permette di usare un linguaggio memory safe su un dispositivo che sta 24h/24 esposto alla rete.

Ma se anche un Soc piu' potente impattasse di una percentuale maggiore sui consumi, si sta parlando comunque di un dispositivo che viene usato per 5-10 min a sessione prima di essere riposto sulla sua base. Ovvero consumi dell'ordine del Wh prima di ritornare attaccato alla rete. Io tutto questo terribile problema di autonomia non ce lo vedo

Oh, l'hai scritto eccome.
Hai elencato una serie di premesse e hai tirato queste conclusioni:


Finché ti limiti a dubitare l'onere della prova rimane a me, ma l'onere di provare i controargomenti è tuo, e solo tuo.

"Ha senso" per ribattere alla tua stroncatura senza se ne ma. Se vuoi potevo dire (come ho gia' fatto intendere in diverse maniere):

- Allo stato attuale delle nostre conoscenze riguardo al progetto in questione non ci sono elementi per affermare che il linguaggio di programmazione "Java" sia necessariamente inadatto all'applicazione che e' oggetto di discussione.

Meglio?

E io ti ho mostrato che questa lista non è un buon argomento per affermarlo; ora se vuoi continuare a sostenerlo, devi portare argomenti più convincenti.

Non hai dimostrato proprio niente. Come sopra. Sei partito, senza avere gli elementi di valutazione necessari, da assunzioni arbitrarie per arrivare a conclusioni arbitrarie.

OK; in quale modo le specifiche di progetto possono fare in modo che, per esempio, Java sia più efficiente?

Se ti stai riferendo ai consumi vedi sopra. Senno' specifica meglio.

OK, a questo punto ne stai facendo una questione di questione di giudizio di valore, certamente insindacabile. La mia risposta, sempre un giudizio di valore e altrettanto insindacabile, è che è demenziale accontentarsi del sufficiente e avere costi maggiori se è possibile avere una soluzione decisamente migliore a costi minori. Sei libero di non essere d'accordo.

Come sopra. Non hai gli elementi per dire che il C++ diminuisca i costi. Perche' se da una parte potresti avere un costo minore dell'hardware, dall'altra potresti avere maggiori costi di sviluppo e integrazione. Ne tu ne io abbiamo gli elementi per valutarlo.

Ma "quello che fa piu' comodo" a chi?
Non è chiaro che avere una soluzione che usa meno risorse e costa meno dovrebbe fare comodo al produttore dello spazzolino?

Come sopra. E' un modo di affrontare i problemi di sviluppo monodimensionale. E' sbagliato prendere una singola metrica (con assunzioni arbitrarie) per valutare le decisioni ingegneristiche su un determinato prodotto.

Dovresti spiegare cosa vuol dire "nel suo complesso rispetta meglio le specifiche di progetto", perché sinceramente faccio fatica a capirlo.

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

Casi specifici come quello di un microcontrollore che deve finire in uno spazzolino?

A S S U N Z I O N I A R B I T R A R I E

Non è irrilevante ma che non lo sia non vuol dire che non sia lo strumento migliore per lo scopo, è sempre questione di soppesare i pro e i contro.

Vedi che almeno una volta ogni venti quote siamo d'accordo?

"come anche no"

Sai, a costo di essere ripetitivo, voglio rimarcare che su questo progetto non conosciamo nulla e che quindi non e' possibile affermare che Java sia una cattiva scelta.

Perdona anche tu la sincerità, ma io invece mi sono fatto l'idea che sia invece tu che non hai la competenza necessaria per dare giudizi, da "a me Java , per quel poco che l'ho visto, non piace e non lo uso" a quell'elenco di punti che fanno pensare che esperienza di sviluppo su microcontrollori, a differenza di me*, tu non ne abbia proprio.
Mi sbaglio?

* Giusto per mostrare che non mi invento niente, da una veloce ricerca sul forum: 1, 2, 3.

Questa e' una fallacia. Che tu abbia esperienza o meno non ti permette di giudicare un progetto di cui non sai nulla.

Aggiungo inoltre che il fatto che tu sviluppi su microcontroller (di bassa potenza da quello che vedo) non sia assolutamente indice che tu sia capace di fare un corretto design di un prodotto. Anzi, il tuo modo superficiale di affrontare questo aspetto suggerisce il contrario. Ho la sensazione che parte del problema sia che tu pensi che tutti i problemi riguardanti il mondo embedded o quasi si possano risolvere con un microcontroller da una manciata di MHz o KB e programmazione bare-metal.

Io questo problema lo vedo periodicamente.

Es. dove sto io chi fa lo sviluppo hardware, software e firmware e' separato da chi fa ingegneria dei sistemi (Io nel tempo invece sono andato a rompere le p@lle quasi a tutti ). I colleghi che fanno solo sviluppo per il 100% del loro tempo sono estremamente competenti nel loro settore ma spesso mancano di visione d'insieme sui problemi da affrontare. E alla fine, nelle discussioni capita che la loro propongano design come quelli riprodotti nell'immagine sotto a seconda del loro ambito:



Ovviamente l'input e i feedback di chiunque sono ben accolti. Pero' parte del lavoro e' far capire agli specialisti come mai certe decisioni tecniche che riguardano un determinato sistema sono state prese. E sopra di me ci sono persone con visione d'insieme ancora piu' larga che coordinano lo sviluppo a piu' alto livello.

EDIT

E no. Anche solo il fatto di usare librerie standardizzate gia' incluse, se le caratteristiche del progetto te lo permettono, e' un grosso vantaggio anche in ambito embedded.
Anche solo avere sempre la stessa interfaccia per il networking, indipendentemente dalla piattaforma in cui sei, e' utilissimo da un punto di vista di debugging (posso far girare sul mio computer il codice senza tool appositi), velocita' di sviluppo(non mi devo imparare una nuova libreria ogni volta), portabilita' (se cambio vendor non devo rifare tutto da 0), sicurezza (visto che il codice non deve essere cambiato ad ogni nuova piattaforma, il rischio di introdurre nuovi bug e' ridotto), manutenzione (non devo avere N versioni del codice dove N e' il numero delle API che devono essere supportate).

E scusa se e' poco.

Non a caso anche in ambito embedded esistono OS e soluzioni, anche per C++, che forniscono una singola API su una moltitudine di diverse piattaforme per le motivazioni di cui sopra. Ovviamente il layer di astrazione("l'inutile fardello") costa qualcosa in termini di memoria e prestazioni. Ma e' un costo che in molti casi e' sensato pagare.

Che tu rigetti l'argomento in toto dimostra una visione estremamente limitata dell'informatica da parte tua. Divertente come tu mi lanci accuse da questo punto di vista.

Poi il resto delle argomentazioni del tipo "Java non e' semplice perche' forse potrebbe essere difficile installarlo" oppure "dei vendor che hanno gli IC come core business possono dare lo stesso supporto allo sviluppo software di una realta' come Oracle" non vale neanche la pena commentarle. Evidentemente in ambito embedded sviluppi solo progetti molto semplici se queste sono le tue "argomentazioni".

A me sembra che tu stia continuamente cercando di spostare i paletti, stiamo ancora parlando di quei [supposti] "Tre milioni di spazzolini elettrici smart utilizzati come rete botnet per un attacco DDoS", oppure di robe professionali che costano chissà cosa, e che dubito fortemente possano essere così diffusi?

Non sto spostando proprio niente (?).

EDIT

Comunque 3 milioni di spazzolini di fascia alta medio-alta venduti non e' un numero inverosimile. Solo contando il mercato USA ci sono 331 milioni di abitanti. 3 mln sono lo 0.9% della popolazione. E ci metto la mano sul fuoco che il numero di persone che puo' permettersi uno spazzolino da qualche centinaio di dollari sia ben maggiore.

Ti invito quindi a fare almeno una ricerchina la prossima volta prima di fare insinuazioni o congetture. Che qui nessuno, te compreso, ha la scienza infusa.

Il paragrafo sopra...?

Veramente stai mettendo in dubbio che una VM sia più lenta del codice nativo?

No, il mio commento era riferito al fatto che, per l'ennesima volta, tu dichiarassi come le prestazioni siano la parte piu' importante di uno spazzolino smart (ora ho grassettato la parte).

Ah, quindi ora Java non sarebbe semplicemente sufficiente, ma necessario?

Scusa ma che stai a di' . Dove leggeresti questo? Per te si programma in C/C++ solo in bare metal?

E questo, come già detto, dovrebbe essere il tuo dentista a dirtelo.

E come fa a dirmelo? Mi appare in sogno dicendo che il giorno prima non ho insistito abbastanza sulla parte interna del secondo molare sinistro?

Ma molto più probabilmente semplicemente perché, nella stragrande maggioranza dei casi, non è necessario.

Scusa ma non e' proprio compito tuo fare questo tipo di valutazioni

Su questo siamo perfettamente d'accordo, è la retorica che non mi è piaciuta.

Invece a me non piace che mi si mettano in bocca cose che non dico. Lo trovo poco corretto.

Uhm, quindi la maggior parte della gente ha un supercomputer in tasca, ma che sia meglio sfruttare quello che sia al posto di usarne un altro è "una supposizione".
OK

la potenza è nulla senza controllo


Per fare un esempio: a lavoro su un nostro sistema di controllo devo sviluppare un sistema di feedback su CPU. Il crate ha due processori:

• Un vetusto PowerPC 440 da 889 DMIPS che stiamo cercando di resuscitare
• Un Intel-i7 con due core fisici 9000 DMIPS/core e 4 GB di ram

Solo con queste informazioni si direbbe che l'i7 sia meglio. Ma:

• Dovrei trasferire avanti e indietro i dati da un bus PCIe che e' usato per muovere anche altra roba.
• Sull'i7 c'e' linux non realtime. Di conseguenza si ha un naturale jitter nella risposta
• Sull'i7 ci sono altre applicazioni pesanti che possono bloccare il mio task di feedback a lungo

Di contro il PowerPC eseguirebbe solo il mio task di feedback. Inoltre le informazioni verrebbero direttamente caricate su registri dello stesso. Ergo minore latenza e meno jitter.

Il PowerPC e' meno potente dell'I7? Si! Ma questo non significa che usare la CPU piu' potente nelle vicinanze sia sempre la soluzione migliore.

Il caso dello spazzolino e' simile ma peggio. Il sistema dovrebbe appoggiarsi alla rete wireless per scambiare informazioni con il cellulare. Cellulare che non e' assolutamente pensato per task di feedback e che potrebbe inserire ritardi notevoli se sovraccarico, peggiorando l'uso dello spazzolino e quindi la soddisfazione del cliente.

Scusa ma penso che inserire una dipendenza non necessaria da un dispositivo esterno (cellulare), con caratteristiche ignote (Il produttore non ha idea delle prestazioni del cellulare di ogni suo acquirente) e che puo' essere disponibile oppure no per le piu' svariate ragioni, sia cattiva progettazione della peggior specie. Soprattutto visto che con qualche spicciolo puoi mettere un SoC di tutto rispetto. SoC che ti permette di avere lo spazzolino indipendente dal cellulare, che puoi caratterizzare completamente in fase di sviluppo e su cui hai il controllo totale.

Altri esempi altrettanto stupidi: se uno non ha Internet, oppure lo spazzolino è scarico.

Immagino che se uno non ha Internet non si orienti su prodotti IoT? (temporaneamente o permanentemente?) Comunque non vedo il motivo per cui, se va via internet temporaneamente, lo spazzolino non possa essere utilizzato.
Da quello che ho capito leggendo in giro la parte IoT serve principalmente a comunicare al dentista da remoto i risultati dello scan dentale dello spazzolino giorno per giorno. Se per un giorno manca internet non credo sia un grosso problema.

Per la carica vedi sopra.

[zappy]

Originariamente inviato da raxas

comunque... non ha "videocamera", ed è connessa al web solo quando scelgo l'opzione (è un Samsung 40" 4k del 2017) e inoltre il browser è pesantissimo (mi è rimasto solo un aggiornamento di un paio di anni fa...) almeno per quello che scelgo di fare...
e magari c'è un trucco che bypassa la scelta dell'utente

hmmm.
quasi certamente si collega come quando e dove vuole....

Originariamente inviato da Krusty

Connesso anche quello. Ti dice quando hai goduto.
Funzionalità extra: mappatura della vagina.

banale.
Fa le statistiche con tutti gli utenti del mondo e tu ovviamente sei nella top ten o sul podio... Sempre che tu compri sempre l'ultimo modello, altrimenti vieni classificato come schiappa moscia e i tuoi dati sono pubblicati su tutti i social ed additati al pubblico ludibrio...

Originariamente inviato da ZeroSievert

Comunque a quelli che dicono "a cosa serve lo spazzolino smart?"....
Non ne ero a conoscenza, ma esistono spazzolini che:

- dicono in tempo reale se ti stai lavando correttamente i denti
- ti fanno la mappatura dello stato della dentatura
- vedono se ci sono problemi (e.g. accumulo placca) e ti suggeriscono quando intervenire.

Bisogna vedere quanto siano effettivamente efficaci questi dispositivi. Ma se funzionassero non e' un'applicazione per niente stupida.

Meglio spendere qualcosa in piú per un dispositivi di medicina preventiva che piangere dopo dal dentista che ti deve rifare la bocca (con il portafoglio che piange con te).

Ovviamente problemi come quello della news sono incidenti di percorso che possono accadere.

ma per favore, sembra lo spot di una casa produttrice.
dai, dillo che sei del marketing e sei pagato per suggerire qua e là l'utilità di una emerita ciofeca che dirà sempre che sei bravissimo perchè usi il prodotto xy...
poi lo lasci lì per 1 mese e quando lo riprendi sarà programmato per dirti che stai per perdere tutti i denti... salvo che se usi il nuovo modello yx 4° gen che ti salverà la dentatura, e tutti vissero felici e contenti

ho già letto altri tuoi post "entusiasti" per fesserie... dai, su... NON hai passato il test di Turing...

[ZeroSievert]

Originariamente inviato da zappy

...

Credo di aver sentito una mosca ronzare.

[raxas]

Originariamente inviato da zappy

hmmm.
quasi certamente si collega come quando e dove vuole....

non cerco ipotesi ma non sono così ingenuo da pensare che sia tutto "lindo",
non mi sorprenderebbe l'interesse nelle abitudini degli utenti-consumatori,
avevo già letto anni fa del pericolo intrusione,
ho anche probabilmente esagerato chiamare la mia come Smart Tv, del 2014 comunque, non 2017 (è una UE40JU6400) ed è UHD 4k... ha sì... uno Smart hub ma non ha una videocamera... o almeno non risulta tra le caratteristiche,
qualora sia celata all'utente, bè, comunque non so che "profilazione" debbano fare, e cosa se ne vorrebero fare... / ma non mi sorprenderebbe...

- per il resto... la discussione, a visione di uno sconoscitore, e non penso ci sia necessità di retorica... ritengo che sia proseguita con contributo che fa emergere delle competenze aderenti all'ambito

[zappy]

Originariamente inviato da raxas

non cerco ipotesi ma non sono così ingenuo da pensare che sia tutto "lindo",
non mi sorprenderebbe l'interesse nelle abitudini degli utenti-consumatori,
avevo già letto anni fa del pericolo intrusione,
ho anche probabilmente esagerato chiamare la mia come Smart Tv, del 2014 comunque, non 2017 (è una UE40JU6400) ed è UHD 4k... ha sì... uno Smart hub ma non ha una videocamera... o almeno non risulta tra le caratteristiche,
qualora sia celata all'utente, bè, comunque non so che "profilazione" debbano fare, e cosa se ne vorrebero fare... / ma non mi sorprenderebbe...

cercando in giro ci sono ricerche in merito all'uso che le tv fanno della connessione internet.

[!fazz]

Originariamente inviato da biometallo

Segnalo che l'articolo è stato aggiornato:


Aggiornamento: come segnalato da un utente di cyberplace, la notizia potrebbe essere un falso generato da una errata interpretazione (nel caso in cui saremmo incappati anche noi). Quanto illustrato da Stefan Zuger sarebbe uno scenario plausibile, ma mai avvenuto realmente.

L'intento era di dimostrare il rischio legato anche a quelli che appaiono come dispositivi innocui, come uno spazzolino da denti. Si tratterebbe quindi solo di un esempio, per mettere in guardia sui rischi dell'IoT (Internet of Things) che sta abbracciando sempre più dispositivi di uso quotidiano, ma che in molti casi presentano sistemi di sicurezza inadeguati.

Attualmente, come sottolineato in precedenza, non viene citato alcun soggetto coinvolto. Come Forbes, a questo punto ci chiediamo se quanto riportato dalla testata svizzera sia realmente accaduto o meno. Naturalmente, vi terremo aggiornati in caso di ulteriori sviluppi.




Non credo che abbia senso mettere una backdoor in un dispositivo che già normalmente invia al produttore ogni dato raccolto...






E che ci volevi IOS sullo spazzolino?
....
....
E' ora che Apple pensi alla nostra sicurezza è ora di Ai spazzolin.

di solito i dispositivi iot sono piene di backdoor da banali connessioni di test a bootloader standard che permettono l'upload di firmware non firmato come il classico uboot fino a pagine web che danno accesso a cli con privilegi di root.
il perchè? per velocizzare il processo di sviluppo di sw alla Mickey Rourke in ironman 2.

Originariamente inviato da ZeroSievert

E perche' non avrebbe senso? Tu cosa avresti usato? E' una versione di Java specificatamente pensata per i dispositivi embedded. E Java:

- E' conosciuto da moltissimi sviluppatori. Ergo e' piu' semplice assumere qualcuno che lo sappia usare.
- E' abbastanza semplice e quindi puoi arrivare a un risultato velocemente se non devi fare cose esoteriche o con performance estreme. Quindi time-to-market piu' breve.
- E' "battery-included" ed e' molto orientato al networking. Non devi impazzire con le dipendenze ne con le licenze.
- Oracle fornisce un servizio clienti ufficiale/training/tutorial etc.
- Il codice e' portabile su tutte le piattaforme supportate dalla JVM

Ha quindi molto senso IMHO che un'azienda non-IT o una piccola realta' abbia usato questo strumento per un dispositivo che si connette alla rete.

Poi che non piaccia il linguaggio (a me Java , per quel poco che l'ho visto, non piace e non lo uso) o che ci possano essere alternative e' un altro discorso.

Che si debba stroncare uno strumento se non si sanno esattamente i requisiti del prodotto in questione mi sembra un poco presuntuoso.

Anche perche', da quello che mi sembra, oltre a sapere che questi dispositivi sono spazzolini che si connettono alla rete non si sanno molte altre informazioni.

EDIT:

Aggiungo tra i vantaggi che probabilmente su NetBeans e' possibile fare qualsiasi cosa inerente al ciclo di sviluppo del prodotto. Dalla scrittura del codice al deployment. Ed e' un vantaggio non da poco per un team piccolo fare tutto con un singolo tool, anche se meno flessibile, invece che con N diversi.

di solito non si usano linguaggi ad alto livello su sistemi mcu e di solito non ci si usa java la scelta di usare un linguaggio del genere significa che hanno usato personale non qualificato probabilmente riclicato da altri ambiti (tipo il bancario dove java era molto utilizzato e che sta andando in phase out) in quanto qualsiasi firmware developer conosce linguaggi di basso livello e di solito si specializza su un architettura di mcu.

tutto il resto dei presunti vantaggi di java e netbeans che hai scritto significa che non conosci nulla dell'ambiente di sviluppo a mcu? perchè pensi che per sviluppare su micro bisogna utilizzare mille tool esoterici che rallentano il lavoro ? ora è tutto impostato se usi un ide serio si fa tutto con quello dalla scrittura del codice al debug al deploy alla gestione delle diverse toolchain di svilupppo fino alla gestione dell'ota
poi parlare di oracle e supporto significa che non hai mai provato ad usare oracle senza avere dietro una società da billion con un supporto paid da nmila euri all'anno. mentre su mcu anche se sei piccolo il reseller fa da tramite con i field engineer anche per pochi pezzi annui.


tornando a bomba che tool utilizzare per creare uno spazzolino smart? ci sono diverse opzioni

opzione barbone style con un minimo di esperienza in mcu che è probabilmente quella utilizzata,

prendo un hw ultra scrauso che costa pochi centesimi e che ha uno sputo di capacità di calcolo ma con wifi e bt (esp32) che è probabilmente la scelta che farei io nel progettare una scheda per un sistema che costa pochi euro all inclusive

a questo punto o uso la toolchain del produttore (che è una cli ) e il codice me lo scrivo bare to metal utilizzando qualsiasi editor che mi piaccia anche notepad++


opzione barone style senza il minimo di esperienza in mcu installo vscode che ha un plugin apposta per la gestione di queste mcu scrause (platform.io) scrivo il codice partendo da esempi dal forum di arduino e tiro su un codice del genere in meno di un giorno anche con esperienza minima (ci sono librerie che fanno tutto dalle api rest alla comunicazione ble con letteralmente 10 righe di codice

opzione sono uno sviluppatore fw serio: uso un tool professionale in grado di creare codice ottimizzato e programmo mediante jtag il micro ottenendo di piallare il bootloader (libero memoria ) sfruttando al massimo tutto l'hw disponibile cosa che è inutile su un applicazione del genere


tutte le opzioni ti danno la possibilità di fare debug e deploy in letteralmente 1 click e qualche secondo (decina di secondi utilizzando le prime due opzioni con il bootloader pochi secondi la terza)

riguardo al fatto che secondo te lo sviluppo in java è facilitato
giusto per farti capire lo sforzo di implementazione: la cosa più complicata in un sistema del genere è sicuramente l'invio dei dati verso una piattaforma cloud preferibilmente sicura.

ora effettuare una http post verso un server remoto aws gestendo pure la sicurezza mediante https e api key con un sistema del genere si fa con queste righe di codice (a meno della gestione errori)

const char *server = "https://[server address]"; // Server URL 
void SendInformationToHttps(String sTemp)
{
  HTTPClient http;
  http.begin(server))
    http.addHeader("x-api-key", "[api key]");
    http.addHeader("Content-Type", "application/json");
    http.addHeader("Host", "[host]");
    String payload = "[json string]";
    int httpCode = http.POST(payload);
    http.end();
}

come vedi è praticamente identico che usare un linguaggio ad alto livello

tl:dr my 2 cents

[ZeroSievert]

Originariamente inviato da !fazz

...

Eh vabbe' guarda. Che ti devo dire. Hai ragione tu e quelli che hanno sviluppato lo spazzolino sono sicuramente dei c*glioni che si sabotano da soli e hanno scelto Java per farsi male.

Per me la discussione finisce qua. Mi sembra che si facciano troppe assunzioni su un oggetto di cui non si sa praticamente niente.

Oh. Poi se qualcuno mi posta qui tutte le caratteristiche del progetto riguardante questo spazzolino (o spazzolini? Anche questo non mi e' al 100% chiaro) e mi dimostra da queste che Java sia stata una scelta scema sono disposto a dargli ragione (again, non mi frega difendere Java). Mi da fastidio pero' che si critichi il lavoro altrui senza cognizione di causa.