Modo kiosco Ubuntu para menús de restaurante: guía de configuración

Modo kiosco Ubuntu para menús de restaurante: guía de configuración
kiosk mode ubuntu ubuntu kiosk chromium kiosk wayland kiosk linux kiosk

Si estás configurando un kiosco Ubuntu ahora mismo, probablemente no estás montando un proycto de laboratoro. Estás intentando mantener un menú, una página de pedidos o una pantalla de cara al cliente fun cionando durante el servicio sin que nadie toque el escritorio, active actualizaciones o te deje con una pantalla negra y un encargado preguntando por qué la pantalla se ha vuelto a apagar.

Eso cambia la forma de construir el modo kiosco en Ubuntu. Las configuraciones limpias de demostración no son suficientes. Un kiosco en un restaurante debe resistir el maltrato táctil, los microcortes de energía, los fallos del navegador, las sesiones caducadas y al empleado que siempre encuentra el gesto de esquina que sale de pantalla completa. La buena noticia es que Ubuntu ha soportado la administración tipo kiosco durante mucho tiempo. La Wiki de Ayuda de la Comunidad Ubuntu ha documentado KioskMode desde el 1 de agosto de 2015, con actualizaciones tan recientes como el 2 de mayo de 2026, lo que deja claro que esto no es un truco de nicho nuevo sino un patrón de larga duración en la administración de Ubuntu (documentación de KioskMode de Ubuntu).

Tabla de Contenidos

Por qué los kioscos Ubuntu fallan en el mundo real

Un sábado a las 9 de la noche a nadie le importa que el kiosco haya pasado las pruebas en un banco de trabajo el martes por la tarde. Importa que la pantalla del menú se haya qedado en blanco, que Chromium haya vuelto con un mensaje de restauración después de un corte de energía brusco, o que un miembro del personal haya encontrado una forma de acceder al escrittorio mientras intentaba desbloquear la página.

Así es como suelen fallar los kioscos Ubuntu. No porque Ubuntu no pueda hacer el trabajo de kiosco, sino porque una installación de escrittorio por defecto sigue comp ortándose como un escrittorio. Quiere suspenderse, espera apagados limpios, conserva el estado del usuario y asume que la persona que toca la pantala tiene permitido acceder a la configuración si hace suficientes clics.

E he visto esto con mayor frec uencia en carteles de menú y pantallas de autoservicio de restaurantes. La installación parece estable durante la configuración. Luego empieza el servicio, se toca el disposi tivo todo el día, se corta la corriente del circuito detrás de la pantalla sin previo aviso, y eventualmente alguien conecta un teclado porque "la pantalla se quedó colgada". Las vijas recetas con LightDM y X11 lograban realizar muchos de estos trabajos, pero también dejaban muchas vías de escape. Los enfoques más nuevos basados en Wayland cierran algunas de esas brechas, a la vez que introducen diferentes opciones operativas.

Los fallos comunes que cuestan tiempo de servicio

Regla práctica: Si un fallo normal del navegador aún requiere una persona en el lugar, el kiosco no está listo para producción.

El punto débil no suele ser "aplicación web versus aplicacción nativa". La decisión clave es cuánto de la pila del escrittorio está dispues to a dejar en su lugar. Las antiguas construcciones de kiosco Ubuntu a menudo usaban LightDM, un usuario de autoinicio y un script de lanzamiento de navegador en X11. Eso todavía puede funcionar, especialmene en hardware más antiguo o en locales donde ya conoce las rarezas. También deja más piezas que vigilar. Las sessiones modernas de kiosco Wayland y las configuraciones de tipo disposittivo elim inan parte de esa superf icie, pero pueden ser menos indulgentes si nec esita periféricos personalizados, herrammientas de señalización legadas o controladores de pantalla táctil poco comunes.

