8 ms·

I don't understand how they write an OS kernel, command shell, graphical shell, and browser in 3 years? I get there are more than a single person involved but i

I don't understand how they write an OS kernel, command shell, graphical shell, and browser in 3 years? I get there are more than a single person involved but it still seems very rapid. 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?

tuckerpo 5y ago
Andreas just gets stuff done. Watch his live content sometime.
- johnwheeler 5y ago
  Unacceptable. If this is so, I quit.
  - joeberon 5y ago
    He has a strong philosophy of "if you want it, do it". Coming into the Serenity community and asking for features to be implemented for you is a taboo. He believes that all computing tasks can be done given enough dedication. This project is basically proof of that. Keep in mind though that he was a WebKit developer at Apple for many years working with full stack control of iOS from kernel to browser.
- alpanka 5y ago
  That's the part I find most impressing. "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
  - jerrre 5y ago
    At the risk of being nitpicky: 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
    - alpanka 5y ago
      You are ignoring that we often use software created by other people. 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...
      - calvinmorrison 5y ago
        There you nailed it. Want a feature X in the plan9 kernel? Okay, add it. Recompile and Run. When a system is self contained and has fewer external users it's easy to iterate and develop without the fear of breakage
akling 5y ago
It's still very immature and not 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. :)
- devsatish 5y ago
  I have been following Andreas/SerenityOS for a quite a while now. It's extremely impressive - how he and the community support built an entirely new OS. https://github.com/SerenityOS/serenity/graphs/contributors https://github.com/SerenityOS/serenity/graphs/contributors
  - selykg 5y ago
    Heads up that the person you responded to is _actually_ Andreas.
- tails4e 5y ago
  I've watched many of your videos and love your approach to building complex features, building the skeleton first with asserts for uimplemeted code paths. However I'd love to see how you got started, the first early (before gui) steps of the kernel. Is that documented? The earliest git checkin I found was already a pretty capable os. Huge congrats on building such a positive community by the way.
  - cxr 5y ago
    > love your approach to building complex features, building the skeleton first with asserts for uimplemeted code paths Write code top-down <https://www.teamten.com/lawrence/programming/write-code-top-down.html 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_.

tuckerpo 5y ago

Andreas just gets stuff done. Watch his live content sometime.

johnwheeler 5y ago
Unacceptable. If this is so, I quit.
- joeberon 5y ago
  He has a strong philosophy of "if you want it, do it". Coming into the Serenity community and asking for features to be implemented for you is a taboo. He believes that all computing tasks can be done given enough dedication. This project is basically proof of that. Keep in mind though that he was a WebKit developer at Apple for many years working with full stack control of iOS from kernel to browser.
alpanka 5y ago
That's the part I find most impressing. "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
- jerrre 5y ago
  At the risk of being nitpicky: 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
  - alpanka 5y ago
    You are ignoring that we often use software created by other people. 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...
    - calvinmorrison 5y ago
      There you nailed it. Want a feature X in the plan9 kernel? Okay, add it. Recompile and Run. When a system is self contained and has fewer external users it's easy to iterate and develop without the fear of breakage

akling 5y ago

It's still very immature and not 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. :)

devsatish 5y ago
I have been following Andreas/SerenityOS for a quite a while now. It's extremely impressive - how he and the community support built an entirely new OS. https://github.com/SerenityOS/serenity/graphs/contributors https://github.com/SerenityOS/serenity/graphs/contributors
- selykg 5y ago
  Heads up that the person you responded to is _actually_ Andreas.
tails4e 5y ago
I've watched many of your videos and love your approach to building complex features, building the skeleton first with asserts for uimplemeted code paths. However I'd love to see how you got started, the first early (before gui) steps of the kernel. Is that documented? The earliest git checkin I found was already a pretty capable os. Huge congrats on building such a positive community by the way.
- cxr 5y ago
  > love your approach to building complex features, building the skeleton first with asserts for uimplemeted code paths Write code top-down <https://www.teamten.com/lawrence/programming/write-code-top-down.html 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_.