There’s lots of reasons that that phrase could be in the document:

“Open up the world of Wifi by purchasing our optional Wifi Adapter (not found in base model)”

“Open up the world of WiFi with our new wireless printers (coming soon)”

Op’s lazy approach of doing a search and not even bothering to read the documents that he found is the core of the approach. The “algorithm” didn’t let him down. It found the most relevant document for his search.

Sorry, I can’t follow this logic. What I THINK you are saying:

“I searched for ‘Canon G2570 wifi’. Since there are results, that means this particular printer has Wifi.”

However, If I search for “canon g2570 aliens”, I also get the same support page. Does that mean the printer was created by aliens?

Especially these days,you must actually read the links that appear in search engines. Their job is to take your search keywords and to find the most relevant document. From what I can see above, the indicated document WAS the most relevant to your search. For all you know, that bit about Wifi was for a blurb of a separate product linked from the indicated page.

If this is how you conduct internet research, I would urge you to actually read and confirm the documents you find in search engines.

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.