Zamundaaa @ Zamundaaa @discuss.tchncs.de

Posts

0

Comments

158

Joined

2 yr. ago

I'll change it back anyways

You don't need to, this is only few new installations

Maybe we should have an onboarding dialogue that plainly asks you if you prefer UX concept A or B. I don't really know. But not for just this one thing.

Yeah, something like that could be great - personalize the defaults for the person actually using the computer when it gets set up, instead of having only one set of defaults for the masses.

Why collect telemetry at all if you're not going to use it anyways?

Because we're sadly not collecting enough and actually useful telemetry. I think we know from telemetry that a big majority has double click set, but we don't know why (default setting vs user chose it explicitly).

And we can't easily add such things without breaking user trust. We need a new telemetry system that's more useful and extendable, but doing that is a lot of effort that noone has put in yet.

And if the distros are already having it as a default, it's even worse. We're setting it per default because it's set as the default.

No, we're setting it as a default because a bunch of people that are closer to the users than us decided to deviate from the upstream default. That's a super clear sign that we're doing it wrong

Telemetry wasn't a factor iirc. The biggest reasons for this change were that

• defaults like this (that only apply to new installations) should make life easy for newcomers, not for the existing users. Those users come from Windows, MacOS or other Linux DEs, which all use double click
• it already is the default in pretty much all popular distros. KUbuntu, Fedora, Manjaro, SteamOS and I think also OpenSuse are double click by default

Partially, sure, but there's also a lot of KDE devs that are really convinced that it's objectively superior and wanted the default to convince more people to use it.

It's still the case, at least for Firefox on Android

Nah, for most people SteamVR works ootb with the Index... but SteamVR is also quite buggy.

Coincidentally I also merged a kms thread into KWin late July. When dragging windows around, the cursor is now visibly ahead of the window.

It does not make a real difference in practice. Outside of the server space, the most important thing a user has is not access to their root filesystem but access to their home folder - to their data and fun things like .bashrc and .profile that allow to hijack pretty much everything the user runs

Where you run a random script from some random guy who is likely unassociated with the project which has very little chance of being audited?

Until recently, most Flatpaks were also published by random people and you had no easy way of verifying who they were.

In that case, yes, one could have a poorly sandboxes app, but the vast majority have some to a larger amount of sandboxing

That is not a usable argument for security. The app developer sets how much sandboxing their app gets, so if they want your data, they can get it.

And sure, you can restrict permissions yourself if you want, but that's not what any normal user does.

When I use multiple monitors I get a range of odd behaviours, including a white screen, lock ups, failure to display anything on second screen. I've unplugged the second screen for now and all is OK except that adaptive sync does not work properly.

Sounds like a driver problem. What kernel are you using, and have you tried running Mesa-git?

When I set adaptive sync to "Always" in the settings the screen sort of flickers when I move the mouse. To be more precise the screen gets a bit brighter when the mouse is moved, then returns to previous slightly dimmer brightness when the mouse is stopped. There are no errors that I've found.

You can't find any errors because there are none. The brightness changing with the refresh rate is sadly how most monitors work today, and can't really be fixed. It's the whole reason for why adaptive sync is not set to always by default.

Why doesn't automatic work for you though?

You could always do that. If you update Mesa, any applications you start after updating will use the new version of Mesa

they don't properly tell users the dangers of the aur like the time a guy put two calls to an IP logger beside a list of people who can fuck themselves or an on init fork bomb. This should not be a toggle directly next to snaps and flat packs, which are safer than a normal package.

Flatpaks or snaps are not safer at all, as the package maintainer decides how much sandboxing, if any, is applied by default. Manjaro also very much does have a warning in the settings page for the AUR...

Please start a gdb console for the last crash with coredumpctl debug kwin_wayland, get a backtrace in there with "bt full" and create a bug report with the backtrace at bugs.kde.org

... or targeting Microsoft again too

Sure. When it comes to updates, Manjaro is pretty much doing what every single other distro is doing. Updates that are buggy don't get pushed to the stable branch until they're fixed up, and security updates tend to get pushed through faster than feature updates. The time period that updates get held up by is not a fixed duration, it depends on the specific package and update and can be anywhere between a few days and a few weeks.

As a concrete example, with some major Plasma updates Manjaro has waited for three or even four point releases (4 / 8 weeks) before considering it stable enough vs the newest point release of the previous major release, and following point releases after that get pushed to stable much faster.

As another point, even Arch has a very similar process... Their policy on pushing updates is far more geared towards pushing updates quickly than towards not breaking things, but otherwise it's pretty much the same.

Idk about a source on this stuff though. There's stuff like https://wiki.manjaro.org/index.php/Switching_Branches but I don't know anything better.

Manjaro packages start their lives in the unstable branch. Once they are a deemed stable, they are moved to the testing branch, where more tests will be realized to ensure the package is ready to be submitted to the stable branch

When life gives you lemons... don't make lemonade. Make life take the lemons back! Get mad! I don't want your damn lemons, what the hell am I supposed to do with these? Demand to see life's manager! Make life rue the day it thought it could give Cave Johnson lemons! Do you know who I am? I'm the man who's gonna burn your house down! With the lemons! I'm gonna get my engineers to invent a combustible lemon that burns your house down!

Simply freezing them for two weeks

That's not what they're doing at all. That dumb myth needs to die.