Programmer

The post that broke my website

Fri, 30 Jan 2026 00:00:00 GMT

I decided to write this to review and share some insights about my latest post.

Last Tuesday, I posted an article entitled ‘2030 the year of desktop Linux’. The "year of the Linux desktop" is a well-known meme in the community, mostly because this year never really comes. But I suggested in the title that 2030 might actually be the "promised year."

I argued that, utilizing some work-in-progress projects, the ecosystem may be mature enough for the average user in the next 4 years—a thought that I had been mulling over for some while.

But to be fair, what I wasn’t expecting was the repercussions that post caused.

I decided to share the link on the r/linux subreddit with a discussion tag. In less than 30 minutes, the post got 20k views and 50 comments.

Fast forward to today, and the post is closing in on 100k views and nearing 200 comments.

Insights about the post on Reddit.

The influx was so sudden that it actually took my site down for a few hours. I completely blew past my hosting traffic limit. It was a bittersweet moment: a mix of "Yay, people are reading!" followed by "Oh no, nobody can read it anymore."

I think the reaction was largely driven by the title I chose for Reddit: “Why desktop Linux could just feel normal by 2030.” It was a simple, innocent, yet clearly provocative title.

A lot of people commented to say that Linux is already normal today. And yes, I agree. It is normal for me, and likely for you reading this. Knowing what I know now, I might have chosen a title that made my idea clearer—perhaps emphasizing "frictionless" rather than just "normal"—to better reflect that I was talking about the experience for the average, non-technical consumer.

However, despite the semantic debate, the main goal was achieved: to generate a healthy discussion around the incredible engineering work being done right now.

Thank you to everyone who read, commented, and engaged.

Regarding what’s next: as I hinted before, I’m planning a piece on Mac gaming. And over the next few months, I want to explore a handful of other topics too—still in the same style: a technical deep dive first, and then some predictions based on what I find.

Here are a few ideas currently on my list:

What if Windows became open source?
Web Applications
Linux and mobile
Storage
Modern cryptography
WireGuard

These are all topics I genuinely enjoy and want to dig into. But, this isn’t a strict roadmap and they're not in a sequential order. Also, other subjects may show up along the way.

It might take a little while to write and publish these topics because my routine is currently packed with work and university, but stay tuned.

‘2030 the year of desktop Linux’

Mon, 26 Jan 2026 00:00:00 GMT

I installed my first Linux distro in 2022: Pop!_OS.¹

It didn’t take long before I did the thing everyone does after the first successful install: I started hopping. Fedora. Arch and even Nobara Project by GloriousEggroll.²³

By the end of 2023 I bought my first Mac, and that did solve a lot of day-to-day friction for me, but it didn’t cure the Linux itch.

I think that’s the part people miss when they reduce Linux desktop to a niche alternative. Once you get used to an ecosystem that builds in public, where the plumbing is discussed openly and you can see the tradeoffs, it’s hard not to keep checking back in.

But most people don’t “choose an OS,” they just buy a computer. And yes, Linux on desktop is still small today. StatCounter’s desktop numbers are still low single digits for Linux, for example, December 2025 shows Linux at 3.86% worldwide.⁴

So here’s where I’m landing: I think 2030 is the first year where desktop Linux can realistically stop feeling like a hobbyist choice and start feeling like a normal choice. Not because one magical breakthrough happens, but because a bunch of important details are finally lining up.

The Nvidia story is finally getting interesting

One reason AMD and Intel often feel easy on Linux is simple: their graphics stacks are largely upstream-first. The kernel side (DRM/KMS), userspace (Mesa), and the compositor stack tend to evolve together, with fewer vendor-specific special paths needed for the common desktop workflows.⁵⁶

Nvidia has historically been harder because the stack has been split across two paths.

Fragmented past stack.

On one side there’s the community stack (Nouveau + Mesa), where the kernel driver and Mesa drivers are developed in the open and integrate naturally with the upstream graphics stack.

On the other side there’s the proprietary Nvidia driver, where kernel modules and the userspace OpenGL, Vulkan and EGL implementation are delivered as a vendor stack, and historically have lagged or diverged on integration points that matter on modern Linux desktops.⁷⁸

What’s changing is that both paths are moving in directions that reduce the number of special cases needed for Nvidia to behave like any other GPU on Linux.

On the Mesa side, NVK is now a serious part of the plan. NVK is Mesa’s open-source Vulkan driver for Nvidia GPUs. Mesa documents it as a conformant Vulkan 1.4 implementation for supported Nvidia generations.⁹

What makes NVK especially relevant to desktop users is how it pairs with Zink.

Zink is a Mesa OpenGL implementation built on top of Vulkan. Instead of maintaining a hardware-specific OpenGL driver backend for every GPU family, Zink implements OpenGL once and emits Vulkan calls underneath.

In practical terms, this consolidates effort around the Vulkan driver path (NVK) and reduces reliance on the older Nouveau OpenGL driver for modern Nvidia cards.¹⁰

Then there’s Nova.

Nova is a new upstream Linux kernel driver project for Nvidia GPUs that use the GSP (GPU System Processor) model. The kernel documentation describes Nova as two drivers, nova-core and nova-drm, and states that it intends to supersede Nouveau for GSP-based Nvidia GPUs.

nova-core provides the low-level firmware/hardware abstraction, and nova-drm is the DRM/KMS piece that plugs into the normal Linux graphics stack.¹¹

Why this matters is straightforward: NVK and Zink live in userspace (Mesa), but they still depend on a functional kernel DRM driver for memory management, command supmission, display, and synchronization. Today that kernel foundation is generally Nouveau on the open stack, longer-term, Nova is the path aimed at being the modern upstream kernel foundation for newer Nvidia generations using GSP.

That is how NVK + Zink can eventually sit on top of a kernel driver that is designed for the modern firmware model and developed upstream alongside the rest of Linux graphics.¹²¹³

Unified modern stack.

Meanwhile, on the proprietary side, Nvidia has also been addressing some of the most visible Wayland pain points. The 555 driver series added support for the linux-drm-syncobj-v1 Wayland explicit sync protocol, which is one of the missing pieces that historically contributed to stutter, flicker and timing issues on some Wayland setups.¹⁴¹⁵

There’s also a second category of problems that matters specifically for Linux adoption among gamers: DirectX 12 through Proton.

DirectX 12 games on Linux usually run through Proton using VKD3D-Proton, which translates D3D12 calls to Vulkan. When performance is worse on Nvidia than expected, or when certain D3D12 titles regress, the cause is often a messy interaction between translation-layer assumptions and driver behavior. Nvidia users have been reporting these issues publicly for a while, including performance complaints in Nvidia’s own Linux forums.¹⁶

What’s relevant here is that there are signs Nvidia is actively targeting general improvements for D3D12 and VKD3D workloads on Linux, rather than only one-off game fixes, which is exactly the kind of work that can move the baseline instead of just patching symptoms.¹⁷

And this matters because Nvidia isn’t a niche vendor in the gaming world, it’s still the default GPU choice for a huge portion of Steam users.¹⁸

Most of these users will never learn what NVK, Zink, or Nova are, and they shouldn’t have to. The only metric that matters is the experience: you launch a game, you launch an app, you alt-tab, you drag a window across monitors, and nothing weird happens.

If the Linux experience becomes smoother on the hardware people already own, the adoption story changes.

Wayland becomes the baseline

Wayland used to be the future. Now it’s increasingly just the default.

KDE has been explicit about moving Plasma toward a Wayland-exclusive future, with Xwayland used for legacy X11 apps rather than maintaining parallel desktop sessions indefinitely.¹⁹ GNOME is moving the same way: the X11 session was disabled by default and the project targeted full removal during the GNOME 50 cycle, leaving Wayland as the only supported session, but also with Xwayland for X11 apps.²⁰

What I expect over the next four years isn’t “Wayland is done,” but something more practical: protocols that are currently debated, drafted, and sitting in review will either land, consolidate, or be replaced by clearer approaches.

That process matters because paper cuts on Wayland are often not compositor bugs, they’re missing or incomplete protocol agreements that everyone is waiting on.

Wayland protocol development can leave even basic functionality sitting for months or years, and that becomes a product problem when you’re shipping devices and a compositor (Gamescope) to real users.

This is where Valve’s frog-protocols exists.

Frog-protocols isn't a new Wayland replacement.²¹ It can server as a fast-moving proving ground where protocols can be shipped, exercised by real users, and then folded back into the upstream process once the shape is clear.²²²³

One concrete example is frog-fifo-v1. The stated goal is to address FIFO/VSync behavior under Wayland in cases where applications can end up in bad states (including GPU starvation and freezes when windows are occluded with FIFO/VSync enabled).²⁴

Wayland also pairs well with another shift that makes the Linux desktop feel more coherent: the security and permissions model is getting a default path.

Flatpak’s sandboxing model is restrictive by default, and portals provide a consistent interface for sensitive operations. That doesn’t make Linux magically secure, but it does move desktop Linux toward a platform model instead of a loose collection of conventions.²⁵²⁶

Compatibility stops being a philosophical argument

I don’t think Linux wins because people suddenly care about freedom. I think it wins when the question becomes, “Can I run my stuff?”

This is why I pay attention to the compatibility work.

Wine’s Wayland driver work is a good example. The goal is to make Windows apps on Wayland a first-class path, not something that relies on legacy X11 behavior. When that upstream work matures, it reduces the amount of X11 surface area Linux desktops still need to keep around for compatibility.²⁷

On the gaming side, SteamOS being treated as a product line matters too. It forces investment into Linux gaming as a first-class experience.²⁸

A big reason that experience feels real now is Proton. Proton is a stack of translation layers and fixes that keep getting hammered into shape by real users at scale.²⁹

But there’s one compatibility cliff that turns this into a very non-philosophical argument: kernel-level anti-cheat.

A lot of competitive multiplayer games rely on anti-cheat systems designed around deep Windows integration, including kernel-level drivers. Call of Duty’s RICOCHET, for example, explicitly uses a PC kernel-level driver as part of its approach.³⁰ In that world, it’s common for a game to run perfectly well under Proton, until matchmaking is blocked, the client is kicked, or the anti-cheat refuses to initialize.

The frustrating part is that the ecosystem already has a workable pathway. Epic introduced Easy Anti-Cheat support for Linux, but enabling it is ultimately a developer or publisher choice.³¹ BattlEye has a similar story: Proton support exists, but it’s opt-in per game.³² So you end up with a strange middle ground where compatibility is technically possible, culturally inconsistent, and commercially uncertain.

This is why the discussion is hard: the incentives don’t line up cleanly. Studios don’t want to expand their attack surface for a relatively small slice of player base with full control over your system, and players don’t want to adopt a platform that locks them out of their most-played competitive titles.

So yeah: it’s a chicken-and-egg problem. Companies are more likely to take Linux seriously when it’s a meaningful chunk of their revenue. But Linux only becomes a meaningful chunk of revenue if more people decide to use it anyway, even knowing that not every favorite game or app will work 100% on day one. That early tolerance is how market share grows.

My bet is that the long-term escape hatch is less client trust and more server authority: more server-side validation, better telemetry, stronger behavior analysis, and maybe ML-assisted detection where it actually makes sense. But then you hit the question that decides everything: will the ROI ever justify the investment?

I hope we have better answers by 2030.

PCs shipping with Linux stops feeling rare

Most people don’t install an OS. They buy whatever shows up on the machine.

That’s why OEM momentum compounds. Dell shipping Ubuntu preinstalled on XPS Developer Edition models is a small example, but it’s the kind of thing that normalizes the idea that Linux can be the default.³³³⁴

If that expands, more models, more regions, more validation, then the first-run experience becomes less fragile. And once first-run is predictable, word-of-mouth gets dramatically easier.

A second-order effect is that rising interest in Linux makes it rational for some companies to treat the OS as part of the product, not just a removable software layer.

System76 is the obvious reference point here: they sell hardware designed, tested, and supported around their own distro (Pop!_OS), and the preinstalled with a validated stack approach removes a lot of first-boot uncertainty for end users.³⁵³⁶

You can see a similar dynamic starting to appear in handhelds. Valve has been explicitly expanding SteamOS beyond the Steam Deck, and Lenovo is shipping officially licensed third-party handhelds that come with SteamOS out of the box (Legion Go S, and now additional SteamOS-enabled models announced later).³⁷³⁸

From a business perspective, this kind of bundling can be attractive even before it becomes mainstream. In theory, if an OEM isn’t paying for a Windows license on a given SKU, they can choose to pass some of that margin to the buyer, keep it as profit, or reinvest it into support and validation.

The stuff I didn’t mention, but still matters

