VNC Very Slow after Intrepid Upgrade

[MMarking]

Binary package hint: vino

I upgraded a box from Hardy to Intrepid, and now connections to this box via SSH and VNC are super slow.

Visually speaking, it looks like no compression is being applied to the connection. I connect to the Intrepid box from a Windows machine using Putty and tightvnc, and it "looks" like vino thinks this remote box is on my local LAN. The compression and "quality" controls within tightvnc have no effect on the connection. The only thing that changes the connection is if I choose 8 bit graphics, but it's still very slow.

There is obviously a regression here because nothing else changed with my setup.

[Sébastien Valette (sebastien-valette)]

same here, screen updates were fast and are now very slow...

[Sébastien Valette (sebastien-valette)]

OK, found the issue, use vinagre instead of vncviewer, at it is fast again...

[volkris (volkris)]

Sébastien's solution doesn't work for me. No matter which viewer I use (vncviewer from tightvnc, vinagre, or remote desktop) vnc connections are now unusably slow.

This is clearly a regression.

[Andy (andy-xillean)]

Same here. This is basically unusable. I tried the Vinagre client and its no luck there. Its a dog. Does anyone test this stuff before they release it? Remote Desktop is a commonly used feature on modern operating systems don't you think one would test this stuff without releasing with such a major regression? And when will this be fixed? in the next version of Ubuntu? 6 months from now? What a mess.

[volkris (volkris)]

No kidding. How did nobody catch this before the release?

Anyway, Andy, in the the mean time look in to installing xvnc, which has a server with perfectly good compression.

[Sebastien Bacher (seb128)]

there is only a few persons working in the ubuntu desktop team and mostly volunteers and there is over an hundred components to work on for several version of ubuntu and thousand of bugs, you are welcome to help testing those software if you want but there is no real point to blame volunteers for being overworked

[volkris (volkris)]

Sebastien, I found your "don't blame the volunteers!" reply personally insulting and, more importantly, inappropriate and unhelpful for the present bug. Was that supposed to be PR?

We bring up the "how did this get through" not to blame, obviously, but to highlight the severity of the bug: this is no annoying quirk or minor regression; this bug makes Ubuntu's VNC implementation immediately and completely unusable if there is a standard residential internet connection involved. Any testing under residential conditions should have shown it immediately.

But since we've crossed that bridge, I will say this: if you can't properly test an update--whether because you don't have the resources, man hours, infrastructure, or whatever--you're still on the hook for the results. If you can't sufficiently test then I suggest you don't release. The regressions in the past few versions of Ubuntu are staggering, disastrous even, and no excuses change that fact.

So yeah: blame the volunteers if that's where the blame lies. They may be overworked and faced with an impossible task, but that doesn't somehow absolve them of the blame. That's life in the real world.

[buck0182 (owensm)]

Its free if you don't like the new release, use the older ones. Sure there are some problems with the new release but there are also alot of things that are drastically improved.

Get over it, let them know the bugs you find and they will fix them.

[Andy (andy-xillean)]

Chris thanks, I'll look at XVNC. Sebastien, If there are only a few people working on fixing bugs then we should just expect massive obvious functionality killing regressions with each new release and not be surprised when Ubuntu gets a reputation for being full of obvious bugs right? No one is blaming you so I don't see why so defensive. This is the responsibility of Canonical and Mark. Maybe Canonical should just hire a team of people to test the basic functionality of visible user facing features so we don't have things like this and the pusle audio, and CD/DVD reading/burning and NvidA 640x480 and SB450 model=xxxxx etc fiasco. Among others. Regressions are a very bad thing and is not to be taken lightly. So if you cannot handle your workload maybe that frustration should be directed at Mark. Buck0182, Telling people its free so they should expect poor quality control does not do anything to promote Ubuntu or Free Software. That is simply programming people to expect that poor quality control = free software. ( Sticking to release dates < Fixing regressions. )

[Sebastien Bacher (seb128)]

what about being constructive rather than blaming canonical for not having infinite money to use to solve your bugs and opening a bug on bugzilla.gnome.org if you have the issue so the people writting the software know about it and can start working to get it fixed next?

[volkris (volkris)]

Sebastien, your excuses for imperfect software weren't exactly (and continue to not be) constructive in the first place. Right: there are bugs here. Right: perfect software is impossible, especially with too few resources. But so what? Accept the flaw and deal; the development problems at Ubuntu aren't any of our business. The buck stops at Ubuntu, and if that means volunteers are to blame then so be it.

In any case, bugzilla.gnome.org already has the bug report, though I don't have the bug number immediately at hand. They believe it has something to do with passing too many mouse events, I believe, though last I checked there was no solid proposed solution.

With regard to Ubuntu, it's entirely legitimate to report the bug here as well as it may be possible for Ubuntu to roll back to the previous release of Vino since this one is unusable. At the very least, a user might not know that bugzilla.gnome.org was the proper place to report bugs in Vino... lord knows I had a little trouble looking for a homepage for the project.

[Andy (andy-xillean)]

Sebastien this is not "My" bug. This bug shows up on every installation of Ubuntu that I do for people. No matter the hardware. If i knew how to program then i would fix it myself god knows i would volunteer to test user facing features before release and fix all of them if I knew how to do that. What i try to do to help is first spread Ubuntu (157 users so far) and second report bugs here. Why wait for upstream to fix bugs? Can't they be fixed downstream? Would that not be a good value add to Ubuntu if they fix the obvious bugs instead of waiting for upstream and a whole new version to upgrade to? I have tried different windows clients, and Mac clients along with clients on Ubuntu and PClinuxOS none of them work. If I install hardy then it works but only IPV6 out of the box. What gives? Can you try verify this bug and see if you can duplicate it. I have no problems doing so. Just install a plain vanilla version of Intrepid then enable remote desktop then try to connect to it with a 54MBS wireless connection. See what happens. Try it even with a DSL Cable connection. See what happens. As it stand right now Ubuntu does not have any viable remote desktop feature out of the box. That is sad in these times. Unfortunately this is a bug of anyone that uses VNC. This is not just "My" bug. So i ask you. What else can I do to be constructive so that you and your team can fix this bug in a timely fashion? I am at your command.

[Sebastien Bacher (seb128)]

the issue is that nobody is working on vnc in ubuntu right now, your frustration is understandable but the best you can do now is either find somebody interested to work on that or send the bug upstream where you might find an another set of interested people to read about the issue

[MMarking (cpt-mocha)]

A search on bugzilla for vino brings up 17 bugs, none of them are related to this problem. Chris, what is the bug number you saw this issue reported under? Thanks.