cmhe @ cmhe @lemmy.world

Posts

0

Comments

349

Joined

2 yr. ago

Right, they saying "We are just following the law." as if that was an apolitical statement. While they still get to choose whom laws to follow by deciding where to make business, which are political decisions.

As you see with Twitter or starlink, they decided to be do business in Brazil, but when the country actually have laws against uncontrolled mass propaganda and hate speech, they are suddenly against the law, and do not try to stop or limit doing their business there, when they do not want or can't abide by these laws.

Well, I consume more open source software that I will ever produce, so I am in a dept to the community. If it means working a bit more to make my contribution useful to others and fit it into the bigger whole, I will gladly do so.

Valve contributed to Linux before, so the fact that they don't have any direct upstreaming plans right now indicates that something is causing friction.

I would avoid reading too much into it. They and their developers are still contributing on other stuff. Also when working together, there will always be some friction, in any public collaborative project ever.

Nothing of this is a burden, it is just part of being a good contributor that reads and follows the rules. Contributing is pretty easy, when you have read and are following the guides. If you haven't already, you should give it a try.

I am pretty sure that this isn't the first contribution of Valve to the Linux kernel. It sounds more to me like "works for me, don't care about others" attitude. Which is not a good attitude to have when working in any collaborative project. (Not necessarily against the developers, could also be management.)

Well, it is about code quality. And the same codebase should work on different hardware, which is not something that is required in downstream forks.

But it is sad to see that the driver was submitted in the past, is still actively developed and improved, but there doesn't seem to be plans of submitting them again.

Also I don't think that a platform driver is so complicated that it requires such a long time for mainlineing. It not a filesystem or VPN.

On a more interesting topic, the SteamDeck platform drivers are still not merged into mainline Linux... :'(

Last news about it: https://www.phoronix.com/news/Steam-Deck-Platform-Driver-2024

AAAA games are clearly inferior to AAAAXY games.

So similar to kakoune? I tried that for a while, but it was missing some features so I went back to vim/neovim.

I need to know vi anyway, because that is available everywhere (as part of busybox), so using vim/nvim for bigger systems just fits.

Or you get a message at 3 am the next day, where they apologize that they didn't made it, but that they will deliver sometime between 8 and 22 that day.

And they do that for while gaining 0 XP?

In my head canon the people are sometimes just rusty and forgetful, because even if someone lives 100 year, that doesn't mean that they will remember everything or get better at stuff. That is why I think immortal beings that live aeons, can still be surprised or tricked. Being old doesn't necessarily mean that people are wiser.

Sometimes people just need the right motivation to improve themselves.

What about Lua/Luajit?

In most scripting languages you have the interpreter binary and the (standard) libraries as separate files. But creating self-extracting executables, that clean up after themselves can easily be done by wrapping them in a shell script.

IMO, if low dependencies and small size is really important, you could also just write your script in a low level compiled language (C, Rust, Zig, ...), link it statically (e.g. with musl) and execute that.

E2E is just one part of the puzzle, you got to have a open source P2P or federated architecture as well, otherwise you have to trust a nebulous company or person intrinsically. People change and companies can be bought, but you will be stuck with their platform in order to contact your acquaintances, and changing that means loosing your contacts.

That is why the DMA is important. But you will be even better off just directly choosing a chat platform, where the users are in control.

"Corporatism vs Capitalism" was invented by capitalists to create a strawman that they can blame instead of blaming capitalism for everything wrong with captitalism.

The rest of the world uses Corporatism for something else entirely, what you might mean is corpocracy or corporate capitalism, which are just manifestations of capitalism.

Yeah, the whole article is a bit fishy:

In addition to generating clean electricity, the new ITO-silver window coating creates a cooling effect by allowing only the visible part of the light spectrum to pass inside. Other parts of the spectrum are reflected outside.

So how would a room actively cool down, when you let only the visible light spectrum inside? Sure it might not get as hot as if you let all light inside, but it will also not get colder.

Nothing about mod support or releasing the toolkit, like they did in DA:O.

That is why (A)GPL and not MIT/BSD, that is why no CLA.

