http://en.m.wikipedia.org/wiki/Operating_system-level_virtua...
894 karma · joined July 6, 2011
http://en.m.wikipedia.org/wiki/Operating_system-level_virtua...
https://github.com/sarnowski/mitigation/blob/master/mitigati...
Comments mentions safe OS and golang bugticket.
[0] http://kerneltrap.org/OpenBSD/Virtualization_Security
"x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit. You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes." -- Theo de Raadt
OpenBSD clean and simple design makes it a breeze to maintain. It's documentation always tells you the whole truth and for most tasks, its so intuitive that you almost always already know where to do your stuff.
Contrary to that, most companies would never upgrade a linux system. My feeling is, the most used "upgrade" plan for debian is to not upgrade as long as possible and then do a full reinstall with a new version.
Any chance me, as a non-tester and interested person, gets a "fix" for that?
edit: linking 1 to 0 works so far, but please consider a migration to new version - e.g. chrome did the same some time ago ago[0].
[0] https://groups.google.com/a/chromium.org/forum/?fromgroups=#...
Disclaimer: I am an OpenBSD fanboy because it opened my eyes. OpenBSD's base system already solves 90% of my problems with exactly one, perfectly maintained and documented solution. You want a firewall? Choose between pf, netfilter or something else on FreeBSD. On OpenBSD the answer is "use pf" (which is btw by far the best paket filter I every experienced). The port system just works, is up-to-date and has good default configurations (and I never missed a package). Maintenance is very easy. It is not as easy as apt-get update && upgrade but the release upgrade (every 6 months) never broke anything on my systems (and takes just 10 minutes). Besides that, there is nearly nothing to do. Here is the bug/update list of the current release (5 months old): http://openbsd.org/errata51.html The last thing I want to mention now is the consistency in all tools. For network configuration there is ifconfig which can just handle everything (e.g. on linux you have to use special tools for wlan). You have great manual pages. The manual pages are real manual pages with introductions to the systems, various high level topics down to device nodes etc. They are completely up-to-date and the best source for all informations.
TDD encourages better APIs and more testable code. I don't use TDD to prevent more bugs. I don't even know if this is really true.
Everytime I think of a new feature I fastly have an API in mind. Starting with a test almost always shows me a better way to provide the functionality (easier, more failsafe). Thats one of my two key features of TDD.
The second key feature is that the tests you write are much more expressive than tests you write afterwards. I observe that everyday in my team and company. Writing tests after the implementation is done leads to a lot of mocks and just a static verification that the implementation works how it works. In the end, it is difficult to change the implementation and easy to break the specification. Writing your test ahead of the implementation means you test the specification and not how you implemented it. Tests become much easier to read as they express the specification instead of a 1000 lines test where every variable assignment of the implementation is checked.
As a last hint: I read here that people complain that TDD does not work with "prototyping". I agree with that - the problem with that statement is that a lot of people use their prototype as productive code later on instead of rebuilding it after the experimental phase. In my opinion that is a misuse of the word "prototype". A prototype is an experimental work to verify or learn some ideas and afterwards designing a better system. Other people may state that testing everything is not possible - that there are situations where it is not possible to write a test. I would bet that in 90% of that cases, this is just wrong and means a lack of testing experience of the writer. I can really recommend the following book: http://www.amazon.com/Driven-Development-Embedded-Pragmatic-... I rarly do embedded system programming. My main focus are languages like Java and Go but this book is worth its money independent of your choice of programming language.
(This is my personal opinion and view of the situation)
http://news.gmane.org/gmane.comp.version-control.git
edit: with "git send-email master..origin" all your commits will be send as seperated emails to someone you choose. Afterwards, the receiver can easily get the commits from his mbox via "git am".
In general the non-technical part is more complicated like localized user Services.
(This is just a general hint - not against Microsoft. I don't know how they do their job.)
http://www.zeit.de/digital/internet/2012-02/acta-deutschland...
# (c) 2012 me
#
# The following comment is tried to be copyrighted
# by me. Do not misue!
#
awesome