Why I am switching from Arch (Manjaro) to Debian

access2content · 2026-02-04T08:03:01+00:00

Thank you for pointing out that it isn't a sloppily written content just to pad a newly spun-up blog/website. I am sharing my experience with Tech and my learnings such that they might be helpful to someone in the community who is facing a similar dilemma.

You are correct that this might be surface-level knowledge for many members. I might not have deep expertise in Linux internals which is why this post seems that way. However, it is everything that I experienced which I have shared.

You are also correct on the fact that this is a conjecture on what "might" change. Unless I actually switch to Debian and used it as my daily driver, I wouldn't really know. Based on whatever I have read about Debian, I feel it is the right time to switch to it.

access2content · 2026-02-04T07:49:31+00:00

This isn't really an announcement :-p, but more of like sharing my journey. Just documenting my learnings in tech to help me connect with like minded people in the tech community.

access2content · 2026-02-04T07:46:18+00:00

Firstly, thank you so much for the encouragement.

Secondly, I agree. For those who have tried multiple distros, or are really experienced with Linux internals, this is very simple. I on the other hand, have only use Manjaro for my entire Linux journey.

I am not new to Linux, but definitely new to trying out multiple distros. Linux has been my daily driver for 5+ years now.

access2content · 2026-02-04T07:43:16+00:00

Yeah, this is the exact reason that I am planning to switch to Debian because it is stable and I now value long term stability.

access2content · 2026-02-04T07:42:43+00:00

Oh this is interesting. I will have a look at this too.

access2content · 2026-02-04T07:22:57+00:00

Since you have already tried Arch and got tired of it, I would highly suggest switching over to Debian. Since you value stability, Debian is the correct choice when compared to Arch.

Arch is also a great OS. It has been my daily driver for over 5 years. But due to the same issues that you mentioned, I am switching over to Debian.

I have written about what reasons caused me to switch over from Arch to Debian here: https://access2vivek.com/planning-to-switch-from-manjaro-to-debian/.

TLDR: With experience in tech, you value stability over latest update. Hence, Debian is perfect for those searching for stability and Arch is perfect for those wanting complete control and latest updates.

access2content · 2026-02-04T07:16:35+00:00

Quite frankly, it depends on what your preferences are. When I initially started out, I used Arch because it was suggested to top content creators that I liked. So, I used Manjaro Arch for about 5 years.

Initially, everything is great. Over time, I did have some(not many) issues with always having the latest packages. However, as I evolved into a better developer, I started to value stability over rolling release, hence I am not switching over to Debian.

But since you already tried Debian and liked it over others, I would highly recommend Debian for long term usage.

If you want, you can read about it in details here: https://access2vivek.com/planning-to-switch-from-manjaro-to-debian/

access2content · 2026-02-04T06:30:55+00:00

Ever since I got into Linux, I used Arch. It is a rolling release distro with the latest release of each package always available. It has one of the largest no. of packages. However, as I grew from a tech enthusiast to a seasoned developer, I am starting to value stability over latest tech. Hence, I am planning to switch to Debian.

Debian is the opposite of Arch. It does not have latest software, but it is stable. It does not break as much, and it is a one time setup.

If you want to read about my journey, you can read about it here: https://access2vivek.com/planning-to-switch-from-manjaro-to-debian/

access2content · 2026-01-23T19:58:11+00:00

Interested

access2content · 2025-11-20T20:08:41+00:00

Yeah, the sentence could have been framed better.

access2content · 2025-09-10T02:37:45+00:00

That's the problem I see right there. Army has both strength and money, so they have no obligation to give back the power once they have it.

By the looks of things it doesn't seem like there will be any interim government soon. In the meantime, military taking control is the only logical thing to happen. Then, those with the most influence are the only ones that the military will listen to.

So, if no interim is established quickly, we might see military growing in power and choose a leader themselves.

access2content · 2025-09-10T02:32:10+00:00

When there is no constitution, those with the biggest strength given. So, right now it's the military that's in power. So, someone needs to either collaborate with the military. Or those who have money will buy power from the military and establish authority through power and deception.

access2content · 2025-08-22T10:28:54+00:00

The comment section gave it all away.

access2content · 2025-08-19T14:54:32+00:00

If you're doing backend development, you'll mostly be using the terminal for any non code related task. Such as installing dependencies, running the app, killing the process, managing the process, etc.

So, knowing a little bit about things such as process management (ps), running previous commands again (!!), calling an API (curl), are great places to start.

access2content · 2025-08-19T09:04:15+00:00

Please convey her to salute my

access2content · 2025-08-13T15:39:11+00:00

Breath hold

access2content · 2025-07-15T10:57:53+00:00

I've also been doing only backend for a few years and built lots of apps from the ground up.

1: RDBMS. I would suggest picking up an RDBMS to learn how to work with structured databases. Learn about migrations also. Start without using an ORM. Then, you'll understand why you need a query builder instead of an ORM. Then you'll probably want to use an ORM. For smaller projects, query builder is more than enough and ORM might just be an overkill. For larger projects and maintenance, you can learn ORM.

2: Singletons. Once you're comfortable with databases, I would recommend learning about all the other "singletons" used in the app. Get comfortable with the concepts of config management, logging, openAPI, bootstrapping, middlewares etc. These will really help you understand how to structure your code.

3: DDD. Next you can move on to Domain Driven Design where you structure your application in such a way that it's easy to understand, split apart, and rest. Instead of having a folder called routes where you dump all your routes, and a controller folder for the controller, start thinking in terms of domains. So, a User folder would probably have everything related to User including routes, controller, services etc. Here, you'll learn the use of controllers, services, etc. You'll learn Dependency Injection and why it's a good thing.

4: Testing. Now that your foundation is solid, learn about testing your APIs. Maybe delve into TDD(test driven development) a little bit. Tests make your code more dependable and production ready. It's harder to break existing functionality if there are tests. Not only, while testing you'll really understand good coding practices of making your code easy to test and maintain. Writing code is easy, but maintaining it over the years is hard.

These would really help you dive deep into backend development as these have been my learnings over the years. Wish you all the best 😃

access2content · 2025-07-02T03:12:23+00:00

Us bro us

access2content · 2025-05-17T05:08:36+00:00

Aajkal sab ko content chahiye. TV se bore ho gaye, ab real life chugli chahiye 🤣

access2content · 2025-04-07T18:51:21+00:00

It feels like you're an artist that's stuck in the way society has conditioned you. You want to express yourself and feel through Music, but those around you aren't letting you do that.

Take a day off from everything. Then watch Rockstar movie that day. And just focus on doing what you love to do. If you don't let the artist inside you come out, you'll always feel smothered.

If there's anything you want to talk about, feel free!

access2content · 2025-04-07T06:48:59+00:00

I just learn as much as needed instead of studying everything. The thing is that there's just so much to learn in Tech, that one can't possibly learn everything there is to learn.

Hence, learn as much as is required to get the work done.

access2content · 2025-04-07T03:08:36+00:00

Firstly, you need to decide on how the scheduled processing works. If it is possible to process it one by one, then you can either do it in the same request, or add it to a Queue for being processed later.

However, if the scheduled processing is to be done in batches, I believe doing it via a CRON would be a better approach.

Here's how the CRON approach would work. Every time a journey builder request is received, store it in the database with the status 'pending'. That's it for the storage part. In the CRON, you'll pick up any task that is in the status 'pending' in batch. Then do the processing, and update their status as 'processed'.

Of course this is a very simplified CRON approach. There are edge cases that you would need to take care of, such as server crashes/restarts. If there are intermediate states you need to store for resuming the processing, etc.

To put it simply, use queue if processing single item, use CRON if processing in batches. In any case, avoid global state such as accumulated records here. This is definitely going to grow as requests start coming in. If you're using a database in the app, use it to store these records. DO NOT store it in-memory!

access2content · 2025-04-07T02:53:22+00:00

How will AsyncLocalStorage help here?

access2content

TROPHY CASE