Un despl iogue de menú de restaurante hace evidente la compensación. Si la máquina solo nec esita arrancar, mostrar TopFoodApp, recuperarse de un fallo y nunca exponer el escrittorio, una sesión de kiosco reducida es más fácil de soportar que un escrittorio GNOME coleto disfrazado. Si el local también nec esita herramientas de soporte remoto, pruebas de impresora, inicios de sesión del personal o sol ución de problemas puntual en la misma caa, el patrón basado en escrittorio es tentador. Esa comodidad suele ser lo primero que falla.

Lo que realmente aguanta

Los kioscos Ubuntu que sobreviven los fines de semana son los aburridos. Usan un usuario de kiosco dedicado. Desactivan el apagado de pantalla y la suspensión a nivel del sistema operativo y de la sesión. Lanzan el navegador desde una ruta de inicio controlada, no desde un perfil de shell aleatorio. Limpian o contienen el estado del navegador. Reinician la aplicación automáticamente si sale.

Las guías de kiosco más recientes de Canonical se han movido hacia la implementación nativa de Wayland en lugar del patrón anterior de "escritorio más navegador en pantalla completa", lo que es una señ al útil in cluso si aún elige X11 por razones de compatible idad (Ubuntu Frame y dirección moderna del kiosco).

Lo que aguanta en producción no es la construcción más bonita. Es la que tiene menos piezas móviles y aún puede soportar su hardware, su navegador y su plan de recuperación. Ese es el estándar que uso para las pantallas de menú en cafeterías y bares, porque la máquina eventualmente se reiniciará de forma incorrecta, se tocará con las manos mojadas y se le culpará por un problema de red que no causó.

Elegir el enfoque de kiosco adecuado

A las 4 de la tarde, un kiosco con Ubuntu de escrittorio comple to parece flexible. A las 9 de la noche, cuando la pantalla del menú se ha caído a un mensaje de inicio de sesión y el personal se prepara para la hora punta de la cena, la flexibilidad suele ser el problema.

Ubuntu le ofrece tres patrones de kiosco que siguen siendo prácticos hoy. Los trato como tres modeloss de fallo diferentes. La vieja receta X11 con LightDM es fácil de inspecc ionar y ráp ida de reparar en el sitio. El enfoque más nuevo Wayland y Frame elim ina gran parte del equipaje del escrittor io, pero pide aceptar un flujo de trabajo más tipo electrodom éstico. Un kiosco simple de navegador se sitúa en el medio y sigue siendo la respuest a correcta para muchos tableros de menú de restauranes.

Kiosco con navegador para un solo local

Un kiosco Chromium o Firefox encaja mejor cuando TopFoodApp ya se eje cuta en el navegador y el trabajo de la pantalla es simple: arrancar, conec tarse, mostrar el menú, recuperarse si el navegador sale.

Este es el camino que sigo utilizando primero para un solo restaurante o un bar con una o dos pantallas. Se ajusta limpiamente al viejo manual de administración de Ubuntu: usuario ded icado, autoinicio de sesión, inicio de sesión controlado, navegador en pantalla comple ta, rutas de salida restringidas. Si el sitio web es el producto, empaquet arlo como una aplicación nativa a menudo añade trabajo sin sol ucionar los problemas que le despiertan por la noche.

Esos problemas son operativos. Los perfi les del navegador se vuelven sucios. El estado en caché se vuelve obsoleto. Una actualización del navegador puede cambiar el comport amiento de reproducción automática, v entanas emergentes o GPU sin previo aviso. Nada de eso convierte a los kioscos de navegador en una mala elección. Signifi ca que necesita una configuración que pueda restablecer ráp idamente.

Kiosco basado en Snap para instala ciones de disposititvo más simpples

Canonical ha impulsado los despliegues de kiosco Ubuntu hacia herrammientas nativas de Wayland por una raz ón. La vieja pila de escrittorio funciona, pero lleva muchas partes que no necesita en una pantalla de menú montada en la pared. El tutorial más antiguo de kiosco Wayland de Canonical ahora dirige a los lectores hacia métodoss más nue vos, lo que es un mar cad or út il de hacia dónde ha ido la dirección del kiosco de Ubuntu (tutorial de kiosco Wayland de Ubuntu).

