What are the catches? Is it still very immature or assuming there was enough user-land software (which I'm sure there is not), is this ready for production use?
What are the catches? Is it still very immature or assuming there was enough user-land software (which I'm sure there is not), is this ready for production use?
That said, you can do a heck of a lot in 3 years if you put in consistent time and effort towards something. :)
Write code top-down <https://www.teamten.com/lawrence/programming/write-code-top-...>:
> With bottom-up design you start with the components [...] Designing a component is a small tractable task that can be finished and called _done_. You’re creating a perfect, beautiful, reusable jewel. All engineers really want to _do_ is write components. [...] At every level there's pressure to do bottom-up programming. Avoid it. Instead, start at the top, with `main()` or its equivalent, and write it as if you had all the parts already written. Get that to look right. Stub out or hard-code the parts until you can get it to compile and run. Then slowly move your way down, keeping everything as brutally simple as you can. Don’t write a line of code that isn’t solving a problem you have _right now_.
There's a bit of history about early development here: https://serenityos.org/happy/1st/
Also, one of my earliest videos was showcasing some pre-YouTube builds of SerenityOS: https://www.youtube.com/watch?v=rveS_vwp0y8
I didn't know about computron until you mentioned it in the video, so I have to ask, would serenity run under computtron? If so, could a serenity port of computron run serenity in serenity?
"Today we are going to add X"
2 hours later: X is added and working fine.
Meanwhile, at work I could easily spend 2 hours looking for a GCC flag or figure out why the build script fails on arch after latest update
Updating tools in your environment/workflow is exactly a thing that can lose a lot of time, often for not much gain[1]. One way to become very productive is to know your tools very well, and that would extend to not changing them often.
[1] not much gain in productivity, but perhaps in security, compatibility, etc
Raise your hand if you have ever spend an afternoon trying to get someone else's build scripts working. Wondering why make, cmake, scones and ninja are used in the same project...