HDR belongs here, because it’s one of those features that exposes whether a desktop stack is actually modern.

HDR on Linux has historically been blocked by missing standard plumbing: compositors need color management, clients need a way to describe their content, and the protocol layer needs to carry that information consistently.

A big inflection point is that Wayland’s color management work finally landed upstream: the color-management-v1 protocol was reported as merged to upstream Wayland protocols in early 2025 after years of work.³⁹⁴⁰

From there, you start seeing user-facing desktop progress. GNOME 48 explicitly calls out the initial introduction of system-level HDR support, enabling HDR output for apps that support it.⁴¹ KDE’s KWin work has also been documented publicly in detail, including practical aspects like brightness behavior and the constraints imposed by protocol maturity.⁴²

Another important development is System76’s COSMIC desktop environment, because it represents a serious attempt to modernize the Linux desktop stack end-to-end. COSMIC is Wayland-native and written in Rust, with its own toolkit (libcosmic with Iced-based UI stack) and a dedicated compositor, and System76 positions it as something you can use beyond Pop!_OS as well.⁴³

This matters for the same reason HDR matters: features like color management, input, window management, and security properties are increasingly constrained by the assumptions baked into the compositor, toolkit and desktop shell layer. COSMIC is being developed as a cohesive stack, and it shipped as COSMIC Epoch 1 in Pop!_OS 24.04, with ongoing point releases and public tracking of compositor and shell changes.⁴⁴⁴⁵

Outside HDR and desktops, I keep thinking about ARM and Android app paths.

ARM matters because desktop Linux isn’t just an x86 story anymore. Fedora Asahi Remix is a strong signal that the community is trying to turn Apple Silicon Linux into something that feels like a daily-driver system, not an experiment.⁴⁶⁴⁷

Android app compatibility matters because it’s a practical safety net for certain workflows. Waydroid already runs Android in a Linux container across multiple architectures. And lately there’s been reporting that Valve is working on something called Lepton, apparently based on Waydroid, which could eventually make “Android apps on Linux” a more standardized option in gaming-adjacent setups.⁴⁸⁴⁹

Monetization belongs here too. Right now, if you want to sell software to Linux users, you often end up routing around the Linux desktop’s fragmented storefront story. For games and software, the obvious defaults are Steam or itch.io, because they already provide payment rails, distribution, and discovery in a way that works cross-platform.⁵⁰⁵¹

Today, Flatpak and Flathub is the closest thing Linux has to a shared app store layer across distributions, but payments are still in the process of becoming a real, normal, user-facing default.

Flathub has been pretty direct about what’s been missing: not just a checkout UI, but the legal and governance foundation needed to handle taxes, compliance, and cross-border transactions. They’ve described integrating Stripe and building the backend pieces for purchases and donations, but also that switching payments on in a broad, store-like way depends on organizational and legal readiness.⁵²⁵³⁵⁴

And the direction is clearly toward Flathub becoming a place where money can move: Flathub leadership has said they plan to allow verified apps to require payments or solicit donations (with different commission assumptions depending on whether the software is proprietary or FLOSS).⁵⁵

Will 2030 actually be “the year”?

The 'Year of the Linux Desktop' has always been a joke about winning the market. But 2030 isn't about winning, it's about functioning. The roadmap doesn't show a magical flip in the charts. It shows something more important: the moment where the unified Nvidia stack and Wayland protocols finally make the OS boring enough to just use.

This is where the timeline matters. By 2030, projects like Nova and the unified GSP firmware won't just be experimental branches, they will be the default LTS standard. The anti-cheat battles will likely have shifted from client-side kernel wars to server-side validation or market dynamics will finally force developers to recognize the platform not as a niche, but as a revenue stream, and the fragmentation we complain about today will have largely settled into a coherent platform definition via Flatpak, Portals and FreeDesktop.

I mentioned at the start that I bought a Mac in 2023 because it solved the friction of daily life. That is the real metric.

Linux desktop doesn't need to destroy Windows or replace macOS to win. It just needs to stop punishing the people who choose it. It needs to reach a point where the trade-off for freedom isn't stability, but simply preference.

The victory won't look like 50% market share. It will look like something much quieter: it will be the year where installing Linux stops feeling like a brave political statement or a hobbyist experiment, and starts feeling like just buying a new computer.

I enjoyed writing this article so much that I'm now considering writing another one about the year of Mac gaming, lol.

Rebuilding after the pandemic — Part 2

Mon, 12 Jan 2026 00:00:00 GMT

In Part 1, I talked about the post-pandemic slump, how I rebuilt my discipline, and how that led to an award-winning project.

This post is the second and final part of that story: how we built my final course project (TCC)—from the first half-baked ideas to the final delivery and presentation.

A classroom split in two

At my ETEC, our Systems Analysis and Development class had around 40 students, but the lab rooms couldn’t fit everyone comfortably.

So the class was split into Side A and Side B—20 students each.

odd numbers → Side A
even numbers → Side B

My name starts with V, which put me near the bottom of the list… and on Side A (this was still pre-pandemic).

It sounds like a tiny detail, but it mattered later.

Watching TCCs during the pandemic

During the pandemic, we had a chance to watch TCC presentations from older classes finishing the course. I remember sitting there, in front of recorded videos and live chats, trying to understand what a “good” final project looked like.

I asked teachers questions in the chat. I watched a bunch of projects. Little by little, I got a clear picture of the challenge:

A TCC wasn’t “just an assignment”.

It was a full project, with planning, scope, documentation, presentation, and delivery—and I’d have less than a year to study and build something worth defending in front of a panel.

That reality hit me early.

And honestly? It scared me in a good way.

Back to in-person

When we returned to in-person classes in 2022, the TCC conversations started almost immediately. This would be the first fully in-person TCC cycle in two years.

The rules were pretty straightforward:

Build a project (real or fictional) for a business/institution
Don’t charge for it
Apply what we learned over the three years of the course

Simple on paper.

At the time, I wanted to do the project alone—not because I dislike teamwork, but because I wanted to prove to myself I could carry a full project end-to-end.

But there was a problem:

Teams were mandatory.

Teachers even said we could switch between Side A and Side B to form teams with people we worked well with. That’s when that classroom split from earlier came back.

So I moved to Side B, grouped up with four friends, and we created our team:

Frog Developers (yes, there’s a story)

We named ourselves Frog Developers, and the origin is… extremely high school.

Some students had a group they proudly called something like “the rat squad”. We had a tiny rivalry with them.

So to mock it, our friend group became “the frog squad”. And when it came time to form a serious TCC team, Frog Developers was basically:

A few “frog squad” friends who decided to ship a project together.

Not exactly a startup origin story… but it worked.

The idea graveyard

Before we found our final project, we went through the classic phase:

too many ideas, too little time.

Idea #1: a Brainly answer site (yeah… no)

My first idea—still during the pandemic—was a dynamic website that would query Brainly’s API and return answers to academic questions for students.

I killed that idea pretty quickly. For obvious reasons.

Also, it’s funny to think that about two years later, AI would basically become the “same thing” on a completely different scale. Life moves fast.

Idea #2: a condo administration system (too big)

My second idea was more legit: build a condo management system for a family friend.

The users (building managers, caretakers, supervisors) would have daily task checklists like:

checking fire extinguishers
elevator maintenance
drainage system routines
general inspections

It was useful… but the scope was massive. The more we mapped it, the clearer it became:

We wouldn’t finish it in time.

So we dropped it.

And that decision taught me one of the most underrated project skills:

Scope is everything.

Learning Vue at the right time

Around that period, I decided to learn a framework that was getting really popular: Vue 3.

Vue felt different to me. More direct. More intuitive. Less friction than what I’d felt with React at the time.

And most importantly:

It felt like something I could use to build fast without sacrificing structure.

So I committed to it.

And that choice ended up saving our project.

The final idea

After a while, one member of the group brought a new idea:

Build an inventory control system for a natural products store owned by the family of another student in the school.

That’s when everything clicked.

We defined something practical and clear:

Desktop + mobile system for internal stock control and daily operations
A website for customers to check purchase-related information

The problem?

I was the only developer in the team.

And we had less than three months left.

But we looked at each other and basically said:

Alright. Let’s do it anyway.

Building under pressure

Once the design was ready and I felt comfortable with Vue 3, I went into full execution mode.

Somehow, I managed to finish the interface in less than one month.

Then the real work started: turning screens into a product.

Over the following days, I focused on the parts that make a system feel real:

cloud data persistence
state management
routing
portability to desktop and mobile

It wasn’t glamorous. It was a lot of debugging, a lot of late nights, and a lot of “why is this breaking now?”

But it moved.

And each day it moved more.

The presentation

When we were just a few days away from presenting, we shifted into rehearsal mode. We practiced the delivery, planned who would say what, polished the narrative, and tried to make the presentation feel confident—not improvised.

Then we had one final idea.

Since the project was for a natural products business, we decided to bring small succulent seedlings as a gift for visitors and judges.

It was a small detail, but it made the room warmer.

More human. Less “school assignment.” More “real project.”

And in the end?

It worked.

The teachers evaluating us said it was one of the best TCC presentations they had seen in 10 years.

Their words.

I still remember that moment because it didn’t feel like a grade.

It felt like recognition.

The lesson that closed the chapter

Looking back, the technical part mattered—but the real lessons were bigger:

A good project is a scoped project;
The right tools at the right time are leverage;
Execution beats perfect planning;
Presentation is part of the product.

But the biggest takeaway of that year wasn’t even technical.

It was personal.

Between the post-pandemic slump, the award-winning prototype, and the final project under pressure, I rebuilt something I thought I had lost: discipline, focus, and the ability to deliver.

And that’s why I like to revisit this story.

Because none of it happened by accident.

It happened because I made a decision back in 2021: to stop running from discomfort and start building a future I actually wanted.

Effort pays you back.

Sometimes with skills. Sometimes with confidence. Sometimes with recognition.

But it always pays you back.

References

Rebuilding after the pandemic — Part 1

Tue, 06 Jan 2026 00:00:00 GMT

I like to think of 2022 as the year I proved something to myself: I could lose my way, rebuild my habits, and still create something meaningful.

In fact, that year took me from a post-pandemic slump to an award-winning project—and the path between those two points taught me more than any class ever did.

This post is Part 1 of two stories from that year. Here, I’ll talk about my post-pandemic slump, what it did to me, and how I turned things around through a ridiculously ambitious project that ended up being recognized and awarded.

Part 2 will be about executing my final course project.

The ETEC dream

In the state of São Paulo, ETECs are known for offering high-quality public technical education. Back in 2019 (my last year of middle school), I had one clear goal: pass the ETEC entrance exam.

My routine was intense but simple:

school in the morning
lunch at home
a nap
studying in the afternoon

I kept that pace for months, took the exam at the end of the year, and in early 2020 I got the news: I was accepted.

I was about to start high school combined with a technical program in Systems Analysis and Development—exactly what I’d always wanted. 2019 had been great, so why would anything go wrong from there… right?

Right?

When the world closed (and so did I)

Early 2020 brought news that still felt far away: a few cases of a new virus in China. Like most people, I didn’t understand what it would become.

Then it went from a “small situation” to an epidemic, and from an epidemic to a global pandemic. Suddenly everything changed: isolation, masks, remote work, remote classes—life reorganized around minimizing contact.

And for a long time, my world shrank to one place: my room.

Studying from home didn’t feel like studying. Some classes were recorded. Interaction with teachers often happened through chat. I barely interacted with other students.

To make it worse, my phone was broken—so I couldn’t even text properly. No hobbies. No healthy distractions. Just me, a computer, and assignments.

My motivation collapsed.

The gaming loop

I fell into a pattern that felt harmless at first and slowly turned into a trap: gaming became my escape.

Hours and hours of Minecraft, Rocket League, and whatever else helped me unplug from the day. I still submitted assignments—but I did them fast, often pulling answers from the internet, just to get back to playing.

The scary part?

It “worked.”

I turned things in, got decent grades, and stayed safe on paper—even while my discipline and ambition quietly disappeared.

At some point, I couldn’t ignore it anymore.

I admitted the truth

I realized I was wasting my potential. I wasn’t the dedicated student I used to be. And even though the world was in crisis, I knew that if I didn’t change something, I’d come out of that period as a weaker version of myself.

So at the end of 2021, I made a decision:

I would recover the lost time and actually study what I had dreamed of for years—software development.

Rebuilding myself through code

I started watching the recorded classes I had ignored. I took free online courses. I created personal projects. I learned and practiced:

HTML / CSS / JavaScript
PHP
VB.NET
SQL
and I even installed Linux (Pop!_OS)

More importantly, I learned something I wish I’d understood earlier:

