LKML Archive on lore.kernel.org
 help / Atom feed
From: "Enrico Weigelt, metux IT consult" <lkml@metux.net>
To: Pavel Snajdr <snajpa@snajpa.net>, michaeljpwoods@gmail.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: Linux 4.19-rc4 released, an apology, and a maintainership note
Date: Mon, 8 Oct 2018 15:54:26 +0200
Message-ID: <dc799c03-fefd-45f2-e0bc-b65e356dce61@metux.net> (raw)
In-Reply-To: <260205ec45d097fb037f71ae42e7b69e@snajpa.net>

On 18.09.2018 03:30, Pavel Snajdr wrote:

Hi folks,

I usually try to stay out of political issues in software projects
(there're already too much real political problems, where people need
to stand up and push away actual oppressors), but now I have the bad
feeling that political (or more precisely: social engineering)
techniques are abused against the Linux kernel project.

> and how about if we viewed the new Code of Conduct as about the same> thing as BitKeeper was for the development process?
Bitkeeper was used as an intermediate workaround for conceptional
deficiencies in CVS (and all other tools based on the same principles).

But I really don't see any conceptional deficiencies in the way the
Linux kernel community worked in the last decades. Actually, it worked
very, very well. It created the best general purpose OS kernel in
known history, that scales from small embedded to big clusters.

And this has *VERY MUCH* to do with how the community worked for the
last decades. IMHO, it's even the primary reason. Not having to care
about personal behaviours, corporate hierarchies, marketing, whatsnot,
only care about technical excellence. Nothing more, nothing less.

> It was not perfect, but wass *something* for a start. 

A start for what exactly ? Just for the sake of doing *something* ?

Well, that sounds like the typical corporate manager's / politician's
behaviour pattern: There seems to be a problem, we need to do something
fast - doing nothing is worse than not doing anything quick enough.

Yeah, that's exactly what I'm regularily observing with my clients (the
bigger the corporation, the worse). And that's exactly why so many of
their projects fail so miserably, and products are such a crap.

I really hate the idea of the Linux community falling into the same
trap. (many of the GUI projects already did, and their code is crap)

The best thing, IMHO, is to totally ignore any kind 'social rules'
and focus on the actual technical goals. And don't take anything here
personally. *If* there really happen some ugly personal attacks, we
can talk about that on a case by case basis.

> I've been always looking up to the guys leading major community projects> and how they go about things - and I think, that most of the bad>
fall-out in them is caused by insanely high expectations - firstly from>
the leader themselves, and secondly from others as well.
Can you give some example of such bad fall-out ?

> P.S.: this is my first "contribution" to LKML, I hope to start sending> up some of my very prototype work soon for discussion, regarding the>
Cgroup subsystem ID allocation & limits - and subsequently, start a>
discussion about getting Linux to do better OS-level containers (ie.>
those, which have a "look&feel of a real VM" from the admin's perspective).
Please add me to CC. I'm working on similar areas (if my time budget
allows ;-)).

Even better: create a separate maillist for that, if there's not already
some fitting one. LKML's a pretty crowded already.

> We started our organization (vpsFree.org) on top of OpenVZ patch set and> are now working to get vanilla up to the task of replacing the
venerable> 2.6.32-based OpenVZ 6 Linux-like thing.
What exactly are you yet missing in current mainline ?
Are these things that really need to be done in the kernel or could
it be done in userland ?

My personal area of interest in the container context isn't the usual
'put a whole system in a box'-thing, but instead using namespace
isolation an general software architectual feature, similar to the
Plan9 world - eg. allow unprivileged processes to manipulate their own
fs namespace at will, use synthetic filesystems as generic IPC, split
huge applications into small and resusable programs, etc.

> The new Code of Conduct is a guarantee for us, that we won't be laughed out
> of the room  and that our members won't be demotivated to contribute upstream

Seriously ? You really need some kind of 'social law' that protects you
from the risk of being laughed out ?

No offense, but if that's really the case, then you've got a much
bigger, more serious problem, which also persuades you in your daily
life: deep lack of self confidence. I feel very sorry for that,
and I'm offering my help. For anybody who feels that way.

Yes, I had exactly that problem for my whole childhood and youth, until
I've learned a vital lesson: It just *DOES NOT* matter whether some
people laugh about you or your work - as long as you're sure that you
your work is the right thing for *YOU*. Simply ignore the trolls.
(BTW, the really good point on FOSS is: you can fork anytime and do
whatever changes you feel right for you - no matter what anybody out
there thinks about them).

So, don't let such things come into your way. Just do whatever you feel
the right thing to do and then let's talk about that.

I have no idea whether your patches have a chance to mainline anytime
soon. But that shouldn't even matter. Solving a specific problem and
fitting in something into the big generic world are two entirely
different things. Many great things (eg. various container subsystems,
realtime, android stuff, ...) went a long way towards mainline, some
still have a long way to go. That's just because it's these topics
are far from being trivial. And that shouldn't stop anybody.

> If I understand the context correctly, the previous "regime" could be
> the culprit, at least to some extent, why still don't have the VM
> look&feel-having containers with vanilla. 

Why exactly do you think so ?
What exactly are you missing here ?
Where's the connection to social rules ?


--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287

  parent reply index

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-16 19:22 Linus Torvalds
2018-09-16 21:42 ` [...] " Adam Borowski
2018-09-16 23:59   ` Moritz Obermeier
2018-09-17  0:18 ` Linux 4.19-rc4 released, " Rene Herman
2018-09-17  0:20 ` [...] " Andy Isaacson
2018-09-17  0:23 ` Linux 4.19-rc4 released, " Rene Herman
2018-09-17  6:57 ` opal hart
2018-09-17  7:57 ` […] " Martin Steigerwald
2018-09-17  8:53   ` Martin Steigerwald
2018-09-30 12:09     ` Re: Linux 4.19-rc4 released, " lkcl
2018-09-30 14:07       ` Martin Steigerwald
2018-09-30 16:27         ` Luke Kenneth Casson Leighton
2018-09-17 12:58 ` Guenter Roeck
2018-09-17 17:09 ` Joe Perches
2018-09-17 21:09 ` Michael Woods
2018-09-18  1:30   ` Pavel Snajdr
2018-09-21 22:13     ` Michael Woods
2018-10-04 14:57     ` ebiederm
2018-10-08 15:29       ` Enrico Weigelt, metux IT consult
2018-10-08 13:54     ` Enrico Weigelt, metux IT consult [this message]
2018-10-08 16:36 ` Enrico Weigelt, metux IT consult
2018-09-17  2:15 Luke Kenneth Casson Leighton
2018-09-18  2:10 ` Luke Kenneth Casson Leighton
2018-09-30 11:47 ` Luke Kenneth Casson Leighton

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dc799c03-fefd-45f2-e0bc-b65e356dce61@metux.net \
    --to=lkml@metux.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michaeljpwoods@gmail.com \
    --cc=snajpa@snajpa.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org linux-kernel@archiver.kernel.org
	public-inbox-index lkml


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/ public-inbox