71–80 of 82 posts
Earlier quoted context omitted.
seems low
Well, it depends on whether or not "4-5 years in related experience" means systems programming or if it means making single-page webapps.
Earlier quoted context omitted.
> Sending patches is as easy as sending one in GitHub or any other web-based system. Its still prehistoric in projects like the Linux Kernel, from a beginners point of view compared to GitHub, Gerrit or GitLab, which most of the active contributors are already working at large companies who's work requires contributing to it, thus already have invested in time and money learning the contribution process. To look at t…
Well, if you want to be more likely to get reaction from any one of 10 or so odd people the typical patch series goes to directly (sometimes simply because they may have contributed some code to some file you're also modifying now) + hundreds more on a bunch of subsys and more general mailing lists, forcing them to register on some random web service of your choice and then monitor it for further communication and re…
The clear misinterpretation happens when I said 'beginners eyes' to assume that I'm some sort of 'beginner', when in fact as a maintainer I keep hearing the opinion of students and newcomers making this comparison and they use their preferred way to contribute (Github being mentioned often) when joining a project. Therefore, you giving a very naïve assumption that I somehow wanted to force everyone to '...register on some random web service' when I clearly said that beginners should start with a similar open-source project using similar tools like Gerrit, GitHub before trying something harder.
Yes, I have confidence that everyone knows how to reply to an email. But in comparison to tools like Gerrit or Github, I won't expect many non-commercial contributors to stay for long if the review process was via mailing lists, unless they are paid to work daily on the project, which is why I recommended beginners other OS projects that have a similar review process before going onto looking at the Linux kernel.
I miss the Eudyptula Challenge [0], I never got around to complementing it. It was a series of 20 challenges to introduce you to Linux kernel development, and it was done entirely over email. I think it's been shut down for a few years now, I'm not sure when or if it'll come back at this point. [0] http://eudyptula-challenge.org/
It is still possible to find the exercises/answers on github, so anyone can complete the challenge on their own.
Earlier quoted context omitted.
This isn't about me or what workflow I can learn. It's really about the entry point for beginners contributing to operating systems in general and making it accessible for them. Not just Linux. On that matter, the barrier for being a long term Linux contributor is still very high and this is from the perspective of outsiders in general. So unless you're working at a company that does professional Linux development wi…
And why should beginners be contributing to the bloody kernel? Why should kernel devs (paid by companies) spend resources on making it easy for beginners? Here is the thing: kernel development in the most widely used production one is not a trivial thing. It is like pretending that architecture students should be helped to go work on the next biggest skyscraper as their first project and spend the time of actual arch…
Technically, anyone can contribute to the Linux kernel due to its open-source nature given that their patches are reviewed by the maintainers and it is then accepted.
> Why should kernel devs (paid by companies) spend resources on making it easy for beginners?
Not only I didn't say that, but you do realise that there are companies that exist who both contribute to the Linux kernel and offer training for a one time fee as an introduction into kernel development? Given the beginner meets the experience pre-requisites: Bootlin, BayLibre and several others have professional kernel contributors that do this.
> If you want people to get into kernel development, there are kernels wrote specifically for teaching purposes.
Read all my posts again. I go beyond just 'kernels' and named other complete OSes to get OS development and kernel experience from before joining a company specialising in Linux development. I said in the last post that '...the starting path is certainly not Linux.', it seems you certainly didn't read that.
Every professional Linux kernel developer started as a beginner somewhere and certainly wasn't born an expert. Some beginners were university students who either joined Linux companies by participating in programs like Google Summer of Code or took a paid Linux kernel training course by a company specialising in kernel development. You will notice that your last comment is in agreement with my whole argument.
Earlier quoted context omitted.
> Sending patches is as easy as sending one in GitHub or any other web-based system. Its still prehistoric in projects like the Linux Kernel, from a beginners point of view compared to GitHub, Gerrit or GitLab, which most of the active contributors are already working at large companies who's work requires contributing to it, thus already have invested in time and money learning the contribution process. To look at t…
Here's the thing. Take GitHub, and boil it down, and it's a mish mash of version control, diff, and patch, all plastered over with a shiny HTTP veneer. Diff/patch, git, and email alone are the basic tools you need . Even before VCS was a really big thing, that is how software changes were propagated around. There is nothing wrong with sticking with the basics. In fact, I flat out refuse to tell newbies that they shou…
There will always be those who don't like using the mailing lists for back and forth reviews and the same goes for GitHub (I use both anyway and have a self-hosted community GitLab and cgit). This isn't about me, its about attracting potential contributors to the Linux kernel in the long term.
If I were tasked to attract as many beginners/students to go this path, It won't be to start with the Linux kernel or the LKML mailing lists (that will put them off). It would ultimately be other beginner-friendly similar projects like SerenityOS, HaikuOS or some of the BSDs even, etc so they can get some experience. Then their mental model is used to the Git flow so they can transition to using bare Git commands and can go into a technical discussion involving anything about kernel internals.
Since Linux doesn't need to worry about attracting new outsider contributors due to commercial contributors doing most of the work, little needs to change. Which is why from the very start I much rather recommend beginners to start with other OSes and transition later to Linux internals.
Earlier quoted context omitted.
Well, it depends on whether or not "4-5 years in related experience" means systems programming or if it means making single-page webapps.
That's less than somebody with 0 years experience in FAANG will make. I wouldn't expect kernel developers to get paid much differently than non-kernel developers at a similar level.
Earlier quoted context omitted.
Well, it depends on whether or not "4-5 years in related experience" means systems programming or if it means making single-page webapps.
What if it's systems programming or HW design?
Started getting into kernel stuff for work. Does anyone have a good idea what kind of market demand there is for kernel devs or similar skill sets? Being new to this I absolutely love it, but have no idea. The resources shared by everyone here are so helpful! I’ve been muddling through by reading the docs, source code, and various messages on the mailing list and... it’s been a little painful.
Obviously, RedHat, SuSe Canonical, Microsoft, Apple, AMD, Intel, firmware and embedded companies will always need kernel people. However, the demand has really gone down and it is no more considered "elite" team within companies. Jobs are still there but obviously teams lean towards hiring experts and veterans of kernel instead of new comers. Moreover, once you get over simple char driver and few lines of patch type stuff, kernel development is extremely complex and hard. You wont get much support either as very likely your problem will be unique to your company's hardware. So, my take - learn and do kernel stuff on side but avoid getting into it full-time unless you are really passionate about it.