Effort pays you back.

It wasn’t always fun, and it wasn’t always easy—but little by little, I got that feeling of progress back. The I’m building something feeling.

That change came with a cost: I spent less time with friends because I wasn’t gaming as much anymore. And honestly, Linux wasn’t exactly great for gaming back then.

But looking back, it was 100% worth it.

Back to school and the real world

In 2022, the school adopted hybrid teaching—and by March, we were back in person.

Mid-year, our school received an invitation to participate in an event promoted by an organization called Ideias de Futuro, in partnership with the São Paulo government and Google. The challenge was simple in concept and huge in impact:

Build a tech solution that could help people in the city.

I knew I had to be part of it.

I invited a friend—another aspiring developer—and we joined as a team.

A problem that was actually real

In events like this, many projects revolve around environmental themes or broad community topics. Those are important, but I didn’t want to build something generic. I wanted something tied to a real pain point.

Then I remembered a problem I had personally lived with:

For over 10 years, I used basically the same password across multiple accounts.

And I realized I wasn’t alone. A lot of people do the same thing because it’s easier, because they’re overwhelmed, or because they don’t think it’ll happen to them.

That’s not just a bad habit. That’s a security risk.

So I suggested we build a password manager and present it as our solution.

My friend loved the idea.

We named the project Criptphy.

We worked hard enough to deliver a prototype and record a video pitch. We submitted it and waited.

A week later, the results came out:

We were selected.

That meant we’d present the project at the Ideias de Futuro center, in front of journalists, judges, and government representatives.

No pressure, right?

The presentation day

We went there representing our school. The atmosphere felt bigger than anything we had done before. Professional. Serious. Real.

Presenting Criptphy project.

The jury panel during the event.

And then the results:

Our school won almost all the awards overall—and we were part of that story.

Criptphy won 2nd place in the Development category.

And we received a Kindle as a prize.

It wasn’t just a trophy moment. It was proof—proof that all those nights of studying, all those boring days where discipline mattered more than motivation, had built something inside me.

The lesson I was missing

Winning 2nd place wasn’t the point.

The point was realizing that I could come back—that discipline wasn’t “gone”, it was just buried under comfort, fear, and routine.

That project proved something simple but powerful:

I wasn’t stuck. I was just untrained again.

And once I started putting in the work consistently, things moved—skills, confidence, momentum.

But 2022 wasn’t done teaching me.

Because right after that… came the biggest challenge of the entire course: my final project.

And that’s what Part 2 is about.

References

Thoughts about 2025

Thu, 01 Jan 2026 00:00:00 GMT

2025 was an important year for me.

It was a year with two sides: real achievements that made me proud, and challenges that forced me to grow.

Looking back now, I can see how much changed, not only in what I did day to day, but also in how I learned to deal with pressure, uncertainty, and my own expectations.

From support to developer

My professional story didn’t start with a “developer” title.

In my first job, I joined the company on the IT infrastructure side. My work was mostly about enabling other people to do their jobs: providing technical support, managing assets, handling platforms, stepping in when something broke or when someone needed help. It was a solid foundation, and I spent two years in that world.

But at the end of 2024, something shifted. I was moved internally into solution development.

That made 2025 my first full year as a developer.

And it was a very different rhythm.

Suddenly, I wasn’t just keeping systems running, I was building things that didn’t exist yet. I had to learn how the work actually moves from an idea to something a user can rely on. I dealt with delivery plans, sprints, user stories, features, bug fixes, the whole cycle.

If I had to summarize my biggest work-related learning from 2025, it would be this: organization is not optional.

An idea doesn’t become a working product just because it’s a good idea. It has to travel through many steps: planning, breaking down, prioritizing, refining, implementing, testing, adjusting.

I learned that progress depends on structure, and structure is what keeps the team, and my own mind, from drowning in chaos.

A year of studying

Outside of work, 2025 was study-heavy.

I studied math. I studied programming languages more deeply. And I studied for a college entrance exam.

It wasn’t just “a bit of studying,” either it was a huge portion of my year. Some days felt like I had two full-time jobs: work during the day, preparation at night.

So… what did I get out of it?

A lot.

I passed the entrance exam, one of the clearest wins of my year. Studying math helped me directly during subjects in my first semester. And going deeper into programming languages helped my team deliver a system by the end of the year.

I want to write about that system later, because it taught me a lot.

Anxiety was part of the package

With all that pressure, anxiety showed up, often.

And honestly, it makes sense. My brain was constantly trying to do everything at once: give my best to pass the exam, while also staying sharp and reliable at work.

That kind of mental load doesn’t disappear just because you “try harder.”

It didn’t just affect my productivity, either. At times, anxiety got in the way of my interactions with the people around me.

I was more irritable, more distracted, and more “in my head” than I wanted to be, and that made me realize I needed to take this seriously, not just push through it.

So I had to learn how to calm down in real, practical ways, not just motivational advice.

One of the best decisions I made was taking a trip in the middle of the year, during my vacation, to the countryside. Slowing down for a while helped me breathe again.

Another change was simpler but powerful: I started going for walks every morning. Nothing extreme, just consistent movement, fresh air, and time to be with my thoughts without screens or deadlines.

I deleted my social media accounts and I picked up photography as a new hobby.

But most importantly, I sought professional help.

That step mattered. It taught me that asking for support isn’t weakness. It’s maintenance.

2026

2025 gave me achievements I’m proud of.

It also gave me problems that taught me lessons I needed.

I became a developer. I proved to myself I can study hard and reach a goal that once felt far away. And I faced a lot of anxiety.

For 2026, I have one goal.

Balance my new responsibilities well, and to keep progressing, but at my pace.

No rush. No constant sprint. No living as if everything is an emergency.

I want consistency, not chaos.

Because if 2025 taught me anything, it’s that growth doesn’t have to come from pressure alone.

It can also come from patience, structure, and learning to move forward without burning out. And that’s exactly the kind of days I want to build now.

Slow is still forward.

This website

Thu, 01 Jan 2026 00:00:00 GMT

Since I started learning programming, development, and design back in 2019, I’ve always wanted to build my own personal website. I wanted a place to showcase my skills, track what I was learning, share my projects, and publish thoughts and opinions — something that felt truly mine.

And I actually did it… a few times. Each version reflects a different stage of my journey:

My first page

This was my very first website — and also my first contribution on GitHub. It started as a school project: simple HTML and basically no real understanding of CSS. At the time, I was excited just to have something online, but it didn’t take long for me to feel like it wasn’t “me” yet. It worked, but it looked rough, and I knew I could do better.

My history page

Not long after, I made a second version — also for school. It still didn’t have much CSS (I was learning slowly), but I tried to be more creative with the idea. I wanted to tell a story, not just display information. It was definitely an improvement, but I still wasn’t satisfied. I could feel the gap between what I imagined and what I was able to build.

My portfolio

This one was different: it wasn’t for school — it was personal. By then, I finally had a better grasp of CSS, and I could build layouts that looked intentional. I used this website for a while and it did its job as a portfolio, but deep down I still felt it was incomplete. Something about it didn’t fully represent where I wanted to go.

This website

Eventually, I decided to start over again — this time with a custom template and a clearer concept.

Life also changed. I had new responsibilities, less free time, and I had to rethink what I actually wanted from a personal website. Over time, I learned a lot more: better design decisions, better organization, better tools, better standards — and a better understanding of myself as a developer.

Now, for the first time, I can honestly say I’m completely satisfied with it.

This website is not just a portfolio anymore. It’s a living space: a home for my work, my notes, my experiments, and the things I care about — built slowly, intentionally, and with more meaning than any version before.

Canas & Cunha

Thu, 18 Dec 2025 00:00:00 GMT

At the end of the year, my family decided to visit some relatives who live in the countryside. We traveled with a couple of friends, and after about four hours on the road, we arrived in a small town called Canas.

After spending the night there, we headed to another small town named Cunha, about an hour away. Cunha sits high up, surrounded by mountains, and we spent most of our time in the rural area. It was a special kind of trip for me — I hadn’t been around farm animals since I was a kid.

That’s also where I met Kiko, a super friendly dog whose name was inspired by the character from Chaves. His favorite game was grabbing plastic bottles and bringing them to us so we could throw them, and he could run after them and bring them back again. Kiko ended up becoming part of the trip, and he’ll always be remembered in the photos I took.

One day, I want to come back and hike up Pedra da Macela — they say you can see the sea from the top.

Photos

Building an AI SaaS with Nuxt

Sat, 01 Nov 2025 00:00:00 GMT

2025 was my first year as a developer. And as I mentioned here, it wasn’t an easy year. Without going into too much detail, I went through several management changes throughout the year—which, unsurprisingly, disrupted continuity and made it harder to keep our roadmap moving forward.

Still, near the end of the year, we managed to deliver an internal AI project. I can’t share the repository because it isn’t open source and was built exclusively for the company. Even so, I think it’s worth writing about, because I learned a lot from the process.

Project scope

The initial scope was to build an application where users could:

Interact with multiple AI models
Create and use custom agents based on those models
Have administrators manage access profiles, create user groups, add users, and register external AI models using API keys

We had a little under a month and a half to deliver a pilot that would be presented to headquarters in Spain. So I immediately met with my manager to share a few ideas.

Architecture and approach

I suggested we build a full-stack interface and a backend. The client would communicate through a proxy layer and connect to a RESTful API on the server. That API would then interact with local models via Ollama and persist data in a PostgreSQL database.

I was responsible for the interface, and I chose Nuxt—a meta-framework for Vue.js that I hadn’t used professionally before, but already knew about. And honestly: working with Nuxt and its ecosystem ended up being one of the best decisions for this kind of application.

Prototyping and UI development

As soon as we aligned on the direction in a closed-room session, I started thinking about screen prototypes. I’m not a web designer, and my design knowledge is limited, but a couple of tools helped a lot: v0 and Figma Make. They can generate complete interfaces—from design to code—but I didn’t plan to reuse their code directly. I used them mainly as guidance and inspiration.

For the actual development, I started from an official dashboard template from NuxtUI. Then I customized it, taking inspiration from the UI outputs generated by the tools above. One of the great things about Nuxt is that it uses file-based routing by default—so as you create pages, routes are automatically created as well.

And of course, I used AI throughout the process to speed up implementation. With that support, I finished the static UI in five days. After that, I began turning the interface into a dynamic application by integrating it with local data and real APIs. I implemented composables to manage state across components and pages.

A clean integration pattern

As my manager delivered the backend APIs, my job was mostly to wire the Nuxt proxy into the composables using a consistent pattern:

Component → Page → Composable → Proxy / BFF

This approach kept maintenance simple: each module had a single responsibility, and it became much harder to accidentally break the client.

Rendering AI output safely

Another interesting challenge was formatting model outputs. Most responses came back as Markdown—but the raw output looked “unstyled,” almost like plain text. So I decided to render Markdown as HTML for a better reading experience.

That introduced its own challenges: beyond improving visuals, I needed a sanitizer to prevent any malicious HTML from being injected into the UI.

Writing a Markdown renderer from scratch would be exhausting and time-consuming, so I looked for existing solutions—and, unsurprisingly, the Nuxt ecosystem already had a strong option: Nuxt MDC. It gave me everything I needed, and the moment I rendered the first response properly, I was reminded how mature the ecosystem is.

I even started rendering LaTeX as mathematical equations and Mermaid as diagrams, since MDC supports plugins that make this kind of extension straightforward.

Final result and takeaways

So what did we end up with? Not just a prototype to present, but a tool that was already minimally functional. We didn’t implement every final feature—but we didn’t need to for the pilot. It was enough to demonstrate value clearly.

This experience also reinforced something I strongly believe: the idea that AI will “steal developer jobs” doesn’t match reality—at least not in the way people claim. What worked best for us was treating AI as a copilot: I guided it, reviewed decisions, and took control whenever needed.

Even if we get to a future with extremely powerful AI, someone will still need to steer it, apply judgment, and make trade-offs—whether the task is small or large.

My main takeaway from this project is simple: don’t be afraid to use the right tools for the job. Learn them, leverage them, and use them to your advantage.

I deleted all my social media accounts

Fri, 10 Oct 2025 00:00:00 GMT

A few days ago, I made a decision that felt both scary and freeing: I deleted all of my social media accounts.

Instagram. Facebook. Twitter. Reddit. Bluesky. Mastodon… all gone.

I didn’t do it because I “hate” social media or because I think everyone should quit. I did it because I noticed something simple and uncomfortable: I wasn’t feeling good when I used them. And that was enough.

Instagram: the invisible script I never agreed to

Instagram was the biggest one for me.

Whenever I opened the app, I felt like I was supposed to behave in a certain way, like there was a social script I had to follow:

