I feel like something like Fedora fits the bill: great, reliable, well-maintained repositories, decently updated kernels, yet never faced any major issues, and access to quite updated packages. Only issue is Red Hat caused a stir recently, though I still believe Red Hat does more good than bad in the open source community.
Some are making the case that Fedora’s new telemetry integration isn’t like the bad telemetry like Google and others, it is ‘anonymised.’ Every corporation says this before they remove the username from the data collected and keep the unique user id. I don’t trust Red Hat…and now with this latest reveal, Fedora either. And privacy is all about trust.
I’m making that case. I trust Fedora and Red Hat to handle telemetry correctly, but I can verify it by looking at the source and I’ll give them constructive feedback if I have concerns. May I ask which distro you are planning to use where the source is NOT contributed primarily by engineers working for a corporation that puts dollars first?
I disagree that as the as the article states telemetry “contradicts open-source values”, nowhere is it said in the official definition that telemetry by itself is not ok and as long as it is opt-in and the handler makes clear reports on the data they gathered, I’d say it’s a good opportunity to give valuable insight to the developers on the use of their software, done in this manner it doesn’t trample over anyone’s choices either.
Notable examples of open source projects that implement telemetry are KDE and Mozilla, it’s not unheard of at all
While I admit that the timing with Red Hat’s closed-sourcing is really bad, and I’m also going to start avoiding Fedora for the same reason, saying that opt-in telemetry (that one can literally read the source code of) is “putting dollars first” is really dumb. Do you think the same about Debian’s popularity-contest, which has existed since 2004?
Some are making the case that Fedora’s new telemetry integration isn’t like the bad telemetry like Google and others, it is ‘anonymised.’ Every corporation says this before they remove the username from the data collected and keep the unique user id. I don’t trust Red Hat…and now with this latest reveal, Fedora either. And privacy is all about trust.
Please stop with the FUD about the Fedora telemetry. It is opt-in and is no different than popularity-contest on Debian.
@NoRecognition84@rodneyck its bad anyway. Why a opensource project will do something like that? Telemetry causes bad performance in production. If its opt in, no one will activate, and soon the business will force its use.
oldschool ( from terminal-only era ) => copy by selecting text (mostly in terminals) and paste using middle mouse click
more modern new style ( based on graphical interfaces ) => copy by ctrl+c (or ctrl+shift+c in terminals and such) and paste ctrl+v (ctrl+shift+v in terminals …)
Normally both those clipboards work independent as they are handled by 2 different processes, so you can for example copy one text using ctrl+c and copy another text by only selecting second text, then you can paste both, one with middle click, second with ctrl+v
More and more distro have a clipboard managers that have a feature to “sync” both clipboards, but it’s a lot of time disabled because it’s more confusing people and sometimes annoying. Why it’s confusing and disabled by default? Imagine that you selected some text, then did a ctrl+c, you move to some word document, select text, remove it, and want to Paste it. Guess what, the selecting you did to remove text did copy the selection to clipboard overriding what you did have there from ctrl+c.
Most if not all terminal emulators (konsole, gnome-terminal, xterm) support both clipboard styles, old-school select to copy, and new one but because the “ctrl+c” shortcut reserved to stop/interrupt applications they all decide to use ctrl+shift+c to do a copy. And yes, not only terminal emulators use ctrl+shift+c, I did have few encounters on some random apps, but most of the time, if ctrl+c is used for something else, ctrl+shift+c was available.
Yes this makes sense. I’ve been using terminals for years with the ‘copy on highlight’ feature enabled, and I’m pretty sure when I was on OSX it was a single buffer.
I can see how having mouse selected text end up in the buffer on a non-Terminal app would probably not be the desired behavior.
I found ‘autocutsel’ which will keep PRIMARY and CLIPBOARD in sync, however Gnome Terminal doesn’t seem to support ‘copy on highlight’ while Terminator does.
A very comprehensive and complete reply. I did know about the different clip buffers but reading this was still so good because no one was actually explaining it. Thanks
There was one I used to use that just made the screen black and had no visuals to indicate typing or anything working. Typing the correct password and hitting enter would unlock. I think there was some thing about it not being secure after some shift in typical Linux distro defaults and now I just use the default kde locker because lazy
I didn’t think I would ever say this, but: arch isn’t always the answer. True: the last time the entire system broke on me was in 2006’ish, but I can’t count the times certain apps have stopped working or some python upgrade messes up things. Sure: that’s the price of rolling release and AUR, and I wouldn’t be without it, but it’s a thing one has to learn to live with, and a thing that makes ‘arch’ the wrong answer to this particular question.
Gaming on wayland now has more or less the same performance as on x11. Some things like vrr (atleast on plasma) is even better/easier on wayland than on x11
though can’t really see any need for it as my monitors are similar resolution there
Well wayland may help if the refresh rates of the monitor is different. Also Wayland will be the only one supported in the future as if I understand correctly, X11 is no longer supported
One has 144hz 1440p and one is 60hz1080p, I’ve got one of them running on 170hz on x11 afaik, what’s normally the problem with differing refresh rates?
Telemetry should not exist in the first place. If it exists, it should completely be opt-in and self-contained in one single package that is not installed by default.
The problem with opt-in telemetry is that it messes with the scope of the research.
If you want to understand something about most users (and not just the ones that are active enough in the project to participate in opt-in) you need this, otherwise your results only tell the needs of this subset of your userbase and this sometimes can go completely against the needs of the majority of users.
The problem with telemetry isn’t the telemetry itself, is how it is used, and the way the proposal is worded makes me very optimistic. They are trying 200% hard to make sure we understand that it will never be used in violation of the users’ privacy.
And once again, it isn’t “without consent”, it just means that the default state of the checkbox is on. Users will still be presented with a confirm option before any data is sent.
In other words, unbiased telemetry is not possible to do ethically.
Say that to the opentelemetry and Plausible folks, who have been on the vanguard of doing exactly that for years now.
Wrong again, the “switch” only sets the setting itself, but before finishing the setup process the user would be provided with a confirmation detailing the data that would be sent and provided with the option to send it or not. The process would have user consent.
It’s not mistaken for context, you’re just missing the point. The switch is just part of it, the user would still have to consent to send their data before it is sent and the proposal proposes to have it detailing the data that is going to be sent and explaining the process.
Having it as a default guarantees it doesn’t scare non-power users away from it. It’s not about just having people clicking next and accepting it without consent.
Disagree, no matter the level of detail, having “yes” automatically selected is an assumption. What purpose would it have other than hoping people will just select the defaults and ignore it?
Having it as a default guarantees it doesn’t scare non-power users away from it. It’s not about just having people clicking next and accepting it without consent.
Scare away from what? Data collection? I mean even in that wording you are saying there is something to be scared of. It should be up the user. If you are saying “non-power users won’t fully understand what is being collected and might get scared away if it isn’t the default option” then that is even worse TBH. Preying on people not fully understanding what’s going on.
Having the default box being “on” is only for the purpose of hoping people click through without realizing.
There is literally no other argument here. “Consent” is: “Hey do you want this, yes or no?”. Not “We are assuming yes unless you explicitly tell us otherwise”.
if the average person doesnt consent to fill a questionnaire, or an interview, how do you collect data about the average person. but then again, how do you know the average person doesnt want to fill a questionnaire? did you spread a questionnaire that had the question ‘do you fill questionnaire?’ in it
linux
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.