[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Installing an Alternative Init?



On Tue, Nov 18, 2014 at 01:01:47AM +0100, Ludovic Meyer wrote:
> On Tue, Nov 18, 2014 at 12:41:14AM +0300, Reco wrote:
> > On Mon, Nov 17, 2014 at 07:15:38PM +0100, Ludovic Meyer wrote:
> > > On Mon, Nov 17, 2014 at 06:29:24PM +0300, Reco wrote:
> > > >  Hi.
> > > > 
> > > > On Sun, Nov 16, 2014 at 03:48:34PM +0100, Ludovic Meyer wrote:
> > > > > On Sat, Nov 15, 2014 at 09:41:23PM -0500, Miles Fidelman wrote:
> > > > > > As much as I dislike systemd, I'm not sure that it's a vendor
> > > > > > conspiracy to "control the Linux ecosystem."  Yes, redhat pays
> > > > > > Lennart Poettering's salary (among others).  But... I'm hard pressed
> > > > > > to see how turning a collection of free distros into functional
> > > > > > equivalent's of redhat, or increasing the resources applied to free
> > > > > > distros, is really to their benefit.  If anything, it would seem to
> > > > > > dilute the competitive advantage of paid RHEL.
> > > > > > 
> > > > > > Personally, I think it's more a matter of one, prima donna
> > > > > > developer, who has the advantage of a salary, who has a vision and
> > > > > > design philosophy that he's promoting in a very aggressive and
> > > > > > single minded way.  And he's very overt about it.  (Somebody posted
> > > > > > an email from Poettering last week saying, roughly, 'first we're
> > > > > > going to get kdbus into the kernel, then we're going to make udev
> > > > > > depend on it, and then everyone will have to eat systemd to get
> > > > > > udev.'  As I recall, the message closed with 'gentoo, be warned.')
> > > > > > 
> > > > > > I figure this is more a case of redhat management not wanting to
> > > > > > tick off valued prima donna, and maybe seeing what he's doing as a
> > > > > > contribution to the open source community (to date, redhat has been
> > > > > > pretty good about contributing to the community in lots of different
> > > > > > ways).  Still,  if I were in their shoes, I'd be trying to reign the
> > > > > > guys in. 
> > > > > 
> > > > > Why would the management of a external company care about what 
> > > > > happen in Debian ? 
> > > > 
> > > > Because Debian is upstream for several critical RHEL parts, such as
> > > > shadow (passwd, useradd and friends).
> > > 
> > > 1 ( ie shadow-utils ) is not "several".
> > 
> > Google is your friend. Sorry, could not resist.
> 
> I spend time to give concrete response. It would be polite to do the same.

Sorry again. RHEL uses the software from the https://alioth.debian.org/,
which is clearly controlled by the Debian Project:

SANE - Scanner Access Now Easy
autopkgtest
Bash Completion
piuparts
Muscle PCSC lite
chrpath
minicom

And, thinking about it further, I withdraw my point. It was good
conspiracy theory, but it didn't last colliding with facts :)


> > > And by having a critical look at your affirmation, RH is paying a lot 
> > > of upstreams contributors for several critical Debian part :
> > > - glibc
> > 
> > Not as of Wheezy. Wheezy uses eglibc.
> > And, while we're on topic of glibc - RedHat isn't writing new 'Modern'
> > libc to replace an old one. Yet.
> 
> That doesn't change the fact that before, this was glibc, with the
> infamous Ulrich Drepper, and that eglibc is now merged in glibc.

Ulrich Drepper did a hell of a job maintaining glibc IMO. Although I
don't argue that his maintaining style was somewhat harsh. And, this
exception also show us that 'Stop Reopening' being on Red Hat payroll
did not pursue his employer agendas just because.


> > Next few years we may see systemd-libc if things go as they're going
> > now.
> > 
> > 
> > > - gcc
> > 
> > A GNU project. Not a RedHat pet.
> 
> Read again :
> "RH is paying a lot of upstreams contributors"
> GCC was pushed historically by cygnus, and cygnus got 
> acquired by RH.
> If you look at the committers, you would see lots of
> people from the company.

There're committers, and there're ones who determine project's
development. In the case of gcc it's not Redhat as GNU thought about
control in advance:

https://gcc.gnu.org/contribute.html


> > > - util-linux-ng
> > 
> > A kernel.org project. Not a RedHat pet again.
> 
> https://git.kernel.org/cgit/utils/util-linux/util-linux.git
> Look who make release, look where he work. 

That page listed those people for me (in alphabet order):

Benno Schulenberg
Boris Egorov
Gabriele Giacone
Karel Zak
Tobias Stoeckmann

Of those, only Karel Zak seems to be of Red Hat.


> In fact, by that same reasoning, we can say that systemd is 
> a freedesktop.org project, whic is not more 
> controlled by RH than stuff hosted on kernel.org.
> 
> > 
> > > - kernel
> > 
> > A joint project, controlled by Torvalds & co. RedHat is one of the few
> > who's playing a major role there, true. But that role was not enough to
> > push the most controversial features (kdbus, for example) into the
> > mainline.
> 
> Kdbus is pushed by Greg Kroah-Hartman, who is employed by the Linux Foundation.
> Before, he was working at Novell, and has no link with RH afaik. 

Hmm. It seems that I cannot locate an exact commit on lkml for this.
Care to provide a link?


> > > - udevd
> > 
> > Yup. You nailed that one if we consider latest udev development. It took
> > a merging into systemd to became that way.
> 
> Mhh no.
> http://blog.bofh.it/debian/id_442
> 
> Looking at the graph made by the debian maintener, we can see that 
> more than 95% of the system have it installed since 2008.

Installation base hardly correlates with the control of the project.
And in this case control clearly belongs to Red Hat.



> > > to name a few. I could name a few non critical stuff, from gnome, openjdk.
> > 
> > GNOME is can be considered to be controlled by RedHat indeed.
> > OpenJDK - please. Java is Oracle's turf, not a RedHat one. RedHat
> > invented their own Ceylon language just because of that fact.
> 
> Indeed, I wanted to say icedtea. 

Upstream (http://icedtea.classpath.org/wiki/Main_Page) says:

The IcedTea project provides a harness to build the source code from
http://openjdk.java.net using Free Software build tools and adds a
number of key features to the upstream OpenJDK codebase…


If the source is controlled by Oracle, it hardly matters what exact
tools are used for building it.
And to contribute to OpenJDK one needs to sign Oracle's Developer
Agreement which basically transfers all rights to Oracle.


> > > So I am not sure that your point is valid. Given the size of Redhat, 
> > > I also suspect that having someone working on shadow-utils wouldn't be a problem. Judging by 
> > > SEC fillings, public information, there is around 6900 people.
> > > 1 more coder is not a stretch at all.
> > 

> > and security guys.
> > Do you have any estimate on a number of real developers in Red Hat?
> 
> How would I ?

You seem to have knowledge of these things. 


> Go find a Redhat developper and ask. 
> 
> The best approximation you can have is see how many offer there is for technical
> people on the website vs others type.
> 
> Or dig in the SEC fillings, if you are familliar with the domain ( I work in
> a bank, so that's not hard for me to read and see what I need to look at ).
> 
> You would see in the 10-Q report of July that there was a increase of
> $17.2 million for employee compensation in sales/marketing, 
> $16.1 million for R&D,
> $3.3 millions for general/admin. 
> 
> 
> So if you believe the sales/marketing are paid as well 
> as developpers, that's roughly equivalent. If you take in account
> the fact that there is likely more developpers than commercials people
> in country like india,
> czech republic or china, and they are cheaper, then there is more developpers.
> 
> So if we split, I would say 10% in general ( human ressources, recruiting, like
> internal information services, and accounting, physical security and real estate ).
> Then, 45% between R&D ( ie developper, etc ) and sales/marketing.
> 
> So that's around 3100 based on the estimation of 7000 people, with let's say 
> 5 or 10% of errors. Now, you have to guess where support and consulting 
> go in that scheme. 
> 
> But again, go find a Redhat guy, they are inundating some events like Fosdem.

Ok, thanks, no argument here. Your estimate is better that anything that
I can come up with. As long as you don't imply that everyone in Red Hat
is payed developer I'm ok with it.


> > > > And, curiously enough, systemd's
> > > > goal is to replace those parts (see "Revisiting How We Put Together Linux
> > > > Systems" at http://0pointer.net/blog ).
> > > > Apparently, management doesn't like to be left out of control :)
> > > 
> > > This is free software, there is no way to be left out of control.
> > 
> > For a fellow developer - sure, there's no way to be out of loop as long
> > as said developer plays by upstream rules.
> 
> People could fork. There is more than Veteran Unix Admin that can do that,
> people with enough money can do it. See ubuntu for a very crude example.

And note that it took Shuttlewotrh to sell Thatwe completely to pull the
fork out. Forks on that scale are expensive.


> See EDF for another example of distribution adaptation as people who follow
> the various minideconf knows. See mate for a few
> people deciding to fork a dead project ( or cinnamon ).

I'm not familiar with EDF, and this acronym is too generic to feed it to
the Google. Can you provide a link please?

Mate is basically the endless re-hashing of the old code, and rewriting
stuff in python. Nice thing, but there's hardly any future for the
project. All it takes to shut the project down is killing X server, and
there's active work in that direction (I meant killing X).

Cinnamon is dependent on GTK3, that's something they didn't fork. And
cimmamon is basically a glorified gnome-shell extension.


> It is neither hard or uncommon depending on the project. If one single
> guy was able to fork systemd in uselessd, imagine what one or twi full time dev can
> do.

'Was able to fork' and 'continues to support the effort' are very
different. Future will tell whenever uselessd will survive. Also, it is
not in the Debian main archive, so installing it would be problematic.


> > > That's the whole point of the movement, provided you can code of course.
> > > A lot of people seems to totally forget that point.
> > 
> > But for a typical management drone - it seems we're both agree that
> > there's such a way. All it takes is inability to code.
> 
> As likely counting as management drone ( current title being Technical 
> Manager dealing with my team ), I can tell that you have usually budget 
> to pay if you can justify to your boss why it would be needed. 

Oh, sorry for the possible offence. I didn't mean it, just in case.


> At least in a company with enough money, and having read the sec filling, 
> I suspect that Redhat do seems to have enough money for hiring a coder. 
> Maybe not immediatly, but given their hiring spree as it can be seen in
> older SEC filling, that's a given. 

No argument here.


> > So my point is simple. You mix a few really good developers and an army
> > of managers. That's a modern RedHat.
> 
> For what proportion, and based on what data ?
> So far, I sourced all of my affirmations, so please do the same.

You wrote it all by yourself. My estimate was usual Pareto distribution
(i.e. take any shop, and there's tenth part of employees actually doin'
something), but thinking on your numbers I can agree with 50% developers
(defined as someone who actually touch the code).


> > > > And of course, another distribution = testing a product for free.
> > > 
> > > I wonder how, since Debian is lagging so much behind that even 
> > > RHEL 7 is released with systemd.
> > 
> > By reading users' bug reports. RHEL has a limited choice of prebuilt
> > software, therefore a limited number of usecases.
> 
> Then they wouldn't be interested in use case they didn't support from 
> the start, so any extra testing, especially extra testing on a different version
> wouldn't give much help.

As long as you disregard new features popping here and there in a new
RHEL point release - sure.


> > Besides, RHEL7 is supported until 2024 (IIRC). There's plenty room for
> > small improvements.
> 
> IIRC the presentation they did at my work, that's 2024 + 3 years
> if you pay enough.
> 
> At least, that's the case for RHEL 6, and I do not
> see why it would be different.

Again, no argument here.


> > > I wonder even why they
> > > still have jobs posting for QA people if all is needed is to have users of
> > > others distributions.
> > 
> > I haven't imply that offloading beta-testing to the community mutually
> > exclusive with internal testing :)
> 
> But we can agree that community feedback do not replace internal testing. 

Indeed. Sometimes I wish Debian had one.


> And given that competitor like Novell or Oracle also ship systemd ( and
> soon Canonical ), the testing do benefit to all of them. It also
> benefit to community distribution who then become more serious competitor.
> 
> If it benefit to one, it benefits to the others. 

You're contradicting yourself. To quote your mail:

> Then they wouldn't be interested in use case they didn't support from 
> the start, so any extra testing, especially extra testing on a different version
> wouldn't give much help.


> > > > > People keep wanting the project to be free of corporate influence, but 
> > > > > it seems that some wouldn't be against having a bit of corporate influence if the
> > > > > influence was in the way they want..
> > > > > 
> > > > > > Given that RHEL's main selling points are enterprise
> > > > > > capabilities, quality control, and (for the government market)
> > > > > > security accreditation and lots of support, I'd much rather see
> > > > > > diversity and weak code spread across competing distributions.
> > > > > 
> > > > > Canonical was criticized for keeping their code for their ( mir, unity ),
> > > > > and Redhat would be criticized for not keeping the code only for them. 
> > > > 
> > > > No. RedHat is criticized for pushing their code to everyone and their
> > > > dog.
> > > 
> > > People keep saying that, but none show no conclusive proof. Just stating
> > > it doesn't make it true. And it doesn't resist simple inquiry such as:
> > > 
> > > "if they wanted to push it everywhere, why would it be non portable to 
> > > BSD ?" 
> > 
> > Because BSD 'market share' is irrelevant at RedHat's turf. See AT&T vs
> > BSDi case dated '92.
> 
> I fail to see the relation. That case was closed years ago, and there is lots of companies
> using BSD without any trouble. Lots of security appliance are running BSD so
> the lawsuit is kinda forgotten from people mind.
> 
> Can you clariffy ?

Sure. You go to that hosting near you, you see Linux. Maybe that Redmond
parody for OS. But you have to look really hard to get a hosting on BSD.

Of course, in non-public sector thing will be much different.


> > And, of course, writing a non-portable code is much easier than a
> > portable one ;)
> 
> So is not caring about others distributions, yet someone did.

Maintainers of said distributions, maybe? There're Debian-specific
patches for systemd, for example.


> > > We go back to criticize everything that happen, that's getting old.
> > > And kinda poisonous, looking at the people leaving TC or Debian or maintainership.
> > 
> > People leaving Debian's TC is a sad thing to me too. But I don't read
> > debian-devel to have my own opinion for the reasons of leaving.
> > All I see that DD's that actively promoted systemd in the past are
> > leaving now. If I had the mood I'd even came up with some kind of crazy
> > conspiracy theory.
> 
> You do not need to read debian-devel. LWN make good summaries
> http://lwn.net/Articles/621003/ 
> http://lwn.net/Articles/620879/
> http://lwn.net/Articles/620878/
> or developpers blog :
> https://joeyh.name/blog/entry/on_leaving/

Thanks, I'll read it.


> > > Oracle is attacked by everyone for the stewardship leading to forks on mysql
> > > and openoffice, among others. They even alienated their own community on solaris.
> > 
> > And every time one's using rpm-based distribution one's using
> > Oracle-controlled BerkleyDB.
> 
> That's seriously not the best example, see oracle latest trick on the license
> ( http://lwn.net/Articles/557820/ ) in the latest major release.
> And berkeley DB was started by a university, then sleepycat 
> software maintained it, that was acquired by Oracle in 2006.

A library moved to AGPL3 is a good thing by itself. Collateral damage of
such re-licensing is probably not. But, according to the article, it's
not that big deal for the free software:

To that point, Kuhn clarified what is a frequently-misunderstood issue:
when Debian releases its distribution, the combined work that it
constitutes can be relicensed without relicensing any of the original
upstream packages. In other words, if Debian builds and links BIND 9
(which is under the BSD-like ISC license) against the AGPL'ed BDB 6.0,
the resulting BIND 9 binaries would be under the AGPL, but that new
license only flows downstream to subsequent redistributions of Debian.


And producers of non-free software should suffer <evilgrin/>.


> > And Oracle's own Chris Mason single-handenly wrote btrfs, now a favorite
> > FreeDesktop toy.
> 
> Not really. Josef Bacik ( Redhat ) was also working a lot on it.
> Chris Mason left Oracle for Fusion IO in 2012, and Josef bacik left RH to join him.
> Then Chris joined Facebook in december 2013, followed again by Josef.
> 
> http://www.phoronix.com/scan.php?page=news_item&px=MTUzNTE
> 
> I can also ensure that Chris was not working alone on btrfs in Oracle. 

Does not change the fact that btrfs was born in Oracle. And nobody did
push btrfs to anyone before it was ready.


> > > Novell was criticized for providing Mono, and providing software written in mono
> > > for gnome ( thus changing part of the core of Gnome ), and was criticized for 
> > > trying to get Microsoft working on interoperability. 
> > 
> > And, at the same time:
> > 
> > Novell was THE Xen's leading distribution back in the old day.
> 
> And they dropped as RH acquired Qumranet and pushed KVM in kernel 
> for RHEL 6. While I must admit that KVM is nifty, Xen still have the 
> leading edge when it come to new concepts like unikernel, who permit 
> to have a rather impressive density in computing cluster. But I digress.

I must miss something. This clearly shows that Xen is still in SLES 12:

https://www.suse.com/documentation/sles-12/singlehtml/book_virt/book_virt.html


> > Novell was the company designed heartbeat.
> 
> Sure, they did lot of stuff around, but what controversial changes 
> did they push ?

Nothing comes to mind immediately, and that's was my actual point :)


> Alas, Novell/SUSE did got a few stuff rejected upstream.
> Example, their improved menu for gnome was not merged :
> https://en.opensuse.org/GNOME_Main_Menu

You owe me a new set of eyes. I seen software as ugly as all seven
deadly sins at once, but this image will be etched in my mind forever. I
see why this change was rejected by the upstream. Even if it's GNOME
upstream.


> XGL was "supsersed" by AiGLX.

XGL was a neat X fork, but hardly had any future.


> > Considering mono as a 'change in the core ecosystem' is to stretching
> > things a bit IMO :)
> 
> It indeed depend on what ecosystem we are speaking and I should have been clearer.
> In my case, this was gnome ecosystem, by pushing for having mono as a blessed language for the
> core platform of Gnome. 

GNOME was lost anyway after they decided to implement their own CORBA.
And it did happen long before that controversial programming language
support.


> > > So sure, not changing anything in the core is the right way to avoid some critics. Obviously,
> > > haters still find their way, even when they have the choice.
> > 
> > There's one thing that they fail to understand at RedHat - there's
> > absolutely no need for the change to be disruptive.
> 
> As we say in french, on fait pas d'ommelete sans casser des oeufs.

Well, for some unknown reason I don't feel like my servers need to be a
part of that omelet. At least in the foreseeable future.

Reco


Reply to: