>Resizing a slashdot window in Windows/IE is no
>problem, and at a very rough estimate about 10fps,
>and even Windows/Mozilla at a usable 5. For me it's
>a completely different story under XFree86: Mozilla
>and Konquerer both resized at about 1fps, which is
>unusable.
You are right. But in my experience (I had the same card too once) this cannot be blamed on X, but mostly on the toolkits (Qt,mozilla-xul) and on the applications themselves.
>SVN is a bit nicer than CVS, though, in that the
>conflicts are stored in a.rej file rather than
>inline with the code. You have to remove that.rej
>file to let SVN know that you've handled the
>conflict before a commit can proceed. (this
>prevents the cases where people commit conflict
>markers into CVS).
Personally I like the CVS way (at least for simple changes). I hope there's a way to do it the CVS way
>You want a transparent terminal? How about a
>transparent video player?
Does it support fully asynchronous operation between multiple applications? X does and it's major feature of it. Without it we are just like in the days of Windows 3.1 (cooperative multitasking).
It is bad enough that we have to suffer cooperative multitasking in mozilla/netscape (it sucks). Suffering it trough the entire window system is not acceptable (I'd rather go to NT which doesn't have this misfeature).
It seems to be a nice thing for an embeded device. But I'd never use it on my desktop machine. (The lack of network support doesn't bother me much, VNC is cool).
It's about time Linux supported non-overcommit memory allocation properly instead of the current "efficient" hack.
What we need is:
/proc/sys/vm/overcommit-pages
This would specify he amount of allowed overcommit. If set to 0 (the default) there should not be any overcommit at all!
I think this would help the VM development tremendously because I believe that currently the margin between systems in OOM state and heavily loaded systems is not clearly defined, the system just gets slower until oom_kill happens.
It would be also be useful to disable discarding of executable pages (programs, shlibs). I have noticed this causing slowdowns on my system without swap. I'd prefer to be notified to add more swap instead.
Slashdot Mirror
yes, but CD media is $1 not $15
this why you rip your DVD to a CD and keep the DVD safe.
>Resizing a slashdot window in Windows/IE is no
>problem, and at a very rough estimate about 10fps,
>and even Windows/Mozilla at a usable 5. For me it's
>a completely different story under XFree86: Mozilla
>and Konquerer both resized at about 1fps, which is
>unusable.
You are right. But in my experience (I had the same card too once) this cannot be blamed on X, but mostly on the toolkits (Qt,mozilla-xul) and on the applications themselves.
>SVN is a bit nicer than CVS, though, in that the
>conflicts are stored in a
>inline with the code. You have to remove that
>file to let SVN know that you've handled the
>conflict before a commit can proceed. (this
>prevents the cases where people commit conflict
>markers into CVS).
Personally I like the CVS way (at least for simple changes). I hope there's a way to do it the CVS way
What is superbowl? Is it something you server your dog's breakfast in?
>and it would seriously slow Mozilla down, since >spawning a process is usually pretty slow.
bullshit!
you mean, spawning a "mozilla" process is pretty slow.
Hmm, yes. Does the FreeBSD have a non-overcommit option?
I might switch if it does.... I'd certainly try it.
> there is indeed a /proc entry >(/proc/sys/vm/overcommit_memory)
That setting doesn't work properly. Linux will just overcommit slightly less.
GP3 is still one of the best and most realistic modern-F1 simulators.
You are not alone.
alias = command line alternative for desktop icons
Maybe use the old VMS way where you define an alias for all commands that you need to use interactively.
Scripts should use absolute paths anyway, no problem there.
>>- Mozilla has tabbled browsing
>Which slows down the quick alt+tab everyone uses to >switch between browser windows...
Agreed 100% Tab browsing is just overhyped UI bloat. For many people it's just a workaround for crappy new-window performance
Are you my long lost twin? ;)
I have the exact same problems.
Middle-click paste is the most annoying feature ever.
I also select/deselect text all the time as I read it. This sometimes crashes in drag-and-drop...
ICQ... they should add IRC to really melt down the networks
But we have a great F1 commentator ;)
Nesting window managers is bad.
The fatal flaw with MDI is the nesting of window management. This is often not desirable.
If you find yourself wanting MDI it's probably because your main window manager is not very usable (but may look pretty, eh ;)
The fact that MSDEV forces you to have all your windows in a single huge (99% of the time maximized) window just sucks IMO.
/proc/sys/vm/overcommit_memory=0
certainly doesn't prevent the overcommit. If it worked, this issue wouldn't come up regularly.
Personally, I want to disable overcommit. Disk is relatively cheap and I have no problem with adding 1gig of swap.
And it wouldn't decrease the efficiency at all.
Does it support malloc correctly now (returning NULL when out of memory)?
>transparent video player?
Does it support fully asynchronous operation between multiple applications? X does and it's major feature of it. Without it we are just like in the days of Windows 3.1 (cooperative multitasking).
It is bad enough that we have to suffer cooperative multitasking in mozilla/netscape (it sucks). Suffering it trough the entire window system is not acceptable (I'd rather go to NT which doesn't have this misfeature).
It seems to be a nice thing for an embeded device. But I'd never use it on my desktop machine. (The lack of network support doesn't bother me much, VNC is cool).
I agree about oom_kill being a terrible klugde.
It's about time Linux supported non-overcommit memory allocation properly instead of the current "efficient" hack.
What we need is:
This would specify he amount of allowed overcommit. If set to 0 (the default) there should not be any overcommit at all!
I think this would help the VM development tremendously because I believe that currently the margin between systems in OOM state and heavily loaded systems is not clearly defined, the system just gets slower until oom_kill happens.
It would be also be useful to disable discarding of executable pages (programs, shlibs). I have noticed this causing slowdowns on my system without swap. I'd prefer to be notified to add more swap instead.
SVG yes.
But let's not repeat the mistake of mozilla: writing too much stuff in javascript and overdoing the CSS with themes.
We need a "page linked to all others" ... :)
Excellent replacement for C/C++ for writing high-level stuff. Not a replacement for Java IMO.
Good:
- override keyword
- changes to switch statement
- lots of stuff from Java
Unknown/Missing:
- "throws" keyword? It would be nice.
I hope there's a GCC frontent soon.
I don't think there will ever be one dominant widget set.
These are the big ones:
- Motif+LessTif
- Qt
- Gtk+
- Java Swing
- Mozilla XUL
- Xt/Xaw
- Tk (tcl,perl)
Most people run 3-4 of them at the same time.
This really bad for efficiency of the system, even if we ignore the UI consistency problems.
Unfortunatelly I don't see this improving any time soon. Xt would need to be deprecated in X for anything to happen.