This is interesting. However, I am wondering how relevant this analysis really is. Is the compositor-related power usage relevant relative to typical user applications? And is the increased power usage by Wayland-based systems justified by other improvements?
TBH, I have no idea and should read this up but maybe someone can fill in some context?
Does that mean the copilot key behaves like a key-combination? Sounds like it but maybe I’m misunderstanding.
Standard procedure, no? We used to map non-standard keys back in the days. I’d probably map it to Super and use it for my key combinations for my most used software.
To my understanding, these are confirmed vulnerabilities and have been resolved in 7.1. I have not checked all of them but didn’t find any CVEs without a note on the fixed kernel version.
Moved to Apple Music after Rogan started airing on Spotify. Hence Apple Music on the phone, streaming through Cider on Arch otherwise
Edit: I could not work with local files or my own file server because of the breadth and amount of music I listen to. I’d have to have a massive collection and constantly keep buying 🤑
In general, setting up a client with POP3 rather than IMAP will move all the emails from the inbox to the client. Once they are in the client you can decide how to backup the archive, there’s plenty of options with varying performance and memory footprint. That sounds pretty much like what you would like to do in general.
Just for completeness: That of course also means that syncing to several devices and backups are now your problems to solve.
In any case, the initial download will take a long time either way if you have 20+ years and 10s of GBs of data. No way around that.
I don’t think you are paranoid. This technology is creepy as hell. Almost all cars are connected nowadays and send data back to the manufacturer’s server—visible or not. In the best case it’s just the service history, in the worst case live positions and more. Some cars stop working if the server is shut down *cough. Cameras equipped to unlock based on a face record biometric data. And honestly, would you trust your car manufacturer (!) to handle your biometric data?
Jolla phone + the other half?
From an environmental physics point of view, this is not very weird: Warm air holds more absolute amount of water, leading to stronger downpours and longer dry periods. One could also say, the world is getting warmer and this a little “more like summer”. And strong rains converts to strong surface runoff. In other words: Strong rains causes your streets and fields to flood and that water raises the rivers rather than the soil’s moisture. And there we go: The soil is getting drier although there’s more total rainfall.
With one difference. After merging with text.com they switched to a model with on-device bridges so that the decryption on their servers is no longer needed. Ofc it’s similar if the matrix instance and the bridges run on the own server.
I don’t find this convincing. Everyone knows how easy it is to click “yes” without actually knowing what’s behind it even reading it at all. There’s a reason that “I have read the terms and conditions” is the most common lie on the web. Also, no one will read a lot of information. So adding AI sounds great, doesn’t it? While this is a technical opt-in, it is still really close to an opt-out.
And then the ML generated code. I am aware it’s anecdotal evidence and might not mean anything but every time I tried Ubuntu, I deleted it after a few days because I found the bugs way too annoying after hitting too many road blocks. So if a buggy prone desktop environment additionally accepts ML code, it makes me suspicious and wanna stay away from it.
Exactly at the speed of light, the γ-coefficient would be infinite and so would be the time dialation. The eigen time of the moving person would thus be infinitely slower than the non-moving person. From the perspective of the stationary person, the time of the moving person would stand still and thus the person would never say anything. Very close to the light speed, when the coefficients are large, this problem eases but persists. The stationary person would have to wait for very long (and use a massive Doppler shift of the moving signal) to perceive something. At the end of the conversation, it will have lasted much longer for the stationary person, spending years on this. The twin paradox would basically kick in as well. If the moving person is at a speed too close to the speed of light, the stationary person might die before the conversation is over—assuming the stationary person is not immortal. That is kind of a very slow motion, yes. What a dedication, spending a lifetime on a person who can’t slow down ;-) Funny enough, from the perspective of the moving person, the effect is reversed.
The only thing that really got me going was small applications I had some interest in. Writing games I will not play never kept my interest up for long. So I’ve been building mini tools I used for teaching numerics classes in meteorology (Python, Julia, Fortran, C) or code I would be using for some tinkering with microcontrollers or similar (Python, C++) when using new languages. For me personally, some iconic projects were a CO2 sensor with an attached display, or very simple internal gravity wave ray tracers. But that’s likely not what you’d be interested in. So without trying to suggest specific applications for you (many good examples in the responses :-) I’d advise to do something you’ll have fun with. Get yourself a small project that generates added value for you specifically (and fun is great added value in my eyes).
Link to app repos, both contain the disclaimers: https://github.com/eu-digital-identity-wallet/eudi-app-ios-wallet-ui https://github.com/eu-digital-identity-wallet/eudi-app-android-wallet-ui
Maybe the security expert could read the readmes in the repos first. From the iOS app repo:
The initial development release has reduced security, privacy, availability, and reliability standards relative to future releases. This could make the software slower, less reliable, or more vulnerable to attacks than mature software.
And further:
If you're planning to use this application in production, we recommend reviewing the following steps: […] The Pin storage configuration matches your security requirements, or provide your own by following this guide Pin Storage Configuration […]
So the text hints not at design flaws but at facts that are already stated in the readme. Plus, the major source for the article is Pavel Durov, who’s messenger is of course a standard in security and privacy.
So there seems to be no news but a lot of speculation by Durov instead.
Clouds.
And there’s much more to be found.
/rant Advertising broke the internet in so many ways since it became the number one way of monetizing “free” online services. Most popular means of communication (email, messaging, …), news distribution, or any other digital interaction (social media, neighborhood platforms, …) are driven by either selling users stuff they didn’t want from the service in the first place first place or by helping others do that through gathering huge amounts of data not needed for the service. So participation in the digital society partially forces us to play the game as non-profit open source solution typically only cover smaller portions of society. I’m so sick of it. /rantoff
I was wondering if blocking ads and switching off location services would even limit the impact on Webloc much. It’s always surprising how much information ca be pulled from seemingly harmless interactions.
Not a legal argument but what is the possibility of modifying and redistributing the software worth of the entire branding (!), etc. have to be kept intact. Doesn’t that impose limits on modifications in the first place? Doesn’t feel much like the idea of a viral copyleft license. Also, if the first thing after a prominent fork is starting a legal fight over subtleties in the license with the goal of preserving one’s brand, I’m not so sure why the software was distributed with an AGPL in the first place. The whole thing doesn’t seem to add up.
Nice. I wasn’t aware they managed to assemble all parts with Linux drivers. From all I read (not an expert at all) that seems quite tough. What remains is a runtime environment/infrastructure for everyone who’d like to run Android binaries/packages on the phone.
SFOS is not an Android fork. As many classical Linux distros, it controls sessions through systemd, the compositor is Wayland and the standard c lib is glibc. However, compatibility with the drivers of many hardware vendors and certainly also running binaries build for Android require Android libraries and abstraction layers to be present. Sadly some Android libraries or suitable replacements where available are absolutely necessary to run a phone nowadays. Both hardware and software producers are so focused on Android that drivers / binaries for alternative systems are not offered. That also underlines that this is indeed a niche product. Disclaimer: I ordered one of the phones.