duskos/ROADMAP.md -rw-r--r-- 3.0 KiB
3e6f4fbdVirgil Dupras Update roadmap 6 hours ago

#Dusk OS Roadmap

The biggest task is always to iron out the bugs, which are in ample numbers at this stage of development, but there's otherwise many exciting features on the roadmap!

I have tons of ideas for Dusk, but some of them are too vague yet to be actionable. In other cases, it's Dusk's structure that isn't sophisticated enough yet to accomodate them. The roadmap below contains a list of tasks that could be tackled now. If one of them inspires you and you would like to get involved, please reach out on the mailing list.

If you're inspired by an idea that isn't below, you can reach out too :)

#Complete DuskCC

In a general way, here's the list of things missing from Dusk C for it to be consider complete:

  • union
  • enum
  • goto
  • float
  • macro expansion in #define
  • #if/#else/#endif
  • a few little ops here and there
  • better error checking and messages.
  • probably countless bugs

So, there's a fair chunk of work left, but there's also a lot that's already done.

#Text editor, hex editor

A naive first idea would be to port vi to Dusk, but I think we can do much better than this. The Grid is a much richer environment than a curses one and I think we can build a much more powerful vi-lookalike.

Same thing for a hex editor.

#Begin porting UNIX apps

I was thinking of beginning with something like GNU diffutils (or other versions of diff, which seem to be simpler).

Another good one to port would be libcaca. Being able to do some vizualization on the Grid without needing to enable the graphics mode would bring a lot of flexibility to the system.


See doc/design/speed.

See doc/design/shell.

An existing fuzzy finder can probably be ported from UNIX, but maybe that something brutally simple can work too. TBD.

#New architectures

What about the Raspberry pi? An ARM port is in progress.

Otherwise, I have an old Powerbook 520 lying around and I'd love to have Dusk running on this, so m68k is right there on the roadmap.

#Assemblers, disassemblers, emulators

Assemblers, disassemblers and emulators are very useful tools to play around. We should have as many as possible.

In the case of emulators, things can quickly get complex (I'm looking at you Intel), I think a good idea would be to have "partial" emulators, that is, emulators that are only good enough to run the kind of code that Dusk's supported programming languages generate (which is generally a smaller subset of all the opcodes in all modes that a CPU would support). This could help keeping complexity at bay while keeping all its usefulness. After all, the idea isn't to run Linux on it, but to use it as a development tool.