|
|
Subscribe / Log in / New account

Fedora, UUIDs, and user tracking

By Jake Edge
January 15, 2019

"User tracking" is generally contentious in free-software communities—even if the "tracking" is not really intended to do so. It is often distributions that have the most interest in counting their users, but Linux users tend to be more privacy conscious than users of more mainstream desktop operating systems. The Fedora project recently discussed how to count its users and ways to preserve their privacy while doing so.

Ben Cotton brought up the topic in the context of a proposal for Fedora 30. Instead of the current method of counting unique IP addresses that request updates from the DNF mirrors, which is an unreliable estimator of Fedora usage, the proposal would create a unique user ID (UUID) for each installed system that would be sent with DNF mirror-list requests. It explicitly calls out privacy concerns: "We don't want to track; just count."

The proposal outlines the kind of information that the project would like to count, including the version of Fedora, the Fedora variant (or spin), and the architecture of the machine. It would also be useful to have some way to distinguish long-lived installations from one-off test systems in virtual machines. Currently, variants cannot be distinguished and the unique IP counting method both undercounts systems behind network address translation (NAT) and overcounts systems that change IP addresses frequently. The UUID is similar to what openSUSE uses, so "this is ground already traveled".

Using the machine ID (stored in /etc/machine-id) as the UUID is not part of the plan, since it may be used in other ways that would facilitate tracking. So some kind of random UUID would be generated for this purpose. But, as Lennart Poettering pointed out, sending a UUID makes tracking possible even if the project doesn't want to do that tracking. Essentially, users would need to trust that the project isn't doing the tracking because it says it isn't. While he was skeptical that Fedora really wanted to use a UUID that way, he did suggest using an application-specific machine ID, like those calculated by sd_id128_get_machine_app_specific(). That way, Fedora would be using an existing mechanism that generates a UUID using the machine ID and an ID specific to the counting application.

Poettering also mentioned that Ubuntu counts installations via NTP, which might be an option if Fedora wanted to run its own NTP servers. Both Ubuntu and Fedora configure their systems to regularly ping the NTP servers. Another possibility would be to send a "countme" flag once a day as part of the captive-portal and connectivity detection that is already installed with Fedora, but that did not sit well with Kevin Kofler. He called the existing NetworkManager-config-connectivity-fedora package "spyware" and does not install it on his systems. Fedora project leader Matthew Miller (who is also the owner of the feature proposal) said that the connectivity check could be used but it would only count a subset of desktops and not other types of installations, such as server, cloud, or container. In addition, setting up NTP servers would be much more work than hosting a UUID-counting service, he said.

Miller said that the intention is to rotate the logs "fairly frequently", but that is not really visible to users so there is still a trust factor present. But Tom Gundersen suggested another approach:

You could move the rotation to the client by hashing the UUID with a timestamp of sufficiently coarse granularity (a week?) before submitting it.

Then you make sure that all UUIDs submitted by a given machine during a given time window are the same, but UUIDs submitted in different windows are not related, and you don't have to trust the server to respect your privacy.

That approach would "make sense" Poettering said, though he still advocated using NTP or the "HTTP ping" that is done as part of the captive-portal detection. Others, such as Bruno Wolff III, are worried that even if the UUIDs are changed frequently, users still have to trust Fedora (or someone who gained access to the logs) not to correlate UUIDs, IP addresses, and other information to track users that way. Beyond that, Nicolas Mailhot is concerned about interaction with the EU General Data Protection Regulation (GDPR); that requires a shift in thinking about how data can be misused:

That's what the GDPR is about. It's *your* responsibility as data collector to think about how data could be used, it's *your* problem to protect it, it's *your* problem if it's misused, you can not make it available on a platter for others to do evil things with and claim it's those people's problem.

Wolff also pointed out that attackers may try to send UUIDs that are unexpected. Those could be generated to try to attack the system in some way or they could simply be strings containing profanity or other "not safe for work" (NSFW) content. He wants to ensure that the actual UUID strings don't end up in reports or require review by humans. Even ensuring that the strings are valid hexadecimal doesn't preclude inventive usage that could embarrass the project or offend people. Beyond that, UUIDs could be changed more frequently to try to inflate the statistics.

As these privacy and other problems with the UUID scheme were being discussed, Poettering came up with a scheme that alleviated most of the problems that were identified. He proposed that a "countme" flag simply be added to a single mirror-list query each week. The sum of all such queries over a week's time should provide an accurate estimate of the number of Fedora systems. That way, UUIDs need not be stored, which removes much of the concern—data that is not stored cannot be misused.

Poettering followed up by noting that avoiding even the appearance of tracking will likely result in fewer users disabling the counting mechanism. Miller was enthusiastic about the idea; he suggested that since there would be no UUID associated with the information, the "countme" flag could increment once per week, which would give some additional information about the longevity of systems—without providing much information that could be used for tracking.

It would not even necessarily require that every machine reported, Roberto Ragusa suggested. Machines could decide whether to report based on some property of their machine ID (e.g. divides evenly by 1000) or by combining machine ID and the date so that the counted systems would change over time. Then the counts could simply be multiplied by whatever is used as a modulus to provide the actual estimate.

Overall, there were few complaints about the simpler counting mechanism. Miller has updated the proposal using Poettering's method; it should be posted to the mailing list soon, once he receives some feedback from the DNF developers. It seems likely that Fedora 30 will have the feature when it is released, which is currently scheduled for the end of April.

We have looked at other user-counting initiatives and proposals along the way. In 2010, there was a proposal to add UUID tracking to Yum, but Fedora has been trying to figure how to unobtrusively count users for longer than that. A 2006 scheme involving a tracking image was proposed for Fedora Core 7. More recently, the Django web-framework project discussed adding analytics that would report to Google servers, which was not popular with Debian (at least).

There is a certain amount of tension between the needs of a distribution or software project and the needs of users—especially when it comes to privacy issues. Being able to show the existence of more project users will generally lead to a higher profile and potentially more funding for development and other activities. Counting variants can also help projects make better decisions about where to allocate their scarce resources. But many users do not want to be tracked, though they may be willing to be counted. This Fedora proposal seems like it finds a reasonable balance by reusing an existing mechanism without adding something that could be tracked. It will be interesting to see what Fedora finds once it rolls out this counting feature to users.


Index entries for this article
SecurityPrivacy


to post comments

Fedora, UUIDs, and user tracking

