[haiku-development] Re: Future Haiku Features

For a while I've been compiling a list of ways that Haiku (or any OS really)
could be better adapted to laptops, without comprimising its ability to work
with desktops.  Here are the major points:

LCDs have a fixed resolution, so it's pointless to pretend to change it.
Instead, "DPI" is what should be adjusted.  For Haiku, that likely means
that the number of pixels would be immutable, where as the number of BPoints
can vary.  So photos are always displayed at maximum detail, text and vector
graphics can use subpixel rendering, and GUI widgets could be SVG graphics
so their size can be easily adjusted to keep them in proportion with text.

Since battery life is quite important, minimize the number of times per
second that the CPU has to leave powersaving C3/4 modes.  Look at PowerTop
for Linux with Intel processors for more explanation.

SSD optimizations.  Basically, use the ATA secure deletion commands (TRIM?)
to free space in a way that the SSD knows it's free (keeps performance from
degrading), and minimize the number of small writes to disk (SSDs are
improving in this regard, but it's still their slowest operation due to the
usage of erase blocks).  Also, warn the user if they try to create a
partition that isn't well aligned to disk geometry (if sectors overlap erase
block boundaries then there's a fairly noticeable performance hit).

On Mon, Jul 27, 2009 at 5:25 PM, Stephan Assmus <superstippi@xxxxxx> wrote:

> Hi all,
>
> as Axel, Ingo, Michael Lotz and myself are currently performing a little
> informal/spontaneous coding sprint, we were discussing a bit the Haiku
> "roadmap". As this is open source and heavily depends on the time and
> motivation of any individual to work on any features, it isn't really a
> roadmap/timeline, but a kind of "want to have" feature list, with some
> suggestion as to what could go into which release. The ideas we collected
> are accessible at this Trac Wiki page:
>
> <http://dev.haiku-os.org/wiki/FutureHaikuFeatures>
>
> Eventually, each idea should be entered as another milestone into Trac. If
> it's small enough, a ticket may suffice. We've put some thoughts into why
> we scheduled some features for "R1" and "Maybe R1". Ideally, after we have
> finally managed to release the first alpha, further releases leading to the
> final R1 should come in quick succession, hopefully bringing us R1 without
> unnecessary delay. For this to be possible, we obviously need to keep the
> number of unfinished features we schedule for R1 very low, especially since
> new features usually don't appear after the first beta. The ones we put
> into our list are currently being worked on, or, as in the case of the
> package manager, are desperately needed before a finalized R1 to avoid
> chaos later on. It is possible for anyone to edit this page, but please
> keep the features broad and be very careful and considerate. If you are not
> absolutely certain that a feature would meet the agreement of most if not
> all Haiku fans, perhaps it is better to discuss it on the mailing list
> first.
>
> Best regards,
> -Stephan
>
>

Other related posts: