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 :)
With DuskBSD's approach (see "netbsd/README.md") the door is opened for efficient porting of NetBSD's drivers into Dusk.
I've already written drivers for UHCI and rudimentary HID drivers for the keyboard, but this was time consuming. One thing that is still lacking is USB Mass Storage drivers and I'm looking for a fast track.
The idea is to steal drivers for it so that Dusk can natively boot from a USB key.
Same principle as above, but for the DWC controller and the VideoCore driver.
I'd like Dusk OS to be a really good host for uxn, allowing it to run fast on the oldests of 32-bit machines, something that heavier OSes can't offer.
To this end, rewrite the uxn VM to straight HAL.
Also, iron out the bugs (there are bugs presently preventing Left from running correctly), update the specs to the latest ones and import more apps from its ecosystem.
There's already a text editor, but what we generally call a "hex editor" would be useful.
I was thinking of beginning with something like GNU diffutils (or other, simpler version of diff).
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/shell.
An existing fuzzy finder can probably be ported from UNIX, but maybe that something brutally simple can work too. TBD.
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 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.
The HAL is pretty powerful and opens the door to the addition of many programming languages. Lisp, Lua, Pascal. They could be fun to have around, especially if they're implemented with the same frictionless interaction with Forth than DuskCC. Could Dusk be a kind of Babel tower of programming languages? Sure, FFI is already a thing, but C call conventions are not frictionless. I think Forth's semantics are better. Moreover, regular FFI libraries don't have (or do they?) convenient and on-the-fly code generation in their toolbox. Dusk has.