10 Aug
2004
10 Aug
'04
5:45 p.m.
first of all, sorry if this topic has been talked about to death.
At the moment i'm starting to get more and more into recording (both multi-track and
synths, etc). I added on a second monitor and am now in the process of trying out
different window managers (again). I'm using xfce at the moment, but i might try
fluxbox again for a while.
Now for the question: which window manager are you using for audio work and why? I
don't mean for this to start a flame war... notice it wasn't titled
"what's the best window manager?" ;) I just want to take an informal survey
of what everyone is using and see why people use what they do.
Thanks in advance,
--Andrew
10 Aug
10 Aug
6:02 p.m.
Andrew Dahlin wrote:
first of all, sorry if this topic has been talked
about to death.
At the moment i'm starting to get more and more into recording (both
multi-track and synths, etc). I added on a second monitor and am now
in the process of trying out different window managers (again). I'm
using xfce at the moment, but i might try fluxbox again for a while.
Now for the question: which window manager are you using for audio
work and why? I don't mean for this to start a flame war... notice it
wasn't titled "what's the best window manager?" ;) I just want to
take an informal survey of what everyone is using and see why people
use what they do.
I was using xfce but moved over to using Windowmaker just because I like
the usability of WindowMaker a little more. Both of them are very
lightweight and work well for audio, I think, and don't have the
overhead of a full-blown desktop environment like KDE or Gnome.
--
Rule of Feline Frustration:
When your cat has fallen asleep on your lap and looks utterly
content and adorable, you will suddenly have to go to the
bathroom.
6:16 p.m.
Greetings:
Blackbox. Fast, light, totally unadorned... My machines are quite slow
by today's standards, so I need to squeeze the juice out of 'em. I like
KDE and GNOME, but they're 'way too heavy for me.
Best,
dp
Brett W. McCoy wrote:
Andrew Dahlin wrote:
first of all, sorry if this topic has been talked
about to death.
At the moment i'm starting to get more and more into recording (both
multi-track and synths, etc). I added on a second monitor and am now
in the process of trying out different window managers (again). I'm
using xfce at the moment, but i might try fluxbox again for a while.
Now for the question: which window manager are you using for audio
work and why? I don't mean for this to start a flame war... notice it
wasn't titled "what's the best window manager?" ;) I just want to
take an informal survey of what everyone is using and see why people
use what they do.
I was using xfce but moved over to using Windowmaker just because I
like the usability of WindowMaker a little more. Both of them are
very lightweight and work well for audio, I think, and don't have the
overhead of a full-blown desktop environment like KDE or Gnome.
6:19 p.m.
On Tue, 10 Aug 2004 14:30:01 -0700
Andrew Dahlin <krinkle(a)adelphia.net> wrote:
first of all, sorry if this topic has been talked
about to death.
At the moment i'm starting to get more and more into recording (both
multi-track and synths, etc). I added on a second monitor and am now
in the process of trying out different window managers (again). I'm
using xfce at the moment, but i might try fluxbox again for a while.
Now for the question: which window manager are you using for audio
work and why? I don't mean for this to start a flame war... notice it
wasn't titled "what's the best window manager?" ;) I just want to take
an informal survey of what everyone is using and see why people use
what they do.
Hi,
i use fluxbox. It is rather lightweight and handles multiple screens
very well [as opposed to gnome2.? which didn't quite work here]. KDE
handles multiple screens ok, too. dunno about other wm's/desktp
environments..
Flo
--
Palimm Palimm!
http://affenbande.org/~tapas/
6:47 p.m.
On Wed, 11 Aug 2004 00:13:43 +0200
Florian Schmidt <mista.tapas(a)gmx.net> wrote:
Hi,
i use fluxbox.
I was using fluxbox 0.1.14 for some time, but Debian Testing has
just moved to version 0.9.X which as far as I am concerned is
a significant downgrade. Its slower, suffers from weird redraw
glitches and the slit at the mottom of the screen is missing
borders.
I actually went back to blackbox (fluxbox's ancestor) on the
one box I had upgraded to 0.9.X.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"If you need a piece of paper and a pen to explain it,
then its not bleedin' obvious" -- Erik's First Law
6:45 p.m.
On Tue, 2004-08-10 at 22:30, Andrew Dahlin wrote:
Now for the question: which window manager are you
using for audio work and why?
i ditched KDE when it got bit-rot and i didn't have the time to google
for fixes.
i'm using fvwm for desktop and audio - fast, light, doesn't spawn any
crud you didn't ask for. suspect it differs only in detail from fluxbox
(i have too much investment in fvwm to try fluxbox ATM).
several months ago i gifted my fvwm configs to a guy interested in
switching - he may have compared fvwm and fluxbox and made a less
prejudicial decision.
good luck
R
9:47 p.m.
Andrew Dahlin wrote:
first of all, sorry if this topic has been talked about
to death.
At the moment i'm starting to get more and more into recording (both multi-track and
synths, etc). I added on a second monitor and am now in the process of trying out
different window managers (again). I'm using xfce at the moment, but i might try
fluxbox again for a while.
Now for the question: which window manager are you using for audio work and why? I
don't mean for this to start a flame war... notice it wasn't titled
"what's the best window manager?" ;) I just want to take an informal survey
of what everyone is using and see why people use what they do.
Thanks in advance,
--Andrew
Fluxbox:
It's extremely low in system load, fast, compact, configurable,
efficient, has menus easy to generate and modify, supports simple key
bindings to launch apps or even groups of apps, themes are simple to
create and apply, has no useless crap on screen, power and simplicity of
right-click cascading menus is unbeatable, user can tear off a submenu
then close it when done with a single click, and it does everything I
need a WM to do
Tabbed dialogs - can merge applications into one window, or with Ardour
for example can open the editor under one tab and the mixer under another:
in file ~/.fluxbox/groups all you need is ardour_editor ardour_mixer to
open both in one window from one click
in file ~/.fluxbox/keys Mod1 m :ExecCommand
/usr/lib/thunderbird/thunderbird launches Thunderbird
in file /usr/local/share/fluxbox/styles/Custom this simple line sets the
appearance of the root window -
rootCommand: bsetroot -mod 4 4 -bg rgb:10/20/30 -fg
rgb:30/40/50
in top, system load at idle:
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
1011 root 12 0 2412 2408 1828 S 0.0
0.4 0:00 fluxbox
I've been using this WM for a couple of years now, and whenever I find
myself in Gnome or KDE, or God forbid Windows, I feel constrained,
dictated to, and surrounded by clutter. It supports all Linux audio
work beautifully. I cannot imagine, and certainly have never used a
more productive work environment.
Frank
--
humans may reply by deleting the x from my address
11 Aug
11 Aug
4:03 a.m.
On Tue, 10 Aug 2004 21:34:18 -0400
pirrone <pirrone(a)localnet.com> wrote:
Fluxbox:
It's extremely low in system load, fast, compact, configurable,
efficient, has menus easy to generate and modify, supports simple key
bindings to launch apps or even groups of apps, themes are simple to
create and apply, has no useless crap on screen, power and simplicity of
right-click cascading menus is unbeatable, user can tear off a submenu
then close it when done with a single click, and it does everything I
need a WM to do
I'm really curious about what version you are using.
Version 0.1.14 was really nice but I'm having a bunch of problems with
0.9.9.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
Moore's Law: hardware speed doubles every 18 months
Gates' Law: software speed halves every 18 months
12:43 p.m.
On Wed, Aug 11, 2004 at 05:47:19PM +1000, Erik de Castro Lopo wrote:
On Tue, 10 Aug 2004 21:34:18 -0400
pirrone <pirrone(a)localnet.com> wrote:
I've been running 0.9.9 on gentoo for quite a while with no probs.
What's wrong with yours?
--
Paul Winkler
http://www.slinkp.com
Fluxbox:
It's extremely low in system load, fast, compact, configurable,
efficient, has menus easy to generate and modify, supports simple key
bindings to launch apps or even groups of apps, themes are simple to
create and apply, has no useless crap on screen, power and simplicity of
right-click cascading menus is unbeatable, user can tear off a submenu
then close it when done with a single click, and it does everything I
need a WM to do
I'm really curious about what version you are using.
Version 0.1.14 was really nice but I'm having a bunch of problems with
0.9.9. 
1:46 p.m.
Paul Winkler wrote:
I've been running 0.9.9 on gentoo for quite a while with no probs.
What's wrong with yours?
While not directed at me, since I run Gentoo also:
1) Have you switched to xorg-x11 yet?
2) do you run bbkeys?
If so, I see that Alt-Tabs no longer work reliably. The often just call
up the switcher, but then do not raise the requested window when the
Alt-Tab is released. This did not happen under XFree86.
fluxbox problem? xorg problem? bbkeys problem?
3:22 p.m.
On Wed, Aug 11, 2004 at 10:29:56AM -0700, Mark Knecht wrote:
Paul Winkler wrote:
No to both for me. Fluxbox 0.9.9 works fine with XF86 and no bbkeys.
I've been running 0.9.9 on gentoo for quite a while with no probs.
What's wrong with yours?
While not directed at me, since I run Gentoo also:
1) Have you switched to xorg-x11 yet?
2) do you run bbkeys? fluxbox problem? xorg problem? bbkeys problem?
who knows? :-(
--
Paul Winkler
http://www.slinkp.com
3:34 p.m.
On Wed, Aug 11, 2004 at 10:29:56AM -0700, Mark Knecht wrote:
While not directed at me, since I run Gentoo also:
1) Have you switched to xorg-x11 yet?
2) do you run bbkeys?
If so, I see that Alt-Tabs no longer work reliably. The often just call
up the switcher, but then do not raise the requested window when the
Alt-Tab is released. This did not happen under XFree86.
fluxbox problem? xorg problem? bbkeys problem?)
I run xorg, blackbox, and bbkeys. I've run this same setup for years.
I noticed no change when i switched to xorg.
I'm guessing your problem is fluxbox related.
Find out if fluxbox does any key-grabbing.
--
paul \ /
wisehart >/
<//////$>
|\|\|\
5:52 p.m.
On Wed, 11 Aug 2004 12:28:23 -0400
Paul Winkler <pw_lists(a)slinkp.com> wrote:
I've been running 0.9.9 on gentoo for quite a
while with no probs.
What's wrong with yours?
From an earlier post:
Its slower, suffers from weird redraw
glitches and the slit at the mottom of the screen is missing
borders.
It also seems to lock up (mouse moves, but I can't clock on anthing)
for up to about 5 seconds at a time. That is a SERIOUS PITA.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"It is grossly irresponsible to connect a Windows machine directly to
the net. ;-)" -- John Wiltshire on the Sydney Linux User Group mailing list
1:01 p.m.
Erik de Castro Lopo wrote:
On Tue, 10 Aug 2004 21:34:18 -0400
pirrone <pirrone(a)localnet.com> wrote:
Erik
bbrun-1.4.tar.gz
fluxbox-0.1.14.tar.gz
fluxbox-0.1.14-workspace.patch
fluxconf-0.8.8.tar.gz
MenuMaker-0.15.tar.gz
I've been too busy lately to mess with updates to this stable work
environment, but am curious about the problems you've encountered.
Frank
--
humans may reply by deleting the x from my address
Fluxbox:
It's extremely low in system load, fast, compact, configurable,
efficient, has menus easy to generate and modify, supports simple key
bindings to launch apps or even groups of apps, themes are simple to
create and apply, has no useless crap on screen, power and simplicity of
right-click cascading menus is unbeatable, user can tear off a submenu
then close it when done with a single click, and it does everything I
need a WM to do
I'm really curious about what version you are using.
Version 0.1.14 was really nice but I'm having a bunch of problems with
0.9.9.
Erik
5:48 p.m.
On Wed, 11 Aug 2004 12:48:04 -0400
pirrone <pirrone(a)localnet.com> wrote:
bbrun-1.4.tar.gz
fluxbox-0.1.14.tar.gz
fluxbox-0.1.14-workspace.patch
fluxconf-0.8.8.tar.gz
MenuMaker-0.15.tar.gz
I've been too busy lately to mess with updates to this stable work
environment, but am curious about the problems you've encountered.
Yep, that makes sense. You might want to avoid trying 0.9X until
the problems get resolved.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"I've nothing against OO, I do have something against C++. Its a dogs
dinner. Anyone who's (tried) to read Stroustrups book on C++ like I had
the misfortune of doing knows that the man is very intelligent but has
about as much clarity of thought as Timothy Leary on a bad day."
-- NJR in comp.os.linux.development.apps
5:48 p.m.
> Fluxbox:
>
> It's extremely low in system load, fast, compact, configurable,
> efficient, has menus easy to generate and modify, supports simple key
> bindings to launch apps or even groups of apps, themes are simple to
> create and apply, has no useless crap on screen, power and simplicity of
> right-click cascading menus is unbeatable, user can tear off a submenu
> then close it when done with a single click, and it does everything I
> need a WM to do
Don't forget the middle click drag and droping of a window into another
to tab them together. I love that feature. It makes it completely unecessary
to minimize a window. Oh and the mouse-wheel bind to scroll through
desktops allows me to quickly go back and forth between ardour's editor
and mixer instantly.
--ant
7:07 a.m.
Andrew Dahlin wrote:
first of all, sorry if this topic has been talked
about to death.
At the moment i'm starting to get more and more into recording (both
multi-track and synths, etc). I added on a second monitor and am now
in the process of trying out different window managers (again). I'm
using xfce at the moment, but i might try fluxbox again for a while.
Now for the question: which window manager are you using for audio
work and why? I don't mean for this to start a flame war... notice it
wasn't titled "what's the best window manager?" ;) I just want to
take an informal survey of what everyone is using and see why people
use what they do.
Thanks in advance, --Andrew
i have Icewm installed on one of my linux boxes. very light weighted and
fast, with a taskbar and themes included. some people do not like KDE,
because it's bloated or too heavy with resources, I consider KDE more as
a desktop manager, not a window manager ;)
http://www.icewm.org/
greetings,
kmd
7:32 a.m.
Last Wednesday 11 August 2004 11:51, kmd was like:
I consider KDE more as
a desktop manager, not a window manager ;)
Correct.
Isn't KDE's WM called kwin?
GNOME is also a DE - it uses a variety of WMs according to user preference.
It's good to be clear about this, I know it confuses the hell out of people
coming from monolithic OSs.
cheers
tim hall
7:12 a.m.
Last Tuesday 10 August 2004 22:30, Andrew Dahlin was like:
Now for the question: which window manager are you
using for audio work and
why? I don't mean for this to start a flame war... notice it wasn't titled
"what's the best window manager?" ;) I just want to take an informal survey
of what everyone is using and see why people use what they do.
Openbox3
I use it because I prefer the way it looks to fluxbox and it's totally netWM
compatible (i.e. standards compliant) It's remarkably like running a
lightweight version of GNOME, but totally customisable. All it does is manage
windows, nothing else, which is a Good Thing IMO. I use gkrellm and fbpanel
to provide friendly GUI facilities and lots of keybindings.
cheers
tim hall
8:02 a.m.
On Wed, 11 Aug 2004 11:56:34 +0100
tim hall <tech(a)glastonburymusic.org.uk> wrote:
Last Tuesday 10 August 2004 22:30, Andrew Dahlin was
like:
Oooooo, thats nice!!!
http://icculus.org/openbox/
Written in C (unlike (flux|black)box which is C++).
I'm going to give that a whirl. If it works, its unlikely that
(flux|black)box will have another outing on any of my machines.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"When your hammer is C++, everything begins to look like a thumb."
-- Steve Haflich, in comp.lang.c++
Now for the question: which window manager are
you using for audio work and
why? I don't mean for this to start a flame war... notice it wasn't titled
"what's the best window manager?" ;) I just want to take an informal survey
of what everyone is using and see why people use what they do.
Openbox3
I use it because I prefer the way it looks to fluxbox and it's totally netWM
compatible (i.e. standards compliant) It's remarkably like running a
lightweight version of GNOME, but totally customisable. All it does is manage
windows, nothing else, which is a Good Thing IMO. I use gkrellm and fbpanel
to provide friendly GUI facilities and lots of keybindings. 
8:08 a.m.
* [Wednesday 11 August 2004 13:46] Erik de Castro Lopo:
Written in C (unlike (flux|black)box which is C++).
Why is that an advantage?
I'm going to give that a whirl. If it works, its
unlikely that
(flux|black)box will have another outing on any of my machines.
True, true. You might have a look at PekWM, too.
Greets,
Tom
8:52 a.m.
On Wed, 11 Aug 2004 13:52:39 +0200
Tom <tom(a)abwaerts.be> wrote:
* [Wednesday 11 August 2004 13:46] Erik de Castro
Lopo:
I don't like looking at my own C++ code let alone other
peoples. At least with C, if the code compiles, its rarely
too blecherous for me to look at and usually trivial to fix
even if it isn't. For C++ code the flaws are often in the
design which makes it easier to rewrite from scratch than
it is to fix it.
Written in C (unlike (flux|black)box which is
C++).
Why is that an advantage? True, true. You might have a look at PekWM, too.
Thats C++. No thanks, not while I have one in a C.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"The RIAA is obsessed to the point of comedy with the frustration
of having its rules broken, without considering whether such rules
might be standing in the way of increased revenues. Indeed,
Napster and Gnutella may turn out to be the two best music-marketing
gimmicks yet devised, if only the RIAA would take its head out of
its ass long enough to realise it."
-- Thomas C Greene on www.theregister.co.uk
12:48 p.m.
On Wed, Aug 11, 2004 at 01:52:39PM +0200, Tom wrote:
* [Wednesday 11 August 2004 13:46] Erik de Castro
Lopo:
yay, it has grouping! (like the tabbed windows in fluxbox.)
--
Paul Winkler
http://www.slinkp.com
Written in C (unlike (flux|black)box which is
C++).
Why is that an advantage?
I'm going to give that a whirl. If it works,
its unlikely that
(flux|black)box will have another outing on any of my machines.
True, true. You might have a look at PekWM, too. 
1:10 p.m.
On Wed, 11 Aug 2004 12:33:21 -0400, Paul Winkler wrote
On Wed, Aug 11, 2004 at 01:52:39PM +0200, Tom wrote:
Also check out ion for something different (sorry if it's already been
mentioned) http://modeemi.cs.tut.fi/~tuomov/ion/ I tried this a few weeks ago,
and it's pretty cool, but it hasn't stuck for me.
I'm a diehard windowmaker user, used it for years and use it at work as well
as home. I did use fluxbox for a few months, might try it out again.
dave
* [Wednesday 11 August 2004 13:46] Erik de Castro
Lopo:
yay, it has grouping! (like the tabbed windows in fluxbox.) Written in C (unlike (flux|black)box which is
C++).
Why is that an advantage?
I'm going to give that a whirl. If it works,
its unlikely that
(flux|black)box will have another outing on any of my machines.
True, true. You might have a look at PekWM, too.
3:54 p.m.
Paul Winkler wrote:
yay, it has grouping! (like the tabbed windows in fluxbox.)
Along these lines I just ran across multu-aterm. Open one instance and
then add more aterms in the background. I like it since I often have 5
or 10 terminals open and this way I only have a single instance on the
taskbar to deal with. Check it out if you don't use it already.
4:43 p.m.
On Wed, Aug 11, 2004 at 12:38:24PM -0700, Mark Knecht wrote:
Paul Winkler wrote:
Yeah, that's neat but I prefer to handle it at the window-manager
level rather than having some apps with "multi" support and some not.
So I can do the same thing with any terminal :-)
(and yes, it only puts one item on the taskbar.)
--
Paul Winkler
http://www.slinkp.com
yay, it has grouping! (like the tabbed windows in fluxbox.)
Along these lines I just ran across multu-aterm. Open one instance and
then add more aterms in the background. I like it since I often have 5
or 10 terminals open and this way I only have a single instance on the
taskbar to deal with. Check it out if you don't use it already.
7:31 p.m.
Paul Winkler wrote:
On Wed, Aug 11, 2004 at 12:38:24PM -0700, Mark Knecht
wrote:
Sure. I use flux but don't use tabs as they take up too much room. This
is nice (for me) jsut because I don't have to associate the different
terminals in a group.
To each his own. I was thinking that those who do not use flux might
find this useful. If not I apologize for wasting the bandwidth.
Cheers,
Mark
Paul Winkler wrote:
Yeah, that's neat but I prefer to handle it at the window-manager
level rather than having some apps with "multi" support and some not.
So I can do the same thing with any terminal :-)
(and yes, it only puts one item on the taskbar.)
yay, it has grouping! (like the tabbed windows in
fluxbox.)
Along these lines I just ran across multu-aterm. Open one instance and
then add more aterms in the background. I like it since I often have 5
or 10 terminals open and this way I only have a single instance on the
taskbar to deal with. Check it out if you don't use it already.
7:55 p.m.
On Wed, 11 Aug 2004 16:14:14 -0700
Mark Knecht <mknecht(a)controlnet.com> wrote:
Sure. I use flux but don't use tabs as they take up too much room.
This is nice (for me) jsut because I don't have to associate the
different terminals in a group.
Hmm, it would be cool, if the tabs could be displayed in the title bar
whenever there's enough room [the title of the application not being too
long]. This would save screen estate in many cases..
Flo
--
Palimm Palimm!
http://affenbande.org/~tapas/
8:43 p.m.
On Thu, 12 Aug 2004 01:50:22 +0200
Florian Schmidt <mista.tapas(a)gmx.net> wrote:
Hmm, it would be cool, if the tabs could be displayed
in the title bar
whenever there's enough room [the title of the application not being
too long]. This would save screen estate in many cases..
On Wed, 11 Aug 2004 20:03:38 -0400
Paul Winkler <pw_lists(a)slinkp.com> wrote:
fluxbox hasn't used actual tabs in a while... it
takes up no extra
room now.
yay! cool :) it's been a while since i tried the tabs in fluxbox
flo
--
Palimm Palimm!
http://affenbande.org/~tapas/
8:19 p.m.
On Wed, Aug 11, 2004 at 04:14:14PM -0700, Mark Knecht wrote:
fluxbox hasn't used actual tabs in a while... it takes up no extra room
now.
Yeah,
that's neat but I prefer to handle it at the window-manager
level rather than having some apps with "multi" support and some not.
So I can do the same thing with any terminal :-)
(and yes, it only puts one item on the taskbar.)
Sure. I use flux but don't use tabs as they take up too much room. This
is nice (for me) jsut because I don't have to associate the different
terminals in a group.
sure, but that's one line in ~/.fluxbox/groups .
and every now and then it's really nice to be able to group
windows from arbitrary applications. e.g. group a GUI app with a
terminal on which it's spewing stderr.
To each his own. I was thinking that those who do not
use flux might
find this useful. If not I apologize for wasting the bandwidth.
no apology needed! aterm is cool and not everybody will like fluxbox.
--
Paul Winkler
http://www.slinkp.com
7:09 p.m.
Last Wednesday 11 August 2004 12:52, Tom was like:
I've heard good things about Pek too, but I don't think there's a Debian
package for it. I'm happy where I am anyway.
cheers
tim hall
* [Wednesday 11 August 2004 13:46] Erik de Castro
Lopo:
C has less bloat ;-]
Written in C (unlike (flux|black)box which is
C++).
Why is that an advantage? I'm going
to give that a whirl. If it works, its unlikely that
(flux|black)box will have another outing on any of my machines.
True, true. You might have a look at PekWM, too.
9:54 a.m.
>Last Tuesday 10 August 2004 22:30, Andrew Dahlin
was like:
>
>>Now for the question: which window manager are you using for audio work and
>>why? I don't mean for this to start a flame war... notice it wasn't titled
>>"what's the best window manager?" ;) I just want to take an informal
survey
>>of what everyone is using and see why people use what they do.
fluxbox for me. (0.9.9 Erik - I have some problems too, but only since
moving to xorg-x11...)
I must say that after a couple of years with fluxbox I've been very
happy with how well it works. It's always been stable for me, and it
loads so few things that top is relatively clean.
That said, I seem to be developing a frustration with Linux window
managers and menu management. It seems that for fluxbox I have to manage
my menu using vi. It seems for Mozilla I have to manage my bookmarks
with their editor. I recently started doing some more work in Windows
(since I cannot get wireless working under Linux yet) and had been doing
a bunch of browsing and bookmarking. It's so nice in IE being able to
rearrange my bookmarks by just dragging them around. Same for the start
menu. Just drag apps to the area you want them in the menu.
Do any of the light weight Linux window managers support this?
Thanks,
Mark
10:29 a.m.
On Wed, 11 Aug 2004 06:38:46 -0700
Mark Knecht <mknecht(a)controlnet.com> wrote:
fluxbox for me. (0.9.9 Erik - I have some problems
too, but only since
moving to xorg-x11...)
( snip )
... I seem to be developing a frustration with Linux window
managers and menu management. It seems that for fluxbox I have to manage
my menu using vi.
I'm a happy Fluxbox user, running 0.1.14 on some machines and 0.9.8 on
my studio machine. Since I use hardly any of the features, I haven't
noticed many differences.
Regarding the configuration of the Fluxbox menu, check out FluxConf
at http://devaux.fabien.free.fr/flux/ Depending on your comfort level
with vi and the menu file format, this may or may not be better, but
it's a GUI alternative.
--
======================================================================
Joe Hartley - UNIX/network Consultant - jh(a)brainiac.com
Without deviation from the norm, "progress" is not possible. - FZappa
10:31 a.m.
Mark Knecht wrote:
fluxbox for me. (0.9.9 Erik - I have some problems
too, but only since
moving to xorg-x11...)
I tried fluxbox out for the first time last night and I think I am sold
on it. It's so flipping fast (and I had been using Blackbox, which I
thought flipping fast).
I must say that after a couple of years with fluxbox
I've been very
happy with how well it works. It's always been stable for me, and it
loads so few things that top is relatively clean.
That said, I seem to be developing a frustration with Linux window
managers and menu management. It seems that for fluxbox I have to manage
my menu using vi. It seems for Mozilla I have to manage my bookmarks
with their editor. I recently started doing some more work in Windows
(since I cannot get wireless working under Linux yet) and had been doing
a bunch of browsing and bookmarking. It's so nice in IE being able to
rearrange my bookmarks by just dragging them around. Same for the start
menu. Just drag apps to the area you want them in the menu.
Do any of the light weight Linux window managers support this?
I think the reason the light weights are light weight is because they
are mininmalistic and don't support a lot of these kinds of advanced
features. Gnome & KDE, of course, support this kind of stuff, but they
are not light weight by any means (and are more than just window managers).
--
Rule of Feline Frustration:
When your cat has fallen asleep on your lap and looks utterly
content and adorable, you will suddenly have to go to the
bathroom.
7:16 p.m.
Last Wednesday 11 August 2004 15:18, Brett W. McCoy was like:
I think the reason the light weights are light weight
is because they
are mininmalistic and don't support a lot of these kinds of advanced
features. Gnome & KDE, of course, support this kind of stuff, but they
are not light weight by any means (and are more than just window managers).
The way to do it, I guess would be to get a separate app to deal with the
menus. I'm open to suggestions here Debian's 'menu' package annoys the
fsck
out of me and openbox3's handling of the resultant menus is far from graceful
- My one complaint with it, btw.
cheers
tim hall
3 p.m.
>>Last Tuesday 10 August 2004 22:30, Andrew
Dahlin was like:
>>
>>>Now for the question: which window manager are you using for audio work
>>> and
>>>why?
I'm a fluxbox user as well, and I use ROX as my destop manager/filer. It's
a nice combo. I guess I'm from the camp that doesn't care for the
bloat/resource gluttony of KDE or Gnome.
"Both Rob and I see sound as shapes.
I only have to do this (makes a fist)
and he knows what sound I mean". - Autechre
:::::::::::::::::::::::::::::::::::::::::::
Ernie Dulanowsky CCNA CWLSS
www.pulsewidth.ca
> test_tones on www.cjtr.ca <<
7:35 a.m.
On Tuesday 10 August 2004 23.30, Andrew Dahlin wrote:
first of all, sorry if this topic has been talked
about to death.
At the moment i'm starting to get more and more into recording (both
multi-track and synths, etc). I added on a second monitor and am now in the
process of trying out different window managers (again). I'm using xfce at
the moment, but i might try fluxbox again for a while.
Now for the question: which window manager are you using for audio work and
why? I don't mean for this to start a flame war... notice it wasn't titled
"what's the best window manager?" ;) I just want to take an informal survey
of what everyone is using and see why people use what they do.
Strictly KDE here, I like the way it works... I keep my machine up running
24-7, restarting into different environments is not an option for me.
It works "good enough" with my way of working, realtime composition, Jack set
to 512x2. xruns do occur but seldom enough that I have never noticed it
during recording.
/Robert
--
http://spamatica.se/music/
6:38 p.m.
On Tue, 2004-08-10 at 14:30, Andrew Dahlin wrote:
Now for the question: which window manager are you
using for audio work and why? I don't mean for this to start a flame war... notice it
wasn't titled "what's the best window manager?" ;) I just want to take
an informal survey of what everyone is using and see why people use what they do.
I assume you're worried about the WM overtaxing the system therefore
causing xruns.
It should not matter which WM you're using if you are running a proper
kernel. 2.4 plus some patches works pretty well; 2.6 with Ingo's
voluntary preempt is actually even better but it's not yet 100%
stabilized.
With one of those kernels and with JACK in real-time mode, you could
abuse the system pretty badly and it won't skip a bit.
If you're using one of the "heavy" WMs, just don't run too many silly
applets at the same time.
I'm currently using Gnome in the default configuration that's shipped
with Fedora 2, with font antialiasing and all, and it works pretty well
on a 2.6 kernel + voluntary preempt. No xruns that can be traced back to
the WM (actually, no xruns at all under normal circumstances).
--
Florin Andrei
http://florin.myip.org/
12 Aug
12 Aug
4:22 a.m.
On Wed, Aug 11, 2004 at 03:22:39PM -0700, Florin Andrei wrote:
On Tue, 2004-08-10 at 14:30, Andrew Dahlin wrote:
I assume you're worried about the WM overtaxing
the system therefore
causing xruns.
It should not matter which WM you're using if you are running a proper
kernel.
I've been thinking that: I'm glad somebody else said it :-)
The windows manager and desktop is only user-land code and if jack and
the sound drivers are all running at higher priority all that should
happen while you've got audio apps running is either(a) no difference or
(b) the desktop becomes a little less responsive, depending on the
overall CPU and disk workload.
For what it's worth I'm running standard Gnome on kernel 2.6.6. I don't
do any heavyweight audio though. arecord records 16/44.1 stereo fine.
2.6 with Ingo's voluntary preempt is actually even
better but it's not
yet 100% stabilized. With one of those kernels and with JACK in
real-time mode, you could abuse the system pretty badly and it won't
skip a bit.
That's what I'm looking forward to...
--
Anahata
anahata(a)treewind.co.uk Tel: 01638 720444
http://www.treewind.co.uk Mob: 07976 263827
7:06 a.m.
Last Thursday 12 August 2004 08:58, Anahata was like:
On Wed, Aug 11, 2004 at 03:22:39PM -0700, Florin
Andrei wrote:
Valid point, the issue is that the desktop can become a _lot_ less responsive
on low-resource systems, also, if you're maxing out your CPU usage you can
get nasty stuttering. KDE does take more juice. I don't think there's much to
choose between the rest. My choice of WM is really based on ergonomics.
configurability and looks.
cheers
tim hall
On Tue, 2004-08-10 at 14:30, Andrew Dahlin wrote:
I assume you're worried about the WM overtaxing the system therefore
causing xruns.
It should not matter which WM you're using if you are running a proper
kernel.
I've been thinking that: I'm glad somebody else said it :-)
The windows manager and desktop is only user-land code and if jack and
the sound drivers are all running at higher priority all that should
happen while you've got audio apps running is either(a) no difference or
(b) the desktop becomes a little less responsive, depending on the
overall CPU and disk workload. 
11:26 a.m.
On Thu, 2004-08-12 at 00:58, Anahata wrote:
On Wed, Aug 11, 2004 at 03:22:39PM -0700, Florin
Andrei wrote:
Does anyone know if a package for this kernel has been done for Mandrake
10.0? I'm not at the pseudo Jedi Warrior level for compiling kernels
just yet! :) Although, I HAVE become a master at compiling Wine and fst
/ jack_fst! :P
R~
On Tue, 2004-08-10 at 14:30, Andrew Dahlin wrote:
I assume you're worried about the WM
overtaxing the system therefore
causing xruns.
It should not matter which WM you're using if you are running a proper
kernel.
I've been thinking that: I'm glad somebody else said it :-)
The windows manager and desktop is only user-land code and if jack and
the sound drivers are all running at higher priority all that should
happen while you've got audio apps running is either(a) no difference or
(b) the desktop becomes a little less responsive, depending on the
overall CPU and disk workload.
For what it's worth I'm running standard Gnome on kernel 2.6.6. I don't
do any heavyweight audio though. arecord records 16/44.1 stereo fine.
> 2.6 with Ingo's voluntary preempt is actually even better but it's not
> yet 100% stabilized. With one of those kernels and with JACK in
> real-time mode, you could abuse the system pretty badly and it won't
> skip a bit. That's what I'm looking forward to...
11:45 a.m.
Russell Hanaghan <hanaghan(a)starband.net> writes:
Does anyone know if a package for this kernel has been
done for Mandrake
10.0? I'm not at the pseudo Jedi Warrior level for compiling kernels
just yet! :) Although, I HAVE become a master at compiling Wine and fst
/ jack_fst! :P
Actually, compiling your own kernel is probably easier than that. :-)
--
joq
12:21 p.m.
On Thu, 2004-08-12 at 08:30, Jack O'Quin wrote:
Russell Hanaghan <hanaghan(a)starband.net> writes:
Good god man! I've lost most of my hair and my wife left and the dog
died while I got jack_fst to finally work!! :)
And now, darn it...you got me thinking I should try! Are there any
advantages to compiling and leaving out the bunches of crap I don't ever
use that are built in the kernel? Like resources, memory, speed savings
of any sort?
R~
Does anyone know if a package for this kernel has
been done for Mandrake
10.0? I'm not at the pseudo Jedi Warrior level for compiling kernels
just yet! :) Although, I HAVE become a master at compiling Wine and fst
/ jack_fst! :P
Actually, compiling your own kernel is probably easier than that. :-) 
2:10 p.m.
On Thu, 2004-08-12 at 12:05, Russell Hanaghan wrote:
And now, darn it...you got me thinking I should try!
Are there any
advantages to compiling and leaving out the bunches of crap I don't ever
use that are built in the kernel? Like resources, memory, speed savings
of any sort?
No, absolutely not. 99.99% of Linux users should use their vendor's
kernel. It has undergone a LOT more stability testing than whatever you
would compile off of kernel.org.
You should only use a kernel.org kernel if you need some feature or
driver that your vendor's kernel does not provide, or, obviously, if you
are hacking the kernel. If you go this route you should attempt to
build a binary package for your distribution, then install that. This
way you can post the packages somewhere, and other people who need a
custom kernel for their own purposes can just download your packages vs.
repeating all that work.
Lee
3:57 p.m.
Lee Revell wrote:
On Thu, 2004-08-12 at 12:05, Russell Hanaghan wrote:
I think he was asking a different Q: he was asking about advantages
of using compiled as opposed to pre-built kernel, you are comparing
distro kernel to vanilla kernel.
IMO: in general I think it makes sense to compile kernel because you
get exactly what you need plus you can experiment with different setting
to see if you get better performance etc. I tend to use the kernel
source package for my distro (mostly because it can build a package that
can be installed, which takes care of having LILO option to boot former
kernel etc.)
erik
And now, darn it...you got me thinking I should
try! Are there any
advantages to compiling and leaving out the bunches of crap I don't ever
use that are built in the kernel? Like resources, memory, speed savings
of any sort?
No, absolutely not. 99.99% of Linux users should use their vendor's
kernel. It has undergone a LOT more stability testing than whatever you
would compile off of kernel.org.
You should only use a kernel.org kernel if you need some feature or
driver that your vendor's kernel does not provide, or, obviously, if you
are hacking the kernel. If you go this route you should attempt to
build a binary package for your distribution, then install that. This
way you can post the packages somewhere, and other people who need a
custom kernel for their own purposes can just download your packages vs.
repeating all that work.
4:52 p.m.
On Thu, 2004-08-12 at 15:41, Erik Steffl wrote:
Lee Revell wrote:
Yes, if you only have one or two machines to worry about, then by all
means compile your own kernel. The performance increase and memory
savings will still probably not be enough to make it worthwhile, but you
will at least learn a lot.
Once you are dealing with more than a couple of machines, then tweaking
your kernel *really* becomes a waste of time. Red Hat has spent a *lot*
more time tweaking their kernel than you ever could, and they are also a
lot better at it. Also it's SO much easier to just pop a CD in a
machine and in 30 minutes have a system that will just work, forever,
versus spending half a day customizing the kernel to your hardware, only
to get no performance gain and a few KB memory savings, and have it
crash in a month due to some bug that RedHat already fixed.
So, I am speaking more from my sysadmin background. Most Linux audio
users are more interested in intensively tweaking one box rather than
having to keep 100 of them just working. The requirements are very
different.
A good compromise is compiling your own kernel from your vendor's
sources. Once you get it working, please post .rpms or .debs somewhere
for others to use, especially if you applied some patch to get a feature
that's not in the stock kernel. This is an excellent way for non-coders
to contribute a lot to the open source process.
Lee
99.99% of Linux users should use their
vendor's
kernel. It has undergone a LOT more stability testing than whatever you
would compile off of kernel.org.
You should only use a kernel.org kernel if you need some feature or
driver that your vendor's kernel does not provide, or, obviously, if you
are hacking the kernel. If you go this route you should attempt to
build a binary package for your distribution, then install that. This
way you can post the packages somewhere, and other people who need a
custom kernel for their own purposes can just download your packages vs.
repeating all that work.
I think he was asking a different Q: he was asking about advantages
of using compiled as opposed to pre-built kernel, you are comparing
distro kernel to vanilla kernel.
IMO: in general I think it makes sense to compile kernel because you
get exactly what you need plus you can experiment with different setting
to see if you get better performance etc. I tend to use the kernel
source package for my distro (mostly because it can build a package that
can be installed, which takes care of having LILO option to boot former
kernel etc.)
7:02 p.m.
Lee Revell wrote:
On Thu, 2004-08-12 at 15:41, Erik Steffl wrote:
that's what the question was
Lee Revell wrote:
Yes, if you only have one or two machines to worry about, then by all 99.99% of Linux users should use their
vendor's
kernel. It has undergone a LOT more stability testing than whatever you
would compile off of kernel.org.
You should only use a kernel.org kernel if you need some feature or
driver that your vendor's kernel does not provide, or, obviously, if you
are hacking the kernel. If you go this route you should attempt to
build a binary package for your distribution, then install that. This
way you can post the packages somewhere, and other people who need a
custom kernel for their own purposes can just download your packages vs.
repeating all that work.
I think he was asking a different Q: he was asking about advantages
of using compiled as opposed to pre-built kernel, you are comparing
distro kernel to vanilla kernel.
IMO: in general I think it makes sense to compile kernel because you
get exactly what you need plus you can experiment with different setting
to see if you get better performance etc. I tend to use the kernel
source package for my distro (mostly because it can build a package that
can be installed, which takes care of having LILO option to boot former
kernel etc.) means compile your own kernel. The performance
increase and memory
savings will still probably not be enough to make it worthwhile, but you
will at least learn a lot.
Once you are dealing with more than a couple of machines, then tweaking
your kernel *really* becomes a waste of time. Red Hat has spent a *lot*
more time tweaking their kernel than you ever could, and they are also a
lot better at it. Also it's SO much easier to just pop a CD in a
machine and in 30 minutes have a system that will just work, forever,
there are different ways to handle different situations depending on
what you want, I guess if you have enough machines you might want to
create your image and just install that instead of going through
installation on all machines... (i.e. customizing the kernel is same
whether it's one machine or many identical machines)
versus spending half a day customizing the kernel to
your hardware, only
to get no performance gain and a few KB memory savings, and have it
crash in a month due to some bug that RedHat already fixed.
???
if you compile your own kernel that does not mean you are throwing
away bugs that redhat fixed. don't mix the two issues and then use
argument against one to argue against another.
So, I am speaking more from my sysadmin background.
Most Linux audio
users are more interested in intensively tweaking one box rather than
having to keep 100 of them just working. The requirements are very
different.
A good compromise is compiling your own kernel from your vendor's
sources. Once you get it working, please post .rpms or .debs somewhere
for others to use, especially if you applied some patch to get a feature
that's not in the stock kernel. This is an excellent way for non-coders
to contribute a lot to the open source process.
did you read my email? if you get debian source it creates configured
package for you. there's no point in making it available because the
whole point is to customize the kernel to your HW (which anybody can do,
just as easily)
Building kernels for somebody else is pretty hard and is best done if
you want to make it least hobby out of it (e.g. agnula or some almost
distro like that might want to do tat). The personal kernels are just
that - kernels customized to whatever you need. What helps is posting
what config should be used and which patches were useful (for particular
hw or particular purpose) but sharing the kernels doesn't seem
reasonable - how many people have _exactly_ same hw? How many people
that can build kernels for themselves can build generaly usable kernels?
erik
7:22 p.m.
On Thu, 2004-08-12 at 18:46, Erik Steffl wrote:
My main point was that removing things you don't need from the kernel
will not speed up your system. You don't need to remove anything to
customizing the kernel to your hardware, unless you just want it to
build faster and save a negligible amount of memory. All that needs to
be done to customize a kernel to a given hardware configuration is to
add the features that are missing from the stock kernel. This has the
added benefit that most people can install the .deb
and it will work.
Lee
So, I am
speaking more from my sysadmin background. Most Linux audio
users are more interested in intensively tweaking one box rather than
having to keep 100 of them just working. The requirements are very
different.
A good compromise is compiling your own kernel from your vendor's
sources. Once you get it working, please post .rpms or .debs somewhere
for others to use, especially if you applied some patch to get a feature
that's not in the stock kernel. This is an excellent way for non-coders
to contribute a lot to the open source process.
did you read my email? if you get debian source it creates configured
package for you. there's no point in making it available because the
whole point is to customize the kernel to your HW (which anybody can do,
just as easily)
7:50 p.m.
Lee Revell wrote:
On Thu, 2004-08-12 at 18:46, Erik Steffl wrote:
My main point was that removing things you don't need from the kernel
will not speed up your system. You don't need to remove anything to
customizing the kernel to your hardware, unless you just want it to
build faster and save a negligible amount of memory. All that needs to
be done to customize a kernel to a given hardware configuration is to
add the features that are missing from the stock kernel. This has the
added benefit that most people can install the .deb
and it will work.
who's talking about removing? there's plenty of stuff to customize,
picking the right drivers is part of it but e.g. you might want ext3
support not as module since you want to boot off of the ext3 disk, add
support for chipset xxx (which is not default because it can cause
problems if the chipset is not present) so that your machine does not
freeze, you pick either acpi or apm or neither, you want the SATA disk
to appear as SCSI disk (because when it appears as IDE disk your
computer freezes) etc.
not saying everybody should do it but if you know what HW you have
(i.e. willing to read lables, output of lspci etc.) it's fairly easy to
do, in some cases it might be a significant performance difference (e.g.
if you are able to tweak it so that you can do DMA for HDs which
might not be possible with distro built kernel)
erik
So, I am
speaking more from my sysadmin background. Most Linux audio
users are more interested in intensively tweaking one box rather than
having to keep 100 of them just working. The requirements are very
different.
A good compromise is compiling your own kernel from your vendor's
sources. Once you get it working, please post .rpms or .debs somewhere
for others to use, especially if you applied some patch to get a feature
that's not in the stock kernel. This is an excellent way for non-coders
to contribute a lot to the open source process.
did you read my email? if you get debian source it creates configured
package for you. there's no point in making it available because the
whole point is to customize the kernel to your HW (which anybody can do,
just as easily)
9:41 p.m.
On Thu, 2004-08-12 at 16:07, Lee Revell wrote:
On Thu, 2004-08-12 at 18:46, Erik Steffl wrote:
My main point was that removing things you don't need from the kernel
will not speed up your system. You don't need to remove anything to
customizing the kernel to your hardware, unless you just want it to
build faster and save a negligible amount of memory. All that needs to
be done to customize a kernel to a given hardware configuration is to
add the features that are missing from the stock kernel. This has the
added benefit that most people can install the .deb
and it will work.
Lee
I appreciate both points guys...
I think the main one to take from this is a classic;
"If it ain't broke, Don't fix it!" :)
I find myself digging into a perfectly tight operating system with all
the array of perfectly functional audio apps I use....and hours and
hours later sit there pissed off and frustrated because I didn't achieve
any noteworthy results from it all...and I only like to do so much
_learning_ at a time! :)
R~
So, I am
speaking more from my sysadmin background. Most Linux audio
users are more interested in intensively tweaking one box rather than
having to keep 100 of them just working. The requirements are very
different.
A good compromise is compiling your own kernel from your vendor's
sources. Once you get it working, please post .rpms or .debs somewhere
for others to use, especially if you applied some patch to get a feature
that's not in the stock kernel. This is an excellent way for non-coders
to contribute a lot to the open source process.
did you read my email? if you get debian source it creates configured
package for you. there's no point in making it available because the
whole point is to customize the kernel to your HW (which anybody can do,
just as easily)
9:50 p.m.
On Thu, 2004-08-12 at 21:25, Russell Hanaghan wrote:
I appreciate both points guys...
I think the main one to take from this is a classic;
"If it ain't broke, Don't fix it!" :)
I find myself digging into a perfectly tight operating system with all
the array of perfectly functional audio apps I use....and hours and
hours later sit there pissed off and frustrated because I didn't achieve
any noteworthy results from it all...and I only like to do so much
_learning_ at a time! :)
One other tip I found useful is, if you do have to compile your own
kernel from a kernel.org kernel, use the .config from your vendor's
kernel source package. That way you get a kernel that is close as
possible to the vendor kernel, and you minimize the chance of breaking
anything that currently works.
Lee
13 Aug
13 Aug
3:43 p.m.
honestly, compiling a kernel is trivial once you build one successfully. the first time
will take a few hours to get it right (tops), but by the time you're done, you know
exactly what you're doing. i can configure a kernel from scratch in about 20
minutes... and i'm not a hacker or anything... i just know what i need. i'm not
saying everyone should build their own kernel, but if you install your distro's
sources (with their .config), it's fairly risk free. just back up your old kernel.
[OT: if you run lilo, don't forget to run lilo after copying over the new kernel. TONS
of people don't realize this their first time]
--Andrew
On Thu, 12 Aug 2004 21:35:36 -0400
Lee Revell <rlrevell(a)joe-job.com> wrote:
On Thu, 2004-08-12 at 21:25, Russell Hanaghan wrote:
I appreciate both points guys...
I think the main one to take from this is a classic;
"If it ain't broke, Don't fix it!" :)
I find myself digging into a perfectly tight operating system with all
the array of perfectly functional audio apps I use....and hours and
hours later sit there pissed off and frustrated because I didn't achieve
any noteworthy results from it all...and I only like to do so much
_learning_ at a time! :)
One other tip I found useful is, if you do have to compile your own
kernel from a kernel.org kernel, use the .config from your vendor's
kernel source package. That way you get a kernel that is close as
possible to the vendor kernel, and you minimize the chance of breaking
anything that currently works.
Lee
12 Aug
12 Aug
9:15 p.m.
On Thu, 2004-08-12 at 10:55, Lee Revell wrote:
On Thu, 2004-08-12 at 12:05, Russell Hanaghan wrote:
Whew! For a moment I thought I was going to lose the horse and my truck
wus gonna break down on a train track! {Hmmm...aint that a song??}
Appreciate the heads up. I sometimes find myself spending a bunch of
hours on nothing worth doing in the pursuit of "the fast machine!"
R~
And now, darn it...you got me thinking I should
try! Are there any
advantages to compiling and leaving out the bunches of crap I don't ever
use that are built in the kernel? Like resources, memory, speed savings
of any sort?
No, absolutely not. 99.99% of Linux users should use their vendor's
kernel. It has undergone a LOT more stability testing than whatever you
would compile off of kernel.org.
You should only use a kernel.org kernel if you need some feature or
driver that your vendor's kernel does not provide, or, obviously, if you
are hacking the kernel. If you go this route you should attempt to
build a binary package for your distribution, then install that. This
way you can post the packages somewhere, and other people who need a
custom kernel for their own purposes can just download your packages vs.
repeating all that work.
Lee
4:44 p.m.
Russell Hanaghan <hanaghan(a)starband.net> writes:
On Thu, 2004-08-12 at 08:30, Jack O'Quin wrote:
My condolences. ;-)
I didn't say it was trivial. If wine and jack_fst is an 8 or 9 (on a
difficulty scale from one to 10), building your own kernel is probably
only a 6 or 7.
Why? Despite the inherent complexity, kernel builds are a
well-trodden path, with years of development support and mature
configuration interfaces, makefiles, HOWTOs, README, etc.
Because jack_fst is so new, it will likely require a bit of fiddling
for a while yet. Any time you work with Windows binaries, things get
tricky. They're not made to work with Linux. The kernel sources are.
Russell Hanaghan <hanaghan(a)starband.net>
writes:
Good god man! I've lost most of my hair and my wife left and the dog
died while I got jack_fst to finally work!! :) Does anyone know if a package for this kernel has
been done for Mandrake
10.0? I'm not at the pseudo Jedi Warrior level for compiling kernels
just yet! :) Although, I HAVE become a master at compiling Wine and fst
/ jack_fst! :P
Actually, compiling your own kernel is probably easier than that. :-) And now, darn it...you got me thinking I should try!
Are there any
advantages to compiling and leaving out the bunches of crap I don't ever
use that are built in the kernel? Like resources, memory, speed savings
of any sort?
There are minor advantages. None are really compelling unless you
need some feature (like lower latency) not available with your
distribution's version. Most distributions keep up to date fairly
well. So if you're willing to wait a while, they will likely provide
what you need.
But, curiosity is a good enough reason. It just costs time, no money.
:-)
I my view, the vanilla 2.6.7 kernels perform well enough already for
many audio applications. If you need something better, by all means
try some of the recent patches. Lee, Flo, Nando, Takashi and others
have done valuable work providing a test bed for kernel developers
like Ingo and Andrew to do their work. It's beautiful to see.
--
joq
5:26 p.m.
On Thu, 2004-08-12 at 16:29, Jack O'Quin wrote:
I didn't say it was trivial. If wine and jack_fst
is an 8 or 9 (on a
difficulty scale from one to 10), building your own kernel is probably
only a 6 or 7.
So building XFree86 (or Xorg ) would have to be an 11.
Editing makefiles by hand? `make World'? What the hell is ths crap?
They should get with the program, everyone else can ./configure && make
&& make install, so should they.
Lee
9:34 p.m.
On Thu, 2004-08-12 at 13:29, Jack O'Quin wrote:
Russell Hanaghan <hanaghan(a)starband.net> writes:
Thanks for the feedback. TIme is so precious lately...if only I had 36
hour days I'd be in great shape.
I _will_ get to this kernel thing before long just so I can say "I
dunnit". But for now...I'll stick with whats working.
R~
On Thu, 2004-08-12 at 08:30, Jack O'Quin
wrote:
My condolences. ;-)
I didn't say it was trivial. If wine and jack_fst is an 8 or 9 (on a
difficulty scale from one to 10), building your own kernel is probably
only a 6 or 7.
Why? Despite the inherent complexity, kernel builds are a
well-trodden path, with years of development support and mature
configuration interfaces, makefiles, HOWTOs, README, etc.
Because jack_fst is so new, it will likely require a bit of fiddling
for a while yet. Any time you work with Windows binaries, things get
tricky. They're not made to work with Linux. The kernel sources are.
Russell Hanaghan <hanaghan(a)starband.net>
writes:
Good god man! I've lost most of my hair and my wife left and the dog
died while I got jack_fst to finally work!! :) Does anyone know if a package for this kernel has
been done for Mandrake
10.0? I'm not at the pseudo Jedi Warrior level for compiling kernels
just yet! :) Although, I HAVE become a master at compiling Wine and fst
/ jack_fst! :P
Actually, compiling your own kernel is probably easier than that. :-) And now, darn it...you got me thinking I should
try! Are there any
advantages to compiling and leaving out the bunches of crap I don't ever
use that are built in the kernel? Like resources, memory, speed savings
of any sort?
There are minor advantages. None are really compelling unless you
need some feature (like lower latency) not available with your
distribution's version. Most distributions keep up to date fairly
well. So if you're willing to wait a while, they will likely provide
what you need.
But, curiosity is a good enough reason. It just costs time, no money.
:-)
I my view, the vanilla 2.6.7 kernels perform well enough already for
many audio applications. If you need something better, by all means
try some of the recent patches. Lee, Flo, Nando, Takashi and others
have done valuable work providing a test bed for kernel developers
like Ingo and Andrew to do their work. It's beautiful to see.
11:59 a.m.
New subject: Voluntary scheduler for mdk, was Re: [linux-audio-user] what window manager are you using?
torsdagen den 12 augusti 2004 17.11 skrev Russell Hanaghan:
On Thu, 2004-08-12 at 00:58, Anahata wrote:
None that I know of.
Asking this guy might be an idea, perhaps he can include it:
http://mandrake.contactel.cz/people/svetljo/mandrake/kernel/
On Wed, Aug 11, 2004 at 03:22:39PM -0700, Florin
Andrei wrote:
Does anyone know if a package for this kernel has been done for Mandrake
10.0? On Tue, 2004-08-10 at 14:30, Andrew Dahlin wrote:
I assume you're worried about the WM overtaxing the system therefore
causing xruns.
It should not matter which WM you're using if you are running a proper
kernel.
I've been thinking that: I'm glad somebody else said it :-)
The windows manager and desktop is only user-land code and if jack and
the sound drivers are all running at higher priority all that should
happen while you've got audio apps running is either(a) no difference or
(b) the desktop becomes a little less responsive, depending on the
overall CPU and disk workload.
For what it's worth I'm running standard Gnome on kernel 2.6.6. I don't
do any heavyweight audio though. arecord records 16/44.1 stereo fine.
> 2.6 with Ingo's voluntary preempt is actually even better but it's not
> yet 100% stabilized. With one of those kernels and with JACK in
> real-time mode, you could abuse the system pretty badly and it won't
> skip a bit. I'm not at the pseudo Jedi Warrior level for
compiling kernels
just yet! :) Although, I HAVE become a master at compiling Wine and fst
/ jack_fst! :P
;-)
/Robert
R~
> That's what I'm looking forward to...
--
http://spamatica.se/music/
12:18 p.m.
New subject: Voluntary scheduler for mdk, was Re: [linux-audio-user] what window manager are you using?
On Thu, 2004-08-12 at 08:43, Robert Jonsson wrote:
torsdagen den 12 augusti 2004 17.11 skrev Russell
Hanaghan:
Yup...I suspect so. Thac has stopped compiling his own kernels and is
linked to these. So they would be what I'm using right now. 2.6.7-1-35
seems ok and has alsa 1.06 built in but is still kinda "xrunny" :) I
don;t know how these different types of scheduling etc, stack up but
what I'm reading about the voluntary preemption is sounding promising.
Can anyone give a very _brief_ comparison between these methods? I wan't
also to run as user and not root. Why...'Cause I break $__t! :)
R~
On Thu, 2004-08-12 at 00:58, Anahata wrote:
None that I know of.
Asking this guy might be an idea, perhaps he can include it:
http://mandrake.contactel.cz/people/svetljo/mandrake/kernel/ On Wed, Aug 11, 2004 at 03:22:39PM -0700, Florin
Andrei wrote:
Does anyone know if a package for this kernel has been done for Mandrake
10.0? On Tue, 2004-08-10 at 14:30, Andrew Dahlin wrote:
I assume you're worried about the WM overtaxing the system therefore
causing xruns.
It should not matter which WM you're using if you are running a proper
kernel.
I've been thinking that: I'm glad somebody else said it :-)
The windows manager and desktop is only user-land code and if jack and
the sound drivers are all running at higher priority all that should
happen while you've got audio apps running is either(a) no difference or
(b) the desktop becomes a little less responsive, depending on the
overall CPU and disk workload.
For what it's worth I'm running standard Gnome on kernel 2.6.6. I don't
do any heavyweight audio though. arecord records 16/44.1 stereo fine.
> 2.6 with Ingo's voluntary preempt is actually even better but it's not
> yet 100% stabilized. With one of those kernels and with JACK in
> real-time mode, you could abuse the system pretty badly and it won't
> skip a bit. I'm not at the pseudo Jedi Warrior level for
compiling kernels
just yet! :) Although, I HAVE become a master at compiling Wine and fst
/ jack_fst! :P
;-)
/Robert
>
> R~
>
> > That's what I'm looking forward to...
2:18 p.m.
New subject: Voluntary scheduler for mdk, was Re: [linux-audio-user] what window manager are you using?
On Thu, 2004-08-12 at 11:43, Robert Jonsson wrote:
None that I know of.
Asking this guy might be an idea, perhaps he can include it:
http://mandrake.contactel.cz/people/svetljo/mandrake/kernel/
Please be patient; there are still enough bugs in the voluntary-preempt
patches that distributing a voluntary-preempt kernel package would not
be a good idea just yet. People with ACPI and APIC systems are having
problems.
At this point the remaining bugs can be counted on one hand, so it will
be ready very soon.
I would say in a week or two this will be ready for general use.
Lee
torsdagen den 12 augusti 2004 17.11 skrev Russell
Hanaghan:
> On Thu, 2004-08-12 at 00:58, Anahata wrote:
> > On Wed, Aug 11, 2004 at 03:22:39PM -0700, Florin Andrei wrote:
For what it's worth I'm running standard Gnome on kernel 2.6.6. I don't
do any heavyweight audio though. arecord records 16/44.1 stereo fine.
> 2.6 with Ingo's voluntary preempt is actually even better but it's not
> yet 100% stabilized. With one of those kernels and with JACK in
> real-time mode, you could abuse the system pretty badly and it won't
> skip a bit.
Does anyone know if a package for this kernel has been done for Mandrake
10.0?
9:15 p.m.
New subject: Voluntary scheduler for mdk, was Re: [linux-audio-user] what window manager are you using?
On Thu, 2004-08-12 at 11:03, Lee Revell wrote:
On Thu, 2004-08-12 at 11:43, Robert Jonsson wrote:
None that I know of.
Asking this guy might be an idea, perhaps he can include it:
http://mandrake.contactel.cz/people/svetljo/mandrake/kernel/
Please be patient; there are still enough bugs in the voluntary-preempt
patches that distributing a voluntary-preempt kernel package would not
be a good idea just yet. People with ACPI and APIC systems are having
problems.
At this point the remaining bugs can be counted on one hand, so it will
be ready very soon.
I would say in a week or two this will be ready for general use.
Lee
{tapping fingers on table moderately} Oh ok! 8~}
They say patience is a virtue! I have no virtues!!
Cheers~
R~
torsdagen den 12 augusti 2004 17.11 skrev Russell
Hanaghan:
> On Thu, 2004-08-12 at 00:58, Anahata wrote:
> > On Wed, Aug 11, 2004 at 03:22:39PM -0700, Florin Andrei wrote:
For what it's worth I'm running standard Gnome on kernel 2.6.6. I don't
do any heavyweight audio though. arecord records 16/44.1 stereo fine.
> 2.6 with Ingo's voluntary preempt is actually even better but it's not
> yet 100% stabilized. With one of those kernels and with JACK in
> real-time mode, you could abuse the system pretty badly and it won't
> skip a bit.
Does anyone know if a package for this kernel has been done for Mandrake
10.0?
7556
days inactive
7559
days old
linux-audio-user@lists.linuxaudio.org
59 comments
24 participants
participants (24)
-
Anahata -
Andrew Dahlin -
Anthony -
Brett W. McCoy -
Dave Griffiths -
Dave Phillips -
Erik de Castro Lopo -
Erik Steffl -
ernst＠pulsewidth.ca -
Florian Schmidt -
Florin Andrei -
Jack O'Quin -
Joe Hartley -
kmd -
Lee Revell -
Mark Knecht -
Paul Winkler -
paul wisehart -
pirrone -
Robert Jonsson -
robin fell -
Russell Hanaghan -
tim hall -
Tom