Posted Jan 15, 2019 18:14 UTC (Tue) by dowdle (subscriber, #659) [Link] (1 responses)

And what about those of us who run private mirrors because we have more than a handful of machines... that don't use the mirror-list references in our .repo files? :)

No matter what you do, it won't be accurate but it'll be MORE accurate than in the past.

Fedora, UUIDs, and user tracking

Posted Jan 15, 2019 19:01 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

> And what about those of us who run private mirrors

A subset of users are never going to be counted without some intrusive per user registration system which is definitely not worth the cost

> No matter what you do, it won't be accurate but it'll be MORE accurate than in the past.

Indeed

Fedora, UUIDs, and user tracking

Posted Jan 15, 2019 18:20 UTC (Tue) by davidstrauss (guest, #85867) [Link] (2 responses)

> the "countme" flag could increment once per week, which would give some additional information about the longevity of systems—without providing much information that could be used for tracking

The addition of sequence numbers -- combined with the client IP addresses -- could allow identifying systems in a way similar to the approaches that de-mask NAT by relying on IP and TCP fields like sequence numbers. It would be better for clients to only classify themselves into demographic-style buckets: less than an hour, 1h-1d, 1d-1w, 1w-1m, 1m-1y, 1y+.

Fedora, UUIDs, and user tracking

Posted Jan 16, 2019 13:44 UTC (Wed) by sgallagh (guest, #80524) [Link]

This is something we've been talking about on the list. I think right now we're looking at "first week", "after the first week", "first week after a distro-upgrade", carrying the contents of /etc/os-release which should give us much of what we really need:
* Metrics on how many systems are short-lived (e.g. testing environments) vs long-lived and/or upgraded vs. freshly installed.
* Rough metrics on user counts that are a better approximation than the current guesses at the mirrorlist hits.

Fedora, UUIDs, and user tracking

Posted Jan 16, 2019 18:42 UTC (Wed) by mattdm (subscriber, #18) [Link]

I basically _was_ thinking week-sized buckets, but, sure, making a "log scale" bucket like you suggest would work too.

Fedora, UUIDs, and user tracking

Posted Jan 15, 2019 22:28 UTC (Tue) by jhoblitt (subscriber, #77733) [Link] (10 responses)

Wow. `NetworkManager-config-connectivity-fedora` seems to phone home every 5 minutes.

```
$ cat /usr/lib/NetworkManager/conf.d/20-connectivity-fedora.conf
[connectivity]
uri=http://fedoraproject.org/static/hotspot.txt
response=OK
interval=300
```

`exclude=NetworkManager-config-connectivity-fedora*` just went into my `dnf.conf`.

Fedora, UUIDs, and user tracking

Posted Jan 16, 2019 13:33 UTC (Wed) by sgallagh (guest, #80524) [Link] (9 responses)

The purpose of NetworkManager-config-connectivity-fedora is captive portal detection. Every five minutes, it's used to signal to NetworkManager whether it has a real connection to the Internet and if not, NetworkManager fires off a signal that desktops can use to present a browser window to resolve the situation (such as signing a hotspot's terms of service).

This is exactly the same mechanism used by iOS and Android (and Windows and OSX I think).

This information is not really useful for the information we want to gather, which is basically

* Trends in the number of active users (this is *not* the same as an exact user count)
* Identifying which Edition, Spin or Lab is in use (this information isn't transmitted and also this package is only installed on the Workstation Edition by default; it's not really useful on Server or Cloud)
* Identifying whether the system is short- or long-lived (this information also isn't transmitted)

The best we could possibly get from those logs would be "This number of unique IP addresses accessed this site". That's meaningless when you figure in that most Workstation systems are behind NAT devices (especially those at universities which probably results in a massive under-counting).

Fedora, UUIDs, and user tracking

Posted Jan 16, 2019 14:06 UTC (Wed) by ibukanov (subscriber, #3942) [Link] (1 responses)

As the plugin pings each 300 seconds, it is straightforward to count users behind NAT from the frequency of pings per IP address.

Fedora, UUIDs, and user tracking

Posted Jan 16, 2019 14:37 UTC (Wed) by excors (subscriber, #95769) [Link]

That doesn't give you the user count, it gives you the user count multiplied by the average fractional uptime of each user. Servers might have an uptime close to 100%, but laptops etc are much more unpredictable since people suspend and resume them all the time, so you still can't determine the user count.

Fedora, UUIDs, and user tracking

Posted Jan 16, 2019 18:58 UTC (Wed) by jccleaver (guest, #127418) [Link] (5 responses)

> The purpose of NetworkManager-config-connectivity-fedora is captive portal detection. Every five minutes, it's used to signal to NetworkManager whether it has a real connection to the Internet and if not, NetworkManager fires off a signal that desktops can use to present a browser window to resolve the situation (such as signing a hotspot's terms of service).

And if anyone cared about privacy, it wouldn't do that by default. Opt-in for this kind of stuff.

You don't even need place any sort of HTTP call as your initial primary detection mechanism; there are other ways to do it, including comparing host records for disparate DNS entries and looking for sudden RFC space responses in a cached value. And final validation could always ask for approval before an HTTP request, and pick something innocuous (example.com) since you're only going to hit it once, not 12x/hour from all connected clients. Or make it GUI-configurable, or import the homepage setting from common browsers, or any number of other options...

Fedora, UUIDs, and user tracking

Posted Jan 16, 2019 19:11 UTC (Wed) by sgallagh (guest, #80524) [Link] (4 responses)

> And if anyone cared about privacy, it wouldn't do that by default. Opt-in for this kind of stuff.

That's a significant overstatement. Many of us in the Fedora Project care very deeply about privacy. Which is why this information isn't kept and stored or used in any way to identify individuals. It is, however, so extremely useful that having it enabled by default is in the best interests of the users of the Fedora Workstation. We document how you can disable it if you're so inclined (read: paranoid). Honestly, the only things we can learn from this is that there exists at least one Fedora Workstation connected to the Internet at that IP address. We cannot (and would not) collate this information with anything else and we don't send any information across this connection. And, frankly, we don't even actually know that it must be Fedora, because it's just a configuration setting available to anyone using Linux. If another distro decided to use our site for this connectivity test, we would have zero way to tell (though if we saw a sudden massive uptick in bandwidth usage, we might have to find a way to address that somehow for purely economic reasons).

Lastly, it's a trivial config setting. Don't want to use our site? Great! Set up your own site. Point /usr/lib/NetworkManager/conf.d/20-connectivity-fedora.conf at any website that returns a 200 HTTP message and you're done.

Fedora, UUIDs, and user tracking

Posted Jan 16, 2019 23:34 UTC (Wed) by jbicha (subscriber, #75043) [Link]

> Many of us in the Fedora Project care very deeply about privacy.
> We document how you can disable it if you're so inclined (read: paranoid).

Maybe you can help get the Connectivity Checking switch in to the GNOME Settings > Privacy panel. It's been in Ubuntu for over a year. I think I've done about as much as I can do to push it forward (including updating the patch today). It's being held up by what feels to me like unfair design hurdles.

https://gitlab.gnome.org/GNOME/gnome-control-center/merge...

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

Posted Jan 28, 2019 2:41 UTC (Mon) by Garak (guest, #99377) [Link] (2 responses)

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.

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

Posted Jan 28, 2019 3:24 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

> 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

Posted Jan 30, 2019 13:22 UTC (Wed) by codeofdrama (guest, #127444) [Link]

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.

Fedora, UUIDs, and user tracking

Posted Jan 16, 2019 20:00 UTC (Wed) by johannbg (guest, #65743) [Link]

What are you planning to do once you have optained that information and the cost of Fedora's end user privacy? Are Fedora's end user privacy being sacrificed for some graph on slides or are you going to start killing of contributed maintained community projects or packages if they dont meet certain end user usage? what exactly will be done once that information has been gathered?

Fedora, UUIDs, and user tracking

Posted Jan 15, 2019 22:39 UTC (Tue) by nilsmeyer (guest, #122604) [Link] (5 responses)

> There is a certain amount of tension between the needs of a distribution or software project and the needs of users—especially when it comes to privacy issues. Being able to show the existence of more project users will generally lead to a higher profile and potentially more funding for development and other activities.

To me it sounds more like collecting data for the sake of collecting data. While the technical solutions sound quite elegant there has to be a better way to solicit quality feedback.

Fedora, UUIDs, and user tracking

Posted Jan 16, 2019 13:37 UTC (Wed) by sgallagh (guest, #80524) [Link] (4 responses)

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.

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.

Fedora, UUIDs, and user tracking

Posted Jan 16, 2019 20:18 UTC (Wed) by johannbg (guest, #65743) [Link] (1 responses)

Is it not up to those that are doing the work to decide how long they want to continue doing that work as well as deciding who are their target end users?

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?

Is not the reality that IBM/Red Hat needs to know this information to decide where it wants to spend it's money/workforce contribution in the project. Perhaps the next step will be start selling that information as well you know to keep meeting laid out paychecks and other expences?

Fedora, UUIDs, and user tracking

Posted Jan 17, 2019 9:53 UTC (Thu) by nilsmeyer (guest, #122604) [Link]

> 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.

Fedora, UUIDs, and user tracking

Posted Jan 17, 2019 10:13 UTC (Thu) by nilsmeyer (guest, #122604) [Link]

> 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

Posted Jan 18, 2019 9:22 UTC (Fri) by flussence (guest, #85566) [Link]

>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

Posted Jan 16, 2019 7:47 UTC (Wed) by amarao (guest, #87073) [Link] (17 responses)

Is it really this important to count usage? I feel that in this case interests of someone in charge is put ahead of interest of public.

Debian have much cleaner approach: there is a `popularity-contest` package to track package use. It has user UUID, but it's a single package and users are free to install/remove it at wish. Moreover, an installer is clearly asking about 'opt-in' for it. 'popcon' stats are definitively in public interest (as it influences the base packages in the base package set for next distro).

I can't understand what is the public interest in the user count.

Fedora, UUIDs, and user tracking

Posted Jan 16, 2019 13:41 UTC (Wed) by sgallagh (guest, #80524) [Link] (16 responses)

It's not strictly about user count (see my other posts in this comment section). It's about trends over time in usage.

We don't specifically care how many users there are, we care if it's growing or declining and *where* it's growing and declining. So the proposals are ways to get a better picture of what the project is doing right and wrong. Are we growing our users faster than we used to with Fedora Workstation? Great! Let's keep that momentum. Alternately, is Fedora Server seeing a sharp decline? We should probably re-evaluate some of our decisions.

Right now, that information doesn't exist in a meaningful way. We have some *very* rough estimates of usage of Fedora as a whole, but virtually no data at all on the various sub-projects within it.

Fedora, UUIDs, and user tracking

Posted Jan 16, 2019 14:56 UTC (Wed) by amarao (guest, #87073) [Link] (1 responses)

To be honest, I don't feel that this is a public interest. It's nice to have, but in modern privacy war there are too many victims to think that any tracking would benefit users. In some ideal society where private data are sacred and never is violated by secret services and other bad guys, it may give some benefits.

In our current society, any tracking information is against user. Any. Why? Because there is always a third party actor nearby, gathering this information. You think it helps you to check distro momentum, but in reality it's an excellent way for the man in the middle to join together two independent connection log entries from different IPv6 addresses. Privacy extension had randomized IPv6, and two Fedora machines had became indistinguishable from a single machine... Until it send count-me-in packet with a specific number which clearly give an answer that those two machines are the same.

Do we really want this?

Fedora, UUIDs, and user tracking

Posted Jan 16, 2019 16:23 UTC (Wed) by mattdm (subscriber, #18) [Link]

The information is sent over SSL so the man-in-the-middle would have to compromise that. At that point, there's much stronger, more effective, and more likely attacks to worry about.

But even then, I'm proposing a granularity of one week, with a maximum number of, say, 60 — covering the expected lifecycle of a single Fedora release. That means the number wouldn't provide much by way of useful disambiguation for an attacker.

Fedora, UUIDs, and user tracking

Posted Jan 16, 2019 22:04 UTC (Wed) by johannbg (guest, #65743) [Link] (13 responses)

"We don't specifically care how many users there are, we care if it's growing or declining and *where* it's growing and declining. "

Thats irrelevant, what matter is if the contribution back to an project or distribution is increasing or declining because thats what keeps the project or distributions afloat

But let's say that an distribution can accuratly gather that statistic, then there is nothing that says it's direction is the direct cause for example for an negative result.

It could be for example that a another distribution is currently serving hotter sauce, the hot dog of the month ( or people just go upstream to download a prebuilt ( docker ) image and they dont care on top of which distro the application or application stack runs on top off ) or participate in downstream distribution efforts or it could also just be the interest in Linux ecosystem is declining right...

How are you going to seperate the enviromental factor from the project direction short answer, it cant be done or atleast not without spending resources that the community cant afford in trying to do so.

mkosi+systemd literally put it in the hands of the end user to build his own custom distribution image or container for whatever purpose they need and run it or download a docker image and run it in systemd.

So now the administrator or user might look for an management and provising tool in the distribution since he has so many docker images to maintain, which begs the question how well available those provisining and management tools all are in Fedora and how well supported.

For example take the red hat product stack ovirt,foreman,ansible, ansible tower all that stuff, is it available in Fedora or only in a copr repo with the usual disclaimer of shoot your self in the head rather then to use said copr repo or is it only available in package repo upstream or as an docker image upstream???

If all the popular upstream images are for example running debian or ubuntu, of course the first thing that pops in the new end users head is to join debian/ubuntu community not Fedora.

Which leaves the existing Fedora/RHEL/CentOS local admin that wants to run the fancy Red Hat product stack but is it available as rpms in Fedora, the answer to that is no so why should they use Fedora?

Documentation nope Arch owns that and has for years,

Fedora Workstation does not come with all media support so thats no go for novice end user who just needs an Gnome distribution with full media support and flatpak ( linux mint propably owns that market.)

Which leaves us witb the upcoming sbc/tinker/pi generation. No armbian owns that now...

The project has been on a downhill spiral ever since Matt took over and the rings nonsense got implemented. His modular approach would never work as I pointed out at that time.

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...

JBG

Fedora, UUIDs, and user tracking

Posted Jan 17, 2019 18:28 UTC (Thu) by jccleaver (guest, #127418) [Link] (12 responses)

> 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

Posted Jan 17, 2019 22:49 UTC (Thu) by johannbg (guest, #65743) [Link] (11 responses)

"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

Posted Jan 17, 2019 23:12 UTC (Thu) by jccleaver (guest, #127418) [Link] (10 responses)

> 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

Posted Jan 18, 2019 0:32 UTC (Fri) by johannbg (guest, #65743) [Link] (9 responses)

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

Posted Jan 18, 2019 6:47 UTC (Fri) by jccleaver (guest, #127418) [Link] (8 responses)

> 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

Posted Jan 18, 2019 8:22 UTC (Fri) by johannbg (guest, #65743) [Link] (7 responses)

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

Posted Jan 18, 2019 9:33 UTC (Fri) by pabs (subscriber, #43278) [Link] (5 responses)

> 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

Posted Jan 18, 2019 9:56 UTC (Fri) by amarao (guest, #87073) [Link] (3 responses)

>> 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

Posted Jan 18, 2019 17:51 UTC (Fri) by jccleaver (guest, #127418) [Link] (2 responses)

> 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

Posted Jan 23, 2019 18:52 UTC (Wed) by edgewood (subscriber, #1123) [Link] (1 responses)

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

Posted Jan 23, 2019 19:38 UTC (Wed) by jccleaver (guest, #127418) [Link]

> 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

Posted Jan 18, 2019 10:23 UTC (Fri) by johannbg (guest, #65743) [Link]

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

Posted Jan 18, 2019 17:47 UTC (Fri) by jccleaver (guest, #127418) [Link]

> 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

Posted Jan 16, 2019 19:45 UTC (Wed) by johannbg (guest, #65743) [Link]

Since Fedora is allegedly a community distribution thus knowing how many users are using Fedora is irrelevant.

It should not matter how many or few are maintaining a component, an module, a spin, edition whatever, since it's actively being worked on and maintained.

What matter is knowing which components,spins, modules are not being maintained so that distribution deadweight can be removed and you most certainly dont need to go outside the community for that information, you can simply file a ticket with infra for that.

But let's say for arguments sake the distribution tracking stalker rapes fedorians privacy to obtain that information to have the most accurate usage information in the whole distributions kingdom and knows if there has been increase/decrease in usage and then what?

What is supposingly supposed to be acted upon now which could not have been acted on using the previous method of optaining that "unreliable" information?

Are fedorians gonna get notification spammed from Gnome if they arent participating in the project and just use it?

What's the end game here after that information has been retrived at the cost of Fedora's end user privacy ?

Fedora, UUIDs, and user tracking

Posted Jan 16, 2019 20:49 UTC (Wed) by dkg (subscriber, #55359) [Link] (1 responses)

Lennart's "countme" flag proposal is far better than any of the uuid proposals.

However, the devil's in the details for how you do "countme". For the sake of the dicsussion, i'll assume that the period of "countme" queries is one per week.

The safest way to do this is for each installation to store the last time it sent a "countme" flag as timestamp lastcounted. When fetching updates, if the most recent Sunday midnight in UTC is later than lastcounted, then send the "countme" flag. When a valid HTTP response is returned from the server, set lastcounted to the current timestamp. This causes all machines to send "countme" at about the same time each week, and avoids per-device identification.

Some fancier proposals which spread the "countme" across different times (e.g. based on hash of UUID, or having them report "countme" as long as it has been a full week since the last time it was sent) offer an additional possible source of tracking and identification of users. So they're more problematic in terms of privacy.

Fedora, UUIDs, and user tracking

Posted Jan 16, 2019 23:09 UTC (Wed) by jccleaver (guest, #127418) [Link]

Quite frankly, this all seems like a bit of a lost cause.

For install counting, a new anaconda leaf should be added that allows distro/spin counting to happen *once* at install time.

For everyone else, and for counting cloned systems, make the component a separate package. Call it "fedora-census" or whatever.

Firstboot for GNOME/desktop lusers can enable simple (distro/spin counting, with the countme decrement) or *enhanced* telemetry (which uses UUIDs to distinguish). For everyone else, a config file allows this to happen via a fedora-census service. This service should be *DISABLED* by default. (If a cloud/kickstart/image/VM user wants discrete VMs to be counted discretely, they can enable the UUID service.)

Fedora, UUIDs, and user tracking

Posted Jan 17, 2019 9:41 UTC (Thu) by Gladrim (subscriber, #45751) [Link] (21 responses)

What is the benefit to the end user? Are any users demanding this?

Fedora, UUIDs, and user tracking

Posted Jan 17, 2019 22:58 UTC (Thu) by johannbg (guest, #65743) [Link] (16 responses)

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

Posted Jan 18, 2019 15:45 UTC (Fri) by mattdm (subscriber, #18) [Link]

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

Posted Jan 22, 2019 11:51 UTC (Tue) by nilsmeyer (guest, #122604) [Link] (14 responses)

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

Posted Jan 22, 2019 12:58 UTC (Tue) by johannbg (guest, #65743) [Link] (13 responses)

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

Posted Jan 22, 2019 17:30 UTC (Tue) by jccleaver (guest, #127418) [Link] (12 responses)

> 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

Posted Jan 22, 2019 21:59 UTC (Tue) by johannbg (guest, #65743) [Link] (11 responses)

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

Posted Jan 22, 2019 23:37 UTC (Tue) by pizza (subscriber, #46) [Link] (8 responses)

> 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

Posted Jan 23, 2019 1:24 UTC (Wed) by jccleaver (guest, #127418) [Link]

> 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

Posted Jan 23, 2019 6:14 UTC (Wed) by johannbg (guest, #65743) [Link] (4 responses)

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

Posted Jan 23, 2019 12:20 UTC (Wed) by pizza (subscriber, #46) [Link] (3 responses)

>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

Posted Jan 23, 2019 13:22 UTC (Wed) by johannbg (guest, #65743) [Link] (2 responses)

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

Posted Jan 23, 2019 16:16 UTC (Wed) by pizza (subscriber, #46) [Link] (1 responses)

> 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

Posted Jan 23, 2019 18:30 UTC (Wed) by jccleaver (guest, #127418) [Link]

> > 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

Posted Jan 23, 2019 6:36 UTC (Wed) by zdzichu (subscriber, #17118) [Link] (1 responses)

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

Posted Jan 23, 2019 7:52 UTC (Wed) by johannbg (guest, #65743) [Link]

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

Posted Jan 23, 2019 1:20 UTC (Wed) by jccleaver (guest, #127418) [Link] (1 responses)

> 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

Posted Jan 23, 2019 7:00 UTC (Wed) by johannbg (guest, #65743) [Link]

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

Posted Jan 18, 2019 15:38 UTC (Fri) by mattdm (subscriber, #18) [Link] (3 responses)

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

Fedora, UUIDs, and user tracking

Posted Jan 20, 2019 15:48 UTC (Sun) by archbtw (guest, #129959) [Link] (2 responses)

What about ring signatures as a form of tracking?

Fedora, UUIDs, and user tracking

Posted Jan 20, 2019 19:02 UTC (Sun) by mattdm (subscriber, #18) [Link] (1 responses)

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

Fedora, UUIDs, and user tracking

Posted Jan 20, 2019 23:26 UTC (Sun) by archbtw (guest, #129959) [Link]

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.


Copyright © 2019, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds