Why is qt3 still default?
ceed
I have been using 64 bit qt4 builds of Opera for some time and it's rock
solid. Also, the qt4 builds integrates much better visually in my desktop
environment (menus etc.). Actually, it makes Opera as pleasing to look at
as Firefox, Chromium and even Epiphany. I have no idea why Opera chooses
to offer a qt3 based builds as default. In my case it would be the only
program I use which would require qt3. Has anyone here had problems with
the qt4 builds? If there's stability problems that would explain it, but
again, it's been rock solid here.
--
//ceed
Remco Lanting
http://my.opera.com/ruario/blog/2009/09/28/which-version has some info on
that.
I've been on the Qt4 version for quite a while now, it works fine here.
--
Remco Lanting
[Unofficial Opera bug tracker links]
http://opera.remcol.ath.cx/bugs |
http://my.opera.com/community/forums/topic.dml?id=217364 |
remco.lanting...@gmail.com
Jens Schuessler
I don't use qt4, but you can find a lot of people with actual problems
about qt4 in the forum
http://my.opera.com/community/forums/topic.dml?id=282339
http://my.opera.com/community/forums/search.dml?term=qt4&id=3
That doesn't sound very rock solid to me.
ceed
> I don't use qt4, but you can find a lot of people with actual problems
> about qt4 in the forum
> http://my.opera.com/community/forums/topic.dml?id=282339
> http://my.opera.com/community/forums/search.dml?term=qt4&id=3
> That doesn't sound very rock solid to me.
The thing is that people have problems with qt3 versions of Opera as well.
The link you provided doesn't say if the person had the same, or other,
problems with qt3. On the other hand he "threatens" to move to Chromium,
so it seems like Opera qt3 isn't an option for him either. The thing is
that if someone has a memory leak when using qt3 they won't automatically
blame qt3 since it's the standard. I do not not have any problems at all
and found the reports in Opera's forums and elsewhere inconclusive.
--
//ceed
Aaron W. Hsu
I am seeing the same common complaints there that I see everything. Opera
uses too much RAM. It doesn't look like a memory leak to me. Opera uses
free RAM, and that's a good thing. It's also the fastest program I know of
to make those pages available again for other applications when memory
gets really tight.
The reason that QT4 builds are probably still not the default on Linux (I
don't know much of the context here), is that some of the latest releases
of QT4 that some of the distributions ship has serious incompatibility
issues with Opera, and Opera is completely unusable with them: it crashes
on startup every time, I think.
I use the QT4 builds on Slackware64 13.0 and have great reliability with
them, but their QT4 version was cut just before that other release made
life a mess for those who were tracking snapshots.
Aaron W. Hsu
--
Of all tyrannies, a tyranny sincerely exercised for the good of its
victims may be the most oppressive. -- C. S. Lewis
TimC
was almost, but not quite, entirely unlike tea:
> I am seeing the same common complaints there that I see everything. Opera
> uses too much RAM. It doesn't look like a memory leak to me. Opera uses
> free RAM, and that's a good thing. It's also the fastest program I know of
> to make those pages available again for other applications when memory
> gets really tight.
What?
It's not a good thing when it pushes other things out of the working
set of ram+cache. As far as I'm aware, there's no mechanism other
than parsing /proc/meminfo as to when there's memory pressure, and
I've never seen opera dump any ram in response to this. I have had to
instate a 3.5G ulimit on opera though so it won't cause the rest of
the system to thrash when my 4G of ram starts to run low (opera starts
getting unstable once it has taken about 3G on my system anyway).
--
TimC
Our goverment "invests" in roads, but "subsidises" public transport.
-- Peter Corlett (UK)
Aaron W. Hsu
<tcon...@no.spam.accepted.here-astro.swin.edu.au> wrote:
> It's not a good thing when it pushes other things out of the working
> set of ram+cache. As far as I'm aware, there's no mechanism other
> than parsing /proc/meminfo as to when there's memory pressure, and
> I've never seen opera dump any ram in response to this. I have had to
> instate a 3.5G ulimit on opera though so it won't cause the rest of
> the system to thrash when my 4G of ram starts to run low (opera starts
> getting unstable once it has taken about 3G on my system anyway).
Where are you seeing this? I've never seen this, and haven't heard about
it in the most common complaints against Opera's memory usage. Are you
saying that if you stop using Opera, background it, and don't mess with
it, and then start using other programs that start to consume RAM, that
the other applications are forced into Swap
rather than Opera?
Also, are you also saying that Opera, during use continues to consume more
and more RAM, without stopping or hitting an upper limit? This is without
any plugins
enabled, and coming directly from the opera executable, and not the forks
for plugins?
This is using the QT4 builds on Linux?
Creideiki
> Also, are you also saying that Opera, during use continues to consume
> more and more RAM, without stopping or hitting an upper limit? This
> is without any plugins
> enabled, and coming directly from the opera executable, and not the
> forks for plugins?
I'm not sure what Tim's saying, but that's what I'd like to say. It's
gotten worse since I switched to 64-bit builds of Opera 10.00 - a
32-bit Opera at least had the natural limit of hanging after
allocating 4GB.
I first saw it on 9.64 and filed bug DSK-253347, but it's still there
in 10.00. I had the feeling that I started seeing these large memory
leaks when I started using Opera to read RSS feeds, but I have another
instance of a 64-bit 10.00 without any RSS feeds but that does the
same thing, albeit slower (it takes two weeks to grow to 4GB instead
of 4 days).
> This is using the QT4 builds on Linux?
9.64 Qt3, 10.00 Qt3, 10.00 Qt4, all on Gentoo/AMD64.
TimC
was almost, but not quite, entirely unlike tea:
> <tcon...@no.spam.accepted.here-astro.swin.edu.au> wrote:
>
>> It's not a good thing when it pushes other things out of the working
>> set of ram+cache. As far as I'm aware, there's no mechanism other
>> than parsing /proc/meminfo as to when there's memory pressure, and
>> I've never seen opera dump any ram in response to this. I have had to
>> instate a 3.5G ulimit on opera though so it won't cause the rest of
>> the system to thrash when my 4G of ram starts to run low (opera starts
>> getting unstable once it has taken about 3G on my system anyway).
>
> Where are you seeing this? I've never seen this, and haven't heard about
> it in the most common complaints against Opera's memory usage. Are you
> saying that if you stop using Opera, background it, and don't mess with
> it, and then start using other programs that start to consume RAM, that
> the other applications are forced into Swap
> rather than Opera?
Nope. But since my working set always includes opera (I'm a sysadmin/
developer, so I'm always on the web (wasting time)), when I return to
opera, if it's using 3.5G, then I have to sit and wait for it to fight
with emacs, etc etc.
What your explanation earlier sounded like was that opera actively
drops some of its memory usage when it notices the rest of the system
wants it. As you are probably aware, this most certainly is not the
case.
If opera is using all that ram for caching, then caches are meant to
speed up a system. Fighting with the rest of the system is not one
way of achieving that. On the other hand, since memory usage grows
unboundedly linearly with time, my suspicion is more that it's a
memory leak rather than a cache (or someone forgot to instate a bounds
on some cache somewhere), or there's really bad memory fragmentation
and a not-so-good memory allocator somewhere.
> Also, are you also saying that Opera, during use continues to consume more
> and more RAM, without stopping or hitting an upper limit? This is without
> any plugins
> enabled, and coming directly from the opera executable, and not the forks
> for plugins?
From top currently:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME COMMAND
9220 tconnors 20 0 3583m 2.3g 11m R 83 60.2 41,37 opera
Looks like it's about to hit my 3.5G virtual memory ulimit[1], darnit.
Lastnight it still had a few hundred megs to go.
(htop shows the threads and forked processes:
9220 tconnors 20 0 3583M 2383M 11740 R 87.0 60.1 41h38:10 `- /usr/lib/opera/9.63/opera -newwindow
30306 tconnors 20 0 411M 22904 10432 S 0.0 0.6 0:54.25 | `- /usr/lib/opera/9.63/operapluginwrapper-native
10311 tconnors 20 0 11640 228 208 S 0.0 0.0 0:02.35 | `- /usr/lib/opera/9.63/operaplugincleaner 9220
9467 tconnors 20 0 3583M 2383M 11740 S 0.0 60.1 0:00.00 | `- /usr/lib/opera/9.63/opera -newwindow
)
[1] ulimit -v $((1024*512*7))
> This is using the QT4 builds on Linux?
$ dpkg -s opera
Package: opera
Architecture: amd64
Version: 9.63.2474.gcc4.qt3
...
(debian unstable)
--
TimC
Personally, I think of first-order predicate calculus (FOPC) as a
large fluffy bunny called Fopsy with long ears. - John D. Salt