Language Selection

English French German Italian Portuguese Spanish

More on Masterbaiting Monkeys

Filed under

Why give this fanboy nonsense publicity?

It's a blatant untruth on Torvalds's part, born of complete ignorance of the way in which OpenBSD's actually maintained, made in full knowledge of the fact that anything he says about the *BSDs (and OpenBSD in particular) will be parroted by every idiot who fancies he might have something to gain by blindly uncritical Linux advocacy.

re: nonsense

Well, I think the first article I saw on the subject sums it up for me:

Linus is known for being the best coder he can be, and backing his words up. When Linus went after the Gnome developers and their clique, he backed up his firestorm with actual code. Linus is seen as being rude in the light that there is something behind the rudeness.

And I just happen to agree with him. So many times security issues are blown out of proportion. Most of the time they are obscure issues that would never be exploited in the every day life, but let's make a big deal out of them giving crackers more information to use against us. Yes, the security issues should be known and fixed, but as Linus said, just as any other bug. Many other times they are used by Microsoft people to prove Linux isn't any more secure than Windows.

Should Linus have used that metaphor? Well, no, probably not. But he is entitled to express his opinion and make his point. I just wouldn't have been so rude about it.

As far as linking to the headlines - that's what I do. I don't have to agree with them and many times I don't like the articles I link to. But I'm not into censorship. I'm always catching hell for linking to articles that "insult" Linux or OSS. But folks need to know the good and the bad. They need to know what other folks are saying. Some may want to go to the site and comment. It'd get pretty boring around here if I ignored everything somebody thinks I shouldn't link to. I try to please the crowd, but you can't. You can't please everybody all the time. I just do the best I can with what I know how.

re: re: nonsense

Well I pretty much side with Security.

If you're driving down the road at 70 mph, and your tire blows out just as you notice your glovebox won't stay shut, are you: A) more worried about the blown out tire that might cause you to careen out of control and maybe die, or Cool more worried about the glovebox because that annoys your passenger? Obviously some problems are more important then others.

Security - especially at the enterprise level - is the PRIMARY concern. PERIOD. And the fact that it's obscure and MIGHT not be exploited is a very weak (and stupid) security practice (if your business has 15 entrances - do you leave one door unlocked because maybe a thief is too lazy to check all 15 doors?)

Also, it's sad when the developer of Linux states that "all bugs" are equal. Since they are pretty much are all equally IGNORED, for proof, look at pretty much any 6 month rush-to-release distro.

Because of that, I for one, am GLAD that security problems get the hype and attention. I don't want a possible exploit vector ignored for 3 or 4 releases because it's just another bug.

re: re: nonsense

Yes, of course, you're right. I was a bit flippant with that original remark due to being on the defensive. I went too far the other way to try and justify my actions.

re: nonsense

> But folks need to know the good and the bad.

No, they just need to be well-informed. Isn't the fact that you can apply years of knowledge and judgement (and therefore a measure of discrimination) what distinguishes from automated aggregators?

> So many times security issues are blown out of proportion. Most of the time they are obscure issues that
> would never be exploited in the every day life, but let's make a big deal out of them giving crackers
> more information to use against us.

I'd have thought full disclosure was necessary to any serious, open source security auditing. It's certainly established policy with every other major FLOSS OS.

In any event, the distinction between (in Torvalds's words) "boring normal bugs" and security bugs is ultimately unfounded, provided, that is, your security policy's proactive (as in the case of OpenBSD) rather than than reactive (as is largely the case with Linux). I quote:

"During our ongoing auditing process we find many bugs, and endeavor to fix them even though exploitability is not proven. We fix the bug, and we move on to find other bugs to fix. We have fixed many simple and obvious careless programming errors in code and only months later discovered that the problems were in fact exploitable."

re: re: nonsense

well, "well-informed" was exactly what I meant. It's what I try to do.

> I'd have thought full disclosure was necessary to any serious, open source security auditing. It's certainly established policy with every other major FLOSS OS.

yes, you're right. Of course it is.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

LWN (Now Open Access): Kernel Configuration, Linux 4.14 Merge Window, Running Android on a Mainline Graphics Stack

  • A different approach to kernel configuration
    The kernel's configuration system can be challenging to deal with; Linus Torvalds recently called it "one of the worst parts of the whole project". Thus, anything that might help users with the process of configuring a kernel build would be welcome. A talk by Junghwan Kang at the 2017 Open-Source Summit demonstrated an interesting approach, even if it's not quite ready for prime time yet. Kang is working on a Debian-based, cloud-oriented distribution; he wanted to tweak the kernel configuration to minimize the size of the kernel and, especially, to reduce its attack surface by removing features that were not needed. The problem is that the kernel is huge, and there are a lot of features that are controlled by configuration options. There are over 300 feature groups and over 20,000 configuration options in current kernels. Many of these options have complicated dependencies between them, adding to the challenge of configuring them properly.
  • The first half of the 4.14 merge window
    September 8, 2017 As of this writing, just over 8,000 non-merge changesets have been pulled into the mainline kernel repository for the 4.14 development cycle. In other words, it looks like the pace is not slowing down for this cycle either. The merge window is not yet done, but quite a few significant changes have been merged so far. Read on for a summary of the most interesting changes entering the mainline in the first half of this merge window.
  • Running Android on a mainline graphics stack
    The Android system may be based on the Linux kernel, but its developers have famously gone their own way for many other parts of the system. That includes the graphics subsystem, which avoids user-space components like X or Wayland and has special (often binary-only) kernel drivers as well. But that picture may be about to change. As Robert Foss described in his Open Source Summit North America presentation, running Android on the mainline graphics subsystem is becoming possible and brings a number of potential benefits. He started the talk by addressing the question of why one might want to use mainline graphics with Android. The core of the answer was simple enough: we use open-source software because it's better, and running mainline graphics takes us toward a fully open system. With mainline graphics, there are no proprietary blobs to deal with. That, in turn, makes it easy to run current versions of the kernel and higher-level graphics software like Mesa.

Beautify Your KDE Plasma 5 Desktop Environment with Freshly Ported Adapta Theme

Good morning! It's time to beautify your KDE Plasma 5 desktop environment, and we have just the perfect theme for that as it looks like the popular Adapta GTK theme was recently ported to Plasma 5. Read more

Roughing it, with Linux

I have been traveling for about two weeks now, spending 10 days camping in Iceland and now a few days on the ferry to get back. For this trip I brought along my Samsung N150 Plus (a very old netbook), loaded with openSUSE Linux 42.3. Read more

Red Hat: Ansible Tower, Patent Promise, and Shares Declining

  • Red Hat’s automation solution spreading among APAC enterprises
    Red Hat recently shared revealed its agentless automation platform is spreading among enterprises in APAC countries like Australia, China, India and Singapore. The company asserts its Ansible Tower helps enterprises cut through the complexities of modern IT environments with powerful automation capabilities that improve productivity and reduce downtime. “Today’s business demands can mean even greater complexity for many organisations. Such dynamic environments can necessitate a new approach to automation that can improve speed, scale and stability across IT environments,” says head of APAC office of technology at Red Hat, Frank Feldmann.
  • Red Hat broadens patent pledge to most open-source software
    Red Hat, the world's biggest open source company, has expanded its commitment on patents, which had originally been not to enforce its patents against free and open source software.
  • Red Hat expands Patent Promise
    Open-source software provider Red Hat has revised its Patent Promise, which was initially intended to discourage patent aggression against free and open-source software. The expanded version of the defensive patent aggregation scheme extends the zone of non-enforcement to all of Red Hat’s patents and all software under “well-recognised” open-source licenses. In its original Patent Promise in 2002, Red Hat said software patents are “inconsistent with open-source and free software”.
  • Red Hat Inc (RHT) AO Seeing a Consistent Downtrend
  • Red Hat, Inc. (RHT) noted a price change of -0.14% and RingCentral, Inc. (RNG) closes with a move of -2.09%