Hacker News Reader

Comment by kornish | Hacker News Reader

Unreal – never knew XMonad was so small. It's only 1650 lines of code!

  tedkornish : dev/xmonad @ master :: cloc src
         8 text files.
         8 unique files.
         0 files ignored.

  http://cloc.sourceforge.net v 1.64  T=0.03 s (244.6 files/s, 95612.1 lines/s)
  -------------------------------------------------------------------------------
  Language                     files          blank        comment           code
  -------------------------------------------------------------------------------
  Haskell                          8            446           1028           1653
  -------------------------------------------------------------------------------
  SUM:                             8            446           1028           1653
  -------------------------------------------------------------------------------

View on HN

That's extremely bloated. ;) For several years early on in its life, the entire XMonad core codebase was just under 500 lines of code. Of course, I believe the Zipper rewrite (many moons ago) was what increased the size somewhat, and it was for the best... It's even small enough someone did a formalized Coq proof of the core data structures (i.e. they proved that XMonad cannot 'crash' in several ways.) :)

I have used it very fondly almost for a decade now (since 0.0!) and it is a good piece of software. I don't think I've changed my config more than 10 lines in like 7 years...

If anyone wants to see the old school cool: check out XMonad 0.3. This was a good release, trust me:

    $ git clone https://github.com/xmonad/xmonad.git && cd xmonad
    $ git checkout -b old v0.3
    $ cloc Config.hs* Main.hs Operations.hs StackSet.hs 
       5 text files.
       5 unique files.                              
       1 file ignored.

    http://cloc.sourceforge.net v 1.60  T=0.01 s (561.3 files/s, 213300.6 lines/s)
    -------------------------------------------------------------------------------
    Language                     files          blank        comment           code
    -------------------------------------------------------------------------------
    Haskell                          4            211            625            684
    -------------------------------------------------------------------------------
    SUM:                             4            211            625            684
    -------------------------------------------------------------------------------

I also take back what I said earlier. I have been using XMonad for almost exactly a decade, since 0.1 was released in April 2007, and I used the pre-release. So its 10th birthday is very close.

I also think it's interesting to note that XMonad is a pretty good example of stable software that doesn't need to change much. Lots of tiling WMs probably fall in this category by some metric, I'd say. For example, the v0.3 version of XMonad had exactly 572 commits in its history at that point:

https://github.com/xmonad/xmonad/commit/dede0a2ce91eebdb1c02...

The HEAD version of XMonad, 0.13, only has exactly 1,265 commits, at the time of this writing. But it has been released almost 10 years later. So that's only a little over 2x as many commits over the course of a decade, and roughly 3x more code at the core level. It does exactly what it needs to do -- so it hasn't needed to evolve much more than that. Files like StackSet (the most central data structure in XMonad) have almost not changed in 10 years, modulo some shuffling, comments, re-exports. That's quite nice, really.

(Where all the extra code came from between 0.3 and 0.13 is left as an archaeology exercise to the reader.)

That is only the base library.

Contrib and extras, where a lot of the useful stuff is defined are here:

https://github.com/xmonad/xmonad-contrib

https://github.com/xmonad/xmonad-extras

On the other hand, xmonad has a remarkably well defined set of defaults so I for one am able to be very productive with them very well. My personal config provides stuff that I use maybe 3 % of the time.

Yep, it was a discovery for me that it's easier to go to the source code directly than to try to do something using documentation.

Unfortunately, GHC isn't too small. Here's a recent example:

https://lists.gnu.org/archive/html/guix-devel/2017-02/msg009...

Wait, but can't you just ship the xmonad binaries rather than the source?

The configuration language is Haskell.

Probably to great advantage of DWM where configuration requires recompilation but you can static link and distribute once you've compiled.

But the configuration is also compiled into the binary. And if you really need runtime configuration without the weight of GHC, well, Haskell is well known as an excellent language to write interpreters in... (I think someone already did that for Xmonad, actually.)

xmonad source itself can be small but, running xmonad consumes a lot of memory due to huge ram/space requirements of the ghc (haskell) (edit I don't remember exactly what consumed so much memory). that's why i moved to i3 wm after years of xmonad use.

I did the same thing. i3 is very nice so far.

I moved to i3 just for configuration ease. That you would move to save the difference in a tiled window manager might be a little over valuing the memory saved :)

At least it isn't I left KDE bloat to go to Gnome when Gnome was actually having a larger foot print back in the day.

Same, but moved from Awesome WM to i3. Config is simple but powerful, and i3 itself brings so much to the table out of the box that your customization footprint is going to be smaller than that of scriptable WMs.

I tend to use xfce these days, but when I'm really getting sshdirty, I'm usually in i3, but I tried and still want to use awesome mostly because I try hard to favor GPL products, but i3 is just so easy and works without nearly as much work.

Curious, why do you favor GPL over BSD as a user? You have all the same abilities with it, and a few additional ones too.

The closed source forks for the BSD licensed projects... sure, don't use those but the projects themselves are good to go.

> Curious, why do you favor GPL over BSD as a user?

In my case, because I know that any contributions I make will become part of the software commons and won't be taken proprietary.

You can make your own GPL fork if you'd like. That's the nice part about BSD, you can relicense it exactly as you please.

"Curious, why do you favor GPL over BSD as a user?"

Because BSD licenses are abused by the tivoization of devices far too often, and I think GPL(v3) is one of the few licenses that gets in the way of that. (because to be fair, GPL1/2 were also abused in this way, but I think GPLv3 has fixed most of those loopholes)

BSD style licenses are about freedom for the developer, not the user, whereas GPL style licenses are about freedom for the user. All devs are also users, but not all users are devs, therefor GPL licenses are for freedom for a greater number of people as well. (Can you tell I think RMS is/was right?)

Also, you can theoritcally license BSD stuff under GPL if you fork it and make the new code contribs GPL, but enforcing it would be almost impossible, so I don't think that's a valid get out of license free card.

> enforcing it would be almost impossible

It'd be about the same as GPL enforcement as is. I don't see any reason this would introduce a special circumstance.

I tried many of the tiling WMs, and XMonad was the one I liked second best behind i3. One thing I really liked about XMonad was the "flip this window with the "main" window. But marks and "stack" or "full screen" in i3 work for me. The thing about XMonad was that I don't know Haskell and so the config was something I would cut and paste snippets into and pray that they'd work.

Approximately how much memory would XMonad use for you?

Yeah, that comment doesn't make much sense as it stands. GHC is a compiler not a runtime. Functional languages like GHC-compiled Haskell are not known for extreme memory efficiency in all cases, but it depends entirely on the program. Unless I'm not aware of how XMonad actually runs.

Well, GHC does have a runtime, and in some way XMonad also uses the compiler at runtime because configurations are written in Haskell...

And you have to recompile it if you change your xmonad.hs config file. There's no interpretation going on at runtime - well except when you actually run xmonad with an interpreter like ghci.

Recompilation[0] simply calls the compiler binary, though.

[0] https://github.com/xmonad/xmonad/blob/master/src/XMonad/Core...

I m on an old laptop with 2G of rams. it was 3 years ago with xmonad so I don't remember well but i3 left more free ram.

It's using 1.6 MB for me at the moment.

I'm currently showing ~8.5M resident and ~4.6M shared. You can certainly do "better" than that with a different tiling window manager, but before going nuts trying to improve that or condemn XMonad/GHC, I'd definitely suggest running "top" and pushing "M" (capital matters) and seeing where it shows up in your listing. snapd and NetworkManager is taking more RAM for me right now than XMonad by a bit, and emacs, konsole, pidgin, thunderbird, clementine, and firefox all grossly outweigh it. Optimizing your window manager to take 1MB instead of 4MB of RAM is a complete and utter waste of time if you're running any web browser at all, that's less than a single big image's worth of RAM.

I use xmonad, It's consuming 5MB right now, uptime of 10 days, I'm more than happy. If this is a "huge" consume I wonder what are your expectations

Reply on news.ycombinator.com