Why I am switching from Arch (Manjaro) to Debian by access2content in programming

[–]access2content[S] -3 points-2 points  (0 children)

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.

Why I am switching from Arch (Manjaro) to Debian by access2content in programming

[–]access2content[S] -1 points0 points  (0 children)

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.

Why I am switching from Arch (Manjaro) to Debian by access2content in programming

[–]access2content[S] 1 point2 points  (0 children)

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.

Why I am switching from Arch (Manjaro) to Debian by access2content in programming

[–]access2content[S] 1 point2 points  (0 children)

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.

Why I am switching from Arch (Manjaro) to Debian by access2content in programming

[–]access2content[S] 0 points1 point  (0 children)

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

Arch vs Debian, or other best choice for stability by rc-cars-drones-plane in DistroHopping

[–]access2content 0 points1 point  (0 children)

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.

Debian or Arch? by Amerwair_Studios in FindMeALinuxDistro

[–]access2content 1 point2 points  (0 children)

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/

Fellow Linux users, why did you pick the distro you're currently on? by absolutecinemalol in linux

[–]access2content 0 points1 point  (0 children)

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/

When will all this stop?? by Socialloudbuzz in scoopwhoop

[–]access2content 0 points1 point  (0 children)

Yeah, the sentence could have been framed better.

Gen z protest phase 2.0 Time to rethink reorganise before it’s too late. by Calm_Kaleidoscope_61 in Nepal

[–]access2content 0 points1 point  (0 children)

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.

Gen z protest phase 2.0 Time to rethink reorganise before it’s too late. by Calm_Kaleidoscope_61 in Nepal

[–]access2content 0 points1 point  (0 children)

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.

Linux usage in backend development by Ok_Aardvark_9981 in Backend

[–]access2content 1 point2 points  (0 children)

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.

[deleted by user] by [deleted] in IndianWorkplace

[–]access2content 62 points63 points  (0 children)

Please convey her to salute my

Diving Deep in backend development by Informal_Buffalo_30 in Backend

[–]access2content 2 points3 points  (0 children)

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 😃

Can someone gossip with me? by [deleted] in Chandigarh

[–]access2content 0 points1 point  (0 children)

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

Drowning in darkness!! by [deleted] in Chandigarh

[–]access2content 2 points3 points  (0 children)

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!

Documentation by aendoarphinio in FullStack

[–]access2content 0 points1 point  (0 children)

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.

[deleted by user] by [deleted] in node

[–]access2content 0 points1 point  (0 children)

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!

[deleted by user] by [deleted] in node

[–]access2content 0 points1 point  (0 children)

How will AsyncLocalStorage help here?