Hacker News new | past | comments | ask | show | jobs | submit | fsflover's comments login

> How We Use Your Data

>To improve our website, products/services, marketing, or customer relationships.

>To recommend products or services that may be of interest to you.

This seems to be incompatible with the GDPR. Is this opt-out?


You're right that the previous privacy policy language wasn't GDPR-compliant. It is now updated our policy to make analytics and marketing fully opt-in rather than assumed consent.

The updated policy clearly separates essential data uses (providing services, billing, support) from optional uses like marketing and analytics. These optional uses are now explicitly opt-out by default, requiring users to actively opt in through their account settings.



Here, we have the equivalent of Jack posting a stern issue, without proposal, without rationale, without previous involvement in the project.

And Elon doing a +1.

Two bros who are not the least committed to what they're suggesting, and that don't even have the need to.

4 basic questions pop up when a maintainer receives such a issue (or poorly expressed pull request):

1/ what are you trying to achieve?

2/ how do you maintain the good things working in order (here, an ecosystem that sustains creativity and community)?

3/ how is it better than the existing code?

4/ who will maintain that?

Be like the engineers you claim to be, guys. Show us how you do engineering. Show us how you do understand law, and IP laws. Do specs. Projections. Plans. Data.


I'm not trying to defend Elon, I'm just saying that copyright is not always good for the people, in contrast to what you wrote.

I agree, I'm not saying it's perfect. Far from that.

But removing the framework within which artists still have the means to control their work (however unbalanced contracts can happen to be between corps and artists - it's a complex field to navigate).

Improving/upgrading it? Certainly. With a proven, demonstrable improved replacement or path... that takes into account primarily the artists, that do want the public to have access to their work, but to be also appropriately compensated, and in control of it.

What Jack and Elon are sustaining, when you read between the lines, is not reform to sustain the actual people that actually create the stuff.

But to benefit the power structures they have and want, first and foremost by allowing them to literally suck in all the existing artworks without having to pay for it, so they can sell it back to everyone, under the guise of "democratising" "creation".

The ploy is so obvious, though, it's fascinating not more people see it.

What is often, very often lacking in these discussions within the tech/software spheres, is the perspective of people actually working with and making a living out of these (ie, professional _and_ non-pro artists).


> I agree, I'm not saying it's perfect. Far from that.

> But removing the framework

Are you trying to convince me that this path is wrong? I never said or implied it was correct.

> What Jack and Elon are sustaining, when you read between the lines, is not reform to sustain the actual people that actually create the stuff.

I completely agree.


What's the point in buying a new phone when the old one works flawlessly and continues to receive not only security updates but also all software improvements, and is getting more optimized and fast with time? Sent from my Librem 5.

This is a well-know enshittification, which is going on for a long time already: https://pluralistic.net/2024/08/17/hack-the-planet/

Did you try to unsubscribe? They mention such possibility in their every email.

I'd be happy to provide dozens of examples in my inbox that prove otherwise, and that's just the ones that have escaped my spam folder over the years.

I can also provide you with examples of other people's less than flattering replies about the exact same issue that have somehow reached my inbox (I'm assuming due to a brief misconfiguration).


> and the issue seemed to be the CPU wasn't up to the task.

This is definitely not true, the issue is in the non-optimized software. I tried SXMo [0] on a Pinephone (which is much slower than the Librem), and it was unbelievably fast, including watching videos and looking a maps in a split-screen mode, simultaneously and smoothly. Android had 10 years and a huge team of developers to optimize the UI.

[0] https://sxmo.org/


Sxmo is based on a keyboard-driven tiling window manager. Yes, it is as bad as it sounds. Touch gestures suck so much[1] that the most comfortable way to navigate it is with the volume buttons and power button. Each of these buttons has like 3 different functions with double, tripple click etc. Changing the volume is not one of the functions[2].

Auto screen orientation only works 50% of the time, because the whole thing is based on a pile of shell scripts.

There is no lock screen included.

No, I'm not kidding.

[1] https://sxmo.org/docs/gettingstarted/

[2] https://man.sr.ht/~anjan/sxmo-docs/USERGUIDE.md#strongglobal...


It's just an example that the UI on a Pinephone and Librem 5 can definitely be snappy given enough optimizations.

If you want security through compartmentalization, you should consider Qubes OS, my daily driver, https://qubes-os.org.

This only secures between vms. This side steps the problem and people can still easily run multiple applications in the same qube.

It's impossible to isolate applications inside one VM as securely as with Qubes virtualization. You should not rely on intra-VM hardening if you really care about security. Having said that, Qubes does provide ways to harden the VMs: https://forum.qubes-os.org/t/hardening-qubes-os/4935/3, https://forum.qubes-os.org/t/replacing-passwordless-root-wit....

People may want to have multiple apps work together. It makes sense to have security within a qube itself than to just declare it a free for all.

If the apps work together, they typically belong to the same security domain / trust level. Do you have examples when you still have to isolate them from each other?

Even if things are on the same trust level that doesn't mean that if one gets compromised I don't care that it affects the 2nd.

So just run them in different VMs?

Apart from that, any hardening in Fedora can be utilized inside a Fedora VM on Qubes. Qubes doesn't force you to use VMs with no isolation inside.


But then the files can't be shared.

Qubes has such functionality.

And you just deduced why sandboxing as it is implemented today is really pointless for the desktop .

I'm using Qubes as my daily driver on my desktop, so no.

What do you get from it? Specially considering that from above "programs that work together go in the same context"..


What exactly do you want to upgrade? See also: https://puri.sm/posts/the-danger-of-focusing-on-specs/

I'm still using my Librem 15 and it works fine though.

Lucky!

The first issue I had was the battery not being replaceable since they stopped making the 15's battery and couldn't offer any OEM/part info for a replacement.

The second issue was more serious, the motherboard simply died and couldn't boot.

At least I was able to recover the drive/ram which went into my new system76 laptop (that was 2.5 years ago).




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: