You Won't Believe These 6 Nasty Side Effects of Osdev!
Posted: Mon Mar 31, 2014 7:59 pm
You Won't Believe These 6 Nasty Side Effects of Osdev!
While operating system's development is regarded as a fun past-time, it comes as a nasty surprise to many how osdev can destroy your life in unexpected manners. You may already be infected! Here is a list of 6 ways operating system's development may already have destroyed your life.
1. Osdev is addictive.
The truth is that operating system's development is considered highly addictive. A 2012 study shows how operating system's development tend to steal more and more of your precious free time, and sometimes even considerable chunks of your professional time. Developers usually fall victim to the addictive effect of the simple satisfaction they get from fixing an impossibly hard bug, porting a difficult program or implementing a powerful feature from the first time. This powerful temporary high combined with expert knowledge gives you a perfect sense of temporary wonderful clarify, not entirely unlike narcotics.
However, as the addiction and technical skill progresses, so does the reward for technical work diminish. Suddenly the same amount of operating system's development just doesn't give the same high, which leads to withdrawal. Many tend to up the challenge by making their operating system's development even harder, leading to an ever increasing armsrace against their limitations. Many people in this situation even come from much simpler projects that somehow turned into fully-fledged operating systems and they won't rest until they have made their own hardware and remade the entire universe to their liking. Even people that manage to cold turkey operating system's development end up returning years later. Some people have successfully managed to turn operating system's development abuse into their actual profession and make a living selling operating systems to users.
The hello world tutorial is free, but you have to write the rest of the operating system yourself.
2. Sleep disorder.
Operating system's developers tend to sleep badly and practically live in completely different time zones when left to their own devices. The fact is that when the hobby operating system starts developing nasty bugs, novice developers attempt to work around the bug, but never quite managing to solve the real issue. Experienced developers know this and when bugs are not fully explained to their insatiable satisfaction, they develop paranoia that lead to sleep trouble. You lay in your bed with anxiety that the bug wasn't actually solved and you get a moment of clarity and realize you forgot to pass important compiler options. Your addition kicks in and you get up at 3 AM and fire up your development environment. Of course, that wasn't actually the full solution and there goes a few more hours of sleep.
This can be especially bad in more skilled developers that haven't yet realized their addiction in the making. As their free time start running out and their professional life continues to be demanding, they start cutting corners when it comes to proper sleep. Soon they are making excuses why they don't have to actually attend university tomorrow. Before you know it, you are up late competing with a bunch of other operating system's developers via IRC at who can port an OpenGL implementation to their operating system the fastest and post a glxgears to the forum screenshot thread.
3. Not-Invented-Here.
Not-Invented-Here is why we osdev. We all suffer from a deep craving to reinvent the wheel and never being satisfied with existing technology. As the symptoms progress, the C++ library that reinvents the wheel and will never see any actual usage becomes a fully-fledged operating system. In particularly nasty cases, the developer even beings developing his own compiler toolchain. Some even view modern operating systems as so fundamentally flawed that they set up to write a much faster operating system written entirely in assembly, which they surely will get around to actually optimizing one of these days.
You can usually identify the worst cases of Not-Invented-Here as the projects without any actual documentation, as the developer evens to automatically even his own code as soon as a fixed interval of time has passed, leading to a constant cycle of rewrites. The Not-Invented-Here accelerates the addiction, as the scope of the project explodes in size. Normal programmers fail when the project scope increases at such rate, but operating system's developers have the technical skill to actually pull off such massive undertakings. The result is that developers suffering from these particularly bad cases actually wish to complete all the work, which leads to the desire of having infinite time available. This leads them to destroy their free time and even start making free time for osdev when none should have been available.
4. Fundamentalist compiler usage opinions.
Experienced operating system's developers have made all the mistakes. They followed all the easy tutorials and experienced the fallout when their tutorial-based operating systems fell apart. They did all the hard work fixing the design mistakes and put in the hard time building countless cross-compilers by reading the GCC documentations. They never asked for help, just pointers on where they can learn everything. Operating system's development is hard and they know it.
Naturally, they are friendly people and desire everyone to osdev as well, so they painstakingly take their time to help newcomers to operating system's development. Unfortunately for the newcomers, help means that the experienced developers want them to avoid making any mistake the experienced developer has ever made. This sets insanely high expectations for newcomers. The experienced developers know by heart how not using a cross-compiler can lead to trouble for newcomers, and osdev is damn hard and they know it, and the newbies should damn well know this as well. If any part of the way newcomers develop their operating systems is less than absolutely perfect, the experienced developers let them know damn well There Is No Other Way to much confusion and controversy.
5. Smug superiority.
Indeed, the hardship that the advanced operating system's developers have been through leads them to conclude they are extraordinary. The confused newcomers are regarded as stupid and incompetent for not immediately comprehending all the compiler details, toolchain details, hardware details, ABI details and so on. The experienced developers know their work is hard (even though they see it as easy through the addicting clarity) and hate how regular people don't appreciate the unusual magnitude of difficult the work is. Most operating system's developers spend a lot of time around uninitiated people and never will be able to do even the tiniest part of the work the developer considers easy.
The situation is so bad in many developers that any newcomer that fails to use supernatural information seeking skills are regarded as incompetent and preconceived as an ultimate failure. Perhaps this is because of the high mortality rate in new operating system developers (before they get really going and addicted) due to not having the required skills, or perhaps they are repelled by the culture of smug superiority. Not that the developers aren't trying to be helpful. They love nothing more than publicly displaying their expertise and superiority when someone asks for help, especially if the asker is known as skilled. Indeed, the smugly superior developer views any question as weakness and can't wait to helpfully answer if he has any advise, even irrelevant advise.
6. Irrelevant Expert knowledge.
As the years progress and the hobby operating system goes from hello world to self-hosting, the developer keeps enjoying the wonderful clarity of understanding everything that is happening inside his own operating system at any level of detail. The developer knows hardware internals, driver specifics, the standard API for his operating system just by memory. The developer is an expert in everything regarding his operating system and recognizes himself as very bright.
Of course, this is worthless knowledge. He is an irrelevant expert. The knowledge doesn't translate to the real world where all this work has already been done in the actually used operating systems, where operating system's research is irrelevant as everyone uses Unix or whatever came with their computer. If the developer is really lucky, he cloned Unix when making his operating system, so his knowledge is only mostly useless instead of entirely. Yet, he takes great pride in nothing all the details that are irrelevant simply because it was hard, not because it was of any actual value.
While operating system's development is regarded as a fun past-time, it comes as a nasty surprise to many how osdev can destroy your life in unexpected manners. You may already be infected! Here is a list of 6 ways operating system's development may already have destroyed your life.
1. Osdev is addictive.
The truth is that operating system's development is considered highly addictive. A 2012 study shows how operating system's development tend to steal more and more of your precious free time, and sometimes even considerable chunks of your professional time. Developers usually fall victim to the addictive effect of the simple satisfaction they get from fixing an impossibly hard bug, porting a difficult program or implementing a powerful feature from the first time. This powerful temporary high combined with expert knowledge gives you a perfect sense of temporary wonderful clarify, not entirely unlike narcotics.
However, as the addiction and technical skill progresses, so does the reward for technical work diminish. Suddenly the same amount of operating system's development just doesn't give the same high, which leads to withdrawal. Many tend to up the challenge by making their operating system's development even harder, leading to an ever increasing armsrace against their limitations. Many people in this situation even come from much simpler projects that somehow turned into fully-fledged operating systems and they won't rest until they have made their own hardware and remade the entire universe to their liking. Even people that manage to cold turkey operating system's development end up returning years later. Some people have successfully managed to turn operating system's development abuse into their actual profession and make a living selling operating systems to users.
The hello world tutorial is free, but you have to write the rest of the operating system yourself.
2. Sleep disorder.
Operating system's developers tend to sleep badly and practically live in completely different time zones when left to their own devices. The fact is that when the hobby operating system starts developing nasty bugs, novice developers attempt to work around the bug, but never quite managing to solve the real issue. Experienced developers know this and when bugs are not fully explained to their insatiable satisfaction, they develop paranoia that lead to sleep trouble. You lay in your bed with anxiety that the bug wasn't actually solved and you get a moment of clarity and realize you forgot to pass important compiler options. Your addition kicks in and you get up at 3 AM and fire up your development environment. Of course, that wasn't actually the full solution and there goes a few more hours of sleep.
This can be especially bad in more skilled developers that haven't yet realized their addiction in the making. As their free time start running out and their professional life continues to be demanding, they start cutting corners when it comes to proper sleep. Soon they are making excuses why they don't have to actually attend university tomorrow. Before you know it, you are up late competing with a bunch of other operating system's developers via IRC at who can port an OpenGL implementation to their operating system the fastest and post a glxgears to the forum screenshot thread.
3. Not-Invented-Here.
Not-Invented-Here is why we osdev. We all suffer from a deep craving to reinvent the wheel and never being satisfied with existing technology. As the symptoms progress, the C++ library that reinvents the wheel and will never see any actual usage becomes a fully-fledged operating system. In particularly nasty cases, the developer even beings developing his own compiler toolchain. Some even view modern operating systems as so fundamentally flawed that they set up to write a much faster operating system written entirely in assembly, which they surely will get around to actually optimizing one of these days.
You can usually identify the worst cases of Not-Invented-Here as the projects without any actual documentation, as the developer evens to automatically even his own code as soon as a fixed interval of time has passed, leading to a constant cycle of rewrites. The Not-Invented-Here accelerates the addiction, as the scope of the project explodes in size. Normal programmers fail when the project scope increases at such rate, but operating system's developers have the technical skill to actually pull off such massive undertakings. The result is that developers suffering from these particularly bad cases actually wish to complete all the work, which leads to the desire of having infinite time available. This leads them to destroy their free time and even start making free time for osdev when none should have been available.
4. Fundamentalist compiler usage opinions.
Experienced operating system's developers have made all the mistakes. They followed all the easy tutorials and experienced the fallout when their tutorial-based operating systems fell apart. They did all the hard work fixing the design mistakes and put in the hard time building countless cross-compilers by reading the GCC documentations. They never asked for help, just pointers on where they can learn everything. Operating system's development is hard and they know it.
Naturally, they are friendly people and desire everyone to osdev as well, so they painstakingly take their time to help newcomers to operating system's development. Unfortunately for the newcomers, help means that the experienced developers want them to avoid making any mistake the experienced developer has ever made. This sets insanely high expectations for newcomers. The experienced developers know by heart how not using a cross-compiler can lead to trouble for newcomers, and osdev is damn hard and they know it, and the newbies should damn well know this as well. If any part of the way newcomers develop their operating systems is less than absolutely perfect, the experienced developers let them know damn well There Is No Other Way to much confusion and controversy.
5. Smug superiority.
Indeed, the hardship that the advanced operating system's developers have been through leads them to conclude they are extraordinary. The confused newcomers are regarded as stupid and incompetent for not immediately comprehending all the compiler details, toolchain details, hardware details, ABI details and so on. The experienced developers know their work is hard (even though they see it as easy through the addicting clarity) and hate how regular people don't appreciate the unusual magnitude of difficult the work is. Most operating system's developers spend a lot of time around uninitiated people and never will be able to do even the tiniest part of the work the developer considers easy.
The situation is so bad in many developers that any newcomer that fails to use supernatural information seeking skills are regarded as incompetent and preconceived as an ultimate failure. Perhaps this is because of the high mortality rate in new operating system developers (before they get really going and addicted) due to not having the required skills, or perhaps they are repelled by the culture of smug superiority. Not that the developers aren't trying to be helpful. They love nothing more than publicly displaying their expertise and superiority when someone asks for help, especially if the asker is known as skilled. Indeed, the smugly superior developer views any question as weakness and can't wait to helpfully answer if he has any advise, even irrelevant advise.
6. Irrelevant Expert knowledge.
As the years progress and the hobby operating system goes from hello world to self-hosting, the developer keeps enjoying the wonderful clarity of understanding everything that is happening inside his own operating system at any level of detail. The developer knows hardware internals, driver specifics, the standard API for his operating system just by memory. The developer is an expert in everything regarding his operating system and recognizes himself as very bright.
Of course, this is worthless knowledge. He is an irrelevant expert. The knowledge doesn't translate to the real world where all this work has already been done in the actually used operating systems, where operating system's research is irrelevant as everyone uses Unix or whatever came with their computer. If the developer is really lucky, he cloned Unix when making his operating system, so his knowledge is only mostly useless instead of entirely. Yet, he takes great pride in nothing all the details that are irrelevant simply because it was hard, not because it was of any actual value.