So, hate to break this to you but it’s been almost 20 years since you shouldn’t just open ports directly to your computer from your home router AND it’s been about that long since ISPs just don’t allow traffic to customers on standard ports like 80, 443, 21, 22, etc.

The way to do this is actually to have multiple computers, with the first computer acting as your firewall, IDS, and IPS. That computer should run no other services and should be heavily locked down after it’s setup, as in most things should be made read-only except the few variable files that are required for operations.

That computer should then route traffic to computers behind it that provide services like https, ssh, etc. This setup makes everything much safer.

But you’ll still have to contend with your ISP and they don’t usually budge, so you’ll have to run services on non-standard ports.

The way out is to learn more. MERN/MEAN is a flash in the pan relative to the trajectory of the industry. You have to keep learning and never stop. Yes, learning Python will help you get more jobs. But so will learning C#, or Java, or getting AWS certified, or Azure certified, or learning tensorflow, or learning perl.

Learning more things will open up more job opportunities. It always has, it always will. And your local job market is not big enough to accommodate all skills, so if you want to stay where you are, try to assess what skills are present in the job postings you want and learn those skills.

I want to college and got a comp sci degree but they didn’t teach me any frameworks. I had to learn everything industry-related on my own. I share this because you do not need a school to give you a degree that says “this person knows python”. But you do need to spend your free time learning more things if you expect to adapt to the constantly changing tech landscape.

Bing. O.

I am so tired of these sorts of shallow analyses from people that think their screw-ups are actually caused by EDAs or micro services or whatever. They’re even totally transparent about the fact that they did because they heard cool things but never say “so we sat down to learn about best practices, what the current state of the art is, and considered how our use cases matched the architecture”

They just say “we thought it would be cool so we just started doing it and it sucked - here’s why that’s an inherent problem of the architecture and not in any way related to our behavior”.

Yes. If you take a team of people who build n-tier and hexagonal MVC monolithic apps, and then tell them to build micro services, they’re going to build a bunch of n-tier or hexagonal MVC monolith candidates and eventually end up with a single service that does too much and ultimately becomes the monolith.

Yes. If you take a team that does 100% synchronous HTTP interfaces, SOAP or ReST, and then tell them to build microservices, they’re going to daisy chain those microservices via synchronous HTTP interfaces, and if you tell them to build an EDA they are going to build an EDA that attempt to replicate all of the aspects of their synchronous HTTP interfaces with busy polling loops.

So stop doing that and actually do the hard thing of learning fundamentally different architecture, techniques, technologies, trade offs, best practices, operational patterns, design patterns, and heuristics and principles for managing software. Learning is difficult and humbling. But it sure beats writing ignorant articles like this.

1:1

Hellz f’ing yes, fellow penguin!! So glad I could help!

It is. I run mint 22.1 as well. The Mint team ended up with a pipewire version that was mostly contemporary but a Wireplumber version that was legacy. It made configuration a nightmare. Once I upgraded Wireplumber, I was able to actually configure it and all my problems went away

I think that installing pulseaudio + pipewire will be problematic, at least that’s what I’ve read. I recommend uninstalling pulseaudio, getting the PPA version of Wireplumber and reporting back with your outcomes. Make sure pipewire-pulse is installed

Mint 22 is on pipewire now. You need to get rid of pulseaudio, go with pipewire and the pipewire-pulse compat layer. I had major problems until I installed an upgraded Wireplumber to 0.5 from ppa:pipewire-debian/pipewire-upstream

After that, you may have further issues with your configuration, and I would start by looking at your syslog for errors indicating what might be happening.

There’s already a document database engine in postgres. It already supports bson. It already supports indexes. What the fuck MS?

Advice is to build relationships with others who also use Linux. Find a chat room that you can stay in and stick with for a couple of years. It will be invaluable. Don’t try to do this purely from documentation, stack overflow, blog posts, and searching forums. Real live people is the way to go.

OK, I’m gonna make this simple, since it seems like no one has tried to do that for you. There’s only 3 points

1. Do not expect to buy hardware and THEN use linux
2. When choosing a linux distro, do not choose one that requires you to compile anything
3. Your killer problem - battery life - is 100% a hardware support problem

Breaking it down…

1. Do not expect to buy hardware and THEN use linux Technically no operating system actually works this way. The problem is that every single hardware vendor works with Microsoft to ensure it works on Windows before they release it. You cannot just buy hardware and then later decide to use Linux. You must always check for linux compatibility, and often distro compatability, before buying your hardware.

The reason for this is that every single piece of hardware needs a driver and not every single piece of hardware has a driver in Linux, and not every driver properly works with the hardware it was built for.

So step 1 is always review your preferred distro for support for your target hardware and don’t just wing it. There’s a lot of shitty broken hardware that Linux devs haven’t built workarounds for and only work in Windows because there’s money to create driver workarounds.

This isn’t that strange in the world of hardware, it’s just something MS managed to prevent everyone from dealing with through it’s monopoly power and Apple prevented everyone from dealing with it by only allowing OSX on it’s hardware and controlling all the updates. In any other world, you don’t just buy random components for your car, or buy electronics without worrying about EU vs US outlets or buy power supplies for electronics without researching voltage, amperage, and polarity. It’s just a thing you have to do.

