[-] Atemu@lemmy.ml 2 points 22 hours ago

What's wrong with lemmy.ml? It's a pretty generalist instance if you ask me. The only issue I have with it is that it doesn't block obvious troll instances like lemmygrad or the one that's even worse by default but you can do that yourself these days.

[-] Atemu@lemmy.ml 6 points 1 day ago

If anyone reading has proof of M$ spying on the German government they could whistle about, right about now would be a great time to do it ;)

[-] Atemu@lemmy.ml 16 points 1 day ago

Hell seems to be freezing over at an alarming rate these days; climate change is getting pretty extreme down there too huh?

59
submitted 1 day ago by Atemu@lemmy.ml to c/linux@lemmy.ml
[-] Atemu@lemmy.ml 1 points 5 days ago

More likely is the device firmware and you likely can't fix that.

[-] Atemu@lemmy.ml 1 points 5 days ago

If you have a reasonably up to date mesa and use a Proton version with a new enough DXVK, DXVK can utilise Graphics Pipeline Libraries to link shaders just like a d3d11 driver on Windows would, eliminating stutter.

I believe shader precomp is used for some video codec edge cases though, so YMMV depending on the game.

[-] Atemu@lemmy.ml 4 points 5 days ago

No, it wouldn't make any sort of difference.

[-] Atemu@lemmy.ml 0 points 6 days ago

And also in any other filesystem's code or the block layers below the filesystem. As I said, unlikely scenario.

[-] Atemu@lemmy.ml 1 points 6 days ago

Also, their client is still open

*is open again. The clients they distributed were not open source until they open sourced sdk-internal. The fact that you couldn't even build it with only open code even if you wanted to was a bug but that's a rather minor issue in comparison.

I also fully believe that they would not have GPL'd sdk-intenral without public pressure. Even when they were originally called out they were pretty clear that the integration of proprietary code was intentional and done with the knowledge that it would typically violate the GPL.

If you don't see what's ethically wrong with even attempting to subvert the GPL, I don't think you've understood open source.

[-] Atemu@lemmy.ml 1 points 6 days ago

Until the situation now, this was limited to the server, not the clients. You could replace the server with Vaultwarden and build it without enterprise features. Not ideal but fine because the server isn't the critical part. It never handles your secrets in any way.

What they tried to do now was integrate proprietary code into the clients that everyone uses. This is a lot more critical as it can access the secrets in plain text.

This also wasn't a "mistake" or "bug", they openly admitted to doing this with the intention of subverting the client code's GPL.

[-] Atemu@lemmy.ml 2 points 1 week ago

One does not "accidentally" build a proprietary SDK for months and make the clients depend on it, intentionally violating the GPL.

They even publicly admitted to doing precisely that, defending their GPL violation with dubious claims how the GPL supposedly works.

245
submitted 1 week ago by Atemu@lemmy.ml to c/linux@lemmy.ml

@brjsp thanks again for submitting the concern here. We have made some adjustments to how the SDK code is organized and packaged to allow you to build and run the app with only GPL/OSI licenses included. The sdk-internal package references in the clients now come from a new sdk-internal repository, which follows the licensing model we have historically used for all of our clients (see LICENSE_FAQ.md for more info). The sdk-internal reference only uses GPL licenses at this time. If the reference were to include Bitwarden License code in the future, we will provide a way to produce multiple build variants of the client, similar to what we do with web vault client builds.

The original sdk repository will be renamed to sdk-secrets, and retains its existing Bitwarden SDK License structure for our Secrets Manager business products. The sdk-secrets repository and packages will no longer be referenced from the client apps, since that code is not used there.

This appears at least okay on the surface. The clients' dependency on sdk-internal didn't change but that's okay now because they have licensed sdk-internal as GPL.

The sdk-secrets will remain proprietary but that's a separate product (Secrets Manager) and will apparently not be used in the regular clients. Who knows for how long though because, if you read carefully, they didn't promise that it will not be used in the future.

The fact that they had ever intended to make parts of the client proprietary without telling anyone and attempted to subvert the GPL while doing so still remains utterly unacceptable. They didn't even attempt to apologise for that.

Bitwarden has now landed itself in the category of software that I would rather move away from and cannot wholeheartedly recommend anymore. That's pretty sad.

220
submitted 1 week ago by Atemu@lemmy.ml to c/opensource@lemmy.ml

@brjsp thanks again for submitting the concern here. We have made some adjustments to how the SDK code is organized and packaged to allow you to build and run the app with only GPL/OSI licenses included. The sdk-internal package references in the clients now come from a new sdk-internal repository, which follows the licensing model we have historically used for all of our clients (see LICENSE_FAQ.md for more info). The sdk-internal reference only uses GPL licenses at this time. If the reference were to include Bitwarden License code in the future, we will provide a way to produce multiple build variants of the client, similar to what we do with web vault client builds.

The original sdk repository will be renamed to sdk-secrets, and retains its existing Bitwarden SDK License structure for our Secrets Manager business products. The sdk-secrets repository and packages will no longer be referenced from the client apps, since that code is not used there.

This appears at least okay on the surface. The clients' dependency on sdk-internal didn't change but that's okay now because they have licensed sdk-internal as GPL.

The sdk-secret will remain proprietary but that's a separate product (Secrets Manager) and will apparently not be used in the regular clients. Who knows for how long though because, if you read carefully, they didn't promise that it will not be used in the future.

The fact that they had ever intended to make parts of the client proprietary without telling anyone and attempted to subvert the GPL while doing so still remains utterly unacceptable. They didn't even attempt to apologise for that.

Bitwarden has now landed itself in the category of software that I would rather move away from and cannot wholeheartedly recommend anymore. That's pretty sad.

[-] Atemu@lemmy.ml 9 points 1 week ago

For ~$30 a month, that's a complete and utter rip-off.

Even here in Neuland Germany you get at least decent internet with no caps for that price.

[-] Atemu@lemmy.ml 1 points 1 week ago

There aren't any "extra access checks" to my knowledge. It's just the same regular access checks applied to a different set of circumstances.

41
submitted 2 weeks ago by Atemu@lemmy.ml to c/linux@lemmy.ml

cross-posted from: https://lemmy.ml/post/21519137

I recently switched from a MBP to a Framework 16 as my primary laptop and one thing I immediately noticed was that I was unable to stop kinetic scrolls in Firefox by laying my fingers onto the touchpad. It'd just slide by unimpeded. You could work around this by counter-scrolling a little rather than holding still which is how I've been coping with it but it's suboptimal to say the least.
(As are many things in the Linux touchpad experience. Linux desktop developers really ought to use a macbook for a little to get a sense for how to do this properly.)

This was caused by Firefox' use of GDK3 to implement its windowing and input needs which does not support hold gestures.

GDK4 does support them but, as I understand it, a port of Firefox to GDK4 would be a ton of work and there isn't really much desire for it as GDK4 doesn't offer many real advantages over GDK3 as Firefox doesn't use classical GTK widgets or anything and only really uses it for basic input/output primitives.

A backport to handle hold gestures in GDK3 too was attempted but, in classic GNOME fashion, it was rejected.

The implementation now somehow gets events from the touchpad directly via wayland somehow from what I could gather but if it works, it works.

You can try this out in the latest nightly builds.

29
submitted 2 weeks ago by Atemu@lemmy.ml to c/firefox@lemmy.ml

I recently switched from a MBP to a Framework 16 as my primary laptop and one thing I immediately noticed was that I was unable to stop kinetic scrolls in Firefox by laying my fingers onto the touchpad. It'd just slide by unimpeded. You could work around this by counter-scrolling a little rather than holding still which is how I've been coping with it but it's suboptimal to say the least.
(As are many things in the Linux touchpad experience. Linux desktop developers really ought to use a macbook for a little to get a sense for how to do this properly.)

This was caused by Firefox' use of GDK3 to implement its windowing and input needs which does not support hold gestures.

GDK4 does support them but, as I understand it, a port of Firefox to GDK4 would be a ton of work and there isn't really much desire for it as GDK4 doesn't offer many real advantages over GDK3 as Firefox doesn't use classical GTK widgets or anything and only really uses it for basic input/output primitives.

A backport to handle hold gestures in GDK3 too was attempted but, in classic GNOME fashion, it was rejected.

The implementation now somehow gets events from the touchpad directly via wayland somehow from what I could gather but if it works, it works.

You can try this out in the latest nightly builds.

54
submitted 3 weeks ago by Atemu@lemmy.ml to c/opensource@lemmy.ml

cross-posted from: https://lemmy.ml/post/21154325

Write is a handwriting app that works on a lot of platforms including Linux which cannot be said about most handwritten note-taking applications.

More information and demo: https://github.com/styluslabs/Write/

I've used it for uni on a Linux tablet/convertible and it worked really quite well and has some nice convenient features for note-taking.

The UI looks like it's from android 4.something though ^^'

What I really appreciate about it is that its storage format are plain SVG(Z) which are extremely compatible. All you need to view your scribbles is an SVG viewer (i.e. a web browser) which basically every computer with a GUI has. Their website is in fact mostly just the output of their own app.

100
submitted 3 weeks ago by Atemu@lemmy.ml to c/linux@lemmy.ml

Write is a handwriting app that works on a lot of platforms including Linux which cannot be said about most handwritten note-taking applications.

More information and demo: https://github.com/styluslabs/Write/

I've used it for uni on a Linux tablet/convertible and it worked really quite well and has some nice convenient features for note-taking.

The UI looks like it's from android 4.something though ^^'

What I really appreciate about it is that its storage format are plain SVG(Z) which are extremely compatible. All you need to view your scribbles is an SVG viewer (i.e. a web browser) which basically every computer with a GUI has. Their website is in fact mostly just the output of their own app.

295
submitted 4 months ago by Atemu@lemmy.ml to c/linux@lemmy.ml
57
submitted 5 months ago by Atemu@lemmy.ml to c/linux@lemmy.ml
24
submitted 6 months ago by Atemu@lemmy.ml to c/linux_gaming@lemmy.ml
61
submitted 6 months ago by Atemu@lemmy.ml to c/hardware@lemmy.ml
55
submitted 6 months ago by Atemu@lemmy.ml to c/linux_gaming@lemmy.ml
view more: next ›

Atemu

joined 4 years ago
MODERATOR OF