Design decisions
When architecting a system, it is inevitable to make certain high-level design decisions.
Some of these decisions, if they’re wrong, can lead to the re-architecturing and re-writing of the whole system some months later, so there is an incentive to keep things rather generic. On the other hand, trying to make system too generic is just another recipe to disaster (usually expressed in terms of missed deadlines and unmanageable code).
IT Hares try to describe certain not-so-obvious architectural decisions, and some considerations which should be kept in mind while making them.
Bringing Architecture of Operating Systems to XXI Century – Part IV. First Draft
November 8, 2019 by • “No Bugs” Bunny
Quote:
While L3 kernel can STILL run on MMU-less RAM-constrained MCUs, it provides responsiveness which is comparable to that of multi-stack kernels.
Another Quote:
multi-coring is essentially a special case of balancing shared-nothing nodes
Filed under: On.System ArchitectureDesign decisions(Re)ActorsOn.ProgrammingEmbedded
Read moreBringing Architecture of Operating Systems to XXI Century – Part III. Basic Ideas
May 9, 2019 by • “No Bugs” Bunny
Quote:
everything in the system should be a Finite State Machine (FSM)
Another Quote:
‘OS’ is not understood as ‘OS kernel’, but rather is defined by the apps which can run on it
Filed under: On.System ArchitectureDesign decisions(Re)ActorsOn.ProgrammingEmbedded
Read moreUnchecked Exceptions for C++
June 7, 2018 by • “No Bugs” Bunny
Quote:
‘unchecked’ std::errors are treated as ‘something which should never ever happen, but in practice MAY occur as a result of potentially-recoverable bug'
Another Quote:
Failing-Fast does NOT mean we should necessarily Fail-Hard(!). In certain (production!) cases, Failing-Fast-AND-Soft IS a substantially better alternative.
Filed under: On.System ArchitectureDesign decisionsOn.ProgrammingProgramming LanguagesOn.DevelopmentDevelopment Philosophy
The Importance of Back-of-Envelope Estimates
August 8, 2017 by • “No Bugs” Bunny
Quote:
trying to optimize out a 3e-7 performance hit is very rarely worth the trouble.
Another Quote:
With 4S/4U boxes having typical MTBFs of 3–5 years, the next question we should ask ourselves, is “Hey, will we really be able to write software which crashes much more rarely than that?”
Filed under: On.System ArchitectureRequirement analysisDesign decisions
Read more
Six Impossible Things Before Breakfast Ltd. © 2026. All rights reserved.
