Slashdot Mirror

More than create buzz as this paper shows, the great benefit of piracy is the countervailing pricing power it imposes. Piracy helps in a better price discovery for "legal" content. https://news.iu.edu/stories/20...

Sadly, this probably means more shit spaghetti code than ever before. Another good reason for Google to ditch this in favor of Fuchsia / Zircon.

Linux being known as "free software" by just about everyone that cares about computers/IT is enough reason to skip the acronym. Besides, humans are lazy by nature, so why force people to tack on an acronym that many people can't even pronounce right?

BTW - This is the best GNU definition to give to anyone who doesn't know what GNU means. It's clean, concise, and very short - yet quite complete somehow.

... to Intel's announcement.

Especially given what he had to say about the patches in the first place:

http://lkml.iu.edu/hypermail/l...

I.e. the 6700K.

I.e. all the chips have PCID

It's a bit hazy when PCID and INVPCID became supported.

This says PCID was first supported in Westmere

https://www.realworldtech.com/...

Another long overdue improvement to the page tables is the Processor Context ID (PCID). The PCID is a field in each TLB entry that associates a given page to a process. Previously, Intel's TLB could only contain entries from a single process and whenever the CR3 register was written (e.g. a context switch), the TLB was flushed. The PCID lets pages from different processes safely inhabit the TLB together, so that CR3 writes no longer flush the TLB. Whenever a process tries to access a page in memory, the PCID is checked to determine whether the page is actually mapped into the process' address space; if the PCID does not match then a TLB miss occurred. This is very much analogous to Intel's VPID, which enables the TLB to contain pages from different virtual machines and avoid TLB flushes during VM transitions.

The LWN patch says

http://lkml.iu.edu/hypermail/l...

PCIDs are generally available on Sandybridge and newer CPUs. However,
the accompanying INVPCID instruction did not become available until
Haswell (the ones with "v4", or called fourth-generation Core). This
instruction allows non-current-PCID TLB entries to be flushed without
switching CR3 and global pages to be flushed without a double
MOV-to-CR4.

I.e. it'd be interesting to see what happens on a CPU old enough not to support enough of PCID/INVPCID to optimized KPTI.

The claims of >10% hits are all for these old CPUs.

Why link to the softpedia article instead of the actual mailing list post Linus made?

http://lkml.iu.edu/hypermail/l...

Anecdotes? Whoa there, buddy, you're argument about a few people is clearly statistically significant! I guess we should discard what scientists say because it doesn't seem right to you.

Its a data point, and one shared by others. It's shared as well by universities, who are spending that money to retrain students and especially their parents

You want references? Need data? Of course in social matters what constitutes data is ephemeral but here goes:

http://counseling.uoregon.edu/...

https://www.washingtonpost.com...

http://news.fsu.edu/news/educa...

http://newsinfo.iu.edu/web/pag...

I can give you hundreds more, so label Universities as trolls and call each one irrelevant.

My anecdotes - and I can give you more - merely corroborate the larger experience. Point is, young adults come out with unrealistic expectations, have not been allowed to grow up and have trouble making their own decisions, and are prone to depression and disappointment, and their parents are the cause.

They are damaged goods, and will need a decade of trying to sort out what they should have learned since childhood. Don't blame your grandparents, and don't blame yourselves. But blame only goes so far, so ya gotta pick yourselves up and move on.

Yeah, that's the quote everyone highlights, but he's a bit more nuanced about it when he's maybe a bit less pissed. Two e-mails in, you have http://lkml.iu.edu/hypermail/l...:

Killing machines because somebody made an assumption that was wrong is not ok.

Killing the machine is ok if we have a situation where there literally
is no other choice.

not a cuss word or insult to be found anywhere in that announcement.

Go ahead, point out where in here

labelling some members “brain-damaged”

is.

"your commenting style/code/idea/product/argument/... is stupid" != "you are stupid".
If you can't tell the difference, seek professional help.

That would be Masturbating Monkeys.

S/MIME is pre-installed on most mail clients. It works on iPhones, Thunderbird, Outlook (the one with a client, not the web version)... I used to use it with kmail back in the day, more than ten years ago. It's been a standard feature that long, and the DOD's been using it forever.

The only problem is that S/MIME, like PGP, GPG, and the ilk, doesn't work on webmail for reasons contested on other threads in this discussion. Gmail is primarily webmail.

No thanks http://lkml.iu.edu/hypermail/linux/kernel/1506.0/02415.html

This is an article about the linux kernel.

Alas, systemd does have its eyes on the very kernel. Rembember that the systemd crowd is super-insistent in its push to implement D-Bus in the kernel. Consider also that the maintainer of the LTS kernels is really into the systemd craptasm. He's one of the cheerleaders of kdbus.

To demonstrate that systemd's push for the kernel has indeed been a concern for kernel developers, consider this from Ted Ts'o in the LKML from a year ago.

Intriguing.

Your comment prompted me to search for references for this (I searched for "linus systemd freebsd", if you're curious). The first I pulled up was this, which quotes him saying:

I don't actually have any particularly strong opinions on systemd itself. I've had issues with some of the core developers that I think are much too cavalier about bugs and compatibility, and I think some of the design details are insane (I dislike the binary logs, for example), but those are details, not big issues.

The second is this, a mailing list thread in which Linus expresses his dearly-held opinion on Kay Sievers and his attitude to systemd bugs. Sounds like Kay isn't the most pleasant developer to work with), though that's hardly an indictment of systemd-the-project.

The third is this, a Slashdot story from a few months ago, where Linus says this:

I have to say, I don't really get the hatred of systemd. I think it improves a lot on the state of init, and no, I don't see myself getting into that whole area.

Yeah, it may have a few odd corners here and there, and I'm sure you'll find things to despise. That happens in every project. I'm not a huge fan of the binary logging, for example. But that's just an example. I much prefer systemd's infrastructure for starting services over traditional init, and I think that's a much bigger design decision.

Yeah, I've had some personality issues with some of the maintainers, but that's about how you handle bug reports and accept blame (or not) for when things go wrong. If people thought that meant that I dislike systemd, I will have to disappoint you guys.

What I'm taking home from those first three hits is that:

1) Linus doesn't hate systemd;
2) Linus hates having to work with Kay Sievers;
3) Linus isn't abandonding Linux or moving to FreeBSD, certainly due to systemd.

Do you have other references that would refute point 1) or 3)? I'm not saying you're wrong, but I'm skeptical, and would like to see some evidence for your claim.

Hannes seems to have a valid point that boundary checking should be standardized in some way. Rasmus backs him up and mentions the result of the rant is they'll end up discarding his more comprehensive work on the issue: http://lkml.iu.edu/hypermail/l...

Linus seems to be saying all boundary checks should be ad-hoc because the new syntax is to hard to GET OFF OF HIS LAWN. Because it is dog poop.

http://lkml.iu.edu/hypermail/l...

They held off for a release.

http://lkml.iu.edu/hypermail/linux/kernel/1309.1/00905.html

HIPAA imposes fines for each patient's record lost through security breaches, even if the medical provider "did not know (and by exercising reasonable diligence would not have known)" https://kb.iu.edu/d/ayzf that there was a breach. These kinds of punitive rules have scared the entire industry to death, and yet the open secret is that nobody is safe from breaches, or these fines. This story illustrates how the law has done little, if anything, to actually protect privacy.

Most providers react to HIPAA in one of two ways:
1) They over-react, creating stupid policies like refusing to tell even a patient's own spouse the details of a patient's medical condition, unless the proper paperwork has been filed, or
2) They under-react, blissfully ignoring any privacy concerns.

If we're going to try to regulate privacy in the medical industry, how about let's focus on the device and software makers with certification programs, and let hospitals and physicians get back to doing what they do best: treating illnesses.

A previous poster linked to a post by Eric Biederman that should be required reading for this Slashdot thread. I'm not sure which part to quote, because the whole thing is pretty damning: Kdbus needs meaningful review

