This is really splitting hairs, but if you asked that cloud CEO if he employed programmers or ‘software engineers’ he would almost certainly say the latter. The larger the company, the greater the chance they have what they consider an ‘engineering’ department. I would guess he employs 0 “programmers” or ‘engineeringless programmers’.

Let me weigh in with something. The hard part about programming is not the code. It is in understanding all the edge cases, making flexible solutions and so much more.

I have seen many organizations with tens of really capable programmers that can implement anything. Now, most management barely knows what they want or what the actual end goal is. Since managers aren’t capable of delivering perfect products every time with really skilled programmers, if i subtract programmers from the equation and substitute in a magic box that delivers code to managers whenever they ask for it, the managers won’t do much better. The biggest problem is not knowing what to ask for, and even if you DO know what to ask for, they typically will ignore all the fine details.

By the time there is an AI intelligent enough to coordinate a large technical operation, AIs will be capable of replacing attorneys, congressmen, patent examiners, middle managers, etc. It would really take a GENERAL artificial intelligence to be feasible here, and you’d be wildly optimistic to say we are anywhere close to having one of those available on the open market.

20 years ago at a trade show, a new module based visual coding tool was introduced in my field which claimed “You’ll never need another programmer”.

It’s because people trying to sell silver bullets is nothing new.

Hint: it’s not just in tech…

How much longer until cloud CEOs are a thing of the past? Wouldn’t an AI sufficiently intelligent to solve technical problems at scale also be able to run a large corporate division? By the time this is actually viable, we are all fucked.

Sweet, I can’t wait to see ModAI implementing moderation to further Reddit’s boring echo chamber.

Been using KDE + HiDPI + X11 for close to 5 years now, not a blurry font to be found.

If the developers’ wants and needs don’t intersect with a given user, there is no way forward for that user, community manager or not.

I suspect the small size of the dev team and the general nature of an OSS project means there aren’t swarms of people around volunteering to be community managers.

Small projects your sway with the project is directly proportional to your ability to submit pull requests. It’s just a sad fact that it’s easier to say “I wish we had feature X” vs. “Here is a pull request that implements feature X”.

At least with OSS you are getting what you paid for (nothing!), vs commercial companies where you pay for the software and they STILL ignore you.

Even “Why don’t you open an issue on our source tracker” will often effectively shut down suggestions from less tech savvy newcomers.

How should developers handle feature requests? Keep in mind there is a need for the whole team to see the suggestion and it’s also good to have a place to gather feedback and further discuss.

In the year 2057, human civilization had made significant strides in technological advancements that transformed their way of living. Computers were no longer just machines but extensions of one’s mind, and programming languages became a fundamental part of society. A prominent figure within this world was Vincent, a passionate programmer who swore by his beloved text editor Vi.

Meanwhile, in another galaxy far away, an advanced alien race called Zorblaxx, discovered Earth during a cosmic journey. With their keen interest in studying intelligent life forms, they intercepted a data stream containing the source code for Emacs. They immediately fell in love with its simplicity and user-friendliness. From that point onwards, the entire Zorblaxx race began using it as their primary tool for coding.

The first contact between humans and Zorblaxx occurred when a spaceship piloted by a group of fearless astronauts encountered a fleet of alien vessels. The initial meeting was cordial, and both species shared their knowledge of the cosmos. However, when humans revealed they used Vi, the Zorblaxx responded with disdain. They claimed that the Vi editor lacked the basic functionality that Emacs provided.

This dispute grew beyond petty differences over software preference. Debates erupted amongst developers worldwide. Some advocated for Vi’s efficiency while others preached the power of Emacs. Passions ran high, turning what could have been a friendly argument into a worldwide conflict.

Political leaders took notice and saw an opportunity to rally support for their respective countries. With the rise of nationalistic sentiments, humanity split into two factions: Team Vi and Team Emacs. Nations aligned themselves, and soon war broke out.

As the violence escalated, Vincent knew there had to be another way. He realized that both sides had something valuable to offer one another, and that a healthy collaboration would lead to better results. He developed a new text editor called Vim, combining the best features of both Vi and Emacs.

With Vim demonstrating the benefits of unity, both human factions united, joining forces against the invading Zorblaxx. In this unforeseen twist, the two races found themselves fighting side by side, bonding through their love for programming and shared vision for progress.

The battle raged on for months, but in the end, humanity emerged victorious. Faced with a common enemy, they learned to embrace diversity and to see past their differences. The same spirit was adopted by the Zorblaxx race, leading them to adopt Vim as their primary editor. A new era of peace and cooperation began between the two civilizations, now connected by technology and their mutual passion for programming.

Be aware that depending on your workload and/or deployment processes, OpenBSD may or may not be a better choice. For example, OpenBSD has a very secure default install, but containerization tools like Docker are not available. Additionally, if you require specialized hardware (e.g., a specific network card), OpenBSD may not have the required drivers available. However, if you prioritize security and want a system that is less prone to attacks and malware, OpenBSD could be a good option for you. Here’s a checklist of things to consider before making the switch:

• Check whether all necessary hardware and software are supported by OpenBSD.
• Make sure you have a backup plan in case something goes wrong during the migration process.
• Get familiar with the OpenBSD user interface and commands to ensure smooth transition.
• Back up all important data and settings before the migration.
• Update your software sources to ensure you have access to the latest stable versions of software packages.
• Prepare yourself with the knowledge of how to handle any issues that might come up during the migration process.
• Test the system thoroughly after the migration to ensure everything is working as expected.

Overall, switching to OpenBSD can be a rewarding experience if you take the necessary precautions and prepare yourself well. Good luck with your migration! Let me know if you need further assistance or have any other questions related to OpenBSD or Linux operating systems.