Post photos constantly;
Share everything in Stories;
Post what music I’m listening to;
Get more followers;
Like generic things so I stay “present”.

Even when I wasn’t doing any of that, the pressure was still there. It felt like the platform was quietly pushing me toward performance.

And honestly, Instagram seems designed to highlight only the best parts of life. People post vacations, achievements, beautiful moments, perfect angles, perfect smiles. After a while, it creates this fake atmosphere where everyone’s life looks flawless.

Mine isn’t flawless. It’s not supposed to be. And pretending it is—either by posting or by comparing—just didn’t feel healthy.

Looking at other people’s lives often made me feel worse. Not because of them, but because of the constant comparison. It’s hard to stay grounded when your brain is being fed a never-ending stream of “look how great this is.”

On top of all that, it’s pretty clear these platforms use mechanisms to keep us scrolling for as long as possible, that's how they make money, btw. And I could feel it working on me.

Reddit: organic, anonymous… and addictive

Reddit was different.

It’s a curious case because it promotes anonymity and organic interaction. In theory, it’s less about image and more about communities. And that’s exactly what made it dangerous for me.

The subreddits I followed were genuinely good. I learned a lot. I laughed a lot. I found tutorials, stories, discussions, and niche topics I truly enjoy.

But that’s the problem: it became too easy to get hooked.

I would check it constantly. A quick look would turn into another post, then another, then another. It stole my focus in a way that didn’t look toxic at first—but it definitely was draining my attention over time.

The only “social” platforms I still keep

Right now, I only kept a few—and with clear boundaries:

LinkedIn: I only log in to update my professional information;
GitHub (for now): it has some social mechanics, but I use it to contribute to open source and publish my projects;
YouTube: I follow creators I consider more organic. Videos take longer to come out, but they’re usually higher quality and a good starting point to learn something new;

The result: less anxiety, more peace

After deleting everything, something changed almost immediately.

I started feeling less worried about missing out, less concerned about engagement, less mentally tied to what other people might be posting or thinking.

It wasn’t like my life suddenly became perfect. It just became quieter. More mine.

And honestly? It feels like a one-way door.

I don’t see myself going back.

São Paulo's Spring

Mon, 01 Sep 2025 00:00:00 GMT

Here are a few photos I took in São Paulo during the beginning of spring, around the expanded center area.

I was walking with no rush, paying attention to small details—the light, the streets, the buildings, and the everyday movement that makes the city feel alive.

This is just a simple collection of moments I wanted to keep.

Photos

Guararema

Thu, 10 Jul 2025 00:00:00 GMT

In the middle of the year, I was feeling completely overwhelmed — work, college, and personal life all at once. So I decided to take a few days off to clear my head.

During those days, I played games and read a lot. That’s when I started One Piece and fell in love with it. In just a few days I finished the Alabasta arc, and now I’m in Jaya. Oda is definitely a genius.

But near the end of my break, I felt like I needed fresh air. I left the city and went to a small town at the beginning of a region known as Vale do Paraíba. I stayed there for three nights, and honestly, it was one of the best decisions I made this year.

The town is small, surrounded by mountains, and full of little things to explore. Here are some of the photos I took while I was there.

Photos

People's Park

Tue, 15 Apr 2025 00:00:00 GMT

Recently, I bought my first digital camera. Shortly after, some friends decided to go to People’s Park. This was our first time visiting the park, and it was my first time taking pictures with a digital camera. Here are some photos I captured that day.

Photos

Obsidian with Syncthing and Gitwatch workflow

Sat, 30 Dec 2023 00:00:00 GMT

If you are looking for a way to keep your notes synchronized across all your devices while maintaining a bulletproof, automated backup history—without relying on proprietary clouds—this guide is for you.

We are going to combine three powerful tools: Obsidian, Syncthing, and Gitwatch.

Note: This guide assumes you are running a Linux distribution (I was using Fedora when I originally designed this workflow). While the concepts apply to any OS, the specific commands below are tailored for the Linux terminal.

Why This Stack? Before we start typing commands, let's look at the tools.

Obsidian: A powerful, extensible knowledge base that works on top of a local folder of plain text Markdown files.
Syncthing: A continuous file synchronization program. It replaces proprietary sync and cloud services with something open, trustworthy, and decentralized.
Gitwatch: A script that watches a folder for changes and automatically commits them to a Git repository. This is our safety net.

Part 1: Installation

Let's get our tools ready.

1. Obsidian

You can grab Obsidian from your distro's software manager (like GNOME Software) or download the AppImage/Flatpak directly from the official website.

2. Syncthing

We need Syncthing on every device you want to keep in sync (your laptop, desktop, phone, etc.). On Fedora, install it via dnf:

sudo dnf install syncthing

3. Gitwatch

Gitwatch relies on git and inotify-tools. Let's install dependencies and set up the script:

# Install dependencies
sudo dnf install git inotify-tools

# Clone the repository
git clone https://github.com/gitwatch/gitwatch.git

# Install the script globally
cd gitwatch
sudo install -b gitwatch.sh /usr/local/bin/gitwatch

Part 2: Configuration

1. Setting up Obsidian

First, create a dedicated home for your notes. I recommend a structure like ./documents/obsidian. Inside that, create a subfolder specifically for the vault you want to sync, for example, ./documents/obsidian/sync.

2. Configuring Syncthing

Now, let's connect your devices.

Start Syncthing: Run syncthing in your terminal. It should automatically open the web GUI at http://127.0.0.1:8384.

Connect Devices: Click "Add Remote Device" and exchange Device IDs between your computers and phone.

Sync the Folder: Click "Add Folder". Give it a label (e.g., "Obsidian Vault") and point it to your path: /home/youruser/documents/obsidian/sync.

Share: Check the devices you want to share this folder with. Once you accept the prompt on your other devices, your files will sync peer-to-peer. Magic!

The Catch: Syncthing is amazing at syncing, but it also syncs mistakes. If you accidentally delete a file on your phone, it disappears from your computer instantly. As the Syncthing FAQ states:

Syncthing is not a great backup application… use other tools to keep your data safe from your (or our) mistakes.

This is where Git comes in to save the day.

3. Setting up Gitwatch

We will use Git to create a versioned history of your notes. Even if you delete everything, you can roll back time.

Initialize the Repo: Navigate to your vault and start git:

cd /home/youruser/documents/obsidian/sync
git init

Tip: I recommend setting up an SSH key for GitHub, GitLab, etc. So you don't have to enter passwords. You can check out this gist for a quick SSH how-to.

This command tells Gitwatch to watch the folder and push changes to your remote repository automatically.

cd /
gitwatch -s [seconds] -r [remote repo] -b main [folder path, e.g., /home/user/documents/obsidian/sync]

Part 3: Automating Everything

We don't want to run these commands manually every time we boot up. Let's use systemd to make them run silently in the background.

First, create the user systemd directory:

mkdir -p "$HOME/.config/systemd/user"
cd "$HOME/.config/systemd/user"

1. Automating Syncthing

Create a file named syncthing@.service and paste this configuration:

[Unit]
Description=Syncthing - Open Source Continuous File Synchronization for %I
Documentation=man:syncthing(1)
After=network.target
StartLimitIntervalSec=60
StartLimitBurst=4

[Service]
User=%i
ExecStart=/usr/bin/syncthing serve --no-browser --no-restart --logflags=0
Restart=on-failure
RestartSec=1
SuccessExitStatus=3 4
RestartForceExitStatus=3 4

# Hardening
ProtectSystem=full
PrivateTmp=true
SystemCallArchitectures=native
MemoryDenyWriteExecute=true
NoNewPrivileges=true

# Elevated permissions to sync ownership (disabled by default),
# see https://docs.syncthing.net/advanced/folder-sync-ownership
#AmbientCapabilities=CAP_CHOWN CAP_FOWNER

[Install]
WantedBy=multi-user.targetcd /
mkdir -p "$HOME/.config/systemd/user && cd $HOME/.config/systemd/user"

Start the service, replace 'myuser' with your system username:

systemctl enable syncthing@myuser.service
systemctl start syncthing@myuser.service

2. Automating Gitwatch

Create a file named gitwatch@.service in the same directory:

[Unit]
Description=Watch file or directory and git commit all changes. run with: systemctl --user --now enable gitwatch@$(systemd-escape "'-r url/to/repository' /path/to/folder").service

[Service]
Environment="SCRIPT_ARGS=%I"
ExecStart=/usr/local/bin/gitwatch -s [seconds until committing] -r [remote repo link] -b main [folder path, ex: /home/user/Documents/obsidian/Sync]

[Install]
WantedBy=default.target

Start the service:

systemctl --user --now enable gitwatch@$(systemd-escape "'-r url/to/repository' /path/to/folder").service

Conclusion

And there you have it. You now have a note-taking system that allows you to write on any device, syncs instantly via Syncthing, and creates an immutable backup history in the cloud via Gitwatch.

It’s private, it’s robust, and best of all—it’s yours.

Frog Developers

Thu, 01 Dec 2022 00:00:00 GMT

Frog Developers was my final course project at ETEC, delivered for a real business: Equilíbrio Natural. Instead of treating the project like a fictional assignment, we scoped it like a real product and shipped a small suite of projects that covered both internal operations and customer-facing needs.

The delivery included three projects:

Cross-platform inventory control system (Windows, Linux, Android)
Customer website for business info and product availability
Team website presenting our identity, members, and delivered work

The story behind this project is in:
Rebuilding after the pandemic — Part 2

My role

Although this was a team project, I was responsible for all of the development.

Projects

Inventory Control

A multi-platform inventory system designed for daily internal operations: managing products, categories, and stores/units with a history log and expiration tracking.

Highlights

Admin and visitor access modes
CRUD for products + search
Change history (audit-style log)
Automatic expiration calculation
Built to run on Windows, Linux, and Android

Stack

Vue + Vite, TailwindCSS
Vue Router, Pinia
Firebase (Firestore)
Electron + Capacitor (cross-platform packaging)

Customer Website

A single-page website for customers with key business information, contact options, store lookup, and product availability.

Highlights

Interactive sections/cards
Email sending flow
Store lookup + product availability
Integration entry point to the app

Stack

Vue + Vite, TailwindCSS
Firebase (Firestore)
Netlify (deployment)

Team Website

The official Frog Developers website, focused on presenting the team and the work delivered during the project.

Highlights

Light/dark themes
Internationalization (multi-language)
Modern landing layout

Stack

Vue + Vite
UnoCSS, VueUse
Vue I18n

Media

Inventory control

Customer website

Team website

What I learned

Scope is everything: a smaller, well-defined product ships faster and better.
A consistent design system improves both UX and dev speed.
Performance comes from details (bundling, image formats, loading strategy).
Presentation is part of the product—how you communicate the work matters.

References

Criptphy — Password Manager

Fri, 01 Apr 2022 00:00:00 GMT

Criptphy is a password manager prototype we built in 2022 for a civic-tech challenge promoted by Ideias de Futuro, in partnership with the São Paulo government and Google. The goal was to create a tech solution that could help people in the city—so we focused on a very real, very common problem:

A lot of people reuse the same password across multiple accounts because it’s easy… until it isn’t.

Criptphy was our attempt to turn that pain point into a practical solution: a simple web app concept for securely storing and organizing passwords.

I explain in more detail how we arrived at this idea in this post: Rebuilding after the pandemic — Part 1

My role

This was a two-person team project:

Me: Front-end (UI, layout, interaction, integration with the API);
My teammate: Back-end (server-side logic, database, endpoints).

Tech stack

Front-end: HTML, CSS, TypeScript;
Back-end: PHP;
Database: MySQL.

Architecture

Criptphy followed a straightforward split:

For the website we used: HTML, CSS and TypeScript;
A PHP back-end that handled data persistence and communication with MySQL
The front-end interacted with the back-end through HTTP requests (API-style integration)

Hosting

During the event, we deployed the prototype like this:

Front-end: Heroku;
Back-end: Railway.

Current status

Criptphy is no longer online and not actively maintained.

That said, the full source code is still available and can be explored on GitHub.

Outcome

We were selected to present Criptphy in-person at the Ideias de Futuro center, in front of judges, journalists, and representatives from the government.

At the end of the event:

Criptphy won 2nd place in the Development category;
We received a Kindle as a prize.

Media

Landing Page: Hero section.

Landing Page: About section.

References

Lambari

Sun, 01 Dec 2019 00:00:00 GMT

Some memories from Lambari, a interior city in the Minas Gerais state, Brazil. For who don't known, Minas Gerais or MG is a.k.a the land of the pão de queijo, a typical breed with cheese inside it. It's very tasty with coffee.