I don't understand why so many open source devs just gift their work and time to big corporations by choosing permissive licenses or signing away their contributions via CLA.

A lot of 3s and no 7. Does AI has a bias on what numbers they create?

Like if I generate 1000 pictures with a number between 0 and 9, are those numbers distributed equally or what would the distribution look like?

Humans, when ask to say random numbers also have biases in some circumstances, so I guess AI does too.

I started using Fedora Silverblue on a tablet, seems to work fine so far, but requiring a reboot in order to install new system packages is a bit cumbersome and the process itself takes a while, but ordinary Fedora also doesn't win any races when asked to install a new package

I think switching to FCOS or Flatcar on servers that just use containers makes sense. Since it lessens the burden of administrating the base system itself. Using butan/ignition might be unusual at first, but it also allows to put the base system configuration into a git repo, and makes initial provisioning using ansible or similar unnecessary. The rest of the system and services can be managed via portainer or similar software.

I also do not have long term experience with FCOS, but the advertised features of auto-update, rolling-release, focus on security and stability makes it a good fit for container servers, IMO.

An alternative to Debian on servers might also be Apline Linux. Which also has more a focus on network devices, but some people use it on a desktop as well.

If you have many different systems, and just want to learn to operate them all, maybe NixOS might be interesting. Using flakes, you can configure multiple machines from just one repo, and share configurations between them. But getting up to speed on NixOS might not be so easy, it has a steep learning curve.

What’s ACC?

ACC - Advanced Charging Controller, which allows to set charge limits, thus extending the battery life, which should have been part of Android from the beginning,

Anyway I would strongly discourage using root under Android as it breaks the security model.

Security isn't a binary, security works like an onion, you have multiple layers of security and multiple decisions to make on every level. Currently you might be right, that having root access to a device might compromise it in some ways, but that isn't necessarily so and depends on how it is done.

You should find ways around using root and if you can’t you probably shouldn’t be doing on your phone anyway.

This kind of thinking is the 'I know better than you' mentality, that I sometimes see around people advertising GrapheneOS. Having 'root' permissions to the device is owing it, I want to decide what to do with it, not the vendor of the ROM, or who ever else. They aren't me, they don't know what I want to do with it.

The goal of security models is allowing me, the owner, to do what ever I want with my device, while preventing others, non-owners, un-trusted applications or the internet from doing what they want with my device. If the security model doesn't allow me, the owner, to do what I want, then it failed its job at least partially.

Root is very dangerous as it can survive a factory reset.

Why is that dangerous? The first thing I do, when I get a new phone is boot into the boot loader, and overwrite the whole partition, then the system is trusted again, at least if I trust the vendor of the boot loader. When I want to do a factory reset, I do the same, overwrite the flash with a fresh OS image.

IMO, there are other reasons why the current implementation of root are dangerous: They currently considered binary and I think they could be implemented more gradually. Like one application having root over individual other applications, e.g. accessing their files. Allowing/Disallowing individual privileged system calls, or access to specific system files, etc. All of this could be hidden behind a switch in the developers menu. Maybe only allow applications to gain root access when using a registered hardware token, etc.

As for MicroG, it is sandboxed but it does require device admin for full functionality. It isn’t running as root but it requires a lot of device permissions. You can turn off the permissions you don’t need but that could break things.

In order for MicroG to work full, you need to fake the signature, which requires a patch to the system, or root privileges.

Like others already said, you can still root your GrapheneOS, there are two ways to do this:

1. Just unlock your bootloader, flash Magisk or whatever, done. Disadvantages, you cannot lock your bootloader again, thus creating a huge security gap where an attacker, when gained physical access to your phone, overwrites your boot partition and you boot your compromised system without noticing. Which is bad, IMO.
2. Recompile GrapheneOS with Magisk installed, signed it with that key and use this key in your bootloader to lock it. You essentially created a GrapheneOS fork, can no longer use their OTA update server and use the security updates, etc. You need to create this yourself.

Yeah, they don't prevent you from doing it, the same as original ROMs don't prevent you from doing it.

Exactly right. However all the downsides you have when doing that sort of defeats the purpose. So a GrapheneOS native way to control your device would be nice.