On one hand, the post (and lack of kdbus in kernel 4.1) seem to indicate that you are correct, and the process is working. OTOH, Eric argues that:

• Kdbus code is nowhere near ready for a merge, it hasn't been reviewed, and in fact may need major reworking before it can be used or reviewed.
• Kdbus authors are pushing the merge very aggressively, and have made a habit of ignoring criticism and refusing to take steps necessary to even make the code reviewable.

You are interpreting this much too hard. Every time a new important kernel features come you have these kind of statements. The point being that some reviewers set the standard to "perfect" to begin with. That way nothing will be merged, so from now on people have to battle out the details until Linus is satisfied. Eg. Linus has personally stated that some of the criticism that Biederman repeats are wrong (about caps metadata in an exchange with Lutomirski).

All in all this is business as usual, and the kdbus developers have been very very quick to change anything specific that has been pointed out as problematic. That they are eager to get things merged is just how such things work, same with reviewers that says "hold your horses".

There are pretty good odds on that kdbus will be merged into mainline in not so far a future when things have been trashed out on lkml a while.

Hopefully the open source community will review kdbus code very carefully and perform security testing before adopting this.

They will. Sure there will be lots of sparing and harsh word duels, and not everybody will be happy, but that is how the process works for any major kernel feature. In the end the process tend to produce good enough results.

A previous poster linked to a post by Eric Biederman that should be required reading for this Slashdot thread. I'm not sure which part to quote, because the whole thing is pretty damning: Kdbus needs meaningful review

On one hand, the post (and lack of kdbus in kernel 4.1) seem to indicate that you are correct, and the process is working. OTOH, Eric argues that:

• Kdbus code is nowhere near ready for a merge, it hasn't been reviewed, and in fact may need major reworking before it can be used or reviewed.
• Kdbus authors are pushing the merge very aggressively, and have made a habit of ignoring criticism and refusing to take steps necessary to even make the code reviewable.

This post was from last week.

Having used Linux audio from before PA came into existence, and having used PA from the beginning, I can assure that PA was a major step forward in fixing Linux audio. With PA sound on Linux actually began to work. Sure it exposed a lot of kernel bugs (drivers) and ALSA bugs in the beginning, and some distros and software got the implementation wrong, but it lead to the first coordinated bug fixing effort between drivers, ALSA and user space. PA was always rock solid for me, and while it had some bugs, but far the most serious and numerous was in the drivers and in ALSA layer.

Yeah, I don't know. I've been using Linux for 20 years, and of course it's steadily become much more usable. My experience with PA was that it implemented some very useful features, but was not rock solid.

When I tried to configure PA to use a sample rate over 100KHz last year, it consistently brought down the entire system. This was on a very capable machine, and high sample rates should be a basic use case for PA. I didn't dig into the cause, but it was PA itself that thrashed the CPU, so it seems unlikely that particular defect was caused by the layers underneath.

If some of you stopping look at every thing systemd tinted glasses you might start reacting like rational adults.

Funny you should say that, AC. I'll wait (not holding my breath though) for the rational, adult answer of G H-K to this message and a timeline for addressing the issues it raised:

http://lkml.iu.edu/hypermail/l...

To quote the last part:

Not that this complaint is not in any sense new you have been ignoring people who try to bring up meaningful issues for a long time. The fact that when people bring up uncomfortable points about the kdbus code they get routingely blown off certainly contributes to the lack of meaningful review as it is not rewarding to work with someone who does not listen to criticism. At this point the strongest possible language and the strongest possible push back are being used because everything else is routinely swept under the rug.

So, feel free to engage in that rational discussion anytime now.

Sure, many systemd-opponents harbour fantasies like that.

Many systemd proponents harbour fantasies of it being the one true way of doing......anything and want to wave away the problems.

This, by the way, is Linus's take on kdbus and why it won't be seen in the kernel for some time to come, if ever:

http://lkml.iu.edu//hypermail/...

Greg - just for your information, I will *not* be merging any code from Kay into the kernel until this constant pattern is fixed.

This has been going on for *years*, and doesn't seem to be getting any better. This is relevant to you because I have seen you talk about the kdbus patches, and this is a heads-up that you need to keep them separate from other work. Let distributions merge it as they need to and maybe we can merge it once it has been proven to be stable by whatever distro that was willing to play games with the developers.

Regardless of any other bullshit and hearsay, that is the policy of the kernel. When he says 'Kay', read any systemd developer. Oh, and no, it's not a joke and no he doesn't write the e-mails on the kernel mailing list for the goodness of his health.

Let's not forget the other contender for replacing Bitkeeper: Mercurial. We will also be celebrating its 10th year anniversary next week during the Pycon sprints.

Mmph. If you have sub-repositiories, it is really easy to get a Mercurial repository into a bad state that takes much voodoo to get consistent again.

Let's not forget the other contender for replacing Bitkeeper: Mercurial. We will also be celebrating its 10th year anniversary next week during the Pycon sprints.

It's not the "TSYNC feature", it's SECCOMP_FILTER_FLAG_TSYNC

http://lkml.iu.edu/hypermail/linux/kernel/1406.1/01964.html

(Buggered if I know what it's for, however).

Sure they will, he's just doing it one dev at a time ;)

Other than that, what should I know about who this guy is? Because the summary (which is, I'm told, also the article) tells me nothing.

Err, he is essentially Linus Torvalds' left hand man. :)

Read the Linux Kernel Mailing List to keep tabs on what is happening in Linux development.

That's something different.

See this LKML page. Search with CTRL+F for "frequent lockups in 3.18rc4".

The thread is clearly still going on. As far as I can tell, the bug has not been fixed.

yes:

http://lkml.iu.edu/hypermail/linux/kernel/1411.3/04672.html/

https://bugzilla.kernel.org/show_bug.cgi?id=85941/

Amusing attitude. "I can do whatever I want, others have to clean up after me".

Yes. Too bad it only affects rare server configurations.

It happens to this guy when he is watching YouTube or playing an audio file.

Guys, do you ever read LKML where this stuff happens? Your GP comment said that they have found multiple bugs. No, they haven't. They are dealing with the very same bug where the watchdog detects a soft lockup. There is no debugger attached at this point, they are just doing bisecting (another powerful tool of course) to find what was the specific patch that introduced the bug. Browse through the LKML archive and search for the subject "frequent lockups in 3.18rc4".

"Older"? How about "only" spelling, when dealing with a computer program (primarily in Unix systems) as was referenced. The word has a meaning going pretty far back, but has never changed. https://kb.iu.edu/d/aiau>Daemon stands for Disk and Execution Monitor.

A daemon is a long-running background process that answers requests for services. The term originated with Unix, but most operating systems use daemons in some form or another. In Unix, the names of daemons conventionally end in "d". Some examples include inetd, httpd, nfsd, sshd, named, and lpd.

Quoting a small snippet from a larger work with attribution in the USA is generally fair use. But in any case, how can the Free Software Foundation claim that code that links to GPL libraries even *dynamically* is a derived work if APIs are not copyrightable? As much as I am against excessive copyright, people can't have it both ways.

Others disagree though, although I think they are probably wrong (but its up to the courts etc...):
https://www.publicknowledge.or...
"There's a dangerous meme going around that if Oracle loses its novel copyright claims against Google that suddenly the GPL will become unenforceable. This idea hinges on a misunderstanding about the difference between linking to a code library and merely using an API. ... Florian Mueller, who provides indispensable analysis of various intellectual property issues in the mobile industry, believes that whether an API is copyrightable can only be determined on a case-by-case basis. He is certainly right that the overall design of a system of APIs can show "creativity," in the same sense that a brilliant mechanical invention is creative. But that does not mean that copyright is the proper way to protect that creativity, if at all. Copyright extends only to "original works of authorship fixed in a tangible medium of expression," and a system of API calls does not meet that test. It is not a "fixed" work in the same way that an actual computer program is. I will not address whether a system of APIs is patentable, but certainly the creativity that a well-designed API scheme might show is closer to the creativity that a concise mathematical statement (not patentable) or a new design for an engine (patentable) might show. In any event, simply because something is "creative" in some sense does not mean that it deserves legal protection, unless it can be shown that some desired level of creativity would not happen without such protection. I do not see any evidence that the dynamic and innovative software industry requires copyright protection for APIs to maintain its current high level of creativity. ..."

Some people also suggest the dynamic linking issue for the GPL would not hold up in the Supreme Court...

To add to the confusion, from Richard Stallman:
http://lkml.iu.edu//hypermail/...
"Someone recently made the claim that including a header file always
makes a derivative work.
That's not the FSF's view. Our view is that just using structure
definitions, typedefs, enumeration constants, macros with simple
bodies, etc., is NOT enough to make a derivative work. It would take
a substantial amount of code (coming from inline functions or macros
with substantial bodies) to do that."

How can he say that and still argue that dynamic linking to a GPL's library makes something fall under the GPL?
http://en.wikipedia.org/wiki/G...
"This key dispute is whether or not non-GPL software can legally statically link or dynamically link to GPL libraries. Different opinions exist on this issue. The GPL is clear in requiring that all derivative works of code under the GPL must themselves be under the GPL. Ambiguity arises with regards to using GPL libraries, and bundling GPL software into a larger package (perhaps mixed into a binary via static linking). This is ultimately a question not of the GPL per se, but of how copyright law defines derivative works. The following points of view exist: ... The Free Software Foundation (which holds the copyright of several notable GPL-licensed software products and of the license text itself) asserts that an executable which uses a dynamically linked library is indeed a derivative work. ..."

So, while they are at it, why not get the Supreme Court to rule on that dy

But at least there's an upside for me: I don't have to deal with the systemd maintainers' excessively passive-aggressive behavior ;-)

There is nothing ambiguous about that.

But at least there's an upside for me: I don't have to deal with the systemd maintainers' excessively passive-aggressive behavior ;-)

There is nothing ambiguous about that.

> Yea, but if you mess up and do something he declares "STUPID"

And if HE messes up he calls it moronic.

http://lkml.iu.edu//hypermail/...

Yeah, what Andrew said. My suggestion of per-task or per-cred is
obviously moronic in comparison.

Linus "hangs head in shame" Torvalds

And Linus isn't afraid to admit something is complex.

http://lkml.iu.edu//hypermail/...

Oh, Christ, I see what you are talking about.

That interface is all kinds of crazy.

> Yea, but if you mess up and do something he declares "STUPID"

And if HE messes up he calls it moronic.

http://lkml.iu.edu//hypermail/...

Yeah, what Andrew said. My suggestion of per-task or per-cred is
obviously moronic in comparison.

Linus "hangs head in shame" Torvalds

And Linus isn't afraid to admit something is complex.

http://lkml.iu.edu//hypermail/...

Oh, Christ, I see what you are talking about.

That interface is all kinds of crazy.

Another response from Linus...

http://lkml.iu.edu//hypermail/...

Indeed. Note what Linus says further down the thread:

>
> Well, parsing kernel cmdline by systemd is a bad idea
No, we very much expose /proc/cmdline for a reason. System services
are *supposed* to parse it, because it gives a unified way for people
to pass in various flags. The kernel doesn't complain about flags it
doesn't recognize, exactly because the kernel realizes that "hey,
maybe this flag is for something else". ...
And yes, that does include "quiet" and "debug". Parsing them and doing
something sane with them is not a bug, it's a feature. ...
And the thing is, this has never really been a problem in practice.
Because nobody minds if some kernel option like "debug" makes not only
the kernel enable debugging, but some system deamon log a bit more
too. ...
HOWEVER.

It does become a problem when you have a system service developer who
thinks the universe revolves around him, and nobody else matters, and
people sending him bug-reports are annoyances that should be ignored
rather than acknowledged and fixed. At that point, it's a problem.

It looks like Greg has stepped in as a baby-sitter for Kay, and things
are going to be fixed. And I'd really like to avoid adding hacky code
to the kernel because of Kay's continued bad behavior, so I hope this
works. But it's really sad that things like this get elevated to this
kind of situation, and I personally find it annoying that it's always
the same f*cking primadonna involved.

One of the original suggestions was utilities parsing the kernel command line was a Bad Thing (TM).

The message to which Linus responds is also interesting:

Short story:

The systemd guy uses the debug keyword on kernel command line to spool a huge log - which can hang the boot process, and that is the problem.
Then the same guy claims that the debug keyword is generic so it can't be reserved by the kernel, even if it's been used first by it since a long time...

I can say that Linus is right there, for sure. He's maybe too kind...

My thanks to you and the AC above.

Both those Wikipedia pages linked to this benchmark, that showed Dm-cache is another option that gives very good performance in write-back caching mode (adequate for most desktop machines),

http://newsinfo.iu.edu/pub/libs/images/usr/15356_h.jpg
Not too shabby looking for a line of racks. Please donate your $0.02 to a charity of your own choice.
Though from the looks of it, I expect it to be mostly calculating ballistic trajectories originating in eastern Europe.

Is internet traffic really only 26 Petabytes a month, while that is a big number it sounds awefully low to me as the place I work does 15 Terabytes a month and they are little more than a miniscule pimple on face of the internet.

That's just wrong. Open Science Grid transfers about 1.4PB a day and I seriously doubt OSG uses a significant fraction of the bandwidth on the net.

"Leveraged support model" does not mean what you think it means.

This is the best definition I can find:

N-ways

Multi-core compute nodes can be described by the number of execution units, or cores. A computer with 8 cores would be described as an 8-way node. This machine can have 8 independent processes running simultaneously. A 32-core system would be called a 32-way node.

Some hold that it only pertains to the number of physical cores and sockets, but I've seen it used when describing a system based on the number of threads as well.

Can you believe that the Internet was once considered a place to escape identity? Where anonymity reigned? It's pretty amazing in retrospect how quickly that changed

The Internet was once a place where your real identity was also your online identity. The schools, companies, and organizations which comprised the Internet all voluntarily enforced a policy where each user's username was their real name, or anyone could easily figure it out from their username.

Anonymity didn't really arrive on the Internet until 1993, when AOL joined. AOL users were allowed to pick up to 5 pseudonyms as their email address (because one AOL account might be shared by an entire family). In retrospect, that change was really quick - a span of a couple years and pretty much everyone was allowed to pick whatever they wanted as a username.

Personally, I think anonymity is the proverbial genie that's been let out of the bottle - it's gonna be really, really hard to put it back in. But a non-anonymous Internet isn't something new; it was the norm a mere 2+ decades ago. The funny thing is that when AOL joined, a lot of people were saying that anonymity would be the death of the Internet due to spam (it was already polluting Usenet), flame wars, posers, etc. When e-commerce was first taking off, people were questioning how online stores would ever be able to validate a customer's real identity when everyone was effectively anonymous behind self-selected usernames. Now the tables have turned and people are saying having your real identity known online will be the death of the Internet.

The Internet has survived both extremes, so it's reasonable to think that it will also survive anything in between.

Yes, because losing or breaking an mp3 player is the same as iTunes automatically erasing it.

Here, in detail, is why iTunes erases music.

In case you can't click the link:

How do I stop iTunes from erasing audio files from my iPod, iPhone, or iPad?

All audio files stored on an Apple iPod, iPhone, or iPad may be erased when the device is connected to a new or recently reformatted computer or hard drive. This is because the contents of the iPod, iPhone, or iPad correspond to audio files added to the iTunes music library on the first computer it is ever connected to. When the device is connected to a different computer running iTunes, all stored audio files may be changed to match the computer's music library. This happens if you set the music synchronization to update automatically, or reset iTunes to its default settings; iTunes is set to synchronize automatically by default.

No dialog box that says "we're erasin' your stuff" -- I love how Apple users felt the need to LIE about that! Pathetic.

For the lulz eh?