Você deve ter notado que este guia foi postado em pleno século 2024, mesmo que o Motorola One (também conhecido como "motorola one", "moto one", deen ou XT1941) tenha sido lançado no final de 2018... melhor tarde do que nunca!

Resolvi fazer isto pois recentemente eu usei o meu Moto G Turbo (merlin) para fazer dump dos meus TOTP do Authy, já que o Authy decidiu parar de suportar o app de desktop do Authy, e, por isso, eu tive vontade de desbloquear o bootloader e fazer traquinagens com o meu Motorola One.

Para contextualizar: Eu tenho o meu Motorola One desde o final de 2019, comprei ele pois o meu estágio exigia que a gente tivesse um celular para a empresa e, enquanto o meu Moto G Turbo ainda atendia as minhas necessidades, a bateria dele já estava indo de comes e bebes.

Como era um celular da empresa, eu tive que instalar todas aquelas travessuras que empresas gostam, como o tal do "Portal da Empresa" da Microsoft, e como o celular era "administrado" pela empresa, eu não podia nem atrever em fazer root nele.

Eu também tive um problema grave de lentidão com este celular, ele era lento mas ao ponto de ser inutilizável, coisa de "eu clico para abrir o teclado e leva uns 30 segundos para realmente abrir", o que era estranho pois enquanto o meu Moto G Turbo era lento, ele nunca era lento ao ponto de ficar não responsivo. Então eu sempre tive a curiosidade de saber se formatar o celular deixaria ele "bom" de novo. Eu não vou usar ele no meu dia-a-dia, mas se ele deixasse de ficar tão travado, eu pelo ou menos conseguiria usar ele para outras coisas.

Então decidi ir atrás disso... e aí eu me deparei com uma situação deplorável: Tem praticamente nada sobre modding dele na internet! Na época eu achava que o meu Moto G Turbo estava em uma situação difícil por ter sido apenas uma revisão do Moto G³ (2015) (osprey) que foi "mal amada" por ter sido lançada em algumas regiões, então a comunidade de modding dele era bem menor.

Mas pelo ou menos o Moto G Turbo tem TWRP oficial e já teve builds oficiais do LineageOS! Infelizmente o Motorola One não teve o mesmo luxo...

Não se engane! Existem outros celulares que também possuem a marca "Motorola One" (Motorola One Action (troika), Motorola One Vision (kane), Motorola One Zoom (parker)), e estes outros celulares possuem mais guias e recursos sobre modding para eles.

O Motorola One que estamos falando é o Motorola One, codenome deen, modelo XT1941, e ele parece ser um coitadinho esquecido pela comunidade, pois são poucos os guias que falam sobre como modificar ele.

E por isso eu decidi fazer o meu próprio guia.

Introdução

* I'm not responsible for bricked devices, dead SD cards, thermonuclear war, or you getting fired because the alarm app failed (like it did for me...).
* YOU are choosing to make these modifications, and if you point the finger at me for messing up your device, I will laugh at you.
* Your warranty will be void if you tamper with any part of your device / software.

Neste guia, eu vou mostrar o que eu normalmente espero quando eu penso sobre "modificar o celular", ou seja:

• Como desbloquear o bootloader do celular
• Como instalar a Stock ROM do celular caso alguma modificação der errado
• Como rootear o celular
• Como instalar ROMs personalizadas (ROMs exclusivas para o celular e ROMs GSI/Treble)

Eu escrevi o guia como se este não fosse o seu primeiro rodeio na parte de modificação de celulares, mas ao mesmo tempo tentei deixar claro ao ponto de não ter dúvidas, deixando as dúvidas que restam algo que você consiga descobrir sozinho. Mas se tiver alguma dúvida, basta perguntar!

---

By default, LXD Virtual Machines do not preallocate their memory up to the limits.memory set. Instead, they allocate up to the maximum memory has needed during its lifetime, but they do not give back memory to the host system after it is freed, ballooning devices notwithstanding.

So, because the memory isn't given back to the host, why not preallocate the memory used by the VM? This way it is easier to reason about if you have enough memory in your system, instead of trying to think about "uuhh I do have 10240 megabytes free, but one of my VMs has a 6144 megabytes limit, and currently they are using 2048 megabytes, so actually we have 6144 megabytes free".

First, you need to shutdown your virtual machine...

lxc stop test-memoryalloc

Now, if you haven't already, let's set the memory limit for the virtual machine...

lxc config set test-memoryalloc limits.memory 8GB

And then we add QEMU's -mem-prealloc parameter to the VM!

lxc config set test-memoryalloc raw.qemu "\-mem-prealloc"

That's it! If you check how much memory the QEMU process for the test-memoryalloc virtual machine is using, you'll see that it will be using ~8GB.

And yes, you need to add the \ before the dash, because if you don't, LXD will complain about Error: unknown shorthand flag: 'm' in -mem-prealloc.

If you want to remove the -mem-prealloc parameter, you can remove it by using lxc config unset.

lxc config unset test-memoryalloc raw.qemu

---

During a "let's improve SparklyPower to make it the best Survival server ever" hyperfixation phase, I've really wanted to update my server to 1.21. I waited eagerly for the shiny Paper experimental 1.21 builds, to update my server right when it is released. Who cares if it is "experimental", after all, what could possibly go wrong?

Well, that was a big mistake.

When the Paper team said that they are experimental builds that you shouldn't run in production, they mean it. The Paper experimental 1.21 builds do not have all of the optimization patches, nor they are stable. But I'm stupid and decided to ignore the experimental label.

Now I'm stuck with a server that could handle ~80 players with 20 TPS on 1.20.6, while on 1.21 it is struggling to keep 20 TPS with only 50 players online. And that makes me sad because it is hard to just shrug it off and carry on when you know that players are sad/angry because the server is lagging, especially because it was entirely my fault.

Here's the deal: Everyone says that downgrading versions is NOT supported, some even say that it is IMPOSSIBLE to downgrade and that's why you MUST backup your server before updating.

---

DaVinci Resolve does not support GIFs, which is a bit of a pain when you want to use GIFs in your videos.

Thankfully, you can convert GIFs to transparent mov files with ffmpeg! This way, the GIF transparent background will be a transparent background in the mov file.

ffmpeg -i source.gif -pix_fmt yuva420p -vcodec qtrle target.mov

After converting the file, just import the target.mov video into your DaVinci Resolve project (drag and drop the file into the timeline).

qtrle is the Apple QuickTime RLE codec, and it supports transparency! However, transparency only works when in a mov file, not in a mp4 file.

---

---

Earlier this year, Coachella uploaded tons of clips from artist's shows of this year's Coachella to their YouTube channel. One of the clips was Underworld's performing Two Months Off and Dark Train. As a Underworld fan, I loved it!

Sadly, the original video is now private. Why did they do this? I don't know, you also can't reupload the video to YouTube because it gets automatically blocked worldwide by Coachella.

Thankfully, Wayback Machine came in clutch! They have archived the video, so the video hasn't been lost forever to time, yay!

Wayback Machine's servers are a bit slow, so the video may take a while to load. Thanks to this thread for explaining how to access archived YouTube videos via the Wayback Machine!

---

Lately I've noticed that my nginx server is throwing "upstream prematurely closed connection while reading upstream" when reverse proxying my Ktor webapps, and I'm not sure why.

The client (Ktor) fails with "Chunked stream has ended unexpectedly: no chunk size" when nginx throws that error.

Exception in thread "main" java.io.EOFException: Chunked stream has ended unexpectedly: no chunk size
    at io.ktor.http.cio.ChunkedTransferEncodingKt.decodeChunked(ChunkedTransferEncoding.kt:77)
    at io.ktor.http.cio.ChunkedTransferEncodingKt$decodeChunked$3.invokeSuspend(ChunkedTransferEncoding.kt)
    at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
    at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
    at kotlinx.coroutines.internal.LimitedDispatcher.run(LimitedDispatcher.kt:42)
    at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:95)
    at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:570)
    at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:750)
    at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:677)
    at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:664)

The error happens randomly, and it only seems to affect big (1MB+) requests... And here's the rabbit hole that I went down to track the bug and figure out a solution.

---

If you have a dedicated server with OVHcloud, you can purchase additional IPs, also known as "Fallback IPs", for your server. Because I have enough resources on my dedicated servers, I wanted to give/rent VPSes for my friends for them to use for their own projects, but I wanted to give them the real VPS experience, with a real external public IP that they can connect and use.

So I figured out how to bind an external IP to your LXD container/LXD VM! Although there are several online tutorials discussing this process, none of them worked for me until I stumbled upon this semi-unrelated OVHcloud guide that helped me go in the right direction.

---

Even though I stopped using Proxmox on my dedicated servers, there were still some stateful containers that I needed to host that couldn't be hosted via Docker, such as "VPSes" that I give out to my friends for them to host their own stuff.

Enter LXD: A virtual machine and system containers manager developed by Canonical. LXD is included in all Ubuntu Server 20.04 (and newer versions), and can be easily set up by using the lxd init command. Just like how Proxmox can manage LXC containers, LXD can also manage LXC containers. Despite their similar names, LXD is not a "successor" to LXC; rather, it is a management tool for LXC containers. They do know that this is very confusing.

Keep in mind that LXD does not provide a GUI like Proxmox. If you prefer managing your containers through a GUI, you may find LXD less appealing. But for me? I rarely used Proxmox's GUI anyway and always managed my containers via the terminal.

Peter Shaw has already written an excellent tutorial on this topic, and his tutorial rocks! But I wanted to write my own tutorial with my own findings and discoveries, such as how to fix network issues after migrating the container, since that was left out from his tutorial because "it is a little beyond the scope of this article, that’s a topic for another post."

The source server is running Proxmox 7.1-12, the target server is running Ubuntu Server 22.04. The LXC container we plan to migrate is running Ubuntu 22.04.

---

---

Since I stopped using Proxmox on my dedicated servers, I found myself missing my VXLAN network, which allowed me to assign a static IP for my LXC containers/VMs. If I had a database hosted on one of my dedicated servers, an application on another dedicated server could access it without requiring to expose the service to the whole world.

Initially, I tried using Tailscale on the host system and binding the service's ports to the host's Tailscale IP, but this method proved to be complicated and difficult to manage. I had to keep track of which ports were being used and for what service.

However, I discovered a better solution: running Tailscale within a Docker container and making my container use the network of the Tailscale container! This is also called "sidecar containers".

---

If you are managing your Docker containers via systemd services, you may get annoyed that your container logs are logged to syslog too, which can churn through your entire disk space.

Here's how to disable syslog forwarding for a specific systemd service:

cd /etc/systemd
cp journald.conf [email protected]
nano [email protected]

In the [email protected] configuration, change

ForwardToSyslog=off

Then, in your service's configuration file (/etc/systemd/system/service-here.service)...

[Service]
...
LogNamespace=noisy

And that's it! Now, if you want to look at your application logs, you need to use journalctl --namespace noisy -xe -u YOUR_SERVICE_HERE, if you don't include the --namespace, it will only show the service's startup/shutdown information.

journalctl --namespace noisy -xe -u powercms

This tutorial is based off hraban's answer, however their tutorial is how to disable logging to journald and, because I didn't find any other tutorial about how to disable syslog forwarding for specific services, I've decided to make one myself.

---