okaaay, let me try and rephrase then... "the widely accepted popular choices/ beliefs/ patterns, etc." basically what i'm trying to say is: question and evaluate everything for yourself. don't just blindly follow what the masses are doing. i believe that's the herd mentality, yes? i have no problems with the industry coming up with standards so that everybody's on the same page. hope i've explained my intentions clearly.
I think one of the main parts here is the word standard. Docker is not the standard, standard is OCI. Docker complies with OCI, Podman complies with OCI. Both are just some of the tools that implement the current container standards. And the main problem, in my opinion, is that we currently view one particular technology as a standard. It's similar if instead of HTTP requests we would be talking about "Focus-Pocus requests", simply because "Focus-Pocus" would be the very popular tool that implements the HTTP standard.
The reason most experienced devs will ONLY go with things that are widely used, is because we've lived long enough to get burned by using some less popular tool or framework where if you try to google some specific problem or issue you find "zero search results".
If you go with the standards all the bugs will be worked out, you'll interoperate with the rest of the world better, you'll find much more resources, and others will want to join you in whatever you're doing. If you go with the oddball framework, you'll have more trouble, less quality, less support, less interoperability, higher maintenance costs, as a 'general rule'.
Just like most products (from guns to cars) if you buy the oddball product, you're just asking for difficulties that otherwise are easy to avoid.
Like any rule, there are exceptions. What I just stated is all "on average", "rule of thumb" type of advice. Take it or leave it. :)
It's an important point about lack of support, community, and Google/Stack Exchange results. A long time ago, I worked in a department where we used Borland (later Embarcadero) C++ Builder and Ingres database, and an ancient version of RedHat Linux on the backend. There were many problems that we had to overcome that existed because of that particular combination of technologies, for which we could find no outside help because I don't think anyone else used that combination of technologies. Whilst trying to figure out how to deal with one of these problems one day, I wondered out loud: "I wonder how many people in the world use C++ Builder, Ingres and RedHat together?". I began to count the number of people in the office: "1, 2, 3, 4..." and everyone laughed.
I've been coding 30 years (in my 50s) and used Borland C++ a lot too. Your example sounds familiar to a lot of what I've seen many times. I've seen junior developers download random libraries from the old sourceforge and put it directly into a commercial product with no permission asked for, no discussions had, etc. And it was a name-brand company you'd know.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
okaaay, let me try and rephrase then... "the widely accepted popular choices/ beliefs/ patterns, etc." basically what i'm trying to say is: question and evaluate everything for yourself. don't just blindly follow what the masses are doing. i believe that's the herd mentality, yes? i have no problems with the industry coming up with standards so that everybody's on the same page. hope i've explained my intentions clearly.
I think one of the main parts here is the word standard. Docker is not the standard, standard is OCI. Docker complies with OCI, Podman complies with OCI. Both are just some of the tools that implement the current container standards. And the main problem, in my opinion, is that we currently view one particular technology as a standard. It's similar if instead of HTTP requests we would be talking about "Focus-Pocus requests", simply because "Focus-Pocus" would be the very popular tool that implements the HTTP standard.
yes 👍
The reason most experienced devs will ONLY go with things that are widely used, is because we've lived long enough to get burned by using some less popular tool or framework where if you try to google some specific problem or issue you find "zero search results".
If you go with the standards all the bugs will be worked out, you'll interoperate with the rest of the world better, you'll find much more resources, and others will want to join you in whatever you're doing. If you go with the oddball framework, you'll have more trouble, less quality, less support, less interoperability, higher maintenance costs, as a 'general rule'.
Just like most products (from guns to cars) if you buy the oddball product, you're just asking for difficulties that otherwise are easy to avoid.
Like any rule, there are exceptions. What I just stated is all "on average", "rule of thumb" type of advice. Take it or leave it. :)
thank you for your opinion ♥️🙏
It's an important point about lack of support, community, and Google/Stack Exchange results. A long time ago, I worked in a department where we used Borland (later Embarcadero) C++ Builder and Ingres database, and an ancient version of RedHat Linux on the backend. There were many problems that we had to overcome that existed because of that particular combination of technologies, for which we could find no outside help because I don't think anyone else used that combination of technologies. Whilst trying to figure out how to deal with one of these problems one day, I wondered out loud: "I wonder how many people in the world use C++ Builder, Ingres and RedHat together?". I began to count the number of people in the office: "1, 2, 3, 4..." and everyone laughed.
I've been coding 30 years (in my 50s) and used Borland C++ a lot too. Your example sounds familiar to a lot of what I've seen many times. I've seen junior developers download random libraries from the old sourceforge and put it directly into a commercial product with no permission asked for, no discussions had, etc. And it was a name-brand company you'd know.