Aquí comparto algunos tutoriales que me han servido para configurar ciertos servicios en rpi 3 b con una distro raspbian basada e debian buster.
Para montar una usb https://geekytheory.com/tutorial-raspberry-pi-6-montar-usb-disco-duro
Cliente transmission https://www.atareao.es/tutorial/raspberry-pi-primeros-pasos/transmission-en-raspberry-pi/
VPN PPTP https://help.ubuntu.com/community/PPTPServer
Copy y paste: https://chartio.com/resources/tutorials/understanding-strorage-sizes-for-mysql-text-data-types/
TEXT data objects, as their namesake implies, are useful for storing long-form text strings in a MySQL database. The four TEXT data object types are built for storing and displaying substantial amounts of information as opposed to other data object types that are helpful with tasks like sorting and searching columns or handling smaller configuration-based options for a larger project. The different TEXT objects offer a range of storage space from 1 byte to 4 GB and are not designed for storing computational values. It’s common to see these used to store product descriptions for a sales site, property summaries for realty database, and long-form article text on a news website. TEXT objects are best used when VARCHAR and other string-based data objects are insufficient to handle storing the desired amount of information. However, the smallest TEXT type, TINYTEXT, shares the same character length as VARCHAR. TEXT objects differentiate themselves from other string storage types by removing the requirement to specify a storage length, not stripping bytes when selected, and do not pad unused character space for efficient disk storage. Since TEXT objects are not stored in the server’s memory, they require data overhead for retrieval. The following sizes assume the database is using the UTF-8 encoding.
The TINYTEXT data object is the smallest of the TEXT family and is built to efficiently store short information strings. This type can store up to 255 bytes (expressed as 2^8 -1) or 255 characters and requires a 1 byte overhead. This object can be used to store things like short summaries, URL links, and other shorter objects. TINYTEXT shines over VARCHAR when storing data that’s under 255 characters with an inconsistent length and no need to be used for sorting criteria.
The standard TEXT data object is sufficiently capable of handling typical long-form text content. TEXT data objects top out at 64 KB (expressed as 2^16 -1) or 65,535 characters and requires a 2 byte overhead. It is sufficiently large enough to hold text for something like an article, but would not be sufficient for holding the text of an entire book.
The MEDIUMTEXT data object is useful for storing larger text strings like white papers, books, and code backup. These data objects can be as large as 16 MB (expressed as 24^2 -1) or 16,777,215 characters and require 3 bytes of overhead storage.
The LONGTEXT data object is for use in extreme text string storage use cases. It is a viable option when the MEDIUMTEXT object is not big enough. Computer programs and applications often reach text lengths in the LONGTEXT range. These data objects can be as large as 4 GB (expressed as 2^32 -1) and store up to 4,294,967,295 characters with 4 bytes of overhead storage,
BLOBs are an alternative type of data storage that share matching naming and capacity mechanisms with TEXT objects. However, BLOBs are binary strings with no character set sorting, so they are treated as numeric values while TEXT objects are treated as character strings. This differentiation is important for sorting information. BLOBs are used to store data files like images, videos, and executables.
TEXT fields for select and search queries will incur performance hits because the server will call the objects individually and scan them during the query instead of paging data stored in the memory.TEXT columns require an index prefix length and can’t have DEFAULT values, unlike CHAR and VARCHAR objects.TINYTEXT’s 255 character capacity is insufficient for this use case, while TEXT’s 65535 character capacity offers storage for articles that hit over 11,900 words based on the average criteria.lenguaje de consulta, se presenta como una alternativa a rest y esta pensada en la optmizacion de la comunicacion entre el servidor y el cliente.
Traslada la responsabilidad de los datos que se entregan hacia el cliente. Este decide que datos pedir. Logrando evitar solicitudes innecesarias al servidor.
Rest
Es solo una convención: Es una manera de comunicarse entre el servidor y cliente, cada uno tiene sus reglas.
GraphQL
Lenguaje tipado y validable: Le damos una forma de lo que recibe y lo que devolvemos. Ademas que le agrega seguridad
Rest
Servidor expone recursos: Los clientes se tienen que adecuarse a como están expuestos
GraphQL
El cliente define que recibe: Haciendo una consulta, de la estructura que define como respuesta
Rest
Hace overfetching: Envía más información que necesita
GraphQL
Envía lo necesario: Se tiene control total de las respuestas que se esperan del servidor
Rest
Multiples request por vista: Muy costoso en performance, básicamente es
una aplicación en blanco que aún no ha cargado datos o tiene custom
endpoints
GraphQL
Hace solo un request por vista: Enviados en un solo row
Rest
Documentación ajena al desarrollo: No hay un estándar por lo que depende mucho del desarrollador para mantenerla.
GraphQL
Documentado por definición.
Documentado por definición: Al ser un lenguaje tipado se define un schema que ya esta documentado por definiciòn
Un problema de clasificación busca encontrar un sistema que permita identificar automáticamente para cada objeto la clase a la cual pertenece.