Slashdot Mirror
Aging Linux Kernel Community Is Looking For Younger Participants
Lemeowski writes "Time has been good to Linux and the kernel community, with the level of participation and volume of activity reaching unprecedented levels. But as core Linux kernel developers grow older, there's a very real concern about ensuring younger generations are getting involved. In this post, Open Access supporter Luis Ibanez shares some exciting stats about recent releases of the Linux kernel, but also warns that 'Maintaining the vitality of this large community does not happen spontaneously. On the contrary, it requires dedication and attention by community members on how to bring new contributors on board, and how to train them and integrate them alongside the well-established developers.'"
I'm part of one of these younger generations, and I'm honestly not interested in getting involved because I've seen how much of a raging asshole Linuz can be. He's a great maintainer, but he could be honest and give constructive criticism in less condescending ways. I'm not as experienced as he is, but that doesn't give him the right to be a complete dick in public theater.
Really don't worry. It is commercial enough and if the community just winds down, the companies will just staff the kernel developer ranks,
Get on my Lawn!
---
His controverse ideas will be loved by the majority of the linux tea party crowd :)
Benies? Dental? Vaction days? Sick days? Comp time or overtime? Weekends off? All national holidays?
This semester, I am taking OS course at UMBC. ......there should be one, centralized place with all the useful materials for the beginners + it should be constantly updated.
Course is easy, material is easy. Hard part - figuring out how the fuck you should write Linux Kernel code.
Why there are no good tutorials that on how to write basic kernel code, good guides on its structure (many book sold on Amazon are outdated)
Perhaps a campus tour where the senior kernel devs can personally tell prospective developers that they are retarded and kick them in the balls.
They are too busy working 80 hour weeks to make 60k a year.
The older guys who cant get a job are bashing out the code for the kernel. For resume cred.
It seems like most young programmers are way more interested in developing mobile-apps than in getting yelled at, cursed at, and described as being in compromising situations involving Microsoft.
I know I've mentioned this before, but you need to consider the possibility that your software might be done.
Take TeX for example. The last stable release is 5 years old. It's done.
At some point even the OS kernel will switch from "active development" to "something people study". We studied the circuit diagrams for radio receivers, memory circuits, and even more complicated things like 8-bit ALUs. They're done. We weren't developing that stuff in school. We were just understanding it.
The Linux kernel will end up in a text book some day. People will want to understand it. Nobody will want to develop it. That's a good thing. It means that this phase of technology is approaching the done phase.
What's the next phase? If you're young that's where you should be looking.
*assess. Bazinga.
It is just too damn big, hard and complex. Why would I want to learn the ins and outs of such a large codebase unless somebody is paying me to?
It is not like the old days when you could pick up a "... in a nutshell" book, start hacking up a driver, then get it accepted into the kernel. I don't want a three year unpaid intership while I get up to speed and gain respect in the comunity.
I'll spend my time working on my project on either a microcontroller (AVR, PIC...) or a bare-metal build on ARM.
Why release a simple system, when you can bloat it with a zillion tweaks of dubious value and then charge money to keep the whole mess working?
I don't think it's really as malicious as that. The larger problem is that everyone has a slightly different definition of what makes a simple, stripped down system. You only want the features you want, I only want the features that I want. You want a rock-solid server; I want a responsive and feature-rich desktop system; my brother just wants to play video games. You can't do it all without a little bit of complexity.
And look at what happens when they try. Someone proposes a new window compositing system that will make development easier and performance more responsive, and people get all bent out of shape because it breaks the X11 spec.
Microsoft is a whole other ball of wax. Chronic mismanagement, perverse incentives to sabotage any product which might cannibalize the Windows/Office products, and an attempt to maintain backwards compatibility as much as possible, going back to DOS systems from a quarter century ago.
In which case, *BSD is the answer to your prayers. You only get the featues you actually ask for, and once you have got them, they stay got!
Sent from my ASR33 using ASCII
I'd have to learn a code base developed by near-religious zealots, written in a language 20 years beyond chic only to be treated like a small minded idiot when I make mistakes? I've quit *well paying* development gigs because they met only one of those criteria. There's no way I'd go through that for free. Not for all the resume fodder on Earth.
they just want to kick you off their lawn
Politics is Treachery, Religion is Brainwashing
See subject line.
And maybe they go for the ka-ching because they have bills to pay, little savings to live off, and are trying to establish themselves so that they can continue that bill-paying thing. Don't be so bloody condescending.
I read TFA and all I got was this lousy cookie
The Linux kernel has served us reasonably well, but perhaps it's time for a new generation to create a new generation of kernel.
Hurd?
You never know what is enough unless you know what is more than enough. - Blake
Well, to be truthful it's a bulk of modules. The main kernel isn't any more bloated than any other Unix operating system with safeguards and security code within it.
-- This space for lease, low setup fee, inquire within!
Yeah, I understand that Hurd is going to be big and professional, unlike Linux.
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
If they get a lot of younger kernel devs, do we stand a chance of seeing the kernel equivalent of Unity?
If you want to attract new people, then you will have to bite the bullet and switch to a language that does RAII or a similar predictable resource management technique. Nobody in his right mind will write those mind-numbing goto constructs, when the compiler can do this. It doesn't have to be C++, it could be some modern form of C with classes or D.
There is a completely irrational hatred and fear of C++ among C kernel hackers. It's so steeped in the culture I'm not sure it can change (though a flux of young people would help). The funny thing is, when I've spent enough time with veteran kernel hackers to show exactly how RAII would work in their code, they were accepting that it actually works and would make life easier, but were still unwilling to change.
I suspect a big part of it is simply that so much of your day-to-day work habits as a good kernel guy get invalidated (because made unnecessary) that it feels like starting over.
It's not at all just RAII, BTW. There are times when "placement new" (and overloading the new operator) and where templates could massively clean up code by moving common stuff into the compiler.
Socialism: a lie told by totalitarians and believed by fools.
Feature-rich and stripped down are opposites. You want features to be available to you on a whim, learn to install new software.
You are missing the point. A stripped down system can still have a feature rich kernel. If I want a feature rich desktop then I need a kernel that has features that enable the sort of high performance UX I need.
Right down to a scheduler that's friendly to interactive user processes. But maybe that scheduler's not as optimal for what you were doing with your server, so now we want a tunable scheduler that can be adjusted towards either.
And the complexity begins its lift off.
I'm no kernel code developer, but I'm a systems engineer with light C/C++ experience and that is the reason I stopped contributing to the Gentoo community as well.
While they don't parallel in many ways, the team thought process was kind of the same.
I created full documentation on logical volume management installation with raid setup and so forth during Gentoo installation from scratch and it amounted to them saying to learn their documentation coding language and put it into that. I had other things to do aside from learning a language (some odd hybrid SGML that wasn't well documented) that I'd only use for that purpose.
I used Gentoo for a bit after that but it got to the point of not compiling cleanly due to dependency issues which told me the package management system was suffering the same issues as the documentation more than likely. Haven't really used Gentoo since 2005 for those reasons.
-- This space for lease, low setup fee, inquire within!
There is also the fact that there is an attitude change. The "stone soup" of days past is gone, with only the old guard in place. The younger people want to hear the ka-ching sound when writing code, not the fact that they wrote something to scratch an itch.
Being a skilled Linux kernel hacker is a great career move, though. I routinely get interviewers contacting me for top-tier Linux kernel architect jobs when there's barely a suggestion in my resume that I could actually do that work. Demand far outstrips supply there, even compared to other senior positions.
Socialism: a lie told by totalitarians and believed by fools.
It doesn't have to be C++
How wrong can one be? I *might* give you C (but with classes is really just C++), but why would you do that? C++ has its issues, but as a language to write a kernel in I'll take the issues and get the predictable performance in return. You simply cannot do garbage collection in a kernel and get predictable performance for interrupt routines, context switching, signal delivery and the like. C and C++ are very common Kernel languages and for very good reason, pointers. Folks hate them, misuse them, cast them, and bad mouth them all the time, but they are *fast*, flexible and a great way to shoot yourself in the foot when you don't pay attention.
I suppose there is room for improving parts of the kernel by dropping into assembly, but I seriously doubt it will be worth the effort to do much of that. Certainly you'd not do the whole thing. Besides, C++ compilers are really very good at optimizing things anyway, so you'd not get much gain overall.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
The last thing I would want is a clone of the Windows UI. If I wanted Windows, I'd know where to get it.
The Tao of math: The numbers you can count are not the real numbers.
Really? My impression is that he very occasionally dishes out a ration of vitriol on one of the "upper management" who has insisted on doing something against the publicly established guidelines, usually despite repeated applications of more polite dissuasion. Of course some of the more polite stuff can still seem aggressive, but there's only so many ways you can say "you are wrong and your project will not be incorporated / your attempt to shift the blame will not be tolerated" while avoiding misunderstandings across cultural boundaries.
Which is ruder? To call someone out publicly, or try to dissuade them politely and let them dedicate hundreds or thousands of hours of work to a doomed project because they thought you meant "I need to be convinced by a working example". In his position I'm sure he's run up against plenty of those.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Perhaps a major part, or a major branch (experimental revisited?) needs to be handed over to the control of young blood. It'd be difficult for the old guard... young guys take risks and make more mistakes, but they bring energy and ideas. In any case an area under the control of a new generation MUST happen for a young Linux subculture to further develop, and considering the importance of community as a motivation this is overdue. The size, momentum and commercial interest in Linux will could make this less than straightforward.
The Linux kernel has served us reasonably well, but perhaps it's time for a new generation to create a new generation of kernel.
"It works great! Throw it out and start again!" Your idea is bad, and you should feel bad.
His idea is pretty much like the idea that Linus had many years ago.
You're pulling a Linus - but without the creds.
The Linux kernel has served us reasonably well, but perhaps it's time for a new generation to create a new generation of kernel.
Maybe something with a microkernel architecture rather than a monolithic kernel? :-)
And thus you prove the GP's point.
The problems with the Linux Kernel itself are fundamental and unfixable: too big, at a million lines, and not designed from the beginning for minimum trust of all the many components ... all manner of malware has been written, some of which also appears to accomplish useful work, or corrupts things that do useful work, and it is time for a system that intrinsically distrusts any programs or drivers it is running to do the right things, and ensures that the system owner can retain control.
So Tanenbaum was correct. Monolithic kernels are the past, microkernels are the future. :-)
The younger people want to hear the ka-ching sound when writing code, not the fact that they wrote something to scratch an itch.
Right, back in the 90's nobody even thought of making a buck off of writing code.
Don't get me wrong, I'd have hard time living without The Linux Foundation's products, but when this year I wanted to work for The Linux Foundation in Google Summer of Code, I gave up after reading their proposals. I wanted to learn some kernel development stuff and couldn't find a single suggestion related to that. Instead, there were some higher-level projects like OpenPrinting, which I personally find totally uninteresting.
I'm young (23) and I have a degree in computer science. My favorite parts of that degree focused on systems programming and operating system design. I would love to get involved in kernel or OS development if I could find a good starting point, but so far I haven't really found a good place to start. There's info out there, but there's no natural starting point that I can find. I really just don't know where to begin, so I never do (well, recently there are other reasons, like my job, but that's why I didn't get involved as soon as I was done with my degree).
I'm actually managing an OS course for graduate students, and it's heavily based on linux (userspace and kernelspace). We do a few exercices (like writing a kernel module that computes averages), but nothing fancy. I've always been looking to propose them some projects related to kernel dev, but as I'm not a kernel hacker myself, I have clearly no idea of what seems reasonable.
So here's the deal: If you are involved on some subsystem of the linux kernel and you have something you want to get coded that can be a first experience with kernel dev, and that can be done under about 100 hours (the length of a typical project), you contact me. I'll do as much as possible as a first step filtering so that you won't get spamed. It's a win-win situation: I have great projects for my students, you get free work. For this year, it's a bit short, because projects are from September until January, but next year is ok.
Video of some good progressive thrash music
Really don't worry. It is commercial enough and if the community just winds down, the companies will just staff the kernel developer ranks.
Which companies exactly? --- and who gets to make the final decisions about the evolution of the kernel and Linux as a whole?
When Linux was first released, it was relatively easy to break into the IT field and get directly into programming with limited experience and resources. The fact that the Linux kernel was initially created by a 15 year old kid on a home computer says much about that. My saying so doesn't lessen Linus Torvald's genius in any way, but it does underscore how those opportunities to create haven't been extended to future 15 year olds in the same manner.
Or anyone of working age. When was the last time a company hired junior admins and other flunkies specifically for the purpose of training them up to a competent level of expertise? That was common in the 90s, and is almost non-existent 20 years later. The last two companies I've worked for flat out refuse to hire junior staff and train them. Many companies refuse to future proof their IT (ops and dev) staffing in any way. This has led to a huge gap in expertise.
The final issue that was birthed out of refusing to hire inexperienced staff is all of the certification programs that arose as a result of such parsimony. Am I the only one who thinks that being able to turn on a few services *doesn't* make someone a systems administrator? I'd be more concerned about their ability to write and update their own changes to services, and to the man pages, and submitting complete work back to the relevant project- but THAT isn't (generally) taught in the cert programs, even though that will make someone a better administrator and/or developer. This just weakens expectations in the field, and severely limits a self-selected candidate pool of future kernel programmers.
It's kinda like Star Trek. Live on a starship that seems like it's constantly under attack by hostile forces, put up with with condescending superior officers and any time you think you have something to contribute, you're told to shut up. The best part? You don't even get paid. While watching the show, I've often thought to myself "Why would anyone willingly subject themselves to this crap, when they could be back on Earth doing anything they can imagine inside a holodeck?"
Star Trek analogy aside, I can see how it might not be very appealing to learn how things work under the hood, when computing has basically been distilled down to a point-and-click world of "buy apps from the app store, run apps". As for those who do have the interest and aptitude for programming, perhaps they'd rather use their skills to put a few coins in their pocket? In this economy, can you really blame them?
---
DRM is like antifreeze, to the MPAA/RIAA it's sweet, to the consumers it's poison.
In fairness, look at it from Linus' perspective.
He's been running this project for DECADES and it is successful, stable and very valuable. He's made many mistakes, paid the price for them and then corrected them. He is also heavily invested in this project both privately and professionally.
Then comes the flock of green horn newbies, with the ink still wet on their diplomas (if they graduated in the first place) who make predictable stupid mistakes over and over. The SAME predictable and stupid mistakes that have been made for decades worth of newbies. Now and then one of these newbies who is not content to let his idea die so he presses the idea getting some attention perhaps. If it reaches high enough to get Linus' attention and he recognizes it as a stupid previously dismissed idea, expect him to say so without mincing words or sparing feelings. He's been down this road before and he is decidedly NOT one prone to teach. He is merely ending what he knows is a useless debate, because he is right. More times than not, he really *is* right. I wish he was a bit more diplomatic at times, but there comes a point where it's a waste of everybody's time to argue. Linus is all about *not* wasting time. (Which is why he started "GIT" by the way) I figure that he puts on the narcissist persona to save time and effort, he's just cutting to the chase, the last part of the chase, to save time.
The way to get though this as a newbie is to try your best, be respectful when rejected and don't try to push issues. Go out of your way to learn what's transpired before, research on you own, ask when you cannot find information and above all respect what the long beards have to say. That and NEVER participate a mutiny unless you are prepared to see the thing through and never work on the project again.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
No, no, no.. He was saying HE could do it better.
Which is still a bad idea, and HE should feel bad..
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
But the code should be enough documentation right?
You mean you want *comments* in the code too? Newbies...
Sarcasm aside... You newbies learn from this. DOCUMENT your projects. Do it FIRST because it saves you a lot of time when you are developing, and you will never have time to do it later.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
See OP's step 1.
Well clearly you do not understand what the word "environment" means.
If someone makes a sexist, derogatory joke in the weekly programming meeting and someone is offended and complains, it's not a defense to say "well it was only one joke, in one meeting, from one person."
The problem is not the one joke. The problem is that the environment was conducive, accepting, and tolerant of the joke. Linus's abusive treatment of others is not only tolerated, but accepted, excused, and justified, both there and on other communities (like Slashdot, right now...) Because he's in a leadership position, it sets the example and tone for how others are treated...
The response to people saying "I'm not comfortable contributing" is not "stop being a baby." If it is, you don't actually care about getting people to contribute.
Please help metamoderate.
I think the tl;dr on this is Its ok that he is an asshole to people because it works for him. Awesome.
In other words, Linux is dying...
In Soviet Washington the swamp drains you.
There, is that specific enough for you?
You have freedom to associate or not associate with a group. You have no right not to be offended. And you have no right to expect free adults to confirm to your whiny, politically correct, victimhood critical race theory politics.
I suppose it does work for him. Not my choice of tactics, but understandable if you think about it.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
I've wondered about that myself, however there would be grave ramifications of any decision coming out of planning. For example, should the kernel be a true microkernel with everything in a module, even security, location of drivers, who owns what, and so on.
Just planning a new kernel would take man-years because there are just so many issues. Just security threats alone are too great for any one person. It would probably take the NSA, GCHQ, China's MSS, FSB, ISI, and any other country's intel division's knowledge pooled together in order to hammer out something that is resistant to threats from the ground up.
Of course, then comes the userland. Too strange an environment, and people won't adopt it. Linux had the advantage of being able to get stuff ported to it from SVR4 based boxes as well as BSD stuff.
It would be nice to just throw everything out the window and go with a Harvard architecture, or perhaps one with well demarcated security domains. However, the hard part would be getting people to bother writing apps for it.
Wouldn't be impossible, but it would be an uphill battle.
Can you do better? Please feel free.
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
When the project started it was easier to get involved because the code base was smaller and most people were contributing in their spare time, a few hours here and there on the weekend, while they did their real jobs that brought in money for them to live. Anybody with coding experience will tell you it's much easier to join a project where the code base is fresh rather than work on something that 2 decades worth of ideas implemented by someone who holds all the decisions leading up to why a certain subsystem is written the way it is in their head. It's that knowledge about why a certain piece of code is written the way it is, that you only glean by actually writing the code, making the mistake and learning from it. Expecting a younger person to be able to automagically have this same knowledge when they join the project is short-sighted. The other issue is that Linux may not have started as a commercially driven project, but it is a commercially driven one now. Someone in their spare time wanting to contribute to the kernel can't compete with someone being paid by Oracle to write a file system. They've got better things to do. The solution is to make it worthwhile for younger people to start working on the kernel, because at the moment the barrier for entry is high because commercial interests make it hard for young ones to learn the kernel when all the low hanging fruit is reaped by those paid to work on it, and knowledge required now is higher than it was 20 years ago.
Yup, take 20+ years of code and switch to C++, D, or Objective-C.
Brilliant!
C is perfect for kernel work. It is a fairly terse and simple language with very little cruft.
C++ is a minefield. the Linux style guide would explode in size because it would have to ban much of the languages construct, lest the kernel turn into a rotten mess.
There is no business or technical case to switch languages in the Linux kernel.
He's said he would have probably contributed to BSD if they hadn't been tied up in court with AT&T over copyright issues at the time.
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
That reminds me of the drama with Con Kolivas and his Staircase Deadline scheduler. There was some noises about pluggable schedulers, but apparently Linus wanted a one size fits all -approach. Dunno if that's true.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
I've worked on the kernel (and other low level stuff) professionally for ~10 years. I've had code submitted into the kernel. I've interacted with Linus directly, I've met him in person, etc.
Yes, on occasion he flies off the handle. It doesn't happen often, and when it does it's mostly at things that would drive many people nuts. I think he could deal with it a bit better sometimes, but most of the time it's not a big deal.
Generally when people get flamed it's not a new contributor, and it's for things that they've done wrong multiple times.
So for new people looking to contribute, go ahead. It's fun, and the quality of the code that you'll see is generally pretty high.
The guides to the kernel on amazon are outdated, but any book is going to be outdated and the places where they're outdated are exactly the places that are seeing churn and so it would be hard to keep anything updated. What the books can do is give a general overview about how things were at one point.
That, combined with looking at the kernelnewbies site, reading lwn.net/kernel, and looking at the code will give you somewhere to start.
Linus was in his early 20s and in college when he created the first version of the kernel.
Actually, those opportunities exist for every kid with access to a PC.
If you want to talk about not extending opportunities, talk about devices like iPads that are displacing general purpose PCs. That is how you actively deny such opportunities.
Fire your management. It's the only way. That said, kernel developers are a distinctly different sort from the average "systems administrator." I did that in the late-90s, early 2000s as a summer job and quickly learned that it wasn't what I wanted to do.
It strikes me that the young and (self-professed) cool crowd are only interested in shiny buttons on cloud-hosted web services. Unless you can port the Linux kernel to Javascript...
Patent litigation: A doctrine of Mutually Assured Destruction... in which everyone seems willing to push the button
It's a little thing, but annoying: I do not want to subscribe to your mailing list! The last thing I want is to see my inbox fill with conversations I don't care about - email is for one-to-one conversations, not spam like a mailing list. Create an online forum already, this ain't the 90's any more. Push content is not cool; I'll read the posts when I want to read them, not when you decide to push them into my mailbox. With LKML the additional annoyance is the sheer volume of the thing, turning it into pure spam.
Frankly, the younger generation has very thin skins. When you post anything online, be it an OSS project or a simple forum post, people will hate you. Some will hate you for good reasons, others will hate you for stupid reasons, and everyone else will hate you for no reason at all. Whenever I search for my project's name, I pretty much expect it these days. Gee, my project is not 100% C++ standard compliant. Gee, my project has a class with an unusual requirement that people consider unprintably unreasonable. Gee, my project is useless and what an arrogant asshole I am for working on it.
After a while, you stop caring. You have to, or you'll never get any work done. Without thick skin, you can't do anything online, because otherwise there are just so many jerks out there, they will drive you insane. Yes, you can complain about it. If you do, you'll get flamed. No, you can't change how people behave, it's just their nature. Adjust your spam filters and asbestos suits and move on. Getting "offended" is the most idiotic thing in the world; it accomplishes nothing and hurts only you. So stop it already!
Right, that 25 year old fad. I don't think that word means what you think it means.
Socialism: a lie told by totalitarians and believed by fools.
I'm part of one of these younger generations, and I'm honestly not interested in getting involved because I've seen how much of a raging asshole Linuz can be. He's a great maintainer, but he could be honest and give constructive criticism in less condescending ways. I'm not as experienced as he is, but that doesn't give him the right to be a complete dick in public theater.
I've been in the Linux scene very early, and I've watched contributors come and go
The one thing that I've observed is that it's kinda generation gap
The older crop (age 40+) were the ones who like to take on challenges - and even when they have been shouted down, they still come back again and again, with better and better code implementation, to prove others wrong
The younger crop (age 35 or younger), on the other hand, can't stand people criticizing their code
They seem to think that since it's their code and they have contributed it FREE OF CHARGE others must be happy to accept them as is
What has transpired in the Linux Kernel scene reflects what is going on in the society at large, as well
The young uns can't stand criticism because they think they are too good to be criticized
Those old farts, on the other hand, don't mind criticism, and in fact, many actually welcome criticisms, for criticism only makes them tougher
I know, it's too much a generalization - as there are exceptions - but at least that's from my own observation
Muchas Gracias, Señor Edward Snowden !
Why? The article asserts that the Linux kernel project has a problem attracting new developers. And a lot of comments here assert that this problem is due to Linus' personality traits. If this is indeed so, it's up to him to change or watch his accomplishments go down in flames.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
Do any of these need to allocate memory on the heap? Can they (locking issues etc)? Garbage collection seems like a red herring, since it can't make anything unpredictable that already wasn't.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
Web2.0 and HTML5 support.
350 built in frameworks.
Modules written in Ruby, Python and Javascript.
An appstore.
A touch screen interface.
Twitter, facebook, reddit etc. etc. integration.
Seriously, we need to start tying down people by their beards soon.
"that you malign"
I didn't malign anybody. I think we're done here.
I read TFA and all I got was this lousy cookie
Perhaps it's time to learn to fly using only the power of our minds.
These type of suggestions seem to be easy to make...
"Science can amuse and fascinate us all, but it is engineering that changes the world. " - Asimov.
I seriously hope YOU are a troll... Otherwise, faith in humanity decreased.
"Science can amuse and fascinate us all, but it is engineering that changes the world. " - Asimov.
Nope. Anyone with two brain cells know of the huge amount of damage those two trolls have caused. The future is gone for Linux since newer people who would be interested, is not due to those ... idiots to say the least.
Not everybody is dumb enough to enjoy abuse.
Templates also have a tendency to massively explode compilation problems by returning utterly incomprehensible error messages. Not to mention, the syntax itself is not what I'd call "pretty".
This seems pointless though. You don't deploy source code. You deploy binaries. But separating it out into fragments hardly solves anything - what happens when Bundle A's new patch needs to call some features in Bundle B?
Apparently you weren't aware of the fact that they are the founders and primary intitial code contributors for the Linux and GNU projects respectively. Neither project would even exist without them. The reason you're not even going to be taken seriously by people who agree with the principle of your statement is that what you just said is akin to saying something like "Christianity would have been so much better if Jesus had never gotten involved" or "orbital trajectories would be so much easier to establish if it weren't for all the gravity."
I'm just stating this for the benefit of the rest of the crowd. I'm pretty sure you're the one trolling here too. Nobody could be this clueless and opinionated.
The fact that the Linux kernel was initially created by a 15 year old kid on a home computer says much about that.
Linus Torvalds was born in 1969. The Linux Kernel project began in 1991. He was not 15.
Apparently, I am aware of that fact. Apparently, your assumptions are incorrect. And apparently, you misread what I posted. Creating their respective works do not make them any less abusive. Opinionated? Your perspective, of course. Clueless. The only person proven wrong was you. As for trolling ... Try reading the post you supposedly replied to.
Which part of "predictable resource management" did you not understand?
Which part of non-language-defined resource management flexibility don't you grasp? Linux IS a memory manager. You don't want RAII and other paridigms as shit to work around. It's C because C is close to the metal without being platform dependent. RAII? Are you serious? The kernel has pools of cartridges each conataining prefabed blocks of "objects" already initialized and ready to go prior to being needed. Fine, go create your mythical high level language that's specifically desigend for dynamic and static resource management. When you're done, it'll be the same as C.
My last few remaining microns of sympathy for Linux, evaporated not long ago when I read Lennart Poettering encouraging everyone around him, to throw POSIX under the bus. I'm aware that Linux developers have viewed the system's relationship with older UNIX, in roughly the same manner as a venereal disease since probably 2000; in a sense, it surprised me that it took that long for someone to actually come out and say it openly.
Linux has completely gone to shit; and not in the "yes it causes me to rage, but I'm still putting up with it," sense, but the "I now feel so much contempt and disgust for it that I've washed my hands, and can no longer be remotely bothered," sense.
Linux's developers these days, are a bunch of ivory tower elitists, who in reality have no idea what they are doing, but who have the attitude that everyone else using the system can just shut up and take what they are given, and if the rest of us don't like it, then that is just too damn bad. Lennart Poettering, again, is the main offender when it comes to this sort of thinking, but it has also always characterised the GNOME developers as well.
GNOME should have been recognised as a mess, and rewritten from scratch, before Canonical got hold of it. The problem there is that you have people who are using Microsoft Windows as their template, and so they think that making everything opaque and hard welded together, is somehow the "professional," way to do things. Graphical user interfaces don't *need* to be a bloated pile of shit; it's just that Windows is, and Linux people now are determined to copy Windows.
I've been learning about FORTH, recently; and about the idea of (in languages which are designed for it, at least) writing one function per file, and having said function consist of no more than 500 bytes each. FORTH was the product of an era in which programmers actually knew what they were doing; unlike today, when computer science graduates emerge from university with their heads densely packed full of bovine fecal matter, such as the idea that programs should be as long and complex as possible, rather than short and simple.
But there's no point. There's no point arguing with any of you. You'll just mod me down, and tell me that Ubuntu is great, and GNOME is superb, and Poettering is a genius. So go ahead. Have fun.
I don't see how this is a problem. You can still do this if your language supports RAII.
While I agree with your arguments, I guess the real question is: where do you prefer your complexity to be? With C, the complexity is in the code, and very obvious. With C++, complexity can be "conceptualized", and delegated to the compiler. After using (and abusing) both C and C++ (a turbulent relationship with a lot of love and hate), my gut feeling is that C is probably better for system programming than C++.
The reasons have been discussed so many times by people far more qualified than me. My personal reasons:
1. The C++ language is still a moving target. You should be re-writing old code if you want to keep it conceptually clean, using the latest C++ standard.
2. For some problems, I prefer to have the complexity right in front of my eyes. In C, the code does all the talking (although it does speak a horrendous dialect). While shifting the complexity to the language is very useful, it can create subtle problems with interpretation by the human reader. I still think that C++ cannot be fully appreciated or used by people who would not be able to solve the same problems in C.
Templates also have a tendency to massively explode compilation problems by returning utterly incomprehensible error messages. Not to mention, the syntax itself is not what I'd call "pretty".
This is an amusing comment.
It does, of course, have a grain of truth. With exceptionally writing of templates and heavy use, the code size can increase a lot. The error messages are ugly (not incomprehensible---they're just a stack trace). The syntax for -complex- stuff is not nice.
However, the alternative in this case is c with Macros, which is worse on almost every count.
SJW n. One who posts facts.
You should be re-writing old code if you want to keep it conceptually clean, using the latest C++ standard.
What? No. One reason the C++ committee takes so bloody long is they put in astonishing effort to avoid breaking, or worse silently changing the meaning of, old code. In this regard, C++ is very, very stable.
2. For some problems, I prefer to have the complexity right in front of my eyes. In C, the code does all the talking
No you don't and no it doesn't. C abstracts plenty of stuff. Either through outright abstractions, such as implementing division and floating point for you on many platforms, dealing with stacks and function calls etc or via functions. Do you really know the inner workings of every function call?
If you really practiced what you preach, you'd write in ASM with on reference to external functions.
I still think that C++ cannot be fully appreciated or used by people who would not be able to solve the same problems in C.
Well, that's quite possibly true. I was a long time C hacker before moving to C++. I generally understand C++ in terms of what it's doing under the hood. There are few mysteries. Much of what it does is the same sort of algorithmic code as C except it's vastly easier to write because it automates away the tedium.
SJW n. One who posts facts.
Step 1: Make a very public scene whenever someone does something slightly dumb. Be sure to use horrible names and as much profanity as possible.
Well my reply was not "very public" (didn't make a /. story, anyway), and OPs claim wasn't "slightly" dumb. Noone was called "horrible names" and the amount of profanity could double and it would still be harmless.
;)
Other than that, yeah, totally applies
CLI paste? paste.pr0.tips!
When you're done, it'll be the same as C.
Pretty much, but there's a few things it would be nice to add to C in order to make the code less error prone to write.
For example when yo create a new struct, in many cases you want it to be set up a specific way. I think I'd add "creators" to C so that whenever a struct is created I could automate the call to the initialize function. I might do the same for uncreators too so I can zero out some fileds etc when it goes out of scope.
Sometimes I forget that some parts of a struct are meant ot be opaque implementation details and I don't want to have to chase non inlined functions through a void pointer (for efficiency). It would be useful to tag certain members of a struct as "invisible". That would be handy.
Aggregation works and you can cast a pointer to the struct to a pointer to the first member (handy). I might make it so that you could use a tag which allowed the same shorthand in other places too.
I like having function pointers in my structs. The thing is that this is heavy on the dcache since that data is duplicated in every struct. I'd like to have a single pointer to a single table of functions, but it's really ugly. Perhaps I could get the compiler to help make some of that less hideous.
And oh yeah, macros. Nice, handy system for automating things. Not really integrated with the language and easy to make type errors. Definitely needs fixing.
That would be a really handy language. Basicaly all the power of C, but with some handy extensions to automate stuff everyone does anyway. And the best thing is that those things just automate common tasks so they won't get in the way if I need to so eomthing else.
Now I just need to come up with a natty name. How about C+1 to show that's it's like C but with a bunch of useful stuff added on.
SJW n. One who posts facts.
You should be re-writing old code if you want to keep it conceptually clean, using the latest C++ standard.
What? No. One reason the C++ committee takes so bloody long is they put in astonishing effort to avoid breaking, or worse silently changing the meaning of, old code. In this regard, C++ is very, very stable.
You misunderstood me. The fact is, code is read by humans. Say I am a young programmer that starts working on a C++ project that has been growing for 15 years. How many different styles am I going to encounter? Do I need to understand them all to read the code? How long until I have seen it all and can call myself proficient? At what point do I re-write old code that I have to modify? How do I decide the re-write is necessary? (I know the same is true for C, but to a much lesser extent.)
2. For some problems, I prefer to have the complexity right in front of my eyes. In C, the code does all the talking
No you don't and no it doesn't. C abstracts plenty of stuff. Either through outright abstractions, such as implementing division and floating point for you on many platforms, dealing with stacks and function calls etc or via functions. Do you really know the inner workings of every function call?
If you really practiced what you preach, you'd write in ASM with on reference to external functions.
:) Don't pretend you don't know what I'm talking about. There is a balance between "explicit" and "abstract", of course. It just happens that C strikes the right balance for a job like systems programming, in my opinion.
I still think that C++ cannot be fully appreciated or used by people who would not be able to solve the same problems in C.
Well, that's quite possibly true. I was a long time C hacker before moving to C++. I generally understand C++ in terms of what it's doing under the hood. There are few mysteries. Much of what it does is the same sort of algorithmic code as C except it's vastly easier to write because it automates away the tedium.
Which is why I also think that C++ hate is generally misguided, and a knee-jerk reaction of die-hards.
Oh, so you're then suggesting if they were just polite and unobtrusive quiet little nerds easily swept under the rug by big players who deserve the glory more than there would even be a FOSS movement today of this caliber, or even at all? I assure you I get your point entirely, but still completely disagree with you. How does that make you feel?
You misunderstood me. The fact is, code is read by humans. Say I am a young programmer that starts working on a C++ project that has been growing for 15 years. How many different styles am I going to encounter? Do I need to understand them all to read the code? How long until I have seen it all and can call myself proficient? At what point do I re-write old code that I have to modify? How do I decide the re-write is necessary? (I know the same is true for C, but to a much lesser extent.)
That's a fair point, which applies to any codebase with a history. Do you keep the old working code in the outdated style or rewrite to move to the newer, better styles available. Ususllay projects err on the side of "no" on the grounds that the code works so rewriting it can only serve to introduce bugs.
They are kind of doing it for gcc to move to C++. All new code has to be written in compliant, exception safe C++. Frustratingly for them, they won't yield benefits for ages because exceptions are forbidden until all the code has been made exception safe.
Generally huge rewrite projects run into problems. GCC are doing it very incermentally, so it seems to be working.
[Other points]
Fair enough.
SJW n. One who posts facts.
You confuse me with someone who thinks Linus' actions are justified. I don't. Where I try to understand *why* he does this, it doesn't mean I agree with the tactics he uses.
So Why look at this from his perspective? In order to try and understand how best to deal with him. Life is full of people with personality ticks that are going to rub you the wrong way. Successfully dealing with difficult people will require self control and understanding of what motivates them and adapting your actions accordingly. It's how life works, or doesn't..
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
Your post does not make any sense. Do most people in the FOSS movement lack comprehension?
One of us does, that's for sure...
Exactly.
Case in point: Microsoft .net :-)
Murphy was an optimist
My takeaway from all this is that the kernel community and its developers is facing the same problems as Wikipedia and its editors, for about the same reasons.
The best way to deal with people who can't behave is to ask if you actually have to deal with them, and if the answer is "no", not do so. And, apparently, new developers are doing this very analysis, which then led to this article.
Life is full of nice, well-adjusted people. Why waste it dealing with someone who isn't? Let natural selection do it instead: Software projects that drive new people away die. Those that draw them in survive and grow. It's evolution in action.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
Choosing not to play is indeed a valid option. Choosing to put up with it can be rewarding though.
It's your call.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
No, see, the thing is, your feelings are supposed to be your responsibility, not the group's.
It is, at a minimum, the group's responsibility if they are community of VOLUNTEERS are trying to attract new members, to not be a bunch of assholes to each other.
Your extremely hostile, nasty, aggressive, ignorant, threatened response perfectly demonstrates the issues we're talking about. Also: stop narcissistically blaming everyone around you for how they react to the way you act towards them.
Please help metamoderate.
That's no surprise, my post wasn't a hypothetical, but drew on those real scheduler controversies.
The current CFS scheduler was inspired by Kolivas' work, and largely addressed desktop interactivity.
The CFS is quite a bit more complex, and slower than the previous scheduler which was generally deemed fine (and faster, therefore better) for non-interactive "servers", hence the controversy, and made it a natural example for the argument.
Pluggable or tunable schedulers would have been even more complicated than CFS. But even CFS represents an increase in kernel complexity primarily to satisfy one type of user.