2. When choosing a linux distro, do not choose one that requires you to compile anything

If you want a “just works” experience, then you do not want to be doing it. The forum link you posted is bonkers. There is no way someone with your level of experience should be bisecting anything. You fell into a hole, asked for a way out, and that forum gave you a shovel.

You want to stick with distros that are ready to go: Debian, Ubuntu, Mint, openSuse, Fedora. My personal opinion is every beginner should start with Mint, but everyone’s got opinions.

3. Your killer problem - battery life - is 100% a hardware support problem.

Whatever components you’re running don’t have whatever driver maturity is needed for power management. That could be a lot of things, and there’s no fix unless you want to become a volunteer device driver developer, which is like asking if you want you to become a volunteer suspension bridge repairperson. It’s not a real option for you. That means you’re stuck waiting for someone else to write support for whatever hardware you have. Bringing me back to point #1, do not just attempt to put linux on any old hardware - you must research compatibility as part of your purchasing process.

I’ve been running linux for decades. In the beginning, it was a nightmare. I had to debug it every week, sometimes multiple times each week. Nearly every problem was something I caused trying to fix some other problem. Nearly every problem I was trying to fix was ultimately just a lack of out-of-the-box hardware support and hardware auto-configuration. Fast-forward to 2007, I bought my first thinkpad. I researched linux support and bought one that I knew worked with Debian. Worked first time, no tweaking. Fucking beautiful.

Except some features of the laptop didn’t work. I needed to manually configure the pointer device.

But then, I bought my second thinkpad in 2010. Everything worked, and all the config was through graphical settings tools. Amazing.

Well guess what. I bought a new thinkpad a few years ago. I really wanted a Ryzen. But Lenovo only had the first gen available for sale, the second gen was sold out. I saw the support was perfect for the second gen, but not perfect for the first gen. I bought it anyway.

Wouldn’t you know it. The motherboard has hardware bugs that the drivers just don’t handle gracefully. There’s a fight between Lenovo and the driver developers over it. It never gets fully resolved. However, the battery life problem gets resolved. Now I have 2 bugs:

1. sometimes I have to plug and unplug my external camera into the USB multiple times because the mobo can’t negotiate the connection properly.
2. Sometimes the laptop fails to return from suspend and I have to reboot it.

Both of these suck, and there’s nothing I can do to fix it. I could post on a forum and spend literal weeks trying literally everything everyone tells me, but I know what the problem is - hardware/driver support. I could volunteer to become a driver developer, or to work with a driver developer and give them absolutely everything in detail so they can maybe find the time to fix it, but the reality is, I bought unsupported hardware and this is the consequence. Had I bought the second gen ryzen thinkpad, I would not have these issues.

So don’t try to force your way through this sorta shit and then assume everyone else is going through the same thing. Only buy hardware with components you know are going to work, only use distros that are simple to install and operate. And don’t try to solve problems that are caused by failing to adhere to rules 1 and 2.

Honestly this is completely ridiculous. Hypertext using HTML constraints is absolutely insufficient for representing application state. It’s the wrong tool for the job and always has been, because it conflates document structure with semantic meaning.

Said another way, HTML cannot be relied on to capture a representation of application state.

The reason REST doesn’t use HTML in most contexts is because applications don’t use HTML in most contexts anymore.

Demanding that application representation use a specific encoding strategy is ridiculous and misses the point entirely, which is that HTTP is no longer the right protocol for the job.

deleted by creator

The solution is not centralization, the solution is a protocol. The team at Flattr tried to do something that worked for content, but it was centralized. The team at Ganxy tried to expand the definition of monetize, but it was centralized. If we had a protocol where teams could publish metadata that enabled users to use any data-driven app to generate some form of compensation for the contributors, then we could build all sorts of workflows into package managers that made it easier.

Yes!

Exactly. Track point is the number one reason

It means do not test HOW it is done, only test WHY it is done. Obviously you cannot test an abstract interface, only an implemented one. However, you should not be testing HOW it is implemented. Instead, you should be testing that given X input you get Y output based on the expectations set in the interface.

For example, take method F(x, y) that is designed to take in an identifier x and use it to fetch you a record from some persistence object y. Testing the interface of F(x, y) would mean testing that given the input x you get what you expect from the persistence object y. Testing the implementation would mean testing that F(x, y) issues a call to a specific method of y. For example, if y has an interface with methods getRecordById, getAllRecords, and searchRecords, testing the implementation means asserting which of these methods gets called (usually with a test using a mock object that can be interrogated in this way). Testing the interface means not caring which of these methods are called when satisfying the request for F(x, y)

Sucks living in an authoritarian country with a military dictatorship that spies on its citizens at all levels, pumps propaganda into their homes and schools, and if you disagree with any of it the whole society thinks you’re terrorist and tries to “reeducate” you.

It’s worse than collusion. The break up of AT&T resulted in a legal construction of Franchise Agreements that legally granted regional monopolies in all major population centers in the country in a deliberate bid to avoid Sherman antitrust rules. It’s not merely collusion, you literally cannot compete by law.