Slashdot Mirror

It can function as DRAM, but as you said, why would anyone want that? See https://nvdimm.wiki.kernel.org...

https://www.kernel.org/doc/ols...

Looks like IOMMU is roughly a 15% cpu overhead because of memory virtualization overhead causing increased cache invalidation. But can be up to 60% overhead for events 256bytes and smaller. This might apply for keyboard key presses where the datastructure for the event is larger than the data to indicate which key was pressed or a UDP flood on a network interface, most other hardware devices are going to be dealing in 512byte+ chucks of data at a time. ~15% cpu cost should be the most common.

15% additional CPU cost on IO seems cheap to me. Most of my IO requires virtually no CPU because of offloading and DMA access. To give an example. Transferring 940Mb/s(114MiB/s) over Ethernet copying a file from one Windows machine to another over SMB results in about 0.5% cpu usage on my quad core. A 15% increase would push it to 0.575%

My understanding is the problem is there is no linux driver for the apple SSD. https://bugzilla.kernel.org/sh...

Why would you buy over priced apple hardware just to install linux on it? There are any number of ryzen, or even intel, based laptops for half the price with better or greater performance. An these laptops tend to be a lot more penguin friendly. No weird apple shit to deal with.

My understanding is the problem is there is no linux driver for the apple SSD. https://bugzilla.kernel.org/sh...

As others have answered, "several" in this context means a vague small number.

I'd like to point out that when writing up a news article, the author should have taken several minutes to look up exactly how long ago the X32 ABI was introduced.

"It was just six years ago..."

Unlikely. NT kernel works differently, it has many low level features that are missing or work differently in Linux kernel. For example its FS permission system is more complex than *nix "user, other, group". The kernel architecture affects many low level user mode exposed things such as address space layout, system call ABI, Audio/Video subsystem, process/thread stuff, etc. It's impossible to migrate to Linux and preserve 100% binary compatibility. Also what's wrong with NT kernel? As if Linux kernel is free of issues.

Unlikely. NT kernel works differently, it has many low level features that are missing or work differently in Linux kernel. For example its FS permission system is more complex than *nix "user, other, group". The kernel architecture affects many low level user mode exposed things such as address space layout, system call ABI, Audio/Video subsystem, process/thread stuff, etc. It's impossible to migrate to Linux and preserve 100% binary compatibility. Also what's wrong with NT kernel? As if Linux kernel is free of issues.

No, it wasn't necessary, but changing it also didn't warrant adopting and supporting racism, sexism, and bigotry, or linking to their site which also has a manifesto against meritocracy. That people are defending her, supporting her witch-hunting tool, and not simply choosing an alternative or making up their own is appalling.

To support this sort of offensiveness and hostility towards whole demographics in the name of.... stopping Linus from being hostile towards individuals who screwed up? That's hypocritical and delusional to an extreme.

If you want a healthy productive community, the correct way to handle repeated violations of policy is to document the policy and direct people to it when its violated.

They process is well documented and on the checklist here it's #6 (emphasis mine):

Any new or modified CONFIG options do not muck up the config menu and default to off unless they meet the exception criteria documented in Documentation/kbuild/kconfig-language.txt Menu attributes: default value.

As usual Linus is ranting because people didn't read the basics, if somebody claimed ignorance I'm sure he'd provide the links but they're not exactly hard to find.

If you want a healthy productive community, the correct way to handle repeated violations of policy is to document the policy and direct people to it when its violated.

They process is well documented and on the checklist here it's #6 (emphasis mine):

Any new or modified CONFIG options do not muck up the config menu and default to off unless they meet the exception criteria documented in Documentation/kbuild/kconfig-language.txt Menu attributes: default value.

As usual Linus is ranting because people didn't read the basics, if somebody claimed ignorance I'm sure he'd provide the links but they're not exactly hard to find.

I want to know where he went and who "explained" things to him.

Someone should check his forehead for scars.

Also, why isn't this in the summary: https://www.kernel.org/doc/html/latest/process/code-of-conduct-interpretation.html.

Which has a LOT of really good language. Like how the scope doesn't include other forums. And you're not going to get banned for things you said years ago. But every damn thing in here should be a patch or update to that pile of garbage that is the original CoC. It's a damn good argument that the original was lacking and shouldn't have been used in the first place. When you are forced to use something for political reasons, you add a layer above or below it to deal with all the shit. And I smell politics here. It stinks.

But what's this?:

The initial Code of Conduct Committee consists of volunteer members of the TAB, as well as a professional mediator acting as a neutral third party.

. . . Who is this professional mediator? Why was it not mentioned before? Is it literally any hired professional mediator? Like the sort that gets mandated by a judge?

So the instead of going to the TAB it's going to a CoC Committee? That's honestly a good move. The TAB has way better things to do. The confidentiality clause STILL makes it a problem though. If reported issues are supposed to be kept confidential to the CoC Committee... how can the TAB review it? Or is this the sort of confidentiality where they can share it with anyone they want?

Any decisions by the committee will be brought to the TAB, for implementation of enforcement with the relevant maintainers if needed. A decision by the Code of Conduct Committee can be overturned by the TAB by a two-thirds vote.

Well thank god the children have to go get the mother-may-I from the adults. That sort of check on power will honestly go a long way towards keeping the crazy at bay.

as well details of any overridden decisions including complete and identifiable voting details.

I mean, that's fine. But it's a pretty conspicuous detail. Looks a lot like a set of crosshairs placed directly on the TAB in the explicit form of "WE NEED TO KNOW HOW YOU VOTED" sort of way. ....I want to know who negotiated these terms.

One interesting line that got removed from the actual LF CoC:

Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project’s leadership.

This line got removed. So that's... a specific set of crosshairs that's no longer on all contributors. That's good. It was a fluff piece of vaguely threatening language and has no real specific teeth, but it was still pretty disturbing in it's ability to be abused.

We expect to establish a different process for Code of Conduct Committee staffing beyond the bootstrap period.

I swear if you dumbasses buy into that CoC beacon bullshit we will riot.

https://www.kernel.org/code-of... . . . They STILL link to that racist hate-monger's website. I'm appalled that they'd stand next to that monster.

I want to know where he went and who "explained" things to him.

Someone should check his forehead for scars.

Also, why isn't this in the summary: https://www.kernel.org/doc/html/latest/process/code-of-conduct-interpretation.html.

Which has a LOT of really good language. Like how the scope doesn't include other forums. And you're not going to get banned for things you said years ago. But every damn thing in here should be a patch or update to that pile of garbage that is the original CoC. It's a damn good argument that the original was lacking and shouldn't have been used in the first place. When you are forced to use something for political reasons, you add a layer above or below it to deal with all the shit. And I smell politics here. It stinks.

But what's this?:

The initial Code of Conduct Committee consists of volunteer members of the TAB, as well as a professional mediator acting as a neutral third party.

. . . Who is this professional mediator? Why was it not mentioned before? Is it literally any hired professional mediator? Like the sort that gets mandated by a judge?

So the instead of going to the TAB it's going to a CoC Committee? That's honestly a good move. The TAB has way better things to do. The confidentiality clause STILL makes it a problem though. If reported issues are supposed to be kept confidential to the CoC Committee... how can the TAB review it? Or is this the sort of confidentiality where they can share it with anyone they want?

Any decisions by the committee will be brought to the TAB, for implementation of enforcement with the relevant maintainers if needed. A decision by the Code of Conduct Committee can be overturned by the TAB by a two-thirds vote.

Well thank god the children have to go get the mother-may-I from the adults. That sort of check on power will honestly go a long way towards keeping the crazy at bay.

as well details of any overridden decisions including complete and identifiable voting details.

I mean, that's fine. But it's a pretty conspicuous detail. Looks a lot like a set of crosshairs placed directly on the TAB in the explicit form of "WE NEED TO KNOW HOW YOU VOTED" sort of way. ....I want to know who negotiated these terms.

One interesting line that got removed from the actual LF CoC:

Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project’s leadership.

This line got removed. So that's... a specific set of crosshairs that's no longer on all contributors. That's good. It was a fluff piece of vaguely threatening language and has no real specific teeth, but it was still pretty disturbing in it's ability to be abused.

We expect to establish a different process for Code of Conduct Committee staffing beyond the bootstrap period.

I swear if you dumbasses buy into that CoC beacon bullshit we will riot.

https://www.kernel.org/code-of... . . . They STILL link to that racist hate-monger's website. I'm appalled that they'd stand next to that monster.

Fun story time related by a colleague. A pretty common piece of software (hint: there's probably one running within a few hundred yards of you) had an elusive bug. But as the parent noted, printf caused the problem to go away, and it was suspected because it caused synchronization on stdout. Unlike the parent, the developers didn't have time to actually implement a buffered-log solution to figure this out, so they the obviously-logical thing -- they replaced all the printf calls with barrier() and shipped it. It's still running like this today.

Another good one, I worked with someone who would log everything all the time by fprintfing to a high-numbered pipe. When I asked him, he gave a few advantages that still ring partially true (depends on context): first, he said, I can get the log from any running instance without even stopping by d-tracing the system call. But most critically, he said, all the formatting happens in userland and only after the syscall does the kernel actually realize that there's nothing on the other end of the pipe and drop the write. That means, he reasoned, that the release/debug versions would always have very close behavior and would avoid the class of 'bugs that don't reproduce in debug build'. As with the other story, to this day, there's a slew of machines out there, formatting and writing log messages to a pipe that's never open.

It doesn't matter what the motivations are; it's not happening. This is just not the way you throw a snit in FOSS. You do that by forking.

The hypothesis here is that the Contributor Code of Conduct is intolerable, and that all the best contributors are going to take their balls and go home. But they *can't* take their ball back, the only thing they can take away is a copy of their ball.

Let's ignore all the contributors who are being paid by their employers to participate, and assume that every one of the roughly 10,000 people who contribute to the kernel is a gentleman programmer doing it on his own time. If the intolerability hypothesis is true, we'd see a mass revolt. Nobody has produced any evidence yet of such a mass revolt happening. I'm sure there are individuals who are so hacked off they won't work on it, certainly enough to get some media attention, but do you have enough to force anyone's hand?

Is there honestly anything in the document that is a political agenda?

The Linux Code of Conduct

All it asks is that people not drive others away from the project by being hateful. It's not a particularly political stance. And it lists some particular examples -- no doxing, for example. There's nothing political about it to my eyes.

In the phrase "politically correct," the politics is that they're against anybody complaining that something is hateful. You're not supposed to throw shade on their hate, because it might hurt their feelings with needless empathy or compassion.

Is there honestly anything in the document that is a political agenda?
The Linux Code of Conduct
All it asks is that people not drive others away from the project by being hateful. It's not a particularly political stance. And it lists some particular examples -- no doxing, for example. There's nothing political about it to my eyes.

"there is no reasonable solution for this kind of bug. There will always be a danger of deadlocks when using openvpn."

openvpn should behave the same as stunnel - a userspace program handling the data

Here's one in netlink that was patched just 8 days ago. Code constructs that have the potential to generate gadgets are incredibly common, now shoo Intel shill, your company has no shame and produces shoddy junk.

QA is done differently than "someone testing his code". This is not a true QA. The fact is a fact, even the LTS X.Y.Z versions of vanilla Linux kernels are more like to early betas. As I wrote above, the only truly stable kernels that you can rely on are kernels maintained by Red Hat and Google (maybe SUSE a little bit), the rest are garbage of different degree brokenness. Red Hat maintains a stable kernel driver ABI for 10 years and more in its every major OS version, and RHEL (with its derivatives) is the most successful Linux distro in the commercial world. And yet this tells nothing to the Linux developers who break everything for the sake of change. Yeah, stable api nonsense, almost every other mainstream OS maintains a stable kernel ABI.

ZDNet points out that the move to new licenses "doesn't apply, of course, to Linux itself. Linus Torvalds has made it abundantly clear that Linux has been, will now, and always shall be under the GPLv2."

While it's true that the Linux kernel is sticking with the GPLv2, Torvalds and many of the other copyright holders have already adopted the GPLv3's cure commitment language.

Linus wrote git.
git is not dependent on github.
The mainline Linux kernel is hosted on its own site https://git.kernel.org/

I am sure. But if you have a limping computer that can't handle a cpu-load, there are steps you can take, like:
1) cleaning it
2) not overclocking
3) for multi-core, limit # cores in use using affinity
4) don't use hyperthreading
5) limit the cpu-clock -- most processors in the past 10 years have variable clock rates -- spinning down when idle, or to conserve power, ramping up under load. On Windows you can set the min and the max processor state (might need a patch on some OS's as MS enabled and later hid the controls; a reg-patch from bitsum.com can re-enable). But my cpu normally idles at about 36% max-clock rate. If I set the max-processor-state to 36% or lower, it will never go up from 1.18GHz to its max speed of 3.2GHz. That will save power and result in lower cpu temps: Using https://www.cpuid.com/download...,
Idle: 44C + power ~52W.
Normal w/100% load on all cores: 72C & 122W
with cpu perf limited to 36%: 52C & 62W
---
On linux (more pertinent to article), you can use:
https://git.kernel.org/cgit/li...
(cpupower) to set max frequencies to do the same thing.

There ya go: now you have no one to blame other than yourself for cpu overheating. :-)

Enjoy? Or more unsolvable problems?

https://bugzilla.kernel.org/sh...
Also the single core performance is getting better, it's not amazing.

Well known sites like https://www.kernel.org/ [kernel.org] are flagged as insecure. Again only in chrome.

Just tried it. In Chrome on a Chromebook.

It says 'secure'. No warnings.

I don't use chrome but I do some testing with it every once in a while.

All of these security bullshit droppings in chrome is going to cause error fatigue for problems that are either not problems at all or worthless to most users.

All kinds of shit get errors that only appear in chrome. Certs that have a CN but not SAN are flagged only in Chrome for no sane reason.

Well known sites like https://www.kernel.org/ are flagged as insecure. Again only in chrome.

All resources protected by internal/corporate CA's I assume will now be flagged because none of them participate in log transparency.

I don't have a problem with CT if deployed properly /w user controls and privacy to avoid CT being another excuse for data leakage with widespread coordination and agreement among all stakeholders. But that isn't what happened here. Specifically:

Only Google requiring it with not much in the way of industry buy in.

RFC6962 is an experimental RFC not a standards track document.

Chrome requiring Google CT servers is over the top abuse of power.

Please point to any Linux distro that has 0 bugs.

https://bugzilla.kernel.org/sh...

But have they fixed this yet? Their second bug in Linux?

https://bugzilla.kernel.org/sh...

Yes.

But have they fixed this yet? Their second bug in Linux?

https://bugzilla.kernel.org/sh...

This has been weird... I have posted right now a reasonably big reply with conclusions after some tests/research which hasn't been stored. A bit tired I guess. I am not willing to re-write everything. The short summary is that I wasn't able to find a way for a process, supposed to only access a given address space (its regions are defined in /proc/PID/maps; this is the most similar thing I could find to your "base address"), to do anything with the memory allocated by another one. Regardless of the fact that certain highly sensitive, OS-accessible memory isn't properly managed, the question of how to access that memory remains. Even under ideal conditions (admin privileges, perfect information about the memory addresses and data types), a process running on the give OS can only access memory locations within its assigned range.

How can this be overcome? How can all these memory-dumps become useful? How could that famous-but-not-found-so-far app able to read passwords from Chrome be built? Even by having all the information regarding the memory location of the given strings, how could them be read by a random process? I think that this are all the main ideas which I wrote in that longer-&-now-lost post. If I misunderstood any bit or anyone knows about a ready-to-use sample delivering a tangible result, please let me know.

And when I read the git commit log, I see a more recent commit that enables it by default.

Which is a bummer: I personally use ARM devices more than x86_64, so I'm not exactly looking forward to the performance hit.

Forgive me. I thought the discussion was about Intel is trying to deflect blame by naming AMD in their press release about the bug the KPTI patchset addresses.

I thought it was relevant because ARM64 appears to have the same flaw, with corresponding kernel work, and AMD's Opteron-A is an ARM64 chip (one which I respect a lot, actually).

Perhaps we are agreeing with each other?!? KAISER (now named KPTI now) is a patch set to preserve the effectiveness of the kernel's address space layout randomization... without KASLR, rowhammer is a lot more dangerous.

Will's branch is is now named "kpti", and has been updated since the link I pasted earlier. (Still nearly a month since the last commit, though)

I won't claim to know the arch-specific ARM code, but they're doing a lot of work on the Kernel Address Space Layout Randomization code, which is what the kernel page table isolation is trying to protect. (That and the name of the branch certainly indicates it's addressing the same issue)

Have you just hit infamous bug 12309? It's ostensibly fixed however people keep reproducing it (just google for heavy I/O operations slow down my PC).

The developers behind the GRSecurity project measured up to 63% performance loss. If most common tasks are equally affected, Intel is sure fucked. Home users might not need to bother, but large cloud providers might be seriously affected.

Meanwhile the Linux kernel has received the largest incremental minor patch in its history (229KiB) - perhaps kernel 4.14.11 already contains all the required fixes.

I have a sneaking suspicion Intel shares will fall through the floor in the next few weeks because Intel CPUs might have suddenly become quite slower than their AMD Zen based counterparts.

Turns out they've just added another level to the page tables, taking it to 5.

https://www.kernel.org/doc/Doc...

https://software.intel.com/sit...

  I.e. looking up a virtual address now needs a lookup in PML5, PML4, Page Directory, Page Table. Of course the TLB caches lookups but adding more layers increases the time taken to handle a TLB miss.

I was hoping either Intel or AMD would introduce a more advanced page table - hashed inverted page tables like the ones used in PowerPC, the UltraSPARC and the IA-64 for example

https://en.wikipedia.org/wiki/...

https://www.youtube.com/watch?...

Or maybe someone's invented a better way to do it now.

At any given moment there are millions of people going through the source code of Linux looking for bugs and vulnerabilities. Hence why there are none.

Have an issue with an Apple product? Prepare to be ignored.

Are you seriously saying Linux has no bugs?

Just ask SUSE:

Just learn to read the docs if you insist on having esoteric options turned.
In 2017, RAID56 are still marked incomplete.

Modern filesystem are a huge pile of diverse features, some are fully stable and used in production (e.g.: RAID0 and 1) other are still in development (e.g.: RAID56).
Complain that BTRFS is completely crap because RAID5/6 isn't fully functionnal and production ready, is like complaining that the venerable XFS is utter crap because its copy-on-write and snapshotting doesn't work yet.

(and BTW, in-band deduplication doesn't even exist yet in BTRFS. ZFS is supposed to have it, but is an ultra-massive performance killer from what I've heard)
(auto-defrag works, but is a write-perfomance killer. alternatives a no defrag at all, which is a read-performance killer. or using out-band defrag, which requires maintenance and kills snapshot correlation.
all these are problem which are specific to copy-on-write (ZFS, BTRFS) and log-structured (UDF, F2FS) filesystems)
(

As you may know, RedHat has deprecated BTRFS in RHEL7.4 whereas many distributions like Ubuntu fully support ZFS.

I woud say that the status of BTRFS is worse than that of OpenZFS on Linux. See also here for an interesting article.

Ha ha. Ya got me there!

What about "build.c" in the "linux/tools" directory here: https://www.kernel.org/pub/linux/kernel/Historic/v0.99/linux-0.99.tar.Z

But I dunno. If you read the comments, that programmer doesn't sound all that sure of himself. Maybe take a chance on him? Lowball him and see if he bites?

But "If you need more than 3 levels of indentation, you're screwed anyway, and should fix your program."

Jakub's Mastering Git book discusses briefly that git is less a version control system in itself and more a tool for building version control systems.

Alternative user interfaces like Zit, Cogit and Yap show that there is some merit to this view.

Git's content-addressable data store with locally computable global identifiers can form the basis of a generic storage engine. Microsoft has created what appears to be another file system out of git. There are many other filesystem implementations.

The git wrapper and workflows used by the Linux project can be seen as just the demonstration of one implementation. Collaboration and hosting sites like GitHub and GitLab show that you can turn a git repository into a project management tool. People have even built code review tools out of git (Critic, git-issues, etc.)

I wonder if Microsoft could implement something like etckeeper for the registry? (It would be nice to be able to run git blame after corruption by some vendor's installer.)

I do find it odd that Microsoft is switching to git so the team can put Windows into a single, giant repository while trying to modularize the product. One would think that the prior Perforce based system would have suited the modularization goal. That was forcing multiple repositories on the developers to meet the scale of the codebase. Perhaps the intent is to centralize then reorganize and break out into logical modules again? (It could be a control freak VCS team that is jumping at the chance to become the gatekeepers.)

The article does mention that "the company wanted to develop a single engineering system ('1ES'), spanning not just version control, but bug tracking, building, and more, that could span the entire company. " This makes the next version of Team Foundation Server sound a lot like GitHub Enterprise from Microsoft. Should Microsoft offer this 1ES environment for sale? It could certainly add a twist to the corporate on-premise or could-based git hosting market.

I had to check our AWS systems as I was curious

All our systems are on 4.9 which is a bit more than CentOS 7 but not fully into RH8 land.

I wonder how long it will be till AWS pushes out 4.11.

You don't have anything to worry about; the summary is very misleading. TFA says: "Upgrade to Linux kernel 4.11 as soon as possible if you're using Linux 4.10".

4.9 is an LTS release and will be supported until Jan 2019. Even if using a version not supported directly by the kernel maintainers, many distros backport and test security fixes to their currently-supported releases for many years.

Kudos to Manuel for fixing this thing that's annoyed me for a good twenty years.

Impressive how small the feature patch is!

I'll be setting vgacon.scrollback_persistent=1 on my bare-metal x86 machines.

And I can tell you that you have no clue what you are talking about. I am one of the Linux kernel maintainers, and I keep a very close eye on this. The commit I believe previous was referring to: https://git.kernel.org/pub/scm...

Ext4 doesn't have user data checksums, only metadata: https://ext4.wiki.kernel.org/i...

I think it is an option. Journaled metadata is the default, but you can choose journaled data too. It is just not very well performing. The B-tree structure of writing new entries and switching atomically works much better that way.

Ext4 doesn't have user data checksums, only metadata: https://ext4.wiki.kernel.org/i...

Unless you replaced the root DNS trust anchor in the OS/browser on every single system on your network (something that any well-written OS/browser should make it VERY hard to do)

I don't see how that'd work. Even if it's hardcoded into the kernel, someone who controls all endpoints on a LAN can just recompile the kernel from source with a patch that changes the trust anchor to that of the MITM.

Who cares about EOL, when the firmware of your device includes a fixed kernel image which won't be updated, ever?

I mean, my current Android phone (using Marshmallow) employs a kernel 3.4.42, released on April 2013. The current version of the 3.4 branch is 3.4.113 (source), released on October 2016. I don't know if there are any critical (security, performance) improvements from 3.4.42 to 3.4.113, but I simply don't care becase I know the manufacturer won't publish an updated version of the firmware with a recent kernel. If a serious kernel security bug appears and it is solved in a new kernel version, it won't be solved in my device. The situation is way better when you consider Linux desktop distributions, but still...

What I mean is that for at least 99% of the people, the kernel is an atomic part of the firmware of their device (phone) and they won't bother about updating it. With this in mind, there should be no recommendations to the final users ("yelling very loudly" because your Android phone employs a given kernel version, haha), EOL is only significant for upgradeable systems. Not even phone designers need to worry about using LTS: they know they will never update their kernel.

Who cares about EOL, when the firmware of your device includes a fixed kernel image which won't be updated, ever?

I mean, my current Android phone (using Marshmallow) employs a kernel 3.4.42, released on April 2013. The current version of the 3.4 branch is 3.4.113 (source), released on October 2016. I don't know if there are any critical (security, performance) improvements from 3.4.42 to 3.4.113, but I simply don't care becase I know the manufacturer won't publish an updated version of the firmware with a recent kernel. If a serious kernel security bug appears and it is solved in a new kernel version, it won't be solved in my device. The situation is way better when you consider Linux desktop distributions, but still...

What I mean is that for at least 99% of the people, the kernel is an atomic part of the firmware of their device (phone) and they won't bother about updating it. With this in mind, there should be no recommendations to the final users ("yelling very loudly" because your Android phone employs a given kernel version, haha), EOL is only significant for upgradeable systems. Not even phone designers need to worry about using LTS: they know they will never update their kernel.