Para un operador de restaurante que quiere menos ajustes a nivel de sesión, Ubuntu Frame y un paquete de aplicación de kiosco pueden ser más limpios que mant ener LightDM, archivos de sesión X11, ind icadores del navegador y anulaciones de escrittorio. Las guías de la comunid ad para ese modello gen eralmente siguen el mismo patrón: instalar Frame, instalar la aplicación de kiosco, conec tarla al servidor de visualización y dejar que el sistema arranque directa mente en la superfi cie de la aplicación (flujo de configuración est ilo Ubuntu Frame).

Ese modello más limpio tiene una contrapartida. Los arreglos improvisados son menos convenientes. Si el personal quiere "solo un escrittorio ráp ido" para probar la impresora o revisar el correo electrónico, este enfoque se lo impide, lo que gen eralmente es algo bueno en una pantalla de menú de cara al púb lico.

Si su aplicación ya se distr ibuye en un envoltorio mó vil y la dec isión de hardwa re aún está abierta, compare esto con el comple mento Capacitor Kiosk para Android. El hardwa re Android puede encajar mejor cuando nec esita una aplicación únca más estricta que un mini PC Ubuntu reutili zado.

Ubuntu Core y Frame para flotas

Para múltiples locales, Ubuntu Core con Ubuntu Frame es el que elegiría a propósito en lugar de derivar hacia él. Se comp orta más como un electrodom éstico que como un escrittorio mant enido. Eso importa cuando tiene pantallas en varios restaurantes y nadie en el lugar deber ía editar archivos de inicio despu és de cerrar.

El cost o es la flexibilidad. Se pierde algo de la vieja costumbre de Ubuntu de ini ciar sesión, cambiar un script y volver a trabajar en cinco minutos. Para un solo tablero de menú encima de un mostrador, eso puede sentirse pesado. Para una flota, a menudo se paga solo al mant ener cada caja consistente.

Comparativa de enfoques de kiosco en Ubuntu

thead> < td>Fácil de depurar localmente, pero más fácil de romper /tbody>
Enfoque Mejor para Aactualizac iones R ecuperación F ijación
K iosco de navegador en Ubuntu Desktop Cafeterías ind ividuales, bares, pantallas de menú únicas Gestionado a través de apt y config uración del navegador B aja
K iosco basado en Snap Pequeñas cadenas que quieren instala ciones repetibles Gestionado por Snap y centrado en la aplicación Mod elo de reinicio de aplicación más limpio M edia
Ubuntu Core y Frame Flotas multi-local y construcciones de electrodom éstico Transaccional, flujo de trabajo tipo imagen Mayor consistencia entre dispos itivos Alta

La pregunta clave no es "web o nativa". Es si desea mantener una sesión de escrittorio, un ti empo de ejecución de aplicación o un electrodom éstico bloqead o.

Para pantallas de menú de restaurante, sigo com enzando con el kiosco de navegador a menos que haya una razón clara para dejar el viejo patrón X11 y LightDM. Si el hardwa re es muy táctil, el despliegue necesita ser re petible o las pantallas van a varios lug ares, la ruta moderna de Wayland gen eralmente se gana el trabajo extra de config uración.

Construir un kiosco Chromium que funcione en Ubuntu

Un sábado a las 9 de la noche, a nadie le importa que Chromium se lanzara una vez durante la configuración. Importa que el tablero de menú haya vuelto después de un parpadeo de luz, no haya caído en un escritorio y no haya dejado un puntero de ratón estacionado sobre la lista de bebidas. Ese es el estándar que uso para un kiosco Ubuntu.

Screenshot from https://www.chromium.org/

Para una sola pantalla de restaurante, Chromium en Ubuntu sigue siendo la ruta más rápida hacia algo con lo que el personal pueda vivir esta noche. La parte que las viejas guías a menudo omit en es el control de la sesión. --kiosk es solo una pieza. Tambi én necesita un usuario dedicado, un autoinicio de sesión que aterrice en la sesión correcta cada vez, ajustes de inactividad que permanezcan apagados y una ruta de reinicio para fallos del navegador.

Crear un usuario de kiosco y mant ener su mundo pequ eño

Use una cuenta local separada para la pantalla. No reutilice el inicio de sesión del escrittorio del gerente, y no permita que el kiosco comparta un perfil de navegador normal. Los perfiles compartidos acumulan extensiones, avisos guardados, recordatorios de actualización y otra basura que luego aparece en la pantalla en vivo.

Instale solo lo que el kiosco necesita:

También mantengo el estado del navegador en su propio directorio de perfil. Eso facilita los restablecimientos. Si una caché del sitio se daña antes del servicio, puede borrar una carpeta en lugar de buscar en una cuenta de escritorio general.

Construir limpiamente la ruta X11 legada

Si está uniendo recetas antiguas de LightDM con lanzamientos más nuevos de Ubuntu, trate X11 como una elección deliberada, no como un valor predeterminado sobrante. Para los tableros de menú de restaurante, todavía lo uso en hardware que ya ha demostrado estabilidad con LightDM y Chromium. Es familiar, fácil de depurar localmente y perdonador cuando necesita tocar un script de inicio a toda prisa.

Cree un archivo de configuración de LightDM en /etc/lightdm/lightdm.conf.d/10-kiosk.conf y establezca:

Luego agregue un archivo de sesión en /usr/share/xsessions/ que apunte a su script de lanzamiento.

Ese script de lanzamiento debe hacer cuatro ttabajos:

  1. De sactivar el apagado de pantalla y DPMS.
  2. Iniciar unclutter.
  3. Lanzar Chromium con banderas seguras para kiosco.
  4. S alir de manera que systemd o la sesión pueda reiniciarlo.

Banderas útiles de Chromium para una pantalla de menú:

Deje el paquete del navegador del sistema tal cual si la máquina por lo demás es estable. Ponga su comp ortamiento personalizado en el archivo de sesión y el script envoltorio. Los kioscos son más fáciles de recuperar cuando los archivos propiedad de la distribución se mantienen cerca del estado original.

Desactivar interrupciones en la capa adecuada

Ubuntu aún asume que está ejecutando un escritorio a menos que le indique lo contrario. La suspensión, el apagado de pantalla, el bloqueo de pantalla y las acciones de inactividad deben desactivarse donde la sesión activa las leerá.

En una construcción con LightDM y sesión X personalizada, las viejas herramientas X11 aún importan. xset s off, xset -dpms y xset s noblank pertenecen al script envoltorio si la sesión es X11. Cambiar las claves de GNOME en una caja que nunca entra en una sesión GNOME desperdicia tiempo y le deja con una falsa sensación de que el problema está solucionado.

M uchas construcciones de kiosco de ép oca mixtas salen mal. Alguien copia la configuración de GNOME de una guía de Wayland en un kiosco LightDM, o cop ia comandos X11 en una sesión de kiosco GNOME más nueva y espera el mismo resultado. Haga coincidir la sol ución con la sesión que arranca.

Para los menús que cambian a lo largo del día, el modello del navegador mantiene las operaciones simples. El personal actuaaliza la aplicación web, no la caja sobre el mostrador. Ese mismo patrón funciona bien para actualizaciones de menú QR en tiempo real en múltiples ubicac iones.

Probar el fallo, no solo el arranque

Un kiosco que solo sobrevive a un reinicio limpio aún no está terminado.

Antes de abandonar el sitio, pruebe estos casos:

También verifico qué sucede después de que el navegador ha estado funcionando durante unas horas. Algunas superposiciones táctiles y adaptadores HDMI baratos se comp ortan bien durante diez minutos, luego comienzan a hacer cosas ext rañas después de que se acumula el calor.

Un recorrido visual rápido ayuda si está validando indicadores y comp ortamiento de lanzamiento en el sitio:

Añadir un supervisor (watchdog)

Chromium eventualmente fallará. Construya para eso.

Un servicio systemd simple con Restart=always suele ser suficiente para una instalación de restaurante de una sola pantalla. Si el envoltorio sale o el navegador muere, la sesión comienza de nuevo sin que el personal toque un teclado. Ese paso importa más en el mundo real que aorrar otro minuto en la configuración inicial.

El objet ivo es un comp ortamiento aburrido. Vuelve la corriente. Vuelve la red. Vuelve Chromium. El menú está de vuelta en pantalla antes de que el personal del bar decida que la caja está maldita.

Wayland vs X11 y sessiones de kiosco GNOME

La mayor confusión alrededor del modo kiosco en Ubuntu ahora proviene de un hecho. Las guías antig uas asumen X11 y LightDM. Los sistemas Ubuntu más nuevos le señ alan cada vez más hacia Wayland y sessiones de kiosco orientadas a GNOME. Ambos pueden funcion ar, pero no se comp ortan igual.

Una guía reciente centrada en kioscos Ubuntu seguros señ ala esta discrepanci a directamente. Las guías más nuevas mencionan cada vez más gnome-kiosk-script-wayland y la config uración de archivos de sesión, mientras que las recetas antig uas todavía dependen del autoinicio heredado, Xsessions y scripts de lanzamiento del navegador. Eso deja a los operadores adivinando qué ruta se adapta a cada versión de Ubuntu y combinación de hardwa re (brecha de orientación entre kiosco Wayland y heredado).

Qué cambia con Wayland

Con Wayland, el compositor posee más de la sesión. El apagado de pantalla, la gestión de entradas y el comp ortamiento de ventanas se aplican de manera diferente. Varios viejos hábit os de X11 no se transfieren limpiamente, especialmente cu alqu ier cosa que dependa de xset, trucos directos de sesión X o trucos de gestor de ventanas.

Eso no es algo malo. Los kioscos Wayland suelen ser más limpios. Pero castigan los comandos X11 cop iad os sin entender.

Para comprobar qué utili za un sistema en fun cionamiento, observe la sesión con loginctl y confirme si el tipo es wayland o x11. No asuma bas ándose solo en la versión de Ubuntu.

Cuándo usar cada uno

As pecto S esión X11 S esión Wayland
R ecetas de kiosco con navegador M aduras y ampliamente documentadas M ás modernas, menos trucos heredados
R arezas táct iles Mejor res paldo para hardwa re antig uo Mejor predet erminado en Ubuntu actuaal
C ontrol de energía y apagado A menundo impulsado por scripts M ás impulsado por el compositor
Blloqueo de sesión M ás fácil de improv isar M ás limpio si se construye correctamente
M antenimiento entre versiones L as guías heredadas aún ayudan Mejor alineado con la dirección actual

Si está implementando en Ubuntu 22.04 o más reciente y la pantalla táctil es raz onablemente actuaal, optaría por Wayland. Mantenga X11 para paneles más antiguos, pilas de GPU ext rañas o controladores táctiles antig uos que solo funcionan con controladores heredados.

Regla práctica de decisión

Para autoinicio de GDM en una sesión de kiosco, use la ruta orientada a kiosco de GNOME cuando desee mantenerse cerca de la pila moderna de escrit torio de Ubuntu. Para un disposittivo de pantalla gestionado por compositor, Ubuntu Frame es la ruta más limpia. Para hardwa re antiguo que ya funciona en LightDM más Openbox o una sesión X personaliz ada, no lo reescriba solo porque Wayland es más nuevo.

La jugada incorrecta es mezclar ambos modellos en una misma máquina y esperar que las partes útiles de cada pila cooperen.

