Per oggi avrei dovuto cacciare la soluzione di emulazione finalizzata per i giochi Windows [esenti da requisiti hardware irrealistici] con v86… ma a quanto pare è un po’ impegnativo, devo implementare almeno un’altra hack per soddisfare i requisti essenziali. Però, nel frattempo Boxedwine è rimasto un pensiero fisso, soprattutto dopo avaver constatato che la versione nativa su Windows e Linux funziona e basta: è praticamente plug-and-play con tutti i giochi che sono risaputi funzionare, al contrario del Wine “essenziale” proveniente da upstream o da una distro qualsiasi. 📦
Touhou 6 su Boxedwine per Windows mi è partito, e con una versione (la 5.0 almeno) gira pure bene, ci ho potuto giocare (anche se le ventole del portatile sono volate nel processo). Non credo che adesso magicamente riuscirò a farlo andare sulla versione web, perché c’è un inghippo: il giochino partiva con l’impostazione della grafica nativa, ma non se impostata su quella emulata (che credo sia l’unica utilizzabile nel browser), ma già è qualcosa: il vino inscatolato potrebbe tornarci utile quantomeno per creare repack di giochi che, con un singolo file che parte sia su Windows che su Linux, si giocano e basta senza alcun imprevisto dei soliti del gaming PC… 🦜
Però allora ho pensato: se quello che cambia tra build nativa e web di Boxedwine è solo il codice macchina dell’emulatore (e le sue chiamate all’API host), che però esegue sempre le stesse robe precise al suo interno, com’è che escono fuori quegli strani problemi di compatibilità, tipo il fatto che Wine 5.0 non parte sul browser? La risposta è: il 5.0 che ho provato io non è lo stesso che scarica la versione desktop. Questo è saltato fuori dopo che ho provato a far partire quello da web, e in effetti non crasha come l’altro giorno! E, addirittura, ci gira il 6.0, che nemmeno credevo fosse supportato! Detto in modo diverso: questo progetto è mantenuto un po’ a culo da quello che vedo, ci sono diversi download nominalmente equivalenti sulle diverse pagine ufficiali, sia di questi filesystem Wine che dell’emulatore in sé (ma per quello non c’è dubbio che la versione migliore sia quella dal Jenkins). 🧬
https://octospacc.altervista.org/wp-content/uploads/2024/05/Screenshot_20240527-160241_Firefox-Beta.pngPer fare tutte le prove possibili voglio ora avere sotto mano tutte le versioni dei rootfs che trovo, varie impostazioni di emulazione, e il caricamento immediato di applicazioni diverse, quindi ho iniziato a tirare su questo wrapper per la versione HTML; modificare file di configurazione o parametri URL ogni minuto era diventato doloroso, e la UX del launcher PC è scomodissima. Per ora è sul server casalingo, perché così posso applicare al volo modifiche ai file, ma se dovessi mettere troppe app e finire lo spazio allora creerò una repo Git. Boxedwine desktop offriva per il download anche queste tante altre versioni, quindi le ho messe… ma alcune sembrano ugualmente rognose (tra cui le 1.x, ironicamente), quindi indagherò meglio. Per il lago d’uria: https://hlb0.octt.eu.org/Misc/BoxedWine/ 💦https://octospacc.altervista.org/2024/05/27/lo-scatolvino-di-distrazione/
Des mini-réacteurs nucléaires sans eau, installables n'importe où, dans un conteneur : la solution française Naarea
La start-up française Naarea promet de fournir une chaleur très haute température et une électricité pilotable, sans émissions de CO2. Sa solution ? Un mini-réacteur nucléaire de 4ème génération ultra-compact, d'une capacité de 40 mégawatts électrique.
Just switched my #SelfHosted#PeerTube instance from using #Redis to #Valkey now that it has a stable release out as a #Docker#container too, and.. that went too easily 😅. I know this makes sense as it is 100% compatible, but it still feels quite amazing to have it just work.
In case it helps; I just switched to using the valkey/valkey:7-alpine image, and because I also renamed things in my docker-compose I added PEERTUBE_REDIS_HOSTNAME=valkey to the PeerTube .env file too. That's it!
@mozilla#Firefox
Da ich über mehrere Geräte den #Browser Firefox verwende, nervt es mich jedesmal, dass die #Container Einstellung nicht über Firefox synchronisiert werden!
#AlpineLinux is generally my default goto for #kubernetes#container image bases when I'm writing stuff from scratch. I love how lightweight and simple it is, so I'll often start there until I can prove that I need something more complex.
On that note - need to move some #Kubernetes data to S3? Here's an #Alpine image I pushed today that includes #s3cmd and zip and gets built/tested/pushed weekly by our Jenkins farm at my $DAYJOB. Perfect for a sidecar container or CronJob backup, etc. Enjoy! (And if this is useful to you, thank the Alpine and s3cmd folks, because they by far did most of the work.)
@tcurdt From my point of view both are solutions to different problems. But most people abuse the container ecosystem for other problems than intended.
I never encountered the problems that container try to solve. But problems that can easily be solved with nix.
I'm still learning the tools in nicolaka/netshoot, but also need some #dotnet specific things.
I stumbled on the lightrun-platform/koolkits package for node, and I wish they had a #dotnet image -- anyone using anything better than the dotnet-monitor container?
I'm a Docker (or containers in general) non-believer. I simply don't believe in the promises it makes.
Docker is supposed to be easy to set up, easy to update, easy to migrate and always works. However, I've head plenty of stories where a container setup doesn't want to work, doesn't want to update or doesn't work after migrating. It's the same shit.
I'll stick to plain old system packages and there is absolutely nothing that will stop me.
The Forgejo community has just published the 7.0.1 bug fix release[1]. I went to my server, did a systemctl stop forgejo, to stop the rootless container[2] I use to run it, issued podman pull codeberg.org/forgejo/forgejo:7-rootless to get the updates, and finally systemctl start forgejo and done. Updated. Thank you @forgejo for being awesome and working so hard on making things better and better!
@deflockcom if you're looking for a home server solution, CoreOS may be a better fit since it still uses rpm-ostree but may not be so focused on the IoT use case in it's configuration.