dcatt

It would be great if the colors for the new barber pole progress bar matched that of BeOS, meaning blue and white versus blue and blue. Other than that, it looks great

Stacked_Lambda

I always enjoy these monthly reports.

I found it fascinating to look at the stats and noticing that the code base has been hovering at around 550,000 lines of code since the end of 2015. It looks like there has been much clean-up in the code since the peak of around 1,200,000 lines of code in 2010. This is a very nimble code base especially when comparing it to that of the Linux Kernel which is trending at around 15,000,000 lines of code.

I noted the continued improvements to the USB 3.0 Stack and the UEFI interface. This is good as these components are now “standards” on systems currently on the market.

2 replies

PulkoMandy Developer

The drop in line of code count since 2010 is because we started using package management and could remove a lot of 3rd party code from our repo. Previously, most 3rd party libraries (ICU, ffmpeg, …) and tools (binutils, bash, …) were copied into our sources and their buildsystem rewritten to use Jam. Now these are built using haikuporter instead (and you can see the stats for that, too: http://pulkomandy.tk/stats_hp/ - with a big increase on activity this year)

1 reply

Stacked_Lambda

So, Haikuport is where the roughly 700,000 lines of code which seemed to have disappear went!

Dividing up the code base in self-contained logical units makes sense. The short-term pains associated with the transition to package management now appear well worth the long-gains for the project.

anevilyak Developer

It’d be worth nothing that lines of code on its own isn’t a terribly meaningful measure of things. A sizable chunk of the linux kernel consists of devices and filesystem drivers for various pieces of hardware (a lot of which we don’t support), which isn’t necessarily compiled in at all depending on the target architecture.