LWN: Comments on "Fedora, UUIDs, and user tracking"

clue: when it's not opt-in it's a $cam

codeofdrama — Wed, 30 Jan 2019 13:22:59 +0000

I think it's not completely far fetched to read it as describing a segment of the users of the Fedora distribution in a derogatory way using the name of a debilitating mental illness.

Perhaps it would be less divisive to call the setting itself "paranoid" instead of the people.

clue: when it's not opt-in it's a $cam

rahulsundaram — Mon, 28 Jan 2019 03:24:21 +0000

> You shouldn't have used of the slur 'paranoid'

It is not a slur. I have seen it used as a functional description is many software settings.

clue: when it's not opt-in it's a $cam

Garak — Mon, 28 Jan 2019 02:41:07 +0000

We document how you can disable it if you're so inclined (read: paranoid).

You shouldn't have used of the slur 'paranoid' there if you are really trying to be an honest broker in this debate.

Fedora, UUIDs, and user tracking

jccleaver — Wed, 23 Jan 2019 19:38:27 +0000

> You don't need to keep doing the test *if nothing changes*. If something does change, then you don't *know* that failover will still work the way you think it will, and the only way to be sure is to test it again.

The problem is that that leads to epistemological issues that fly in the face of real-world reasoning. Instead of worshiping at the altar of A/B tests, one can focus on the things that matter operationally. Stateless cattle are a tool, one of many, but they are not the end-all and be-all of operation any more than constant Gentoo-like recompilation for performance improvements "just in case" are.

Process matters, and the Operations side of DevOps have formed a new, artificially restrictive religion around this design methodology.

Fedora, UUIDs, and user tracking

edgewood — Wed, 23 Jan 2019 18:52:21 +0000

You don't need to keep doing the test *if nothing changes*. If something does change, then you don't *know* that failover will still work the way you think it will, and the only way to be sure is to test it again.

Fedora, UUIDs, and user tracking

jccleaver — Wed, 23 Jan 2019 18:30:08 +0000

> > And there are alternatives than forking off.
> Of course. But *every* alternative, including a fork, requires a substantial (and sustained!) increase in time, effort, and money from non-RedHat folks. To pretend otherwise is nothing short of delusional.

And this is the crux of the problem. Forking Fedora is a lot of time, effort, and money to achieve -- an unknown purpose. There's only one Rawhide, and there's only one central upstream for RPM systems. And, again, people use RHEL for reliability and scale. Forking Fedora and try to make a new RHEL out of it (with all the certifications, process, vendor support, etc) would be basically pointless.

Forking EL (either as a rebuild of RHEL in parallel with CentOS, or a rebuild of CentOS) might make more sense (it makes sense for Oracle, and Amazon), but now you're three steps removed from being able to influence any low-level changes in the upstream. You can barely get devel@fedora to care about EPEL these days, so you can be sure derivatives will... continue to be told to pound sand.

Until the philosophical problems with Fedora/Rawhide/RHEL and CentOS/*EL are solved, which really requires an Official Red Hat Plan Of Action, as the organization behind all three*, there's no easy way for an outside team of a few motivated people to have a real impact on the ecosystem by forking. And so here we are.

(*Red Hat itself is the one entity that could "fork Fedora", both morally and practically, if it felt that restarting the project was for the best.)

Fedora, UUIDs, and user tracking

pizza — Wed, 23 Jan 2019 16:16:31 +0000

> You do realize there is a difference between sponsorship and dictatorship right?

It's only a difference of degree.

> And there are alternatives than forking off.

Of course. But *every* alternative, including a fork, requires a substantial (and sustained!) increase in time, effort, and money from non-RedHat folks. To pretend otherwise is nothing short of delusional.

> Red Hat could publicly admit that this is the case or it could change it's involvement in a manner in which the community is not treaded like second class citizens.

What would that entail, exactly? Red Hat no longer funding developers and infrastructure for the things they care about? Or are you honestly trying to say that folks (regardless of who signs their paycheck) should be forced to work on things they don't care about? (Keep in mind that handing over a paycheck tends to greatly increase the likelihood of someone caring)

Fedora, UUIDs, and user tracking

johannbg — Wed, 23 Jan 2019 13:22:45 +0000

You do realize there is a difference between sponsorship and dictatorship right?

Fedora is falsely being advertised as something it's not which could constitute as deliberate deception on Red Hats belhalf.

And there are alternatives than forking off.
It's not the only option as you make out to be.
Red Hat could publicly admit that this is the case or it could change it's involvement in a manner in which the community is not treaded like second class citizens.

Or now that IBM is at the helm it could do something that Red Hat never could or even might have too so it's own products dont get the same treatment as the community made once. ( IBM could make things worse, only time will tell )

Fedora, UUIDs, and user tracking

pizza — Wed, 23 Jan 2019 12:20:59 +0000

>So what you are saying is that gold and platinum sponsors in communities and conference should dictade and decide which direction those community take

Everyone participating in Fedora, or indeed any other community, is acting in their own self-interest. I don't mean they're out to screw others in the process, but rather that they are getting something they value out of it.

Meanwhile. Have you ever participated in any sort of formal organization? Those who participate get to dictate what goes on. And those who have the most time/energy to contribute particpate the most. And who has the most time/energy? Those paid to particpate. (Because participating doesn't take time away from such mundane things like feeding their families..)

> I most certanly disagree but if it's corporate that allows for other to get involved without interference with it's products until the corporate takes interest in your work, in which they either take over your work by overwhelming you with workforce or simply buy it or out it out if does not align with said corporate vision, with end result being always the same. The corporate will take it from here, then I agree with you.

It's Free Software. If you have a problem with (certain) others using it, or building on it in a way you don't like, then you should have released it under a different license.

> Quite frankly i'm amazed that lawsuit hungry colonists that the Americans are, that Red Hat has not been suit over an violation of the consumer act regarding Fedora there in the states but then again i'm not a laywer...

Winning a suit requires demonstrating someone has been tangibly harmed. I'm having a hard time seeing the harm RH has caused. And, for that matter, even the someone.

Fedora, UUIDs, and user tracking

johannbg — Wed, 23 Jan 2019 07:52:54 +0000

By funded you mean employees of Red Hat who bare Fedora title in their job descriptions right? Or is Red Hat donating money to certain community members?

Then there is the fact ( despite misleading mailinglist title ) that there exist no Fedora developers other than those that work or contribute in maintaining the project and associated infrastructure.

The seperation in the role of packager was created, to keep the two different dialogs ( policies vs maintainances ) about packages in the distribution seperated.

Every distribution are made up of ( more or less the same ) upstream components which is the place where the actual development takes place. Not downstream.

You can even extend this further, the only seperation between *nixes as in linux,bsd and solaris takes place in the core/baseos, the rest is more or less the same applications or application stack running on top of those core/baseOS stacks.

Then those upstream components are glued together with the base/coreOS for the relevant *nix, runtime policies are made and new distribution and associated religion is born.

Waisting tremendous time and energy in people own lifecycle for no apparent gain other than maintaining nothing more than collective eco.
Leading to this happy life fulfilling cheers and joys of various upstreams having to deal with this needless downstream distribution deviation mess...

Fedora, UUIDs, and user tracking

johannbg — Wed, 23 Jan 2019 07:00:50 +0000

Well failed from my perspective when Red Hat stop incorporated community innovation ( so to speak ) into RHEL and started to thrust it's internal coporate emphasis into the project and it's direction.

This needless fragmentation between linux distributions only exist on religious,philosophical level and the associated needless deviation that has seperated the distribution on component level as an result of that needs to be stopped ( on the core baseOS level atleast ).

Red Hats plays it's part in keeping that from happening by holding death grip on the /etc/sysconfig directory ( which should have been eliminated in Fedora by now ) , inconsistent naming in components between distributions, ( people can be as religious as they want which package manager is best or whether to use one and innovate in that area, just keep the package names consistent between distros ) etc.

With regards to epel, epel should have never existed in Fedora no more than modularity has any place in Fedora today, tomorrow, ever.

Both of these effords belong in distributions which are based on RHEL not Fedora which naturally puts it in CentOS these days, after Red Hat aquired it and it's community along with it.

Fedora, UUIDs, and user tracking

zdzichu — Wed, 23 Jan 2019 06:36:44 +0000

Funding does not equal developers. About 1/3 of Fedora devs are funded by Red Hat.
RH pays for almost all the infrastructure, though.

Fedora, UUIDs, and user tracking

johannbg — Wed, 23 Jan 2019 06:14:55 +0000

So what you are saying is that gold and platinum sponsors in communities and conference should dictade and decide which direction those community take, to which level and what talks are given ( which would always favour said corpirate?

I most certanly disagree but if it's corporate that allows for other to get involved without interference with it's products until the corporate takes interest in your work, in which they either take over your work by overwhelming you with workforce or simply buy it or out it out if does not align with said corporate vision, with end result being always the same. The corporate will take it from here, then I agree with you.

Quite frankly i'm amazed that lawsuit hungry colonists that the Americans are, that Red Hat has not been suit over an violation of the consumer act regarding Fedora there in the states but then again i'm not a laywer...

Fedora, UUIDs, and user tracking

jccleaver — Wed, 23 Jan 2019 01:24:06 +0000

> It's not like RHEL & Fedora are the only games in town; there's plenty of distribution-level competition, encompassing a wide spectrum of focus, release, funding and governance models.

Well, yes and no. Corporate world is RPM-based. Developers love the Debian/Ubuntu ecosystem. Embeddeds have their own needs.

If we had stronger competition in the RPM ecosystem, I think whatever Fedora ends up being would be a stronger project. Instead we have this weird process of passive-aggressive interaction where the distracted flagship community project is not functioning as a reliable steward.

Fedora, UUIDs, and user tracking

jccleaver — Wed, 23 Jan 2019 01:20:33 +0000

> And as things are evolving ( everything is being pre-built upstream, flatpacks, docker images etc ) there is always becoming less and less incentive for end users even administrators who need to start clinching themselve to cloud solution to make a name for themselves in related communities ( they participate in ansible galaxy not ansible in Fedora right ) to partake in downstream distributions.

We're coming at this from opposite sides, but I agree with you that the current implementation of Fedora Project is not working. "Red Hat Linux" was a wonderful thing, and opening "Red Hat Linux" up to community involvement with a derivative functioning as the funding for it all seemed reasonable enough ($34B of reasons, really). But whatever the Fedora Project has been trying to be distinct from that has failed.

> What once was a birth mark has grown into a tumor because the balance between Red Hat's involvement and the community has been tipped too much in favour towards Red Hat, something I warned Denise about would happen if she would throw more Red Hatters at the problem as opposide to say no you have find ways to make due with what you have, get the community rise to the occation when Red Hatters came running to mommy begging for more resources.

There are people that really want *Fedora* (the Desktop distro) to succeed in the distro wars. I don't. I couldn't care less about *Fedora*... I haven't used it for anything meaningful since Core 5. I care a great deal about RHEL and its derivatives, and Red Hat provides the process used to take Fedora and make a reliable, engineered, released product out of it. Fedora's missteps affect EL users.

I want what's best for the Red Hat ecosystem -- for basically any Linux distro that's RPM-based. If it takes throwing Red Hatters at the problems in the Fedora Project, so be it.

Fedora, UUIDs, and user tracking

pizza — Tue, 22 Jan 2019 23:37:18 +0000

> What once was a birth mark has grown into a tumour because the balance between Red Hat's involvement and the community has been tipped too much in favour towards Red Hat

Um, hasn't Red Hat has always provided the lion's share of the funding (and thus, developers) working on Fedora?

Don't those who do the actual work (or pay for it) ultimately get to set the direction of that work?

It's not like FHEL & Fedora are the only games in town; there's plenty of distribution-level competition, encompassing a wide spectrum of focus, release, funding and governance models.

Fedora, UUIDs, and user tracking

johannbg — Tue, 22 Jan 2019 21:59:21 +0000

It knows everything about it's own customer base but not the path for $NEXT RHEL release.

And as things are evolving ( everything is being pre-built upstream, flatpacks, docker images etc ) there is always becoming less and less incentive for end users even administrators who need to start clinching themselve to cloud solution to make a name for themselves in related communities ( they participate in ansible galaxy not ansible in Fedora right ) to partake in downstream distributions.

Being first is something that Fedora has not been for years, The features are nothing more than those that Red Hat pushes fourth, The only real freedom you have is to choose whether you partake in the distribution or not so the only remaining things of the foundation that Fedora was built upon is friends.

What once was a birth mark has grown into a tumor because the balance between Red Hat's involvement and the community has been tipped too much in favour towards Red Hat, something I warned Denise about would happen if she would throw more Red Hatters at the problem as opposide to say no you have find ways to make due with what you have, get the community rise to the occation when Red Hatters came running to mommy begging for more resources.

It's a fine line to keep in check so that either of these forces dont dominate the other.
An skill that Red Hat or someone(s) understood and had mastered within Red Had and made what Red Hat is today, an skill that Red Hat has lost ( atleast with regards to Fedora ) or those that had it moved to build communities somewhere else *cough* Ansible *cough*...

Fedora, UUIDs, and user tracking

jccleaver — Tue, 22 Jan 2019 17:30:22 +0000

> What get picked up and works in Fedora ( thus needs to be measuarble in Fedora ) gets integraded into the RHEL stack.

Except this is distro implementation level stuff. Presumably RH already knows how many server, VM, or (God help you) Desktop systems you're running since you're paying licenses for it, even if you're not using RHN for lifecycle management.

Fedora, UUIDs, and user tracking

johannbg — Tue, 22 Jan 2019 12:58:16 +0000

Is IBM/Redhat not directing it's customers towards it's implementations in Fedora.

The Fedora is beta platform for Red hat mantra, which dictade and decides the direction of the project and treats it's community as a second class citizen.

What get picked up and works in Fedora ( thus needs to be measuarble in Fedora ) gets integraded into the RHEL stack.

Fedora, UUIDs, and user tracking

nilsmeyer — Tue, 22 Jan 2019 11:51:32 +0000

Wouldn't it be infinitely more useful for Redhat/IBM to know what their customers and potential customers are willing to pay for?

Fedora, UUIDs, and user tracking

archbtw — Sun, 20 Jan 2019 23:26:39 +0000

Sorry mattdm, I should have elaborated. With ring signatures, maybe more people would feel comfortable with providing more data than just a count, given that it is theoretically not traceable back to the owner.

Fedora, UUIDs, and user tracking

mattdm — Sun, 20 Jan 2019 19:02:35 +0000

Can you elaborate? What would this get us over non-tracking counting?

Fedora, UUIDs, and user tracking

archbtw — Sun, 20 Jan 2019 15:48:27 +0000

What about ring signatures as a form of tracking?

Fedora, UUIDs, and user tracking

jccleaver — Fri, 18 Jan 2019 17:51:22 +0000

> As operator I can give you the reason. The key reason is a pride. We CAN shoot any node to the head and keep system running. So everyone talking about 'cattle' not with intention to cause a massive extinction in VM population but as a token of pride.

Sure, I used to do this too with redundant HA systems. But once you've physically pulled the power plug on one box once and your service has kept working, you don't need to *keep doing that* to prove that to anyone anymore.

That's supposed to provide operational support for your service, not be part of the design whenever there's the slightest hint of something unusual.

Fedora, UUIDs, and user tracking

jccleaver — Fri, 18 Jan 2019 17:47:02 +0000

> The method you described was something I setup in the old days when servers where named after planets in the solar system,greek gods or something and administrators talked to them and routinely had hug them to keep them running. Expensive infrastructure model in todays datacenters.

Yes, I quite remember the "old days", but this entire model being pushed is a pendulum too far in the opposite direction. Very, very few entities have the actual need for cattle (c.f. https://xkcd.com/1737/ ) If you're Netflix and you have 500,000 hosts all decrypting H.264 or something and data locality concerns are handled elsewhere, then fine -- good for you. The rest don't have "cattle" like that, but they're not "pets" except for key systems... they're "fleets". And as any auto-mechanic knows, just because everything is the same model doesn't mean the workload has the same effect on a car.

> Today if a server,vm misbehave it's just shoot in the head and one or more new instance is born to take it's place. systemd spawned containers only live for as long as they are needed and created with a git commit.

That's not engineering, that's playing with tech.

> The time it takes to generate an image using official mirrors on this host with the method I used is 1m50.053s or so per host so roughly 15m went on building the images and another 15m in testing.
> Would be faster probably if I bothered to run internal mirrors but then I would have to mirror 4 distro's ( Arch,Debian,Fedora,OpenSuse ) and different releases of those distro's but thats not high on my priority list thou that might change if fedora is about to track it's user base...

Well, in that case you're just shooting yourself in the foot. Local mirrors for OS data is about as fundamental a thing as you'd want for provisioning, and in this day of TB of space everywhere there's no reason not to use one.

I haven't timed installs because I don't have split-second needs, but 2m sounds about right except for any local logic being doing in %post.

Fedora, UUIDs, and user tracking

mattdm — Fri, 18 Jan 2019 15:45:14 +0000

Although you put it in a weirdly negative light (and given the actual plan, "privacy invasion" seems like QUITE a stretch), yes, having better information helps us as a project talk to our sponsors about resources. I definitely want that. But this won't just be available internally — the goal is to make a site like https://metrics.opensuse.org/. Anyone in the project will be able to benefit from the information. Or, if they want, to completely ignore it and do the thing they care about.

Number of systems running, is, of course, just one factor. I don't think there are many people running Fedora Robotics — but the people who do run it do stuff like https://www.electronicspecifier.com/robotics/why-no-one-c..., which is super awesome.

Fedora, UUIDs, and user tracking

mattdm — Fri, 18 Jan 2019 15:38:32 +0000

Measuring patterns in use is one way of better understanding what users want.

Fedora, UUIDs, and user tracking

johannbg — Fri, 18 Jan 2019 10:23:36 +0000

you ofcourse have centralized syslog server to diagnoze problems afterwards but you dont go down the rabbit hole of chasing every issue with every host,vm or container.

Pattern needs to have emerged before issue is looked at otherwize you could be waisting time, resources thus money chaising down anomaly, that corner case bug every one love...

Fedora, UUIDs, and user tracking

amarao — Fri, 18 Jan 2019 09:56:49 +0000

>> if a server,vm misbehave it's just shoot in the head

>I never understood this, wouldn't you want to at least diagnose the problem and fix whatever caused the problem so that the problem goes away for future server/vm/container instances?

As operator I can give you the reason. The key reason is a pride. We CAN shoot any node to the head and keep system running. So everyone talking about 'cattle' not with intention to cause a massive extinction in VM population but as a token of pride.

For the real cases it's mixed. As much as I love to work with Linux, I know how badly it can start to behave in some conditions. One unresponsive block device may brick any server to the level when everything is screwed. Some processes are in TASK_UNINTERRUPTIBLE, and this is the end of the game for the well-behaving system.

Replaced drive got a new letter instead of the old one because old one died with traces - old name is still used.

tmpfs is huge breach in a memory logic, as you have buffers which can not be discarded and all monitoring do not know how to detect 'low memory' condition anymore.

etc, etc. Some of bugs are so 'vendor fault' that it's easier to reboot than to report bugs (example: https://github.com/amarao/lsi-sata-fuckup, bug is now 7 years old, and this script is still hangs IO on whole enclosure).

Sometimes it's a well-known fault in application, but it's easier to cover it with load balancer than to debug it.

To deal with all this, there is the approach when individual server does not need have more reliability then a hard drive. We do 'raids' of buggy servers and this is fine.

If some fault types are often enough it may worth to investigate it. Rare ones are just silently ignored (can't reproduce). If operator have time, s/he can go to server and do some debug, but this is operators time, and there is a bug tech. dept in whole infrastructure to waste it in rare issue of incompatibility of beep with colctr.

Fedora, UUIDs, and user tracking

pabs — Fri, 18 Jan 2019 09:33:01 +0000

> if a server,vm misbehave it's just shoot in the head

I never understood this, wouldn't you want to at least diagnose the problem and fix whatever caused the problem so that the problem goes away for future server/vm/container instances?

Fedora, UUIDs, and user tracking

flussence — Fri, 18 Jan 2019 09:22:33 +0000

>Complaints can be useful for fixing specific issues, but they're generally not useful for helping figure out a more general direction for development.
I disagree. The project could push out tracking to as many users as possible and deal with the (well-known) consequences, *or* it could simply notice whenever a proposal is so bad it sparks flame wars across the entire internet and change course.

The latter option never gets taken by FOSS projects of this size. Fedora has a chance to revolutionize the industry! ;-)

Fedora, UUIDs, and user tracking

johannbg — Fri, 18 Jan 2019 08:22:50 +0000

The method you described was something I setup in the old days when servers where named after planets in the solar system,greek gods or something and administrators talked to them and routinely had hug them to keep them running. Expensive infrastructure model in todays datacenters.

Today if a server,vm misbehave it's just shoot in the head and one or more new instance is born to take it's place. systemd spawned containers only live for as long as they are needed and created with a git commit.

The time it takes to generate an image using official mirrors on this host with the method I used is 1m50.053s or so per host so roughly 15m went on building the images and another 15m in testing.

Would be faster probably if I bothered to run internal mirrors but then I would have to mirror 4 distro's ( Arch,Debian,Fedora,OpenSuse ) and different releases of those distro's but thats not high on my priority list thou that might change if fedora is about to track it's user base...

Fedora, UUIDs, and user tracking

jccleaver — Fri, 18 Jan 2019 06:47:19 +0000

> Based on my experience maintaining rhel and centos for a decade or so in various infrastructure setups, staying on older rhel release was done due to complications and or lack of time upgrading, rather than ease of use or api stability requirements.

Well, one man's "complication" is another man's API stability requirement, or general shared library conflict (ditto), or if-it's-not-broken-don't-fix-it decision. CentOS and RHEL 4 -> 5 was rough at times (especially if you were trying to use Xen), but EL5->EL6 was incredibly smooth. EL6->EL7, definitely not so much. Many I know who've been staying on EL6 were doing it explicitly and consciously, which didn't seem to be the case for EL5.

> Just this evening I did 10 fresh fedora installs ( install + test + delete ) and two debians for the same purpose ( confirm if bug was present there as well ) all in ca half an hour which is something I would never have done if either os or both would still be on legacy sys v init, let alone in half an hour.

If it's a "fresh fedora install" then you're either composing via new anaconda run, using kickstart, or cloning. I'm assuming by "install" you mean a kickstart, but having just done seven automated EL6 VM builds earlier today I'm hard pressed to think of why that would take so long or why you wouldn't be able to too. Kickstart should take a few minutes at most. Boot takes <1m. Do it in parallel depending on your provisioning system. Automating deployments is not difficult, and nothing about regular init blocks this.

Fedora, UUIDs, and user tracking

johannbg — Fri, 18 Jan 2019 00:32:12 +0000

Based on my experience maintaining rhel and centos for a decade or so in various infrastructure setups, staying on older rhel release was done due to complications and or lack of time upgrading, rather than ease of use or api stability requirements.

Just this evening I did 10 fresh fedora installs ( install + test + delete ) and two debians for the same purpose ( confirm if bug was present there as well ) all in ca half an hour which is something I would never have done if either os or both would still be on legacy sys v init, let alone in half an hour.

Fedora, UUIDs, and user tracking

jccleaver — Thu, 17 Jan 2019 23:12:22 +0000

> I would argue quite the opposite as in an distribution ( not just RH ) that is not using systemd cannot be a market winner.

There's still a lot of EL6 out there in deployment

Fedora, UUIDs, and user tracking

johannbg — Thu, 17 Jan 2019 22:58:37 +0000

None what so ever other than having the joy of having it's privacy invaded...

This information is only benefitial to IBM/Red hat so it can focus on what it should focus it's resources on...

Fedora, UUIDs, and user tracking

johannbg — Thu, 17 Jan 2019 22:49:23 +0000

"a RH clone that doesn't use systemd as PID 1 can be a market winner"

I would argue quite the opposite as in an distribution ( not just RH ) that is not using systemd cannot be a market winner.

Modern infrastructure,cloud, container vendors and upstreams are heavily using systemd features to deploy,test and run on it.

Fedora, UUIDs, and user tracking

jccleaver — Thu, 17 Jan 2019 18:28:41 +0000

> At this point, Fedora needs to go back to it's roots of being genering,clean the core/baseOS as should have been done from the start, provide all the Red Hat product stack ( or it's open upstream equallent ) as rpm in the distribution so the remaining admins dont vanish into the cloud and the distribution put on a serious diet by shaving off roughly 7k components from the distribution so it becomes agile enough again to deal with the changes in the linux environment and then just hope for the best...

I really couldn't agree with this more.

"Fedora Workstation/Desktop" can do what it wants -- which seems to be the reference implementation for GNOME and that's it -- but "Fedora", in the context of being the successor to RHL, the owner of rawhide, and the de facto upstream for the entire Red Hat ecosystem, *MUST* change. In trying to be all things to all people, while focusing on Lennart's laptop, it's consistently targeting questionable cadences and questionable technical movements, frustrating the wider Red Hat ecosystem and community, all while naively claiming to be doing something for Linux on the Laptop.

"Fedora Project" as a project should factor out everything that applies to all RPM downstreams and focus on the core, incremental infrastructure necessary to keep that running. Enforce RPM standards that *can* *now* be applied and used by all distributions. Enhance copr, pagure, and so forth to provide resources for the entire RH community.

"Fedora Project" can and should QA and release reference releases for this core functionality, but those are indeed intended to be reference releases, of interest mostly to Linux enthusiasts, distribution developers, and theoreticians, without intent of these *necessarily* being market winners in and of themselves. "Fedora Workstation" can be a market winner. CentOS can be a market winner, a RH clone that doesn't use systemd as PID 1 can be a market winner, a tiny RPM-distro for embedded can be a market winner, but Fedora reference releases shouldn't.

Once steps like this start being taken, the RH community as a whole will start functioning better again.

Fedora, UUIDs, and user tracking

nilsmeyer — Thu, 17 Jan 2019 10:13:15 +0000

> So, that's the thing about collecting feedback: if you make it voluntary, you only get responses from volunteers. Volunteers are, by definition, self-selecting. In general, we've learned that if you ask for feedback, you generally hear mostly from people who want to complain. Complaints can be useful for fixing specific issues, but they're generally not useful for helping figure out a more general direction for development.

I think the selection bias could work in your favour, you will only get responses by people who care enough to respond and you get consent as well. The problem that you're getting mostly complaints is that you mostly only solicit complaints - I can file a bug or an issue but I can't really file a commendation when I like something. Look for example how proprietary app stores and apps do it: They have a review system in place and some applications actively solicit feedback ("please rate [blah] the app store"). So just as an example you could put a short message in /etc/issue (I know canonical uses it for advertising) along the lines of "Like Fedora Workstation? Please tell us about it [link]".

I believe it's a matter of asking the right questions and interacting with your users at eye-level.

> The purpose of data like this is to identify patterns of usage. For example, if we start getting a more accurate count of the relative number of users that install Fedora Server vs Fedora Workstation, we can understand where we should spend more of our limited resources working on improvements.

I think that's the wrong approach to take. First and foremost you should work on something that you find rewarding and that helps you, not something that wins out in a popularity contest - by that metric people should volunteer for Microsoft instead of improving Fedora Workstation.

Fedora, UUIDs, and user tracking

nilsmeyer — Thu, 17 Jan 2019 09:53:53 +0000

> Are you saying that Gnome desktop will be scratched if it does not meet some usage critera or for that matter other products,modules could be sacrificed in order to force uptake in other products,modules to justify it's continued existance in the product portfolio at the cost of existing users of said product and the entire Fedoras end users privacy?

This is why there is now only one text editor around.