fix: update .gitignore to include all bibliography auxiliary files and correct student term in use case
Some checks failed
Build LaTeX Document / build_latex (push) Has been cancelled

This commit is contained in:
2025-03-15 21:38:02 +01:00
parent 89ca38cd85
commit b57abd5738
2 changed files with 29 additions and 89 deletions

2
.gitignore vendored
View File

@@ -28,7 +28,7 @@ Tesi.pdf
.vscode .vscode
## Bibliography auxiliary files (bibtex/biblatex/biber): ## Bibliography auxiliary files (bibtex/biblatex/biber):
*.bbl *.bbl*
*.bcf *.bcf
*.blg *.blg
*-blx.aux *-blx.aux

116
Tesi.tex
View File

@@ -241,60 +241,48 @@ Vediamo degli esempi di come questa interazione potrebbe essere svolta:
\usecase{Esempio d'interazione ``one to many''}{Unazienda per questioni legate alla sicurezza sul lavoro si ritrova con la necessitò di dover fare dei ``workshop'' in diretta ai propri dipendenti con diverse locazioni sparse per il nel mondo senza utilizzare però grandi servizi cloud dato lelevato costo di banda e di noleggio del servizio per singolo utente finale, in questo caso il singolo dipendente}{Dipendenti, azienda}{Video streaming dei ``workshop'' per i dipendenti sparsi per il mondo}{} \usecase{Esempio d'interazione ``one to many''}{Unazienda per questioni legate alla sicurezza sul lavoro si ritrova con la necessitò di dover fare dei ``workshop'' in diretta ai propri dipendenti con diverse locazioni sparse per il nel mondo senza utilizzare però grandi servizi cloud dato lelevato costo di banda e di noleggio del servizio per singolo utente finale, in questo caso il singolo dipendente}{Dipendenti, azienda}{Video streaming dei ``workshop'' per i dipendenti sparsi per il mondo}{}
\usecase{Esempio d'interazione ``one to many''}{Un gruppo di amici deve svolgere un progetto universitario assieme e quindi interagire tra di loro facendo pair programming condividendo lo schermo gli uni con gli altri. Per questioni di privacy e sicurezza non vuole utilizzare un servizio pubblico come Discord in quanto vorrebbero tenere tutto segreto fino al giorno della presentazione}{Studneti}{Pair programming}{} \usecase{Esempio d'interazione ``one to many''}{Un gruppo di amici deve svolgere un progetto universitario assieme e quindi interagire tra di loro facendo pair programming condividendo lo schermo gli uni con gli altri. Per questioni di privacy e sicurezza non vuole utilizzare un servizio pubblico come Discord in quanto vorrebbero tenere tutto segreto fino al giorno della presentazione}{Studenti}{Pair programming}{}
\usecase{Esempio d'interazione ``one to many''}{Una casa produttrice di film emergente vuole condividere i nuovi film in produzione con dei trailer ma a causa di dispute legate ai DRM, copyright e content strike di altre aziende più grandi non vuole utilizzare dei servizi già esistenti con EULA molto restringenti ma vuole avere il controllo dei propri diritti sul contenuto creato da essa stessa}{Filmmakers, appassionati di film}{Condivisione degli ultimi trailer per i film prodotti dalla casa}{} \usecase{Esempio d'interazione ``one to many''}{Una casa produttrice di film emergente vuole condividere i nuovi film in produzione con dei trailer ma a causa di dispute legate ai DRM, copyright e content strike di altre aziende più grandi non vuole utilizzare dei servizi già esistenti con EULA molto restringenti ma vuole avere il controllo dei propri diritti sul contenuto creato da essa stessa}{Filmmakers, appassionati di film}{Condivisione degli ultimi trailer per i film prodotti dalla casa}{}
\pagebreak \usecase{Esempio d'interazione ``one to many''}{Un gruppo di amici vuole fare una serata di gioco online e vuole condividere il proprio schermo con gli altri giocatori per poter giocare assieme}{Gamer}{Condivisione dello schermo per giocare assieme}{}
In tutti i casi elencati sopra (ma anche in molti altri) emerge dalla nostra intuizione la necessità per un attore di eseguire uno streaming uno a molti o molti a molti senza utilizzare un servizio “cloud” già esistente proprietario ma utilizzando un software con licenza libera, senza dover fare il deploy di un intera infrastruttura HW globale, soddisfare le elevate richieste di banda richieste dalla natura dei contenuti video.
Azienda: \break
In sintesi, l'analisi dei casi d'uso evidenzia la necessità di una soluzione di streaming decentralizzata e a licenza libera, capace di operare in modalità uno-a-molti o molti-a-molti, senza affidarsi a servizi cloud proprietari e senza richiedere il deploy di una complessa infrastruttura hardware globale. I requisiti fondamentali, soprattutto in relazione all'elevato fabbisogno di banda tipico dei contenuti video, si declinano nei seguenti scenari applicativi:
\hfill\break
\textbf{Commerciale:}
\begin{itemize} \begin{itemize}
\item Live stream di un evento/riunione interna \item Streaming di eventi o riunioni interne,
\item Assistenza remota,
\item Assistenza remota \item Conference calls,
\item Possibilità di operare sia come utente che come provider/distributore,
\item Conference calls \item Ottimizzazione dei costi e del consumo della banda.
\item come utente o come provider (distributore)
\item Riduzione dei costi/banda necessaria
\end{itemize} \end{itemize}
Education: \hfill\break
\textbf{Educazionale:}
\begin{itemize} \begin{itemize}
\item Live courses \item Trasmissione in diretta di corsi e lezioni.
\end{itemize} \end{itemize}
\hfill\break
Common Joe: \textbf{Sociale:}
\begin{itemize} \begin{itemize}
\item Lan party \item Organizzazione di lan party,
\item Supporto per streaming di gaming e attività live da parte di streamer,
\item Gaming/Streamer \item Conference calls in piccoli gruppi,
\item Impiego per telecamere di sicurezza,
\item Conference calls \item Moderazione dei contenuti online.
\item Security cameras
\item Content moderation
\item Small friends group live sharing
\end{itemize} \end{itemize}
Governo: \hfill\break
\textbf{Istituzionale:}
\begin{itemize} \begin{itemize}
\item Comunicazioni video di emergenza \item Comunicazioni video in situazioni di emergenza.
\item Click day like overload avoidance
\end{itemize} \end{itemize}
Common Lizard:
Metaverso, qualsiasi cosa sarà
\chapter{Stato attuale del software} \chapter{Stato attuale del software}
\epigraph{In questo capitolo andremo ad esplorare ed analizzare tutte le situazioni e le tecnologie attualmente esistenti che possono essere applicate}{} \epigraph{In questo capitolo andremo ad esplorare ed analizzare tutte le situazioni e le tecnologie attualmente esistenti che possono essere applicate}{}
\section{Nomenclatura} \section{Nomenclatura}
@@ -475,57 +463,9 @@ In conclusione, Ace Stream è un software potente e versatile per lo streaming d
\pagebreak \pagebreak
\newpage \newpage
\section{} \chapter{PeerTube}
\section{Decentralizzazione e federazione} \chapter{Analisi e confronto}
\chapter{La piattaforma ideale}
\section{Soluzione ideale}
\todo{Iniziare a spiegare come creare questa piattaforma ideale vs sistemi centralizzati esistenti}
In base a quello che abbiamo esposto fin'ora sorge spontanea la domanda e di conseguenza la ricerca di una piattaforma decentralizzata che soddisfi alcuni requisiti essenziali o meno.
\\Possiamo azzardare a stilare l'elenco di requisiti e features che vorremmo fossero presenti in questa piattaforma decentralizzata:
\begin{enumerate}
\item Decentralizzazione totale della infrastruttura
%\begin{description}
%\item Quindi eliminazione del rischio di controllo da parte di un singolo provider
%\item[Note:] I would like to describe something here
%\end{description}
\item Facilità nell'utilizzo
\item Basso costo di entrata
\item Interazione tra utenti in real time
\item Moderazione
\item Bassa latenza
\item Possibilità di monetizzazione del contenuto da parte dei singoli utenti
\item Altro? Si accettano proposte
\end{enumerate}
Andiamo ad analizzare meglio la nostra proposta:
\newpage
\todo{mirko: Sarebbe magari utile usare uno spettro come viene fatto nel libro di Cittadinanza digitale?
atrent: per ora non ne vedo utilità, vediamo come si sviluppa prima l'outline}
Punto 1: Quindi eliminazione del rischio di controllo da parte di un singolo, Resistenza agli attacchi DDOS, no single point of failure
Punto 2: Se la piattaforma è accessibile via Web o standalone app, o mobile app, se ci sono situazioni di relatività della rete con blocco di porte non standard e/o protocolli
Punto 3: È relazionato al punto 2 con la questione di facilità di accesso e utilizzo rispetto a piattaforme già esistenti PERO' nello specifico sarebbe più la parte di facilità di passaggio da una piattaforma all'altra da parte degli streamer e nella compatibilità dei software/strumenti
Punto 4: Banalmente come fa twitch e youtube live una chat pubblica tra utenti (quindi con autenticazione), in caso di conference audio/video condiviso tra più utenti in real time
Punto 5: moderazione degli utenti/streamer se ha senso farla
Punto 6: relazionato al punto 1, abbastanza ovvia come cosa
Punto 7: io la penso come incentivo da parte di una rete/piattaforma di attrarre nuove utenze
\section{Realizzazioni e implementazioni possibili ad oggi}
\subsection{Possibili problemi nella realizzazione}
\subsubsection{Brevetti, copyright, DRM, moderazione dei contenuti e degli utenti}
\subsubsection{Necessità di competizione}
\section{Varie sottosezioni per tutti i modi in cui si potrebbe realizzare ora}
\subsection{Protocolli/Software Stack: P2P, Matrix, Jitsi, Crowd CDN, standalone apps, etc \dots}
\section{Uno sguardo al futuro}
\chapter{Conclusioni} \chapter{Conclusioni}