How to get OSDev Experience?

Anybody have ideas about how to do it? I've read the devil book, Tennenbaum, and a few other things, and peruse the source code of Linux/BSD, but I don't know how to worm my way into the dev community for OS stuff. Any suggestions?

Write an OS?

https://littleosbook.github.io/#introduction

>>3876 I don't want to write an O.S, that's a project that would take years and never be finished. I want to contribute to an existing O.S. >>3877 I mean the part I'm having trouble with is not "understanding" O.S internals, I'm like, how do I find something to work on? None of the introductory materials bring you up to what the focus of modern O.S dev is today. I need advice for how to get into it on a social level/microtechnical level. Like, "Linux is updating the paging system in these ways, talk Derpo Derpenstein, he needs young proteges to shuffle pointers" and that kind of stuff.

>>3885 I'm not in a position to talk personally about OS development but I can point you to where I'd look: #osdev & #linux-kernel on freenode, #kernelnewbies on oftc.

>>3885 >I mean the part I'm having trouble with is not "understanding" O.S internals, I'm like, how do I find something to work on? None of the introductory materials bring you up to what the focus of modern O.S dev is today. fixing stuff, issues/bugs on their respective bug report site or whatever, though that sounds incredibly difficult imo. Or get more experience writting some simplistic OS. Or look for unsupported hardware in whatever OS and write drivers for it.

>>3889 I understand that point of view, and I've tried a little of that, but what I keep seeing is people being trapped in that position, because the grognards hord the design opportunities and leave the cleanups to the youngins. How the fuarrrk did Leonard write System D more or less by himself and get it so widely accepted? I'd be scared to even submit a patch, for fear of being ripped apart by maintainers for bad style or some soykaf.

>>3896 >the grognards hord the design opportunities and leave the cleanups to the youngins I don't know what to tell you, for some things a shortcut does not exist. (or at least i don't know it, otherwise everyone would take it)

>>3897 Bro, there's a difference between a shortcut and a map. I'm not looking to cut corners, I just don't see many people making that transition from style edits and crap to actual development.

>>3896 >How the fuarrrk did Leonard write System D more or less by himself and get it so widely accepted? He has a very high position in a very powerful company. Don't compare yourself to him. >I'd be scared to even submit a patch, for fear of being ripped apart by maintainers for bad style or some soykaf. Try changing your point of view. They're not trying to make you feel bad they are giving you free advice on how to improve your code. It is their project afterall, if they insist on your code being a certain way it's because they care about the quality of the project, not because they are assholes. So think of it as a learning opportunity. Also consider hanging out on the relevant mailing lists and IRC channels. If you make friends with some of the key maintainers and give them the impression that you care about being part of the community and are not just submits driveby patches and is never seen again then they might be nicer in the review stage.

>>3916 >He has a very high position in a very powerful company. Don't compare yourself to him. You saying just because he works somewhere big they took his stuff? > So think of it as a learning opportunity. ""Of course, I'd also suggest that whoever was the genius who thought it was a good idea to read things ONE F✦CKING BYTE AT A TIME with system calls for each byte should be retroactively aborted. Who the f*ck does idiotic things like that? How did they noty die as babies, considering that they were likely too stupid to find a tit to suck on?"" Every patch goes through the maintainers and they are old grumpy dicks. >Also consider hanging out on the relevant mailing lists and IRC channels. I tried that. Here are my results. Mailings Lists: Too much spam. LKML has 1,000+ messages a day, and most people who submit patches seem to do it for al living, because they submit multiple patches per day and they seem to be instantly accepted. I have no way to understand the direction or intention of development, and there are literally hundreds of developers. Free BSD is easier, but still 30+ mails a day and nearly zero explanation for what people are working on. "Fixed Null Pointer dereference in some system" I used to try and e-mail people from the Free BSD mailing list and try to get to know them, but nearly none of them respond to e-mails. >IRC Yeah, that might have worked 10 years ago. Most of the IRC rooms for this stuff are deadish. Last time I was in the Kernel development IRC for Linux, it was dead and when someone finally got on it went like this: "do you write kernel code?" "No" "know anyone here that does?" "No" "Then why are you here?" "I have a problem with a driver...." Useless. The FreeBSD ones are actually a tiny bit more alive in my experience, but that went like: "Do you maintain the kernel?" "Yes" "Can you help me get started?" "Yeah we have some guidelines for code cleanup! We need someone to change all these function names so they have camel case..." >_> wow. You know you're beginning to convince me it'd be easier to just write my own O.S. Maybe Linux and BSD don't want new developers? Maybe I need to find an O.S that's less finished...

>>3921 >You saying just because he works somewhere big they took his stuff? Err, no. He's not just a random guy who "just works" there and Red Hat isn't "big", it's a billion dollar company. >You know you're beginning to convince me it'd be easier to just write my own O.S. Don't care. Go for it.

>>3925 Bro, he was very young when he wrote all that, he couldn't have been much more than a Junior engineer. That doesn't hurt my point either... how many years of cleaning up style mistakes did he have to do? Seems more like he just made a giant thing and somehow red hat pushed it through. > Don't care. Go for it. Do you commit to these projects? Just curious.

>>3896 >and get it so widely accepted? Believe it or not, systemd got so widely accepted in part because it's a huge improvement over SysVinit and almost all init system and process supervisors that were out at the time (except Solaris' SMF and OS X's launchd, but nobody cares about those). Red Hat must've evaluated the other init systems and naturally picked systemd, because: - it did more stuff - it was more mature than similar systems e.g. Upstart - it was written by one of their employees, so they could control its development very closely The other part of the reason why it is so widespread is that Red Hat and the FreeDesktop cabal pushed it, and people want GNOME to work well on their desktop thread machines.

>>3954 >Bro, he was very young when he wrote all that And yet he already had a lot of experience from pulseaudio, contributing to dbus, and probably a lot more stuff.

>>3956 >The other part of the reason why it is so widespread is that Red Hat and the FreeDesktop cabal pushed it, and people want GNOME to work well on their desktop thread machines. Well see that's a good point, and yeah I'm in agreeance I'm not in a position to do that. >>3957 Yeah, well it feels more and more like he just went for it. Meh. This is always a depressing topic. Do any of you guys actually read OS development mailing lists? 9/10 patches aren't even people really doing anything significant. I swear most people submitting patches are those dudes who get paid to do it at MS.

>>3974 >9/10 patches aren't even people really doing anything significant. What else do you expect? Most patches in basically all projects from people not in the core contributors are people not really doing anything significant. Not many people can even afford to take the time to familiarize themselves with the whole architecture, let alone doing that enough to contribute in a significant way.

write a patch or a driver or two. Make a habit of it. Mess around with a local branch of your favorite OS. Post it to a mailing list in the way that is preferred by the maintainers. >>3921 your problems seem to be more of perspective than anything else. The LKML unequivocally does have some discussion/commentary, and your problem is that generally you go to a mailing list with intent to either submit a patch or bug report or ask the developers about something. Nobody uses a development mailing list to get to know people. Your other problem seems to be that you don't idle well. This isn't something you can just jump in and get instant feedback on, it can take days for some IRC channels to get some activity, and sometimes you have to rewrite a patch a couple times before it gets accepted. And last: if you're trying to get name recognition or make major design decisions right off the bat, look elsewhere. This is a team project, and the leaders are mostly leaders because they've been doing it for decades.

>>3997 >write a patch or a driver or two. Make a habit of it. Mess around with a local branch of your favorite OS. Post it to a mailing list in the way that is preferred by the maintainers. I like that advice, but it's sort of my original problem all over again. What drivers need to be written? I've never seen a list like "ALL THE DRIVERS WE HAVE EVER WANTED." Not do I have a collection of exotic hardware that requires device drivers. The two areas always getting worked on seem to be video drivers and WiFi, which both look intimidating as all fuarrrk. I don't know where to start. If it were a github project, I'd read the bug tracker and look for feature requests.... Like, the nightmare I have is. >add some thing. >it's cool >Mailing list is like fuarrrk off, don't you know we don't like those things? No one asked for your help. > le fail You gotta know what the community's direction and appetite is. >your problems seem to be more of perspective than anything else. The LKML unequivocally does have some discussion/commentary, Yeah but what I *want* it to have is some discussion over the direction and purpose of things. Like, a big banner that says "we gonna clean up the procfs, get on that boys" - that way I know like, what's worth my time to get involved in versus my fear of fixing a problem that's already being worked on silently by 12 other people. That's why I love code bounty programs. They state in clear English what they want to be developed, and it's often features instead of bug fixes. >Nobody uses a development mailing list to get to know people. I only want to get to know people so I can have a clear, human explanation of what the direction of development is. Like for instance "We are converting everything to 64 bit now. Get on that!" >This isn't something you can just jump in and get instant feedback on, it can take days for some IRC channels to get some activity, and sometimes you have to rewrite a patch a couple times before it gets accepted. I don't know what to write in the first place, because the hand guiding things behind the curtain is invisible to me. I don't mind re-writing crap. I have literally never been able to raise someone over chat who knows what the heck is going on. >And last: if you're trying to get name recognition I don't want that. I want experience writing O.S stuff, because I like O.S stuff. I have no other avenue to do this besides these super insular groups. There isn't exactly an easy in to OSDev. > and sometimes you have to rewrite a patch a couple times before it gets accepted. I'll rewrite it 20 times. I just don't know what anybody wants written. The map for development is 100% opaque. >This is a team project, and the leaders are mostly leaders because they've been doing it for decades. I get it man. I just want to get started. I'm not a novice developer, and I want to do something OS related as opposed to basic code cleanup crap. I appreciate your replies man, I think you're listening.

* goto bug tracker * find bug * reproduce bug * fix bug * submit patch >wah wah what if they're mean i can't deal with rejection i want to write cool code and be a rock star wah wah Your emotional issues is not what /lambda/ is for.

>>4000 >Your emotional issues is not what /lambda/ is for. You know exactly what I mean. I asked help figuring out how to get into OS Dev. Fixing people's null pointer derefences isn't going to help that. Or maybe you can link me your own OS contributions? You doing much captain badass?

>>3998 >The map for development is 100% opaque. then literally just ask in the mailing list. I've seen that happen many times on many mailing lists.

>>4003 >Fixing people's null pointer derefences isn't going to help that. Yes it will, stop whining and either start fixing bugs or go write your own.

>>4004 >then literally just ask in the mailing list. I've seen that happen many times on many mailing lists. Seriously give it a shot on LKML. I dare you. You might get to the front of Hacker news for the deluge of derisive laughter. Contrary to what the guy said above, that's not a problem for me because of thin skin, it's just counter productive. I was hoping in this thread for someone to be like: "I do OS dev, here's how I wedged myself in there." >>4007 >Yes it will, stop whining and either start fixing bugs or go write your own. It will help the code quality of the OS. It will *not* help get me closer to learning the craft of building operating systems. I could run a SA tool on the kernel and just point out hundreds of these. I want to be a developer, not a bug fixer... Maybe I wasn't clear about that difference? I'm not saying that be an ass, I'm serious when I say that. No one hires developers on "added a bunch of null pointer checks" - they hire on "implemented high performance queuing mechanism" and what not. Someday I'd like to do OS dev for a living... Just like the dude above said, nobody is going to allow me just go *add stuff* in any existing OS. That's why I was asking about Leonard. The driver suggestion was helpful, but still too broad. I mean, on it's own telling someone to just "go write a driver" isn't specific enough to be anything more than a full fledged year long journey of discovery. Who do I ask about what drivers need to be written? Do I take a poll of all Linux users over which drivers are least available? Who keeps track of this? Is the data good? How do I know a driver is really needed? I could go on for days. Do you expect me to just go out and buy laptops till one of the components isn't supported? How many thousands of dollars before I discover something that has absolutely no form of driver available? Aren't most things already covered? Doesn't each category of driver already have a dedicated dude pumping out new ones? How do I get ahead of that dude? How do I find him? Do I need to? And hey, if you know of a single instance of a dude submitting code cleanup commits being *invited* to make a meaningful change, I'd be happy to hear about it. You could even be like "Yeah bro, that's how I got my start on Linux, fixing people's indentation errors." if it's true. That's just not what I see on the mailing list. I see just about all commits coming from either a) some wunderkind b) someone from some big company or c) someone who's old enough to have been around back in the day. >go write your own. That wont accomplish my goal at all, and would take years to make an inferior product. Come on now, stop being salty. Has anyone on lainchan ever contributed to the Kernel? I'm here to see how the hell you got your in. Not to whine.

>>4013 If you're so fixated on doing meaningful work right off the bat then writing your own really is the best option. Becoming a contributor on projects as huge and as lengthy as the Linux kernel or some BSD's is hard, I don't understand how you can expect anybody to give you important work when they don't even know you, let alone trust you to write good code. Some projects like those participate in the GSoC initiative, and not all listed projects get taken up by somebody. If the project you want to contribute to has something similar you could try scooping it up, but don't expect anybody to mentor you if they were expecting to get paid for it. Otherwise, fixing bugs is a good way to make people remember your name, if anything. Have you ever worked anywhere? Because that's how you start, by fixing the small, stupid bugs. >That wont accomplish my goal at all, and would take years to make an inferior product. The point is not to make a superior product, you dumbass. The point is to do a big project to gain more insight and test your capabilities, so that you will actually have half an idea how the kernel works instead of making people spoon-feed you, and so that when people ask you where are your credentials you'll be able to show them that. Really, I don't get how you can be so entitled as to expect people to tell you everything and hand you big chunks of work, just like that. It takes effort to document your work in a way that makes it easy for newcomers to contribute, and if they don't do it then maybe they don't really need it.

>>4026 >Becoming a contributor on projects as huge and as lengthy as the Linux kernel or some BSD's is hard, That's why I'm asking how. >let alone trust you to write good code. How would they know I wrote good code if my patch is a null pointer check? That's a catch 22. >If the project you want to contribute to has something similar you could try scooping it up That's the closes thing to a good idea I've heard so far, but still sounds a little unlikely to work. >but don't expect anybody to mentor you if they were expecting to get paid for it. based on the tone of the mailing lists, I wasn't expecting that at all. Ever. >Otherwise, fixing bugs is a good way to make people remember your name For doing something trivial. > Have you ever worked anywhere? I've been a dev for years. People who are 1LOC refactor committers don't necessarily earn the love of the people. People can get trapped as "maintenance coders" for years without getting a real project. >by fixing the small, stupid bugs. That's not how I started. And most people who make it to Senior make it there by writing features, not fixing trivial mistakes. It shouldn't be that way, but from what I've seen it is. >The point is not to make a superior product, you dumbass. The point is to do a big project to gain more insight and test your capabilities Sounds more like hobby programming to re-invent the wheel. >how the kernel works instead of making people spoon-feed you I understand how the Kernel works just fine? I read the code all the time, and reading OS stuff is a big hobby of mine. I've written a Kernel mode rootkit for instance... >credentials you'll be able to show them that. I don't know about that. I done a lot of interviews, and people pulling out their "reinvent the wheel" project where they wrote their own compiler or whatnot can be really cringy. It is seldom a demonstration of up to date tech. >Really, I don't get how you can be so entitled as to expect people to tell you everything I'm asking to figure out the direction and intention of development, not "everything" >and hand you big chunks of work I'd be happy finding it myself if I knew where to look. I noticed you didn't reply to my driver rant which typifies the issue. What driver do I write? how do I know it needs to be written? Who will care? Who will approve it? Is there a system? The ad hoc system of commits in all these projects makes it *maddening* to know what to contribute unless you are part of the inner clique. >and if they don't do it then maybe they don't really need it. I don't care what *they* need. I *want* to involve myself.

It's too bad that http://eudyptula-challenge.org/ is down now, it would have been nice to participate. I'm pretty sure all it taught was how to get through the convoluted kernel commit process anyway. https://www.linux.com/news/three-ways-beginners-contribute-linux-kernel has given me some help in the right direction. Here's one thing I would love to know: The Linux Kernel at least, has To-do files. That's nice. http://www.linuxdriverproject.org/mediawiki/index.php/Frequently_Asked_Questions was super helpful. The Linux driver project *does* imply that there are somehow far more driver developers than needed projects, which is actually astonishing. https://www.freebsd.org/doc/en/articles/contributing/article.html also helped me. There is a system that lists enhancements to be added. I think all in all the thing that is missing in both Linux and FreeBSD (and from many private projects to be honest) is a sense of *direction* at the highest levels. Everything is decentralized to the point where it looks like nobody makes large scale design improvements. What keeps a project like FreeBSD from becoming a ball of mud? If someone asks for an enhancement, and I build it, I have no way to gauge the *intentions* of the cabal of hardcore committers who actually run the show. If they take every functioning enhancement (which they likely don't) then the thing becomes a ball of mud. If they don't, then a potential committer has to reverse engineer what they want the project to look like from the outside. For any kind of detail oriented person, this can be a nightmare. Where do I risk my time?

>>4034 >I don't care what *they* need. I *want* to involve myself. Fine then, I guess the only solution for you is to simply try harder; complaining on lainchan probably won't yield any results. I think what >>4064 is pretty accurate. I don't think even the core contributors have the complete grand plan ahead for the Linux or FreeBSD kernel; some of them probably have some feature they want to push, which they're gonna implement by themselves. And of course they're at risk of having their work rejected.

>>4073 >try harder Speaking of which, I tried to send a message to the driver dev mailing list. Apparently all messages from new users are filtered as spam. why?