Slashdot Mirror

Which only implies you don't run into the corner cases, which work well with all other logging solutions, but systemd developers failed to consider in the first place and refuse to fix now. Nice mentality for you and the systemd developers.

Shouldn't they be tagged as "sponsored content"?

Maybe you should just go here instead and stop bitching on slashdot about slashdot. But I suspect that, like the majority of slashdotters, you aren't really interested in Linux hence the reason kernel news gets a couple dozen comments and anything about Microsoft, Google or Apple has hundreds of echo chamberists chanting "SPYWARE" "ANTITRUST" "VENDOR LOCK-IN".

No. "You caused the problem, you need to fix it", whether open source or not.

Correct, you created a dependency on RedHat and now they are doing something you do not like. They are not beholden to your whim, they can do whatever they wish with their project. You were stupid and now you have to fix your mistake.

No. "You caused the problem, you need to fix it", whether open source or not.

which has very minimal, I can even say non-existing, QA/QC and no unit tests at all.

Not so greatest then, considering the number of regressions in each kernel release.

Not so greatest then, considering that people get tired of adjusting their code to new APIs which inevitably leads to even more regressions.

Not so greatest then, considering that bug reports in bugzilla.kernel.org often receive zero attention and LKML posts are lost in the noise of hundreds of patches published every day.

You know, Greg, you don't sound convincing. You sound like a marketer of some dietary supplement.

I know this comment will be modded to hell by rabid Linux fanboys, but I'm just tired of this BS remarks made by open source advocates. The truth of course is a lot less exciting.

Linux is like an ecosystem , with some companies at the top of thew food chain and others who are forced to live underneath them.

What you THINK is Linus is at the top of that foodchain. In reality, Redhat is at the top of that foodchain, and Linus, Mark and everyone else - all other distros -get a lot of code RedHat writes forced onto them whether they like it or not. They are by far the biggest, most well funded, most prolific and most influential Linux distro Plenty of core functionality issues out of them, and because so many other device makers and 3rd party software makers write code which depends on their code, all other Linux distros are forced to follow suit.

Fo course, once code is depended-upon by a large number of 3rd parties, that dependency spreads like a cancer and all Linux distros are forced to include that depended upon code.

And what makes RedHat so sucessful, what lets them maintain their position as top dog / ecosystem dictator? One thing- the contracts it has with the US government.

And what code might I be talking about? I might be talking about Systemd.

http://www.infoworld.com/artic...

You can read about it at this link and especially the ones below but tldr; It Came From Redhat and provoked nonthing less than a civil war in Linux over whether it will be included.

Shuttleworth proclaimed it would never be included in Ubuntu and Linus railed against it, but to no avail. In the end they both submitted to the power wielded by Redhat.

True, there's only a 99% chance this inscrutable mess of code, which has staged violent coup after violent coup against the territory previously held by nicely isolated and well understood parts of Linux *at the lowest levels* isn't a government sponsered backdoor-via-oopsie-a'lookie-at-that-bug-we-wrote ! but that's small comfort to the rest of us who need somewhere to run from the privacy-raping, eavesdropping, keystroke-logging, backdoored piece of shit Torjan known as Windows 10 when Windows 7 stops being habitable.

So yeah, the guy who has root on every Ubuntu installation in the world and was publicly submitted into bowing before and pledging his eternal allegience and fealty to His Majesty the King wants everyone to know that King's clothes are marvelous and all this talk of a naked King is just bunk.

https://lkml.org/lkml/2014/8/1...

http://www.linuxuser.co.uk/fea...

The basic tension here is the use of technology by Bad Guys gives them preternatural power to do bad things in big ways. OTOH , the state sponsored panopticon which is deployed, in all earnestness- let us not pretend otherwise, seriously, I don't question their motives even a little - is a known recipe for the destruction of democracy, dissent and a death sentence for a healthy society. But only a free and healthy society has any hope to counter terrorism. Absent freedom of thought and freedom from intimidation, short-term, parochial local incentives borns of personal fiefdoms take over policy making completely and that society is doomed to fall, just like Rome.

We cannot allow ourselves to become Rome. The only way to do that is to prevent the government from deploying a system which could be used by future governments to crush dissent and independent thought. That is, to crush anonymous speech and the freedom to explore ideas and voicing opinions which run counter to powerful interests.

It not that terrorism doesn't have the potential to bring a doomsday to us all, they most certainly do, it's that through an indirect process which is nevertheless guaranteed to be realized, that potential turns into an absolute certainty if the government is able to get root on all our keystrokes.

Which is irrelevant to the question about technical merits of journald. And I see nothing but crap in journald.

Logging is one of the fantastic bits about systemd, its far more comprehensive than anything else. Its just a matter of learning about the new features and tools.

In other words, "... the worst part of systemd by far is the insane binary logging crap, and I would not be surprised if you have scrogged logs. Quite frankly, everything else in systemd at least has an _excuse_ for it. The binary logging is a pile of unadulterated shit."?

Wow, "I can do whatever I want, others have to clean up after me" once again?

Wow, "I can do whatever I want, others have to clean up after me" once more?

The only place where I feel it falls somewhat short is in systemd-networkd which currently lacks good support for policy routing. Fortunately, it doesn't bar me from running a post-network-up script to do command-line based route installation, so until it develops that functionality, that's what I'm doing.

Linus is challenging you:
> the worst part of systemd by far is the insane binary logging crap, and I would not be surprised if you have scrogged logs. Quite frankly, everything else in systemd at least has an _excuse_ for it. The binary logging is a pile of unadulterated shit.

Calling Android Linux at this point is absolutely pointless. Its Tivo-ization 2.0

It appears you aren't very familiar with the history of Linux. While nobody is calling Android Linux (because Android is software that encapsulates the Linux kernel much like Ubuntu or Slackware), Android systems are indeed using Linux as their kernel and Tivoization is encouraged. Torvalds himself says "I think Tivoization is *good*." It's the Free Software advocates that say Tivoization is bad and Linux is not a vehicle for the FSF to push their agenda, hence the license preamble (preceding the GPL) in the COPYING file, lack of copyright assignment and the refusal to engage even considering a move to GPLv3.

Are you seriously still complaining about this?

The last odd kernel was released in 2003. In 2.6 stable and unstable merged. Kernel 3.0 wasn't even a drastic change.
https://lkml.org/lkml/2011/7/2...

Between 2.4 and 2.6 linux was drastically overhauled. We really don't need separate non stable versions anymore. Plus version control is far better now.

As Linus Torvalds himself would say in this case, "Anonymous Coward, SHUT THE FUCK UP!"

Seriously, read how our God and Savior has responded to similar kernel regressions in the past:

It's a bug alright - in the kernel. How long have you been a
maintainer? And you *still* haven't learnt the first rule of kernel
maintenance?

If a change results in user programs breaking, it's a bug in the
kernel. We never EVER blame the user programs. How hard can this be to
understand?

WE DO NOT BREAK USERSPACE!

Don't go fucking blaming VMware. It's a kernel bug. And as Lord Torvalds himself says, "WE DO NOT BREAK USERSPACE!"

News like this is important because it highlights the sorry state of Linux today.

Linux used to be all about quality, stability, reliability, and robustness. Linux is what we used to use when we wanted our computers to just work, and continue working.

Yet over the last 5 to 10 years, we've seen a massive decrease in quality across the board. It isn't just Ubuntu. This affects pretty much all distros.

Many of us switched to Linux in the first place because we were fed up with Windows repeatedly crashing, or Mac OS being too limited.

For a long time Linux was better than both of them. We could use Linux for months on end without it crashing, and it gave us the full power of a UNIX-like environment, too.

But that has been eroded away.

Like we see in this incident, Linux has become less-stable than Windows. First there are these kernel fixes, indicating a low quality to begin with. Then there was the regression introduced by the fixes, which further shows a lack of quality!

A kernel change should never break user space. Ever. As Linus Torvalds himself said, "If a change results in user programs breaking, it's a bug in the kernel. We never EVER blame the user programs. ... WE DO NOT BREAK USERSPACE!"

So not only is Linux now approaching the low level of stability we saw with Windows 95 and 98, but it's also stripping away the UNIX-like environment that made it so powerful. We're seeing more and more anti-UNIX software being included in most distributions, including systemd and GNOME 3.

So this makes many of us ask, Why the heck do we still use Linux?!

We need stability. We need a UNIX-like environment. We don't want to use Windows. Linux used to offer all of that, but no longer does. So many of us have moved to FreeBSD, with the rest going to OS X.

You might say, "Well, fuck off then! We don't need you!", but it turns out that we are the kind of people the Linux community desperately needs. We are the ones who contributed code, fixes, bug reports, and documentation. We are the people who helped make Linux what it is. As we've been slowly driven away from Linux we've seen the quality continue to fall and fall. We surely won't be coming back as long as that's the case!

So it could very well be a chicken-and-egg problem. Linux initially drew us in because it was better than the competitors. But now that it has become worse, thanks to efforts like systemd and GNOME 3, we are being driven away. And as we are driven away, Linux gets even worse and worse. But since it's getting worse, it doesn't draw us back in! The FreeBSD and OS X communities now benefit from our contributions, while Linux withers away.

What's the point of continuing with Hurd?

Well the FSF doesn't really have an operating system kernel representative of the Free Software ideology. The closest thing is the Linux kernel which Linus has clearly said simply uses the GPLv2 for tit-for-tat contributions because it is a good license, not because Linux is a free software project. Of course it also doesn't do copyright assignment to the FSF and also is not GPLv3 and is unlikely to migrate to further revisions of the GPL in future.

As the FSF evolves the Linux kernel's position on free software does not evolve with them so to evangelize free software the FSF really needs an operating system representative of their ideals, that is what GNU Hurd is.

I agree. It's terrifying (well, more disappointing) that completely unsubstantiated claims from someone who was chatting anonymously on IRC are being taken seriously by anyone,

Well if it's fake, it's a long con. Especially after you start seeing all this stuff right?

A reddit user (beethovens_ear_horn) pointed out comment of a female kernel developer about Sarah Sharp in 2013 (when she started the fire):
https://lkml.org/lkml/2013/7/2...

Clearly, it's a gender problem in LKML, ;)

This is the "deepthroating Microsoft" he's referring to: https://lkml.org/lkml/2013/2/21/228

It was a pretty stupid idea, and it isn't surprising that Linus shot it down.

Exactly. According to: https://en.wikipedia.org/wiki/Matthew_Garrett

This guy is work-related to almost every every dickhead scheme the Linux community ever had except systemd.

-Worked for Canonical
-Worked for RedHat
-Contributor to GNOME
-Was ready to give in to Microsoft's key signing power grab
-Hissy fit over Intel and advertising??? (seriously?)
-Told by Linus Torvalds to go ahead and suck Microsoft's big daddy long stroker (nice one!)

This Matthew Garrett dude needs to go back to working with fruit flies. Ubuntu sucks. They are Microsoft wannabe's. RedHat was nice until 7.3, and at 8.0 they started trying to be the Microsoft of Linuxes. A lot of people uninstalled permanently including me. The only two distros that ever sucked are Ubuntu and RedHat-after-7.3. The dude was in on both of them.

If I see his Linux fork, it will never be downloaded by me. I like BSD a lot, and it's great to have BSD and Linux. If you want something in between the two use Slackware. It lists him as a contributor to Debian... which is an very good mature distro... and has a huge amount of even binary software available. Surely Debian can do without Dr. Fruit Fly.

https://en.wikipedia.org/wiki/Matthew_Garrett
https://en.wikipedia.org/wiki/Lennart_Poettering
^ These two should have one fork and one fork only. Fruit Fly Linux featuring the systemd kernel. Anything that would keep their shit away from other Linuxes would be welcomed. By that I mean Lennart's code and Matthew's poor judgement. Both of them have shit judgement.

Not waiting for a submit timer but this commenter can fuck off. http://linux.slashdot.org/comments.pl?sid=8129259&cid=50672331

You don't blame Linus? When people are talking about signing and parsing PE binaries, and whether that belongs in the kernel or in userland, you think that it's perfectly acceptable to talk about sucking dicks? That's effective management to you?

I mean, why can't Linus just make his point without multiple references to sucking dicks? Why is that not an option?

That's the point he's making. He's not talking about whether or not Linus is correct, he's talking about the way in which Linus chooses to communicate.

Smart people aren't offended by blunt honesty. Linus is very effective. Linux is on 97%+ of supercomputers worldwide, a vast number of huge corporations, the vast majority of websites, the International Space Station, governments, Android devices, etc. Fuck how he communicates, it's good. Linus is right. Right is what matters, not politely being a fucking douche. Linux tries to be the best OS for the sake of being the best OS.

https://www.youtube.com/watch?v=JZ017D_JOPY
https://www.youtube.com/watch?v=iYWzMvlj2RQ

"The way we have come up with to get around this is to .. get the binary signed by Microsoft." ref

This has to be the second most dumbest idea a kernel developers ever came up with. And forking the kernel has to be the most dumbest idea a kernel developers ever came up with.

i have little coding knowledge and have no idea how kernel coding collaboration works

but i tend to side with linus

if he verbally abused me i'd first make sure i didn't do something so stupid it warrants such a response (in case you want to say 'nothing warrants verbal abuse', we're adults, not children) before deciding to move away.

Here's an example of Linus ranting on someone:

https://lkml.org/lkml/2012/12/...

Yes, it's pretty harsh. But I can't honestly say that what Linus said was wrong.

Of she didn't mention it in the blog post. "I'm working on getting a pipeline of women into kernel development, through the FOSS Outreach Program for Women. They slowly get introduced to Linux development culture, starting with a very friendly separate mailing list and IRC channel, and finally moving to work with a kernel mentor on a bigger project on the main Linux kernel development lists. We have seven women participating this round, and I suspect we'll have even more the next round." from https://lkml.org/lkml/2013/7/1...

This is the "deepthroating Microsoft" he's referring to: https://lkml.org/lkml/2013/2/21/228

It was a pretty stupid idea, and it isn't surprising that Linus shot it down.

Guys, this is not a dick-sucking contest. If you want to parse PE binaries, go right ahead. If Red Hat wants to deep-throat Microsoft, that's *your* issue. That has nothing what-so-ever to do with the kernel I maintain. It's trivial for you guys to have a signing machine that parses the PE binary, verifies the signatures, and signs the resulting keys with your own key. You already wrote the code, for chissake, it's in that f*cking pull request.

By the time SCALE 11 hit, Matt was no longer working at redhat. people moved on. A Fork was always an option for Matthew...just perplexed as to why he decided to do it 2 years after...

There's a HUGE difference between not sugar-coating things and being an asshole.

Shut up, Mauro. And I don't _ever_ want to hear that kind of obvious
garbage and idiocy from a kernel maintainer again. Seriously.

That's just one line of a long email. Found here: https://lkml.org/lkml/2012/12/23/75

Here's how you could write that message without being a complete and total shit:

> Are you saying that pulseaudio is entering on some weird loop if the
> returned value is not -EINVAL? That seems a bug at pulseaudio.

Mauro,

Yes, this is a bug, but it is not pulseaudio's bug. The bug is in the kernel, and in particular the code you wrote. Stop making excuses. The primary rule of maintaining the kernel is:

WE DO NOT BREAK USERSPACE!

The use of ENOENT as an error return from an IOCtl is entirely wrong too. ENOENT means "No such file or directory", and is for path operations[note: I didn't modify this sentence! It's actually a good one!]. IOCtl's are done on files that have already been opened, so ENOENT doesn't make any sense.

In the future, make sure you use the correct error returns and don't blame userspace when your code breaks it. This is a wholly unacceptable way to maintain kernel code.

You'll note: I didn't have to tell him to SHUT THE FUCK UP. I still berated him, and I didn't put any bullshit sugar-coating on it. Linus' version is the equivalent of the shift manager getting red in the face and swearing one person out in front of the whole damn factory floor. It's *way* over the top and it's downright unprofessional. If that's how the kernel community runs, then I would never want to be part of it. I have thick skin and I wouldn't be bothered with butting heads with a respected/reputable person like Linus. But there's no fucking way I'm going to volunteer my time to deal with that level of bullshit.

Here is context
https://lkml.org/lkml/2013/7/1...
https://lkml.org/lkml/2013/7/2...

She tried some attention grabbing drama, got all SJWy, was briefly shot down, butthurt feelings etc. Now she quit

Here is context
https://lkml.org/lkml/2013/7/1...
https://lkml.org/lkml/2013/7/2...

She tried some attention grabbing drama, got all SJWy, was briefly shot down, butthurt feelings etc. Now she quit

https://twitter.com/sarahsharp...
https://lkml.org/lkml/2013/7/1...
Note the timestamps.

It has been frequently a topic of Slashdot posts. Even a modicum of Google research will come up with some gems. https://lkml.org/lkml/2012/12/... - here's one

Just looking at the "gem" you pointed out. Ok, I know there's some profanity, but

• 
  Linus was frustrated because of the actions of someone who should have now better. However, he took the time to explain exactly why he was angry.
  He didn't insult the maintainer - just expressed anger at their actions.
  The maintainer seems to have taken it in the right spirit. Three years later I still see him listed 17 times in MAINTAINERS

I'm glad Linus cares so much about getting stuff right. I'd rather have it right (& rude) than wrong (& polite). Before you say "oh, but it can be both right & polite" ... well (a) that's the way things are most of the time & (b) we live in an imperfect world.

He has never been (a dick) (and may will never be).
It's just that his style is not suited with someone, and he/she quits. This is just normal.

The kind of stories about "Linus bullying" has appears four or five a years, but each times, there are people jump out and claim, likely they never ever read these stories before (not about you). So each topic about "Linus bullying", the *same patterns* of discussion appear again and again.
BTW, there was a Slashdot user (he is/was also "a newbie" kernel developer) said that Linus is very nice and friendly toward newbies, unexperienced developers.

He was clearly described the style of discussion (as he described, say louder not insult):
https://www.kernel.org/doc/Doc...
or here,
http://arstechnica.com/busines...
or here,
http://arstechnica.com/busines...
Some may say that he is rude, but in fact, I see he's straight, but his words were putted out of the context. Remember the "F you, Nvidia! (and pointed finger)" incident, he right after added "Don't get me wrong...", but the later usually never mentioned. But the progress of Nvidia action later proved his style works.

While Sarah seemed to be allergic with the style (see the chains of discussions):
http://marc.info/?t=1373580445...
started with Linus' shouting:
http://marc.info/?l=linux-kern...
appeared in story:
http://linux.slashdot.org/stor...

Or, the Linus' "victim" does not have problem with his style:
start with:
https://lkml.org/lkml/2013/2/2...
"victim" respond:
https://lkml.org/lkml/2013/2/2...
appeared in:
http://linux.slashdot.org/stor...

He has never been (a dick) (and may will never be).
It's just that his style is not suited with someone, and he/she quits. This is just normal.

The kind of stories about "Linus bullying" has appears four or five a years, but each times, there are people jump out and claim, likely they never ever read these stories before (not about you). So each topic about "Linus bullying", the *same patterns* of discussion appear again and again.
BTW, there was a Slashdot user (he is/was also "a newbie" kernel developer) said that Linus is very nice and friendly toward newbies, unexperienced developers.

He was clearly described the style of discussion (as he described, say louder not insult):
https://www.kernel.org/doc/Doc...
or here,
http://arstechnica.com/busines...
or here,
http://arstechnica.com/busines...
Some may say that he is rude, but in fact, I see he's straight, but his words were putted out of the context. Remember the "F you, Nvidia! (and pointed finger)" incident, he right after added "Don't get me wrong...", but the later usually never mentioned. But the progress of Nvidia action later proved his style works.

While Sarah seemed to be allergic with the style (see the chains of discussions):
http://marc.info/?t=1373580445...
started with Linus' shouting:
http://marc.info/?l=linux-kern...
appeared in story:
http://linux.slashdot.org/stor...

Or, the Linus' "victim" does not have problem with his style:
start with:
https://lkml.org/lkml/2013/2/2...
"victim" respond:
https://lkml.org/lkml/2013/2/2...
appeared in:
http://linux.slashdot.org/stor...

It took a hell of a lot of digging, but it seems to have started with this thread, way back in 2013.

Now, I'm all for professional communication, and emails can be easy to misinterpret, but this looks like a bit of an over-reaction. Someone commented that they send patches to Greg KH because Linus scares him, but added a winkey smiley afterwards, i.e. not really all that scary. Then Linus made a joke about Greg being big and squishing people that may or may not be playful or insulting, without knowing much about the relationship between these guys it's hard to say. Squish is hardly a word you use when you're really angry though.

And then Linus and Ingo gently tick off Greg and says he should be tougher, Linus says Greg is acting like a "door mat" and says "You may need to learn to say no to people". Ingo says "be frank with contributors and sometimes swear a bit". Probably this discussion would be held off list in a more traditional corporate environment to avoid embarrassing Greg (though "you are too nice" is not that embarrassing), but he takes it in his stride and agrees to be tougher.

OK, so far, just another day in open source land? Well, then Sarah Sharp flies off the handle and says:

Seriously, guys? Is this what we need in order to get improved -stable? Linus Torvalds is advocating for physical intimidation and violence. Ingo Molnar and Linus are advocating for verbal abuse.

Not *fucking* cool. Violence, whether it be physical intimidation, verbal threats or verbal abuse is not acceptable. Keep it professional on the mailing lists.

What the heck? The only thing she could be referring to this thread so far has been Linus talking about Greg being a giant who might "squish you without even noticing". Nobody could seriously interpret that as advocating for violence unless you were so unbelievably literal you'd be unable to handle ordinary conversations.

And then there's the conflation of "verbal abuse" with "violence". These are two words that mean very different things. And finally the assertion that by trying to make jokes (perhaps not very well), Linus and Ingo were being unprofessional. Not surprisingly, Linus had a problem with this claim.

Now I don't know, probably this could have been avoided if the discussion with Greg had been private. But it seems Sharp would have let rip at some other point if someone else made an off-colour joke. I can believe LKML is a tough environment, but this isn't the best evidence possible. Perhaps there have been other incidents, but as Sharp doesn't list any, it's hard to say.

It has been frequently a topic of Slashdot posts. Even a modicum of Google research will come up with some gems. https://lkml.org/lkml/2012/12/... - here's one

It's unclear whether most of the FUD in this discussion is directed at the GPL itself or specifically v3. But it's entirely unfounded.

It's not FUD, and its about the GPL in general - although being GPL3 makes it worse. "GPL2 or later" would have been a better (but still flawed) choice.

You know why libraries aren't generally licensed GPL, right? Anything that links to them has to have the exact same license as the library. For instance, the GPL2 licensed Inkscape can't use this library.

That's the difference between the GPL and the LGPL. You can link to LGPL libraries from any software; you can only link to GPL licensed libraries from code with the same version of the GPL.

In RMS' ideal world, all software would move to the latest GPL and it wouldn't be a problem. Good luck convincing these guys of that.

This is the appropriate license for this image format.

The GPL is not the appropriate license for any general-purpose library. That's what the LGPL is for. Or, like most reference implementations, a non-copyleft license like the MIT license.

Look, I get it, you're a promoter of software freedom. So am I. But this is the real world, and this is a reference implementation. There are conventions to follow for reference implementations, and an OSS non-copyleft license is one of those conventions. This image format could outperform every other format on the planet and it will still see no adoption outside of academia unless there's a compatibly licensed library available. Unless it gets relicensed, or someone writes a non-GPL library, this will go down as just another interesting format that sees no adoption whatsoever.

A multi-trillion dollar industry is hardly clutching at straws.

Except that multi-trillion dollar industry has nothing to do with software freedom, that is why Linux's license preamble exists and why Linux does not do the FSF's copyright assingment. You have obviously also never read Linus' discussions on why he chose the GPL (hint: it has nothing to do with software freedom), the information is all there (on lkml and others) so you are just being ignorant.

Rather, what I see from you is denial.

What you see is your distorted world-view that is not representative of the facts. You choose to be blind and that is your loss, I have given you links to help educate you but you don't want to be educated you just want to remain clueless.

It sure is nice for you that you can make billions of dollars by exploiting a Linux kernel made for free by volunteers and rebrand it Android, but where's my Bash shell, Google? Why do you have to use Free Software to deny me my Freedom, Google? Hey!! FUCK YOU, Google.

I really wish you Free Software folks would stop trying to subsume other projects under your own ideology. Yes it uses the GPLv2 but the Linux kernel was never about Free Software ideals, Linus has made it quite clear that the license choice was purely to ensure "quid-pro-quo" source code contribution and that Tivoization is *good*.

First up lkml.org is a third party site that hosts Linux kernel mailing list archives on a website. Regular Linux kernel mail isn't actually sent from it (I believe that's done by vger) so we're looking up the email reputation for the wrong IP...

Secondly UCEPROTECT is a very aggressive blacklist which states upfront they will block people who they believe are in the vicinity of people who the judge to be sending them spam. It's not the be and end all though and on one server I looked some time ago it's effectiveness was surpassed by other blacklists (here's someone else's old DNS blacklist comparison for 2014). In general I prefer more conservative tools like senderbase when trying to work out an IPs mail reputation.

For what it's worth I've also seen GMail incorrectly mark mails sent to the fio mailing list (which is also managed by vger) as spam and in that case it was purely down to mail being proxied through the list which was a place that didn't match the sender's DMARC records. Most of the time GMail was getting the marking of spam right though (even for mailing list mails)...

You post publicly on both Google+ and the LKML. Some of your posts get a lot of attention on G+ like naming the next version 3.20 or 4.0, which is a different audience than the Linux Kernel mailing list.

What do you like and dislike about communicating on either platform, Google+ or the LKML? How do you feel about their respective audiences? Do you enjoy the tools you use to participate in public discussions on Google+ and the LKML?

I'm fairly confident that there ARE some developers who would be valuable who see Linus as too much of a loose cannon, and don't want to volunteer to make him their boss.

Maybe? But I'm not convinced that the Developers Who Matter and make such contributions would consider themselves 'abused'.

I've been reading Slashdot for nearly 14 years now. Having a story about an incendiary Linus post is "kind of a thing" around here. In every one of the instances where I've seen a link to a Legendary Linus Rant, the rant and insults all stem from a person being incompetent or careless, especially when it comes to doing something that harms the kernel.

Remember this rant? It was discussed at length on Slashdot. I pick it out because, in my opinion, it's a good example of a Linus rant.

If I were the recipient of that rant, I'd hate to be told to "shut the fuck up". I'd be embarrassed to be told that I've submitted a crap patch. But that embarrassment and negative emotion on my part PALES in comparison to the feeling of knowing that my actions directly harmed a project I was working on.

So yeah, I'd hate to have that kind of stuff said to me in a publicly-readable forum, but I'd hate EVEN MORE to know that I earned the derision. And that is what actually matters to me -- I don't want to bring actual harm to a project I'm contributing to. Being called out, regardless of the incendiary nature of the callout, is completely and utterly secondary. As I said before, the 'fix' is to not be incompetent.

Perhaps that is what separates a skilled programmer with the POTENTIAL to contribute to the kernel from a skilled programmer that ACTUALLY contributes to the kernel: The actual contributor knows that the genuine quality of his or her contribution to the project is secondary to bad words directed their way.

If you read the Linux Kernel Mailing List http://lkml.org/ for a while, you will see why Linux was successful. Over and over again, Linus Torvalds over-rides the antics of his minions and explains to them (again) that the changes they made must be backed out because they break something that users actually need. Linux is elegant and beautiful, but not just because it's a work of art. Linux is the most functional piece of code in existence. It is the beauty of function.

Here's more Poetteringware to hate, headed for the kernel!

Security I don't see how, moving it in the kernel is an improvement. You add all the risks associated with being able to step all over systemically important data structures to a "process" that by definition has to communicate with a largish number of less trusted processes. If you limit who/what is allowed to talk to dbus with a firewall like solution you make dbus less useful as an IPC channel.

Kdbus will really will provide several layers of extra security since LSM's like SELinux can hook into the system from the kernel and not in the much less secure userspace. You also gain kernel guarantee for the message marshalling.

The performance considerations might be a justification but I have never really seen DBUS as a high performance IPC channel anyway.

That is exactly because dbus is extremely slow when it comes to data transport.

    Maybe I am just badly misinformed on its planned usecases. I thought it was for deriving simple short messages like "A new input device is a available" not shoveling megabytes of data between processes. We have fifo pipes and UNIX sockets for that, and if latency is an issue there is always shared memory.

The point is that many developers, especially embedded and IVI (and DE's like Gnome and KDE) are interested in using the same framework for both control and data. Having side channels to dbus in order to gain speed for data means maintaining proprietary frameworks that has to duplicate much of what dbus does anyway.
This will also be a great help regarding sandboxing of applications.
See more here:
https://lkml.org/lkml/2015/3/9...

Just for reference, Linus' reply to that:
"Maybe we could some day remove EISA support too.."
https://lkml.org/lkml/2012/5/1...

recent years have also seen MCA bus support being removed from the kernel

Just for reference, here's also the original discussion on MCA support removal from 2012 in LKML.

But you see, the very fact that you have to test out these updates is proof positive that Windows updates break the living shit out of Windows machines.

Only the most incompetent of system admins would not test updates and this is likely where all your complaints stem from. All operating systems have had their issues with updates breaking things and suggesting that they dont just because you have never encountered them is just ignorant. You could just do a quick google search to confirm this but obviously that is too difficult for you. OSX Yosemite had a lot of issues breaking existing functionality and if you have ever browsed the apple forums you would see all the mavericks updates that broke things all over the place though they have gotten significantly better than the older versions of OSX. Just browse linux kernel mailing list and you will see all of the various things that kernel updates have broken along the way that needed patches issued for.

As an osx and linux user I would love to live in your fantasy world where the only broken operating system is windows.

Dude, seriously, Google ... https://lkml.org/lkml/2012/7/1...

here you go

He was citing Torvalds, who did indeed make such a claim.

Why would FTDI have to ensure their driver doesn't break chips that aren't theirs? There's no agreement, licensing, or goodwill.

They don't but I invite you to look at the driver they proposed for Linux: https://lkml.org/lkml/2014/10/23/129
I especially like the line with the comment: "/* Attempt to set Vendor ID to 0 */"

That is the exact opposite of ensuring it doesn't break. That is actively and maliciously breaking something. Also the cloners are producing a product that is perfectly legal when they use that VID/PID pair. It's against the USB spec to use another vendor's ID and then use the USB logo on your device, but I've never seen a USB logo on these devices, so it's all ok.

The only thing illegal here is they are printing FTDI's logo and model number on the chip. If they didn't do that it would be a 100% legitimate product.

Here is the original message. It has the comment "/* Attempt to set Vendor ID to 0 */". So yeah, they are intentionally fucking with a chip when it fails to validate. And in addition to fucking over buyers of equipment where the manufacturer may have unknowingly been given counterfeit parts, they've also told the cloners exactly what to change for their next run of chips.

Wow, just WTF. It's one thing for them to claim some loss, no matter how slight, from people leeching off of their Windows driver. But considering that the clones do not copy FTDI silicon (have ANY of them been found to do so?), and they have absolutely no claim to ownership of the Linux kernel driver, this is just greed at its worst. Also, not all clones have counterfeit labeling on the chip and can thus be considered fair competition. I wouldn't be surprised if some are even in package types that FTDI doesn't sell. Their driver may see their 16-bit VID number on the chip (you can't trademark a number, that's why Intel renamed the 586 as "Pentium"), but it can't see whether FTDI is etched on the chip or not.

Or maybe someone can point me to something that says you can patent a register layout and chip pinout. (essentially the hardware equivalent of software APIs) Except again, there is no way that the driver can even know that the chip uses the same pinout.

Now maybe if they had the chip return the text "FTDI" (aka actual trademark-able text) and checked for that along with some other kind of "real chip" test... but that still won't justify fucking with the chip. Just refuse to run is all you need.