That’s a much reduced statement. Construction noise is indeed a massive disturbance, which is why there’s a lot of efforts on mitigation it. Once the plant is running, however, it has been observed to work as an artificial reef increasing the local populations. To increase the effect there’s some work on adding boulders in between the monopiles. Another reason is that power boats are (depends on country) often forbidden to enter which actually reduces the noise disturbance within the area. There’s also effects on some species (lower trophic levels) due to the local reduction in wind speed in the wake which modifies the amount of mixing in the surface. That is, however, an active field of research. Long story short: fields of wind power plants are depending on the current life stage a disturbance but have in some sites been observed to be the opposite once operating. A conclusion to only build them on land could hardly be drawn at this time.

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.

I was always wondering the same and found the related choices always somewhat inconsistent. My own anecdotal experience was that Ubuntu was always to buggy to actually use it in production (every time I tried, I ended up removing it after a few days only due to driver road blocks and os-related bugs). Moreover, using Debian, as many said before, is a question of feature stability and extensive testing. That’s great for server deployment but not so great for consumer electronics. Thus trying to base a distro on Debian while trying to fulfill the expectation of receiving recent developments in the software seems counterintuitive to me.

Disclaimer: I’ve made a lot of very good experiences with Arch and derived distros and use them in production for more than a decade. Given my not so good experience with Ubuntu I’m certainty on the biased side here.

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.

I’m glad to hear that lack of time/resources for code reviews are more common. Also for clarification: I was the author and requested reviews by my colleagues. In reverse, I did not receive requests to review PRs so far. Tbh. I would really like such a review culture as it is already standard in scientific publishing and it would have avoided some obvious bugs we did encounter in the past. Having that said, as I did not receive any review at all and I would appreciate low(er) quality reviews better than none.

It was more a question of finding the time within the daily business of doing science. I suppose it is also a culture issue, the priority to do a review is usually low. In other words, there was de facto never a review.

From a scientific modeler perspective: Always trying to do 5 (or 4), but I’m having difficulties getting a culture of reviewing each other’s codes going. Many times I was asked to “just merge” months after submitting a PR. In the context of operational or large community codes, 5 is usually strictly enforced. Weather services don’t appreciate broken code.

Do I get this right? A hand full of OS devs who also sell phones form a group that attests combinations of phones and certified copies of their OSs as secure?
Sounds like self-verifying the own ecosystem of devices and OSs in a cartel-like consortium. But wasn’t that to be circumvented? Shouldn’t the certifying body be independent of the certified products?

I am having questions.

Of course one would have to trust Jolla. But then again, isn’t that always the case for everything that isn’t 100% open source? And even then, there could be compromised code somewhere. SFOS is in use for many years, there is an active community around it but the closed source parts of the OS, including hardware vendor drivers, are, well, closed source.

But then that’s just it. Whom do we want to trust? There is no 100% open source phone and SFOS seems the only persistent Linux-based OS for phones around.

I wanna give a shoutout to Manjaro, an arch based distro with a cascading testing cycle for better stability. That being said, I am using Arch and Manjaro for about a decade now and never really had any stability issues (in contrast to my tries with Ubuntu). The arch wiki stays one of the absolute best resources for Linux users on the internet, the rolling release ensures cutting edge Software, the AUR makes it very easy to provide community built packages. And then there’s Debian. Definitely my choice for servers.

Interestingly, open resume and open collective have a very similar logo - even color wise. The latter is even closer to 1 and 4.

Scratchmark is a great name! Concerning the Logo, your suggestions are nice but they might be too complicated. The Logo has to work when it’s tiny on your desktop etc. The more simple the better. Maybe a simple logo and the placing one of the suggestions in your UI somewhere would work? :-)

SEPA is the direct banking standard in Europe. Basically every transaction between banks follows that standard. If you’re doing business in Europe, that’s the most direct way you can go. Many other companies and their transactions follow the SEPA standard somewhere anyway. An SEPA mandate is pretty safe for the customer, too. It can be canceled by the account owner at any time. It does not have any additional insurance layer, though.

Haha. 🤣 Made my day

Tbh, I understand the problem. There are just so many volunteers for making newer developments work on every platform. Streamlining the development and easing the load on the volunteer devs seems a good idea. Having that said, it’s ofc a pity to drop support for devices. At least the LTS kernels will support the current support for a while and the vibrant Linux community will find a good way to work it out, I have no doubt. Many machines, in particular old ones, run with very old kernels to begin with…

I’m not sure I understand this, tbh. Does that mean the P2P network works on a chat group basis? Or does the user explicitly choose who to build a P2P network with? And then, there are lots of follow up questions already looking around the corner.

Their website seems to explain very little and the app itself is closed source. Although there are open source dependencies, it’s for instance unclear whether they are complete. So I guess it’ll all come down to trust into the software and the company. Btw. their privacy statement allows the usage of aggregate data for marketing purposes and the sharing of data with third parties, such as search engines. And latest at that point I’d rather self-host a matrix instance.

Most ML development is done in Python to my knowledge. The reason is mostly the readily available side packages like torch, scikit-learn, etc. And Python, although not constructed as such, does indeed support a functional style. A quick search revealed a HowTo:

https://docs.python.org/3/howto/functional.html

I dunno. P2P traffic always seems to overburden light users and it would indeed require the apps to always run in the background to relay the traffic. Although the idea seems compelling I wouldn’t install the software on a machine of mine.

Appreciate the KISS perspective.

For me, the project management features of a forge are extremely helpful. Setting milestones, assigning issues to them, defining timelines and regularly reiterating the planning has proven to accelerate our work as a team significantly. This experience refers to huge code bases (climate models) and medium to large team sizes, though. And probably also my bad memory 😵‍💫

I suppose it’s always good, though, to evaluate how much management a code will actually need in the end, and what tools correspond to that need.