> there's nothing wrong with starting a business rebranding Nextcloud and keeping your development closed source, as long as you're honest about that, which this initiative is not.
I thought Nextcloud was released under the AGPL, making this very much not okay by default. So either I misunderstood something or Office.eu got a permission to make non-free modifications? (Going by what you said; I have not dived into this.)
If it just says that it is partly based on Nextcloud, that does not imply they modified Nextcloud code at all. Other parts of the platform could be based on some other code, even closed one.
It seems like you can assign this action to Ctrl + S, yes. See here:
Edit → Keyboard Shortcuts → file → Overwrite […]
I think this would be awful default behaviour, but I guess it’s nice to have the option if you really want it, and I was pleasantly surprised at how easy it was to find after reading your comment.
It used to be even simpler, though I am sure it caused all sorts of problems: for any Gtk+ program, if you hovered over a menu and pressed a new key combination, it would reassign the shortcut for that menu to what you just pressed. You still had to turn it on, and it was an amazing feature, but you'd occasionally reassign something you did not want to :)
What Photo app are you referring to? On Debian Trixie, I just get the screenshot app, Spectacle. It shows the screenshot it just took, tells me where it’s been saved, lets me do stuff with it, and lets me take another one. It could do with a facelift, but it’s fairly clear, really. I wonder if they changed it later or if the distribution you used deviated from the defaults.
I believe they changed the app since Trixie was released (Trixie has KDE 6.3, the changes were in 6.4) and buried a lot of the really common settings behind menus. E.g. you might want to take a screenshot on a delay, and that's now hidden behind a menu whereas they used to surface the most common features on a panel.
My reading is they were simply trying to comply with regulations. It wasn't about what ideas they believed the religious texts were trying to convey, but whether their content met a certain definition set by law. The law could be poorly written, or it could be poorly and over-cautiously interpreted by F-Droid maintainers. But I didn't get the feeling they were acting on any kind of moral judgement or own belief about what's appropriate for children.
Does the Bible encourage violence or promiscuity? Not really, no. Does it mention and describe those things in some detail? Yes, absolutely. If that's the kind of content you need to remove from your store, then obviously you need to remove the Bible from your store. Whether that was really the case seems questionable at best, but the stated logic seemed pretty coherent to me.
Which regulations? F-Droid seems to be governed by Dutch law (see https://commonsconservancy.org/dracc/0039/ ). Do they have laws prohibiting all apps with any violence or promiscuity?
(As an aside, if they indeed had to follow some Dutch law and remove Bible and Quran apps, maybe F-Droid can be hosted by freedom.gov, US govt's new anticensorship portal..)
> The law could be poorly written, or it could be poorly and over-cautiously interpreted by F-Droid maintainers. But I didn't get the feeling they were acting on any kind of moral judgement or own belief about what's appropriate for children.
If F-Droid were being overcautious, they would have blocked social media apps too. Social media is explicitly the single biggest target of these “think of the children” app store laws after outright porn sites. F-Droid left Reddit and Mastodon clients unmarked. Am I supposed to believe that F-Droid honestly thought the law applied to apps containing only ancient religious texts, and not to social media? Has any other app store interpreted the regulations the same way? And if they truly believed that was a legal requirement, why did they reverse the policy after only a couple days of user complaints?
It’s heavily inspired by both TeX and Emacs, hence why it’s named after both of those. As if the author had added the best aspects of the two and then some.
Why should skin colour be specified at all? Why not leave it as an implementation detail? Yellow is the popular default choice, but it could very well be green, blue, pink, or anything really.
It seems like Taler has been coming along great and the biggest things it’s missing are more interest and adoption. There has been some first ‘real-world’ use recently, but it’s still far from becoming widespread, which would be a dream come true.
They don’t seem to provide a detailed comparison showing how each compression scheme fared at every task, but they do list (some of) their criteria and say they found Brotli the best of the bunch. I can’t tell if that’s a sensible conclusion or not, though. Maybe Brotli did better on code size or memory use?
It seems to me this point of discussion always tends to get way too much focus. Should it really raise concern?
Of all the people who interact with image formats in some way, how many do even know what an image format is? How many even notice they’ve got different names? How many even give them any consideration? And out of those, how many are immediately going to think JPEG XL must be big, heavy and inefficient? And out of those, how many are going to stop there without considering that maybe the new image format could actually be pretty good? Sure, there might be some, but I really don’t think it’s a fraction of a significant size.
Moreover, how many people in said fraction are going to remember the name (and thus perhaps the format) far more easily by remembering it’s got such a stupid name?
I thought Nextcloud was released under the AGPL, making this very much not okay by default. So either I misunderstood something or Office.eu got a permission to make non-free modifications? (Going by what you said; I have not dived into this.)