Are Proprietary Tools the Key to Linux Desktop Success?

khess 0 421 Views

I'm having a rather traumatic experience with certain Microsoft products lately. My problem is that I'm trying to "get to know" Microsoft's Hyper-V for my virtualization column over at Linux Magazine. The problem is, that to manage a true Hyper-V system remotely, you must have a Windows Vista or Windows 7 system. The problem with that is that I'm not gonna do it. I refuse to adopt either system, which in turn, will also prevent me from using Hyper-V or writing anything about it. I think that for Linux to survive and thrive as a desktop operating system, it needs some proprietary tools.

Must we follow the path of the unrighteous to survive? I believe that all this freedom and openness might be turning in on itself and hurting us in such cases. It is also surprising to note that one must have a Windows Server on which to install VMware's Virtual Center to manage VMware ESX/ESXi systems that are Linux-based.

Where's the freedom in that?

Microsoft recently made a code offering to the Linux kernel for its Hyper-V but yet won't make the remote tools available for anything but <gasp> Vista or the messianic Windows 7.

If vendors feel that they must create proprietary tools for their solutions, they might soon realize that they're cutting out a huge market for those solutions. Why not offer a web-based tool for remote management? Is security the reason? Then offer a cross-platform application to manage those solutions.

In a word, I refuse to adopt or to promote any system or solution whose developers are so nepotistic that they cannot offer cross-platform tools to manage those solutions.

Would the Linux desktop find success in such practices? I don't like the smell of it but it might be the only way to compete. Unfortunately, the open source community doesn't work that way. By providing the source code, anyone, even Microsoft, can take that code and create a Windows-based tool for the world's Windows users.
One interesting side note here--those management tools aren't available for Windows XP either. Isn't that clever of Microsoft? They're forcing you to "upgrade" to one of their newer operating systems which essentially means that they're extorting money from you.

Do you like that? Is this the last resort for desktop operating system survival--by extorting its current user base and technology adopters?

What's your reaction to such proprietary tools and vendor extortion? Write back and let me know.

Dani AI

Generated

This thread highlights a common knee‑jerk vendor pattern: tying the management plane to a specific desktop. is right to be annoyed; is also right that RDP is a useful tool, but RDPing into a headless Server Core won’t magically surface a client‑side GUI. Many management consoles are implemented as client applications or MMC snap‑ins that expect a full Windows desktop, so a remote session to the host just gives a shell and the server’s framebuffer — not the management client.

Practical short‑term options that preserve a Linux desktop on the admin side:

  • Run the vendor management client inside a small, isolated Windows VM or a dedicated Windows management host so the production hosts remain Linux‑only.
  • Check whether the product exposes documented remote APIs (WMI/WinRM, HTTP/REST, SOAP, or other management ports). If present, cross‑platform scripts or lightweight wrappers can be written to automate tasks without the full GUI.
  • Look for third‑party web UIs or command‑line tools that already wrap those APIs.
  • If only a shell is available, verify that remote management services, firewall rules and DCOM/WMI access are properly enabled on the server before assuming the tools are missing.

Longer term, the healthiest outcomes are strategic: insist on documented, networked management interfaces (web or REST), favor vendors who publish cross‑platform SDKs, and support upstream projects that standardize remote management. That reduces lock‑in while keeping security controls intact. summed it up — blocking admins by platform is bad practice. The pragmatic path mixes short‑term engineering workarounds with steady pressure for open, cross‑platform management APIs.

Member Avatar for dietrich
dietrich 0 Newbie Poster

That's just dumb.

The product should support rdp and you should be able to run rdesktop just fine. Yes?

Member Avatar for khess
khess 95 Practically a Master Poster

I can connect to it with RDP but what I see is a command prompt window and a nice cyan screen behind that. There are no local tools that I can find. This is Hyper-V on what amounts to Server 2008 Core.

Member Avatar for Member #421368
Member #421368

Stopping people running stuff because of their choice of platform is just plain wrong. Unless of course if it's IE6.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.

Edit Preview