3,467 karma · joined August 16, 2013
hnchat.com:QC6b1eMuHsLMnBE6wPaw
In order to do that, individuals with too low a body temperature would be removed from the group due to infections. This would create a balanced system between body temperature (energy expenditure) and bacterial immunity.
With the development of antibiotics, this changed. The previous bottom of the group is not culled anymore, removing the barrier of the imbalance. Therefore, the group is 'safely' selecting for lower body temperatures.
Auditors
Trusted Enclaves (but then you trust Intel)
Signed chain of I/O with full semantics specified (blockchain style).
You should never believe anyone outright (including oneself). So yes, you get to choose when to believe them.
The RIVM has traditionally had a very good reputation to its level of scientific research. Nevertheless, this does not entail a good consulting role on policy making, especially under duress.
In conversations I have had with governance experts, the relatively weak political position of the RIVM has come up many times. During normal times, this political position is irrelevant, since the RIVM is merely a reflection of scientific insights. During times of crisis and power struggles, the leadership position crumbles.
That, in and of itself, is the sole reason the RIVM has struggled the last year. Power was not balanced. You can see this numerous times:
- RIVM was forced to make a position on the role of COVID-19 on children. Absence of evidence became evidence of absence.
- RIVM was forced to make a position on face masks. Same thing happened. There simply was not enough strong evidence (according to their own strict rules of peer-reviewed, double-blind research).
Similar miscommunications have happened on the topic of aerosols and schools as an important contributing vector.
Please realise how important this is. This is a large scale and continuing failure of governance.
For example, software architecture around systems design might involve thinking of different layers of responsibility, the sequentiality of development, taking into account the skillsets of the teams and existing technical tools and structures.
To me, programming is the art of transforming and ascertaining requirements and principles into executable structure.
Architecture is the art of shaping the non-functional requirements and principles. Either by writing them down or by discussing them at a whiteboard, or even by teaching the team about these requirements.
Both are like an entangled pair that can be incorporated in one single individual, in different team members or even in different organisational structures. Some architectural decisions can be championed by a random software developer. Some architectural decisions shape companies (AWS). And some architectures should just be thrown out of the window.
But, and I am speaking from experience here, as they are different modes of thinking, there should be conscious time and effort for both and they should not be mixed indiscriminately.
In addition, crises of different nature have similar structures. The readiness to deal with the structure of crises of different nature can be tested.
When the RIVM heard of these actions in February, they downplayed the effectivity of masks. Only in March and April, when the crisis hit us (unprepared), reasons had to be given why our supplies of masks were depleted. This is when the media started spinning the story that mask wearing causes increased touching of the face. There is no scientific basis for that claim.
1. Which resources are held by the company?
2. Which actors are interested in these resources (both benign and malicious)?
3. What could threaten the confidentiality, integrity and availability of these resources?
4. How likely are these threats?
5. What would the impact be if these threats would occur?
6. Given the likelihood and impact of each of these threats, form a method to handle these threats.
7. Execute on the plan.
Furthermore, the results of each of these steps should be documented and periodically reviewed.
That is what a security professional should ask.
An even more professional security professional should model the network of threats. For example, one disgruntled employee might have a relatively small negative impact on many different resources, but causing a large impact as a whole.
Doesn’t have to.
This in turn influences the choice of programming language, unit testing, naming, modularization, infrastructure...
Just as a simple counter example: I write my code so I minimize the amount of state and provide good type information. The advantage is that future (re-)composition in other abstractions of the code will continue to work.
An abstraction would be to say: "These programming statements are actually objects." Or, the time and ordering constraints implied in this program should be explicit.
In addition, I was talking about anticipation and preparation of abstraction. Not the actual abstraction.