What is Reddit's opinion of
Linux kernel?
From 3.5 billion Reddit comments
100 reviews of this app found across Reddit:
Here was the previous code of conflict:
The Linux kernel development effort is a very personal process compared to “traditional” ways of developing software. Your code and ideas behind it will be carefully reviewed, often resulting in critique and criticism. The review will almost always require improvements to the code before it can be included in the kernel. Know that this happens because everyone involved wants to see the best possible solution for the overall success of Linux. This development process has been proven to create the most robust operating system kernel ever, and we do not want to do anything to cause the quality of submission and eventual result to ever decrease.
If however, anyone feels personally abused, threatened, or otherwise uncomfortable due to this process, that is not acceptable. If so, please contact the Linux Foundation’s Technical Advisory Board at <>, or the individual members, and they will work to resolve the issue to the best of their ability. For more information on who is on the Technical Advisory Board and what their role is, please see:
http://www.linuxfoundation.org/projects/linux/tab
As a reviewer of code, please strive to keep things civil and focused on the technical issues involved. We are all humans, and frustrations can be high on both sides of the process. Try to keep in mind the immortal words of Bill and Ted, “Be excellent to each other.”
What was wrong with this one? How is the new one better?
Interestingly, Windows 10 Home only supports 128 GiB of RAM while Windows 10 Pro supports 2 TiB.
In comparison, Linux supports up to 128 TiB.
if you like that, you'll love man hier
edit
Seems people find this helpful.
This is supplied by the Linux man-pages (a side-project of the Linux kernel)
I think most distros install this by default, but if not it's almost certainly available in your package manager.
Their website is here (as a useful overview of what man-pages they provide)
https://www.kernel.org/doc/man-pages/
I personally find the stuff in section 7 invaluable.
I find it amazing that people keep forgetting that github is for-profit company.
Kernel is hosted at kernel.org, which actually is a company as well. Key difference being it is Public Benefit Corporation where github is regular LLC.
On the subject of modifying the CoC Linus used, note it's inspired by the more extreme Geekfeminism CoC:
https://geekfeminism.org/about/code-of-conduct
This one is worth reading to see what the future could have in store as more and more projects introduce these codes.
The Geekfeminism document states their Anti-Abuse Team will not act on complaints regarding: "‘Reverse’ -isms, including ‘reverse racism,’ ‘reverse sexism,’ and ‘cisphobia’ (because these things don’t exist)" and "Communicating in a ‘tone’ you don’t find congenial". So under their enhanced CoC, someone can repeatedly post messages full of screaming abuse or insults targeted at, for example, non-transexual people and that would be absolutely fine - and that's what the people pushing the concept of the CoC onto the open source world want.
For reference here is the old Code of Conflict which was previously present in the kernel since 2015 and is now removed:
https://www.kernel.org/doc/html/v4.10/process/code-of-conflict.html
"The answer to that is that if you need more than 3 levels of indentation, you’re screwed anyway, and should fix your program"
You're definitely onto something.
The patch also contains other people who used only their nicknames - mog422 and poma, yet the guide to submitting patches (section 1, subsection 12) clearly states you should >(...) just add a line saying > > Signed-off-by: Random J Developer <> > >using your real name (sorry, no pseudonyms or anonymous contributions.)
(emphasis mine)
Linux kernel coding style: "Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3."
God... Reading that link, I disagree with basically every one of Linus' style preferences.
Short version is the kernel uses swap space for paging and other general maintenance and well being activities. Without it, the kernel memory allocator will not be as efficient as it should be, leading to worse performance for certain operations in certain conditions.
Like /u/soupersauce says, about 2GB should be sufficient to handle this usecase, the only justification for larger for most users if you want to support hibernation, where you need your swap to equal your RAM so you have enough room to store your memory image.
The long answer is in the book of the kernel memory manager, written by Mel Gormen from SUSE - https://www.kernel.org/doc/gorman/pdf/understand.pdf
there are different kinds of suspend
> Connect the hdd to another machine, change something on it (root password etc).
you really don't want to change anything on it
https://www.kernel.org/doc/Documentation/power/swsusp.txt
- BIG FAT WARNING ********************************************************* *
- If you touch anything on disk between suspend and resume...
- ...kiss your data goodbye. *
- If you do resume from initrd after your filesystems are mounted...
- ...bye bye root partition.
- [this is actually same case as above] *
- If you have unsupported (*) devices using DMA, you may have some
- problems. If your disk driver does not support suspend... (IDE does),
- it may cause some problems, too. If you change kernel command line
- between suspend and resume, it may do something wrong. If you change
- your hardware while system is suspended... well, it was not good idea;
- but it will probably only crash. *
- (*) suspend/resume support is needed to make it safe. *
- If you have any filesystems on USB devices mounted before software suspend,
- they won't be accessible after resume and you may lose data, as though
- you have unplugged the USB devices with mounted filesystems on them;
- see the FAQ below for details. (This is not true for more traditional
- power states like "standby", which normally don't turn USB off.)
There was a merge in kernel 5.11 where system calls from Windows applications can be delegated to other handlers in user space. This was implemented specifically by Collabora (requested by Valve) for supporting anti-cheat software.
Edit: More info: https://www.kernel.org/doc/html/latest/admin-guide/syscall-user-dispatch.html
I prefer a good explanation of the concepts of Git more useful than shortcuts or cheatsheets. This one's particularly good: http://www.sbf5.com/~cduan/technical/git/
Once you've finished the above, you'll have a pretty good grasp of how Git works. After that you may check out the official Git User's manual to gain even more insight: https://www.kernel.org/pub/software/scm/git/docs/user-manual.html
The kernel has support for a few different binary formats.
On most systems you will only encounter two of them: ELF executables and #! scripts.
There are a few slightly more esoteric formats. The a.out format predates ELF, and has only been deprecated very recently. There is also a FLAT format used by uClinux.
Of particular note, there is also a "misc" binary format handier, which allows new formats to be registered by userspace. You could use this to run Windows PE executables via Wine, for instance.
I can understand your attitude, but that goes against the kernel coding style guidelines. Ultimately, when you have 3000 developers working on a codebase, it is more important that everybody is using the same style than it is what particular style they use.
You're not used to reading it, but kernel developers only look at C code styled like that. They know what to expect from if blocks. Fundamentally, that's what makes the code readable or not - "how much effort do I have to put into looking at it to not be tripped up by the formatting." Read enough kernel code and that cost drops to zero, and that's all that matters.
However. Lest we forget:
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail;
That's not to say "they had this bug because they didn't use curly braces" when really they had this bug because they didn't write unit tests or didn't use/care about static analysis.
But I think in Apple's case, where you're dealing with a copy-and-paste-happy codebase, requiring curly braces might have helped.
The kernel, just like any other software project has a coding style, and when collaborating it's much more important to stay consistent with the agreed upon style than to use your own
https://www.kernel.org/doc/html/v4.10/process/coding-style.html#placing-braces-and-spaces
Hybrid Sleep support - "hibernate" and suspend the system
Hybrid Sleep initially only writes hibernation image to SWAP space, it does not power off the machine, as a whole Suspend To Disk (S4) does, it rather Suspend To RAM (S3).
The benefit of this combination is pronto RESUME from S3, whilst in case of battery drained or interruptions in power supply of any kind, you ain't gonna lose your work.
Hybrid Sleep is the feature of the Linux kernel. To test it directly via cli: echo suspend > /sys/power/disk ; echo disk > /sys/power/state
However to make this feature work, both Suspend To RAM (S3) and Suspend To Disk (S4) must be provided by the hardware dmesg: ACPI: (supports ... S3 S4 ...) in working order.
Furthermore Suspend To Disk (S4) requires a relatively simple configuration an appendix to kernel command line: resume=<path to resume partition> i.e. directive to utilize particular SWAP space man 7 dracut.cmdline
Ref. https://www.kernel.org/doc/Documentation/power/swsusp.txt
Signed-off-by: Eric Koegel <>
3.4 is a LTS kernel version..the last update to up was only a few months ago according to kernel.org. So no, it's not a security risk...security patches are still backported to that kernel version. At the same time it's a highly tested version and known to be stable. Updating to anything newer would probably hurt stability a lot and be a major issue.
The 4.4 kernel series is another LTS kernel series by the way...but still far too new to be trust it for anything stable. In some years that series will probably be one you find in a lot devices.
The Linux community has been running fine for nearly 30 years. If you throw in a Code of Conduct it should mainly be about documenting existing best practices, tell newcomers what to expect and how to behave. The old Code of Conflict did that more or less.
The new Code of Conduct is the complete opposite. Not only does it fail to document how things are currently run, it opens up issues that never where a problem to begin with. Nobody in the Open Source world cared about race and gender and stuff like that. Everything operated essentially under "On the Internet, nobody knows you're a dog". Yet the new Code of Conduct makes race, religion and gender a centerpiece. It tries to actively divide people where there was no division before.
In essence the Code of Conduct is trying to enforce a law that wasn't reached by consensus of the community, but created by outsiders. It's job is to divide and destroy, not unify and diversity. It's job is to enforce groupthink, not the free exchange of ideas.
And if there is any doubt left, just read the The Post-Meritocracy Manifesto by the same author.
> Who would you go to? Linus?
Wikipedia lists kernel.org as the place where the project is hosted on git and they have a contact page - https://www.kernel.org/category/contact-us.html
There's also the Linux Foundation, if that doesn't work - https://www.linuxfoundation.org/en/about/contact/
This site tells people how to contribute - https://kernelnewbies.org/
While I understand what you mean, I've found 3 potential points of contact for this within a 10 minute Google search. I'm sure researchers could find more info as finding info should be their day-to-day.
For smaller FOSS projects I'd just open a ticket in the repo and see who responds.
Terminator runs off of linux kernel 4.1.15, which we're approaching.
https://www.kernel.org/pub/linux/kernel/v4.x/
Current stable version is 4.1.2
Linus Torvalds disagrees: > > Note that nobody reads every post in linux-kernel. In fact, nobody who expects to have time left over to actually do any real kernel work will read even half. Except Alan Cox, but he's actually not human, but about a thousand gnomes working in under-ground caves in Swansea. None of the > individual gnomes read all the postings either, they just work together really well. Anyway, some of us can't even read all our personal email, simply because we get too much. I do my best. What I'm getting at is that if you have the patch, then please re-post. In fact, cc'ing me is a good idea. And if at first you don't succeed, try and try again..
And about the development process:
>There is exactly one person who can merge patches into the mainline kernel repository: Linus Torvalds. But, of the over 9,500 patches which went into the 2.6.38 kernel, only 112 (around 1.3%) were directly chosen by Linus himself. The kernel project has long since grown to a size where no single developer could possibly inspect and select every patch unassisted. The way the kernel developers have addressed this growth is through the use of a lieutenant system built around a chain of trust. > > [...] > > When the merge window opens, top-level maintainers will ask Linus to "pull" the patches they have selected for merging from their repositories. If Linus agrees, the stream of patches will flow up into his repository, becoming part of the mainline kernel. The amount of attention that Linus pays to specific patches received in a pull operation varies. It is clear that, sometimes, he looks quite closely. But, as a general rule, Linus trusts the subsystem maintainers to not send bad patches upstream.
Actually, it is often the best practice to not rebase. There are a set of rules of thumbs regarding rebasing by Linus himself:
https://www.kernel.org/doc/html/latest/maintainer/rebasing-and-merging.html
Abuse of rebasing is extremely dangerous
Tabs don't have a specific width and those style guides specify column limits (79 +/- 1 or 100).
The Linux kernel uses 8 character tabs. The width is specified because otherwise you'll wrap in the wrong place.
>Stable kernel versions are a relatively new thing. I believe the first one was 3.10, before that it was essentially "whatever one redhat picked".
How can that possibly be true? Look at the frontpage of kernel.org even:
longterm: 3.14.14 2014-07-28 longterm: 3.12.25 2014-07-22 longterm: 3.10.50 2014-07-28 longterm: 3.4.100 2014-07-28 longterm: 3.2.61 2014-07-11 longterm: 2.6.32.63 2014-06-18
That's on kernel.org, not Redhat's site. Unless you mean that Redhat chose them, in which case, I'm not sure what you're trying to say about longterm branches.
I develop Linux drivers and we use the stable kernels. We haven't made it to 3.4 yet.
> First off, I'd suggest printing out a copy of the GNU coding standards, and NOT read it. Burn them, it's a great symbolic gesture.
It's strange because you wouldn't think there's anything to see there. It's just the first commit of the current repository, the project had already been in development for more than 10 years at that point. The commit even straight up states that he's chosen not to include earlier history because it makes it balloon to 3.2GB.
Wouldn't you find this way cooler? https://www.kernel.org/pub/linux/kernel/Historic/old-versions/
A quote that I find quite funny (from the 0.01 release notes):
> Sadly, a kernel by itself gets you nowhere. To get a working system you > need a shell, compilers, a library etc. These are separate parts and may > be under a stricter (or even looser) copyright. Most of the tools used > with linux are GNU software and are under the GNU copyleft. These tools > aren't in the distribution - ask me (or GNU) for more info.
Or the famous one from comp.os.minix: https://groups.google.com/forum/#!topic/comp.os.minix/dlNtH7RRrGA%5B1-25%5D
> Hello everybody out there using minix - > > I'm doing a (free) operating system (just a hobby, won't be big and > professional like gnu) for 386(486) AT clones.
Programmer here. Solid write-up!
I'm in the tab camp myself but as with most things (and in programming, there a lot of things), all's fine as long as it's used consistently and everybody's willing to stick to the existing style of a given body of code. Mature teams sometimes tend to formalize this in a style guide, sometimes complete with automated checks on the conformity of changed code. (Here's one for the Linux kernel. Or how about the Joint Strike Fighter (pdf).)
But any culture needs a healthy dose of bike-shedding of course. Variable naming is another good one; shall we call our variable totalBytesSent ("camel case") or total_bytes_sent ("snake case")? Oh, and brace styling. You don't want to count the pixels spilled over the difference between:
if (something) { some_code(); } else { some_other_code(); }
And:
if (something) { some_code(); } else { some_other_code(); }
And we haven't even gotten to my pet peeves, variable and function naming order. Does the adjective precede the noun? And what of the noun and the verb? Oh and do buffers have a length or a size?
(I should add, technically none of this actually has an impact on the shipped software. All of it compiles to the same bytes. It's quite important to have a uniform code-base, but ultimately it's just nerds going to war to vehemently defend whatever seemed like a neat idea while they wrote their first program, aged 16.)
[Kernel](https://en.m.wikipedia.org/wiki/Kernel_(operating_system) is basically the interface between the overlying OS and the underlying hardware. Android uses the Linux kernel which categorizes kernel releases as Prepatch, Mainline, Stable and Longterm. Android uses the longterm kernel releases which are not updated as much except for bug fixes. Also most Android phones are stuck at 3.10 longterm release which is quite old (EOL at 2015, the latest longterm release is 4.4). The article talks about shifting the focus from long-term releases to mainline releases which sees frequent updates.
That's really unfortunate how it uses the same name as FUSE, that is used in linux.
> # What is FUSE? > FUSE is a userspace filesystem framework. It consists of a kernel module (fuse.ko), a userspace library (libfuse.*) and a mount utility (fusermount).
> One of the most important features of FUSE is allowing secure, non-privileged mounts. This opens up new possibilities for the use of filesystems. A good example is sshfs: a secure network filesystem using the sftp protocol.
The bug is in the RDS implementation. To my knowledge, it's not very widely used.
Most distros that provide it only do so as an unloaded kernel module. That's certainly the case with RHEL 6, RHEL 7, and Debian Stretch.
The old Code of Conflict said the same.
> https://www.kernel.org/doc/html/v4.17/process/code-of-conflict.html > If however, anyone feels personally abused, threatened, or otherwise uncomfortable due to this process, that is not acceptable.
The issue was enforcement, not the CoC. The new CoC adds flowery words that can be interpreted as you want and makes maintainers punishable if their interpretation of the code doesn't align with the majority or outside pressure. There is now a large attack surface for anyone to interpret in order to support their claims.
Edit: The largest issue in my opinion is the adoption of an existing code insetead of writing your own. This makes you vulnerable to the interpretation formed by public opinion that you apparently support by adopting the work of someone else. It is now possible to argue that Project X has declared this action Y unwelcome. You have the same CoC, so you must do it as well.
Linux Kernel Coding Style vs the GNU Coding Standards
To spare you the reading time, you'll notice the two are quite different. If you frequent the kernel mailing lists, you'll no doubt run across more than a couple emails from Torvalds that just lay into people for not doing things the way he likes. One of the items about which he is known to be intensely particular is coding style. Compound this with the sort of mild rivalry/dislike between Torvalds (Linux) and Stallman (GNU), and it all adds up.
From our GNU/Lord and Savior, Linus Torvalds:
Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3.
A quick google found this, though I have no actual experience with the process. https://www.kernel.org/doc/html/v4.19/process/submitting-patches.html
Assuming you have cloned the kernel tree with git and created your patch in there:
create a patch file with
git format-patch HEAD^1- this creates a .patch file for your last commitrun
./scripts/checkpatch.pl 0001-*.patch- this will run thecheckpatchtool over the patch you have just created, making sure you follow the kernel coding style.run
./scripts/get_maintainer.pl 0001-*.patch- this gives you a list of e-mail addresses and mailinglists to which the patch should be sent.send a mail to the addresses returned by the aforementioned tool with the patch included inline. Make sure your e-mail client does not insert line breaks which would corrupt the patch. Finish it up with a
Signed-off-by: Du Hok <[email protected]>
The official kernel documentation describes the process in further detail.
can people please stop spreading this FUD that ALL LTS are now 6 years. That was never ever mentioned to be the case. Greg KH only agreed to 6-yearing 4.4.
For confirmation, please check this page. Whatever that page says is the official guideline on EOL dates.
Well, I looked it up.
3.18's End Of Life is January 2017.
So, 4 more months of official security fixes...
Or am I missing something here? I expected it to be short, but that just seems downright malicious to release a device which's kernel will start accumulating security holes four months after the device is out.
I mean, as I said, they might backport security fixes themselves, but is there a guarantee that they'll do it?
$ git remote set-url origin --push --add user1@repo1 $ git remote set-url origin --push --add user2@repo2
http://stackoverflow.com/a/12795747 https://www.kernel.org/pub/software/scm/git/docs/git-remote.html
Any OS book will tell you this about paging.
A simple google of linux and swap reveals this:
https://www.kernel.org/doc/gorman/html/understand/understand014.html
which says in the first paragraph:
> Just as Linux uses free memory for purposes such as buffering data from disk, there eventually is a need to free up private or anonymous pages used by a process. These pages, unlike those backed by a file on disk, cannot be simply discarded to be read in later. Instead they have to be carefully copied to backing storage, sometimes called the swap area. This chapter details how Linux uses and manages its backing storage.
Please try to read the COC, it's really not that bad IMO.
https://www.kernel.org/doc/html/latest/process/code-of-conduct.html
Also remember it goes both ways, a so-called SJW would be just as accountable to the COC as everybody else. A SJW attacking a personal or political view you post on twitter is NOT allowed under this COC.
Basically you can attack/criticize the code, not the person who wrote it.
It's very efficient to do grep -r <your error message> .... until you realize the error message is broken on several lines.
It's actually the only explicit exception to "never more than 80 columns" in the Linux coding style.
> However, never break user-visible strings such as printk messages, because that breaks the ability to grep for them.
> No it doesn't. Sure there can only be one "writer" in a cgroupv2 system
Common myth spawned by like 3 emails that gets repeated so much.
cgroupv2 is a multi writer system, it has never been single writer, have you ever used it?
The single-writer thing was a musing, a concept, an idea that Tejun and Lennart had like 4 years back, it has been silently abandoned, it has never appeared in any official documentation. It only appeared on like 3 mailing list posts. Though one was a post from Lennart who said that it would happen and that it was 'absolutely necessary', except it never happened.
There is nothing in the official documentation about their plan of having only a single pid to have the primordial control over the cgroup tree, any process that runs as root can manipulate the entire tree how it sees fit and any process that runs as a normal user can manipulate its own subtrees. The thing is that becausethere was never an announcement of it going to be there, just some mailing list musings, there was never an announcement of abandonment either, it was silently abandoned. When the official documentation started to appear it just wasn't in there.
cgroupv2 like cgroupv1 is a shared resource. Any process that runs as root can use it like any other process running as root, you can go to your cgroupv2 systemd system right now and start digging into /sys/fs/cgroup and completely screw it over if you want to by renaming cgroups and moving processes around from a shell running as root. This is of course not a problem because if you have root there is far more you can do to screw things over.
It would be a fucking problem if you actually had to use that API, now 484994 incompatible API's would appear and all that stuff, but thankfully that is not how it has gone, probably for that reason. cgroups can be manipulated by any process that runs as root by just manipulating the cgroup virtual filesystem tree.
> 4 spaces
More seriously, the Linux Kernel Coding Style does make a really good case for 8 in literally its #1 rule.
I think that single rule actually did go a long way to making sure functions in Linux had to remain simple enough to be easily understandable.
https://www.kernel.org/doc/Documentation/CodingStyle
>> Linux kernel coding style >> >> Chapter 1: Indentation >> >> Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 ... >> >>Rationale: The whole idea behind indentation is to clearly define where a block of control starts and ends. Especially when you've been looking at your screen for 20 straight hours, you'll find it a lot easier to see how the indentation works if you have large indentations. >> >>Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program. >> >> In short, 8-char indents make things easier to read, and have the added benefit of warning you when you're nesting your functions too deep. Heed that warning. ... >> >> Kernel coding style is super simple. Avoid tricky expressions.
Especially when you combine that rule with their rule about function length:
>> Functions should be short and sweet, and do just one thing. They should fit on one or two screenfuls of text (the ISO/ANSI screen size is 80x24, as we all know), and do one thing and do that well."
Between those two rules, it's almost hard to write a difficult to understand function.
The Linux Kernel Coding Style guidelines say this about GNU formatting:
> First off, I’d suggest printing out a copy of the GNU coding standards, and NOT read it. Burn them, it’s a great symbolic gesture.
> The problem is that libc is 100% forward compatible, but absolutely not backwards compatible.
Not quite.
In fact, glibc is one of the only libraries I know that makes use of symbol versioning to solve exactly this problem.
It's not perfect, as the documentation explains, but it's absolutely there. As long as you don't need the absolute-newest features, you can link against the old API versions and it will work in perpetuity.
We currently count ~300 users, who are usually either kernel module maintainers or high-profile developers. To qualify for a kernel.org account, people have to either be listed in MAINTAINERS or receive a special approval from the steering committee (Linus, Greg KH, H.P.Anvin, Ted Ts'o). We also require that people are in the kernel.org PGP web of trust, which means that before anyone is given access, they must have PGP signatures from at least 3 other kernel developers who already have a kernel.org account.
One way to get familiar with the kernel is to run it in qemu and explore it using gdb. I recommend building your own copy of gdb using ./configure --enable-targets=all. The kernel can be built for your favorite architecture using the toolchains available here https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.9.0/
It's good engough for Linux Kernel developers.
Do not unnecessarily use braces where a single statement will do.
if (condition)
action();
https://www.kernel.org/doc/html/latest/process/coding-style.html#placing-braces-and-spaces
> Jesus, all these people are just angry that they can't discriminate against trans people as easily.
I think that's a pretty unfair characterization of those with an actual argument against the CoC changes.
>I can't find a single line that looks even vaguely extreme.
Okay, but what is this covering that wasn't already covered before? The previous Code of Conflict already had the following language:
> If however, anyone feels personally abused, threatened, or otherwise uncomfortable due to this process, that is not acceptable. If so, please contact the Linux Foundation’s Technical Advisory Board at <>, or the individual members, and they will work to resolve the issue to the best of their ability.
and
> As a reviewer of code, please strive to keep things civil and focused on the technical issues involved. We are all humans, and frustrations can be high on both sides of the process. Try to keep in mind the immortal words of Bill and Ted, “Be excellent to each other.”
In my mind, discriminating against someone that is gay, trans, not white, not male, or any other reason that has nothing to do with code is not being excellent to each other, meaning that it already wasn't allowed. If that's the case, what's the point of this change?
There was a part of the conversation where they were agreeing that digital communications was just a way for people to get themselves into social trouble, because basic civility and the reading of body language goes out the window to some extent.
That's true, but there's also numerous advantages to that sort of written asynchronous communication that they didn't mention:
- It's a great equalizer for people who speak different native languages.
- It gives everyone involved a greater chance to reflect on what's said without the immediate expectation of a response
- The time delay factor allows people from all over the world to participate, instead of just people in the same room.
- It's all digitally recorded, so it's easy to refer back to earlier parts of the conversation for fact-checking & referencing, even by people who weren't there (or may not have been born yet).
I think Sam was unduly dismissive of this mode of communication. Yes it takes some discipline, and it can certainly benefit to some degree from occasional in-person meetups, but at the same time it can yield benefits that wouldn't have been possible before. Sam's own website is at least partially hosted on a system whose development is primarily coordinated over E-Mail.
If your Linux doesn't include manuals, they're all on the web anyway:
Also check the program's web site (indicated in the man page) for official documentation.
>When companies have incredibly complex, mission-critical software you can't just slop together a patch in an afternoon and ship it.
Nobody is asking them to do it in a day. Google is giving them 90 days.
Shit, Linux has a default of 7 days: https://www.kernel.org/doc/Documentation/SecurityBugs Microsoft and Apple can fix their stuff in 90 days.
>MS: "Hey, you know our incredibly important software that runs the world? Give us two extra days to get this patch out. We want to do this right."
Microsoft has a habit of not fixing bugs. They have bugs that never get fixed. If you do not hold Microsoft's feet to the fire they will only fix some of their bugs. We deserve better than that. Google is forcing companies to fix bugs in a timely manner.
> One of the core tenets of linux kernel dev is "you don't break userspace!"
That's done with API stability, not ABI stability. That said, many would say that non-stable ABI is a feature, since it encourages companies to upstream their drivers.
> Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3.
>To summarize it I would go with a "Don't be a dick, be friendly instead"
That's exactly what it used to be!
​
https://www.kernel.org/doc/html/v4.17/process/code-of-conflict.html
​
"...We are all humans, and frustrations can be high on both sides of the process. Try to keep in mind the immortal words of Bill and Ted, “Be excellent to each other.”"
Extending /u/Muskaos comment, the Scope section of the CoC shows it to be a literally totalitarian instrument, as we've seen it used in Opalgate and with Node.js:
> This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
Emphasis added.
At its core, drivers in linux are always running at the kernel level, and there's no plans to change that. That said, there are a number of generic drivers in the kernel that essentially expose certain functionality to user space, allowing the bulk of a drivers functionality to exist outside the kernel, where a compromise would be (somewhat) less damaging.
For example, Linux has a mechanism called FUSE which allows an unprivileged user to mount an arbitrary filesystem without having to install any kernel modules specific to that filesystem. This way, if a code execution bug is discovered in a (FUSE) filesystem driver, that code will only run as the unprivileged user, and not as the kernel. FUSE itself is a kernel driver that runs with maximum privileges, but by minimizing the amount of code that runs with privileges, the attack surface is reduced.
There are other interfaces like this throughout the filesystem, and even many graphics drivers offload a significant amount of their processing to userspace libraries, reserving the kernel code for performance critical tasks.
The code-quality of the early versions was all over the place, this is why Ken Thompson criticized it...
http://www.linuxtoday.com/developer/1999050701605NWSM
AFAIK the first UNIX release had exactly two contributors, see this early video interview below.
https://www.youtube.com/watch?v=JoVQTPbD6UY
Linux had lots of contributors, particularly for the user-land stuff and device drivers, so the code quality was uneven.
I personally had an issue where I was porting some software that used mandatory file locking, which simply didn't work properly on Linux. When I did some research I found this:
https://www.kernel.org/doc/Documentation/filesystems/mandatory-locking.txt
> Why you should avoid mandatory locking
>The Linux implementation is prey to a number of difficult-to-fix race conditions which in practice make it not dependable:
This is a very non-Unix way of doing things. Either implement the feature correctly or leave it out.
The best use case I know is to jump to cleanup sections at the end of a method, like in c if you malloc a bunch of space and check to make sure everything worked, if it doesn't you goto your cleanup section, if it does you just proceed as normal. There's really no substitute for that, though I once saw someone put an entire function in a do while(1) loop and would just break out of it to get to the cleanup at the end.
That's how afraid of goto they were.
Edit: also for those wondering, Linux kernel style fully allows goto, and you see it for cleanup sometimes. It's directly mentioned in the amazing kernel style sheet, which I'm not 100% was written by Linus but boy does it read like it was.
don't know what you mean there. its not 1990 anymore, linux needs drivers for nothing - scanners, printers, cameras, arduino, uart's, webcams.... i'm always amazed when trying to help a friend who runs windows at just how much crap you need to go through just to get a printer or trackpad to work lol.
apart from which we're talking about usbserial which supports cp2102, pl2303, ftdi, ch340 etc. out of the box.
https://www.kernel.org/doc/html/v4.17/process/code-of-conflict.html
Yep:
> Try to keep in mind the immortal words of Bill and Ted, “Be excellent to each other.”
It's distro-specific. For example, here's the page Canonical is maintaining that specifies which kernels they have (or will) backport the fix to.
For everyone else, you can expect it in a long term*, stable, and mainline kernel very soon I would suspect given it's priority rating... It's already in mainline.
*depends on who is maintaining it, and their reaction time.
How about:
#define volatile /* volatile considered harmful see: https://www.kernel.org/doc/Documentation/volatile-considered-harmful.txt */
Just trying to help...
That's not really what zero-copy means here. What you're looking for is peer to peer DMA, and it's actually much harder than it is at first glance because there's a lot of bookkeeping involved on the filesystem side of things.
This is not entirely correct, since we're really talking about the kernel and not just any program.
Regarding userspace: Yes, the behaviour you describe (return NULL on allocation failure/when out of memory) would be correct. However, at least in Linux you are pretty much guaranteed this will never happen. In Detail: If the system truly is out of memory and you try to allocate more, the kernel might invoke the OOM killer, i.e. choose a program to terminate in order to regain some memory. If the sacrificed program happens to be the one that requested more memory in the first place, it would just never see the result of the malloc call. As a result, as a programmer you can assume (at least on Linux) that malloc never fails.
Regarding kernelspace: Here it gets more interesting, since allocations inside the kernel can and do fail. Essentially, there are different types of allocation the kernel might make. If a request made by userspace necessitates additional memory, the kernel will allocate the memory on behalf of the originating process in userspace.
For allocations made by the kernel on its own (e.g. for a device driver), there are different types of allocation requests with various associated priorities - think of it as a spectrum between "Might be nice if you happen to have a few spare bytes hanging around, otherwise I can wait" (GFP_KERNEL & ~__GFP_RECLAIM) and "I need this chunk of memory right now, everybody else is waiting for me to finish my work!" (GFP_ATOMIC).
If you're interested in this, have a look at the corresponding kernel documentation: https://www.kernel.org/doc/html/latest/core-api/memory-allocation.html
tl;dr: In userspace, you don't need to worry about allocation failures, but in the kernel, handling them is very important.
Linux TUN/TAP let you do VPNs in userspace --- this is how OpenVPN is implemented. The advantages are being safer and easier to deploy and modify. The main disadvantage is performance.
Well I disagree with you both! :-)
The golang style guide provides excellent advice in this regard..
> the further from its declaration that a name is used, the more descriptive the name must be
IMO overly verbose variable naming makes it difficult to skim a block of code to figure out what it's doing.
This is not uncommon advice - see also the Linux Kernel style guide, for example.
This article is just plain wrong on most things it says. Sorry, I don't get paid for doing this so I'm not going to write an exhaustive list on everything it has wrong. But I can state a few things.
Doing an extensive write-up on how tasks wanting to sleep for a specified amount of time are handled in Linux is really hard and taking into account all the different operating systems in an article like this is just crazy.
On Linux, the whole thing starts from the clock source you have. On my system it's
$ dmesg | grep tsc [ 0.000000] tsc: Fast TSC calibration using PIT [ 0.000000] tsc: Detected 997.637 MHz processor [ 1.781444] tsc: Refined TSC clocksource calibration: 997.691 MHz [ 1.781449] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x1cc323c8d66, max_idle_ns: 881590493406 ns [ 2.781396] clocksource: Switched to clocksource tsc
which means the kernel can set the interrupt with about 1 ns accuracy. On other systems you may have other sources like rtc. I'm too young for those, but their accuracy could be something like 32 kHz.
The high-level idea how Linux manages these tasks that are waiting some time to pass is to always set the clocksource to wake up when the next task should wake up. When the interrupt happens, check which all tasks should be woken up, wake them up and check what the timing of the next task is and reconfigure the clocksource accordingly.
Sounds simple, but I can assure you that it's not. While I was doing my Master's Thesis about task scheduling I read Thomas Gleixner's rant about how hard it's to get everything right since time always moves forward while you calculate offsets and stuff. Rest assured, they've done an excellent job. The interested readers should check up https://www.kernel.org/doc/Documentation/timers/hrtimers.txt and comments in http://lxr.free-electrons.com/source/kernel/time/hrtimer.c
edit: fixed code block formatting
Without manual configuration, nothing. Both Selinux and Apparmor need to be enabled with a kernel parameter and configured in userspace before they have any effect. Dunno about TXT, but i bet such thing requires some setup too.
> What is reasonable about Drepper?
His remarks on the GPL and RMS.
> This part has a morale, too, and it is almost the same: don't trust this person. Read the licenses carefully and rip out parts which give Stallman any possibility to influence your future. Phrases like >> [...] GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version.
> just invites him to screw you when it pleases him. Rip out the "any later version" part and make your own decisions when to use a different license since otherwise he can potentially do you or your work harm.
There's a reason the Linux kernel is released under GPLv2 only.
Edit: Oh, and looks like Drepper is back at Red Hat.
> Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you’re screwed anyway, and should fix your program.
It can actually be smaller, although I wouldn't really recommend it:
https://www.kernel.org/doc/Documentation/power/interface.txt
Relevant bit:
> /sys/power/image_size controls the size of hibernation images.
> It can be written a string representing a non-negative integer that will be > used as a best-effort upper limit of the image size, in bytes. The hibernation > core will do its best to ensure that the image size will not exceed that number. > However, if that turns out to be impossible to achieve, a hibernation image will > still be created and its size will be as small as possible. In particular, > writing '0' to this file will enforce hibernation images to be as small as > possible.
> Reading from this file returns the current image size limit, which is set to > around 2/5 of available RAM by default.
Anyone that think they don't need any swap should create a token swap file, because some algorithms in the memory management in the kernel freak out when there's no swap at all. It tries to swap some pages immediately if it thinks they won't be needed, and if it can't, it trows off some other calculations that divide what's in memory over what's already swapped. It's a division by 0 when there's no swap at all. It's possible then to turn swappiness to zero to avoid actually putting something there.
Reference: https://www.kernel.org/doc/gorman/html/understand/understand014.html "The casual reader may think that with a sufficient amount of memory, swap is unnecessary"
From reading <code>Documentation/input/joystick-api.txt</code>, I think you want something like:
struct js_event e; int fd;
fd = open("/dev/input/js0", O_RDONLY); while (read(fd, &e, sizeof(e) != -1) { if (e.type & JS_EVENT_INIT) continue; }
> But with MS bringing features like DX12 Ultimate & Direct Storage along with Nvidia's RTX IO, it leaves me with a question;
Not particularly interesting. All somebody needs to do is emulate windows api or build their own userspace api. It has been in the kernel for awhile now because ML have huge data requirements
https://www.kernel.org/doc/html/latest/driver-api/pci/p2pdma.html https://www.eideticom.com/media-news/blog/33-p2pdma-in-linux-kernel-4-20-rc1-is-here.html
No, Debian Buster contains 4.19.181 (released in March) at the current moment, which is only a little bit behind the official 4.19.190 release (from May).
The Debian Kernel Team backports any fixes needed and ships newer LTS kernel versions when needed on a regular basis, either via Security Updates or when a new Point Release is made.
You can see the different branches and their versions on https://www.kernel.org/
From the kernel documentation:
This value counts the number of I/O requests that have been issued to
the device driver but have not yet completed. It does not include I/O
requests that are in the queue but not yet issued to the device driver.
It might be an issue of CPU throttling. See:
> how about any width because we code on 23" high definition multi-head displays
Because it's less readable if your code is too wide. It makes sense to set a limit of some kind, even if 80 columns is too strict.
As a similar example, if you've used LaTeX you'll have noticed that the default margins are excessively wide - but it's deliberately designed that way. Same with writing code. Long, run-on lines make things harder to read. Even Reddit does the same thing: maximize your browser window and you'll see that the comment widths stop at a certain point rather than running all the way to the right-hand side.
For some languages (eg. Java) where lots of indentation is necessary and long names are common, I can see an argument for perhaps ~120 columns. But in most cases, 80 columns works pretty well.
As an aside, the Linux CodingStyle file makes another interesting point: excessive indentation is harder to follow, so an 80-column limit acts as a natural warning that you should refactor your code.
If you can easily measure and reproduce this, then it might be worth bisecting the change that caused this and report the issue. Increased power consumption could be a serious bug. https://www.kernel.org/doc/html/latest/admin-guide/bug-bisect.html
>When they become the biggest contributors to everything GNU/Linux, they will control it.
Linus Torvalds manages the mainline kernel, so he has to approve of any changes before they can be merged. From How patches get into the Kernel:
There is exactly one person who can merge patches into the mainline kernel repository: Linus Torvalds.
Typically you have to open the correct device files under /dev and start writing to them directly.
There are several competing sound driver "infrastructures" in Linux (OSS and ALSA being the most notable) and it has evolved over time. You'll need to determine what sort of drivers your kernel has been compiled with, and then go from there to determine which devices you need to flog.
I'm no expert in sound card handling so I can't give more specifics than that. You may want to start by going over the kernel documentation on sound drivers:
It doesn't matter if you're writing C and there's not an OS underneath you. Check out this page from the Linux docs for example. It shows (some of) the hoops that C programmers have to jump through today to be reasonably sure that, for example, a `*` compiles to an actual memory access instead of something that the CPU will happily reorder.
Are you talking about 3rd party (out of tree) drivers or in tree drivers?
If you are talking about 3rd party drivers like Nvidia, then here is their rationale: https://www.kernel.org/doc/html/v4.14/process/stable-api-nonsense.html
No it's not. There's a process for responsible disclosure which gives the kernel maintainers time to verify and patch and notify vendors.
> As a basic default policy, we expect report date to disclosure date to be on the order of 7 days.
> then you just add a line saying: > > Signed-off-by: Random J Developer <>
> using your real name (sorry, no pseudonyms or anonymous contributions.)
Automate it to check for bad words and yell at you. Here: https://www.kernel.org/pub/software/scm/git/docs/githooks.html
You want the commit-msg hook, and the script must exit with a non-zero status code if it detects a naughty message. You can find an example script here: https://git-scm.com/book/be/v2/Customizing-Git-An-Example-Git-Enforced-Policy#Client-Side-Hooks
Most designs, I dare to say the best designs, will be voluntarily shared by their creators. That has been happening with software for several decades by now.
Do you have an Apple computer? It uses the BSD kernel. Or do you have an Android phone? It uses the Linux kernel.
I guess the future will be a lot like the software industry now. Big corporations will spend a lot in marketing pushing you to buy their designs, while people who know how will get better designs from free sources.
debian/ubuntu:
apt-get install build-essential kernel-package
cd /usr/src
wget -c https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.19.tar.xz
tar xvf linux-3.19.tar.xz
cd linux-3.19*
cp /boot/config-$(uname –r) .config
make oldconfig
make-kpkg --initrd --apend-to-version=custom
dpkg -i ../*.deb
update-grub
for anyone who is wondering on how-to-submit-a-trivial-change, https://www.kernel.org/doc/Documentation/SubmittingPatches ctrl+f trivial
or: https://www.kernel.org/pub/linux/kernel/people/rusty/trivial/template-index.html
intel hd audio is a mess. alsa is a mess. pulseaudio inherit both of those messes.
I hate hardware.
https://www.kernel.org/doc/Documentation/sound/alsa/HD-Audio.txt
> Since the HD-audio controllers are supposed to be compatible, the single snd-hda-driver should work in most cases. But, not surprisingly, there are known bugs and issues specific to each controller type. The snd-hda-intel driver has a bunch of workarounds for these as described below.
Kernel is highly likely to be 5.15, since it's the most recent LTS kernel and judging by precedent there will not be another one before 22.04 appears.
https://www.kernel.org/category/releases.html
The October 2023 EOL date shown for support in the table may appear short but that's often the case initially, typically some companies step up to extend it (likely to 2027). Here's what Greg KH (one of the top kernel maintainers for those who don't know) had to say about this in relation to 5.10:
http://kroah.com/log/blog/2021/02/03/helping-out-with-lts-kernel-releases/
But yes, this article doesn't really tell me anything much I that want to know, particularly what's happening with Pipewire and Wayland.
I know a lot of embedded devs are quite dogmatic about volatile, but I am of the opinion that volatile is overused.
For memory mapped IO it makes perfect sense. For variables that are somehow shared and you hope volatile will fix your issues, not so much.
I remember Linus had a quite good breakdown on volatile and I think he is right.
https://www.kernel.org/doc/html/v5.5/process/volatile-considered-harmful.html
The internal Linux kernel API that drivers use is subject to change with every Linux release. There is no attempt at backward-compatibility in this API.
Linux Insides give a lot of low level details about the kernel. More than any other resource I have seen except maybe for the kernel documentation.
> The PC version supports XBox360 and XBone controllers. Any others that are popular?
If you're already using SDL(2), make sure that you use their gamepad API. Pretty much any controller that Linux supports will be supported then. If you want (or have) to be more low-level, there's the kernel API. Those usually don't change for a long time (if they do, Linus Torvalds hops in a plane to punch some guy in the mouth).
Still, if you can, use SDL or some other library for increased ease-of-use and reliability with gamepads that you don't know of.
> then release on itch.io and steam
No GOG? :(
> 64 bit only? We're only doing 64 bit for OSX and Windows.
With 64 bit only you'll already reach the vast majority of desktop GNU + Linux users.
> It requires "GNU C library GLIBC_2.2.5, minimum GNU C++ library CXXABI_1_3, GLIBCXX_3.4".
This has nothing to do with the kernel, those are runtime libraries (think msvcrt on Windows). Unfortunately I'm not very educated on how/where exactly to find out those exact numbers. But Ubuntu (the distro that Steam supports) ships libc in version 2.27 in its LTS release, so I assume pretty much any distro will fulfill these requirements.
So does NVIDIA’s vGPU, which uses the SR-IOV VFIO PCI in non-mediated mode just like MxGPU.
The big advantage of Grid over MxGPU comes in the official VFIO MDEV mode which runs on the standard mediated device framework which is part of the Linux Kernel ;)
https://www.kernel.org/doc/Documentation/vfio-mediated-device.txt
In fact MDEV is used to virtualize legacy AMD GPUs that do not support SRIOV on KVM all the time.
The current code of conduct :)
Seriously, I share here what I've already written on FreeBSD forum on the same topic. Here are the points that I love the most about FreeBSD
- sysctl -a and you can list all the tunable system settings! sysfs is a big mess under Linux, the solution for badly designed interfaces under Linux is, guess what, abstraction (https://www.kernel.org/doc/html/v4.16/admin-guide/sysfs-rules.html)
- Audio quality is superb! Again under Linux the solution to the Alsa mess is abstraction, welcome to pulseaudio latencies!
- Up to date ports, with a stable system base. It is a perfect mix between rolling and stable release models, almost non existent on any Linux distro.
- Documentation is great!
- Kernel modules remain compatible between minor releases, you have a module for 11.0, it is guaranteed to work for all 11.x. Under Linux, a module compiled for 4.16.0, will refuse to load on the kernel 4.16.0.0.0.....1!
- Almost every kernel module has it own Makefile under /usr/src/dev/modules. You can modify/build what you want from there.
- No shit like systemd, my point on that has been always that it is okay to have a parallel init system, but a init that eats other daemons, udev, logind, cron, etc... stopping me from booting my system because it does not find my external sd flash card that is listed in fstab, filling my disk with binary logs, killing my processes by default on logout, noooooo.
- Sane community.
You mean heartbleed, which was an SSL bug.
Also, you're talking about a bug in a library that was being maintained by only 2 people. This is a list of Linux Kernel maintainers. That's a hell of a lot more than two people.
It's not a myth, there is a list of kernel maintainers where it says this:
"Status, one of the following:
- Supported: Someone is actually paid to look after this.
- Maintained: Someone actually looks after it.
- Odd Fixes: It has a maintainer but they don’t have time to domuch other than throw the odd patch in. See below..
- Orphan: No current maintainer [but maybe you could take therole as you write your new code].
- Obsolete: Old code. Something tagged obsolete generally meansit has been replaced by a better system and youshould be using that."
So we can count them:
1 Buried alive in reporters
1634 Maintained
617 Supported
89 Odd Fixes
72 Orphan / Obsolete
About 25% of kernel mantainers are really paid to do that job. The rest are not, so Linux is a community driven development. Maybe those matainers work for a big company, or maybe they are just amateurs. Probably someone who knows a little bit of low level programing is going to work in the industry, but most of them are not paid to do that job.Also, the origin of the contributions don't really matter, as they have to be aproved by kernel maintainers, who are (mostly) independent. I remember hearing complaints of how difficult it can be to contribute to the kernel, as they are very paranoid.And yep, that poor guy buried alive in reports, is Linus.