Si está trabajando con config uración de as ientos o envolturias de sesión, mant éngalas mín imas. Una config uración básica de seatd debe existir solo para soportar el compositor o la pila de entreda que ejecute. No amontone soluciones legadas de X11 sobre un kiosco Wayland a menos que haya demostrado una nesidad real de hardwa re.

Pantallas táctiles, teclados y manipulación de periféricos

Un kiosco que arranca limpiamente aún puede sentirse mal en el local si la capa táctil es descuidada. Los clientes lo notan más ráp ido que los administradores. Si la pantalla registra los toques un poco desplazados, si el mon itor equivocado recibe la entreda o si un teclado en pantalla aparece al azar, la construcción se siente rota incluso cuando el navegador técnicamente está fun cionando.

Qué ajustar antes de la entrega

  • Calibrar la entreda táctil. En X11, xinput sigue siendo últil para paneles más antig uos. En pilas modernas, libinput y la config uración de pantalla del escritorio suelen ser el camino más limpio.
  • Mapear la pantalla táctil al mon itor correcto. Esto importa en tableros de menú de pantalla dual y port átiles convertidos donde el panel interno aún existe.
  • Desactivar lo que los usuarios no necesitaan. Si el local nunca usa un teclado en pantalla, apáguelo. Si un teclado USB es solo para acceso de servico, mant éngalo desconec tado y controlado.

A technical guide graphic explaining how to configure touchscreens, keybords, and periphera ls for kiosk mode systems.

Lista de comprobación del local que evita revisitas

Cuando entrego un kiosco en una cafetería o bar, ejecuto esta comprobación ráp ida del sitio:

  • Precisión táctil: Toque las cuatro esquinas y el centro. Si se monta una pantalla vertical después de la instalación, vuelva a verificar la rotación y la asignación.
  • Comportamiento del cursor: Confirme que el puntero se oculte limpiamente y no vuelva a aparecer después de inactividad.
  • Bloqueo USB: Permita solo lo que el kiosco necesita, como una impresora, escáner o lector NFC. Todo lo demás debe tratarse como una responsabilidad.
  • Comportamiento al despertar: Asegúrese de que un toque aleatorio o un evento de tapa en hardwa re convertible no despierte en un estado incorrecto.
  • Res paldo de entrada: Si el personal de servico nec esita acceso de emer gencia, documente la ruta exacta del teclado y mant éngala separada del flujo púb lico.

Para los operadores que construyen pantallas de menú de cara al cliente, la misma discipl ina se aplica a la capa de conten ido. Un bu en hardwa re de kiosco no puede res catar un menú desordenado. Este recorrido sobre cómo crear un menú digital con fotos gratis es út il porque la pantalla y el dise ño del menú necesitan apoyarse mut uamente.

Un kiosco estable se siente invisible. Nadie lo comenta porque nadie nota la máquina en absoluto. Solo usan la pantalla.

Ej ecutar menús de TopFoodApp en un kiosco Ubuntu

Un kiosco Ubuntu basado en navegador se adapta bien a las plataformas de menú basadas en QR porque la máquina solo tiene un trabajo. Abrir la URL del menú púb lico, perm anecer en pantalla completa y recuperarse si el navegador sale. Eso mantiene el flujo de trabajo de publicación del local separado del hardwa re de la pantalla.

Screenshot from https://topfoodapp.com/kiosk-mode-ubuntu-menu.png

El ajuste es operacional, no solo técnico

Para pantallas de menú, configuraría la URL del menú público como página de inicio de Chromium y ajustaría el tamaño de la ventana para la orientación real del panel. Los tableros verticales necesitan suposiciones diferentes que las pantallas de mostrador. Si el idioma del navegador debe impulsar la selección de idioma, el comp ortamiento de lanzamiento debe respet arlo en lugar de obligar al personal a cambiar manualmente.

La parte út il de este modello es que el kiosco no nec esita trabajos cron, scripts de sin cronización de conten ido local ni cop ias manuales de archivos cada vez que el local cambia un plato. El navegador simplemente carga la página en vivo. Si el operador cambia el conten ido del menú, el kiosco lo refleja al actualizar.

Notas del mundo real de despliegues

El comp ortamiento sin cone xión importa. Si el Wi-Fi del local no es confiable, apóyese en el comp ortamiento de caché del navegador para resil iencia temporal o déle al kiosco una alternativa de conectividad separada, como un módem 4G modesto. Eso a menundo es más val ioso que pasar otra hora intentando que un Wi-Fi de invitados inestable parezca estable.

También mantengo la interacción ajustada:

  • Desactivar comp ortamientos accidental es del navegador que exponen selecciones o ac ciones contextuales si es posible.
  • Mantener el selector de idioma al alcance sin poner ningún cromo del navegador o control es de escritorio en pantalla.
  • Configurar la rotación de pantalla correctamente a nivel del sistema operativo para tableros de menú montados en vertical, no solo con trucos de zoom del navegador.

Si está evaluando si las pantallas de autoservicio tienen sent ido comercial más allá de la config uración técnica, este desglose de costes y ROI de kioscos de restaurante es un comple mento útil de negocio para la construcción Linux.

Para equipos que aún no han configurado su pila de menú, un creador de menús gratuito reduce la barrera porque puede probar el flujo de trabajo del kiosco con una URL de menú real en lugar de una página de pr ueba.

Endurecimiento, actualizaciones remotas y lista de verif icación de mantenimiento

La peor suposición en el trabajo de kiosco es que una vez que la pantalla arranca y se pone a pantalla completa, el trabajo está hecho. No lo está. Un kiosco de local es un disposittivo remoto, y los disposittivos necesitan reglas de mantenimiento.

A checklist infographic detailing four security and maintenance steps for configuring a Linux kiosk system.

Qué bloqear

Elimine las entradas de escrittorio adicionales si la máquina no las necesita. Desactive los atajos de cerrar sesión y cambiar de usuario en la sesión activa. Si se queda en Ubuntu Desktop, mantenga las actualizaciones de paqu etes controladas para que el kiosco no se desvíe en medio del servicio. Si gestiona muchas un idades, envíe los cambios desde un proceso central como Ansible o una descarga de repositorio firmada en lugar de editar manualmente cada caja del local.

Un reinicio nocturno sigue siendo una sol ución práctica para sessiones de navegador de larga duración. No es elegante, pero a menundo previene la ext rañeza lenta que se acumula en pantallas no at endidas.

Ritmo de mantenimiento que realmente funcciona

  • Semanal: Confirme que la pantalla carga la URL correcta y se recupera de un reinicio del navegador.
  • Mensual: Limpie la basura del navegador si el perfil se está hinchando y verifique la salud del almacen amiento con sus herrammientas de disco estándar.
  • Trimes tral: Aplique los cambios del navegador y la plataforma durrante una ventana de ti empo de inactividad planificada, luego capture la imagen cono cida como buena para reemplazo rá pido.

Los kioscos no suelen fallar porque Linux sea frágil. Fallan porque nadie se hace cargo de la ventana de actualizaciones, de la ruta de recup eración o de la lista de verif icación.

Si la máquina es importantte para el servicio, trátela como un pequ eño sistema de producción. Eso es menos glam uroso que ajustar las banderas de lanzamiento, pero es lo que mantiene la pantalla viva cuando el local está lleno.

TopFoodApp ofrece a los restaurantes una forma rápida de publicar menús basados en QR que funcionan bien en pantallas de kiosco Ubuntu, especialmene cuando se desea una única URL púb lica estable y ediciones instantáneas del menú sin tocar el kiosco mismo. Si está construyendo una pantalla de menú, una pantalla de mostrador o una config uración de autoservicio, vale la pena probar su kiosco de navegador con un flujo de trabajo real de restaurante en TopFoodApp.
Publicado:
← Volver al blog