Re: [dwm] musca wm

Greetings,
> Using a prefork or similar technique done by apache f.ex can really
> accelerate such tasks, so a minimal vi editor with nice features can be
> really achieved by delegating all such features to external apps or
> libraries
 a minimal application with a dozen external modules, processes, pipes
to achieve the required functionality will be 10x slower and nastier
than if these things were built in.

 Modularization isn't a cure-all - it has a direct impact on
performance, "user-friendliness", maintainability, and especially on
simplicity. It's also hard to get right.

 <anecdote> when I last used wmii a long time ago, a lot of
functionality was off the core. To listen for keybindings, you had
to interface with a virtual filesystem (because plan9 is automatically
cool, right?) - with a cli util that you had to start everytime to
read/write/touch a file. To drive the keybinding logic, you had to run a
complicated shell script (at least this was the default solution) that
read keyboard events through pipes and wrote back control commands,
everything through this vfs util.
 So to make me able to start a new terminal, you had to continuously run
at least 3 extra processes and a lot of code. How is this minimal or
suckless? No wonder a lot of us flocked to dwm...

 I believe in fast, simple, but powerful CLI interfaces rather than
programs pared down to bones. To be quite honest, I'd miss the color
functionality from ls, dpkg argument-expansion from my shell, or the
standard arguments from all the GNU software - if this means supporting
--version in true, so be it. I'm not running an embedded system, a 97k
ls doesn't hurt me too much.

 (I realize this is the same argument MS supporters use to validate the
existence of a multi-gigabyte Visual Studio etc, but let's be realistic
people, 97k ls in 2009 vs. Visual goddamn Studio.)

Best regards,
 Mate
Received on Sat May 16 2009 - 06:10:59 UTC