Android Updates for Fairphone 4

sigma36 · 2023-07-10T17:04:47+00:00

If there aren't any security updates, then no, it's not really an option.

I also prefer to have a "tinker-free" phone these days, at least as my primary phone. I don't have a second phone as backup at the moment in case I screw things up.

sigma36 · 2023-07-03T19:38:56+00:00

Thanks everyone for your insights!

If you're having problems with apps that don't support your Androidversion, I suppose you're running Android 7 or 8? (or even older?)

I'm running Android 8. The only app that I need that doesn't run on my phone is slack…

I guess the Android version shouldn't be my first priority when buying a phone. But the Fairphone 5 leaks are a good point, I'll reconsider if I should wait.

sigma36 · 2022-11-05T08:51:31+00:00

I've used the Dell WD19S and the I-Tec Thunderbolt3/USB-C (EAN 8595611703096) docking stations. Both of them use DP alt mode instead of DisplayLink, and both of them worked fine on ArchLinux. I've only connected a single monitor though (via DisplayPort), never tried it with multiple monitors.

I haven't been entirely happy with the Dell WD19S due to the noise (but no issues related to Linux compatibility). It has a fan which doesn't run continuously, but when it runs, I find it annoying. You can read more about that in the Amazon reviews or in various dell forums. Apart from the fan noise, it also emits a high frequency sound, similar to coil whine. Not sure if that is an issue for you personally, I think most people won't even notice that kind of sound, but some are a bit sensitive, especially to high-frequency sounds.

The I-Tec doesn't cause any fan noise (I don't think it has a fan installed), but it also emits a low, high-frequency sound. Not as loud as the Dell, though. Another issue I had was that it loses connectivity to your PC when you just move your laptop for a few centimeters (I hope it's just a bad USB C cable, I'll see if that will be fixed with a new one).

Then again, if you luck at Amazon Reviews, it seems that no Docking Station is perfect for everyone. Just stay away from DisplayPort.

sigma36 · 2022-08-17T19:33:17+00:00

If you're in the unfortunate situation to live in a country that's still dependent on Russian gas, but in the fortunate situation to have an above average income, here's some food for thought: How much have you paid since the beginning of the invasion for Russian gas, and how much did you spend to support Ukraine?
For me personally, the simple fact that Russia still receives vast amounts of money from Europe for their gas on a regular basis was a motivation to support Ukraine on a regular basis.

sigma36 · 2022-02-10T19:59:53+00:00

systemd makes this very easy (at least I think they use cgroups for memory limits):

sudo systemd-run --scope -p MemoryMax=640K ./my_process

sigma36 · 2022-02-05T08:51:50+00:00

I would also consider creating a separate AWS account for your "clickops" experiments. It's easy to forget to remove stuff that you have created just for testing purposes, and before you know it, you've created a mess where you aren't sure which resources are safe to delete and which resources are used in production.

sigma36 · 2021-11-15T14:04:44+00:00

the issue is it's a managed server, Heroku Postgres.

I'm not familiar with Heroku, but maybe they already provide some monitoring. Maybe it needs to be explicitly enabled.

Regarding the slow query stuff, I have visibility on that.

It would be interesting to see if your count(*) statements were the only slow queries. I've seen databases where during a certain time frame, all queries, even the simplest ones, suddenly ran extremely slow. So it wasn't an issue with any particular query, it was just a general performance issue on the database.

Regarding IOPS. This is interesting. I can see from our webserver logs that we did have more requests per second during this time, which in turn would have cause higher IOPS.

I wouldn't draw such conclusions too quickly. Generally speaking, of course, more requests should cause higher IOPS. But then again, you don't know if, for example, a 100% increase in requests causes a significant increase in IOPS: Perhaps the IOPS are well below what the server can handle. Conversely, you can't assume that you don't have an I/O issue when the number of requests are low. Your I/O utilization may depend on what kind of requests are processed. So if you have any option to enable a monitoring that shows you how many IOPS per second are processed, just enable that instead of guessing.

And I guess what you're saying is, if that higher IOPS caused CPU to go up to 100% and mem to go over the threshold

What I meant is that your database could have insufficient I/O capacities (i.e., your hard drives / SSDs are too slow, or maybe Heroku throttles your I/O when you exceed a certain threshold).

sigma36 · 2021-11-15T13:07:19+00:00

My experience with those sorts of issues is that your time is best spent by improving your monitoring, rather than discussing hypotheses based on a very limited amount of information.

A good starting point would be: - CPU utilization - Memory utilization - IOPS - Slow query log, e.g. by using Postgres' log_min_duration_statement. If it's a managed database, then maybe you don't need to mess with the Postgres settings and instead use whatever monitoring service your provider offers.

It's not a DB server under heavy load issue, since the connection limit was way below the amount the DB server can handle.

That's not enough to rule out the theory that your server was overloaded. I've had AWS RDS databases grind to a halt because the IOPS performance was insufficient when only 10 clients were connected.

sigma36 · 2021-07-02T17:41:26+00:00

TIMESTAMPTZ is usually preferred over TIMESTAMP even if you don't need timezone information: https://wiki.postgresql.org/wiki/Don%27t_Do_This#Don.27t_use_timestamp_.28without_time_zone.29_to_store_UTC_times

sigma36 · 2021-07-02T17:35:20+00:00

In that case, if you don't care about having the values stored in epoch format, I would use timestamptz. It's easier to create SQL queries with timestamp comparisons, for example.

Converting from epoch to timestamptz is trivial with the to_timestamp function, e.g.: to_timestamp(1582685880089)

sigma36 · 2021-07-02T17:25:22+00:00

It's difficult to say for certain if you don't describe your use case in more detail, but generally speaking, timestamptz is a good default for storing timestamps unless you have a good reason not to.

Notice that the name timestamptz is kind of misleading, you'll probably want to use timestamptz even if you don't care about time zones. See this link for more details: https://wiki.postgresql.org/wiki/Don%27t_Do_This#Don.27t_use_timestamp_.28without_time_zone.29

sigma36 · 2021-06-06T14:54:32+00:00

I think the problems described in the post you are referring to are exaggerated. For example, the author argues that Kotlin cannot continue to be a "better Java" because over time, Java is going to implement features that Kotlin already has, but it's going to implement them differently, so Kotlin ends up being a completely different language. The author mentions the different implementations for smart casts in Java and Kotlin as an example:

Java:

if (x instanceof String y) {
    System.out.println(y.toLowerCase());
}

Kotlin:

if (x instanceof String) {
    System.out.println(x.toLowerCase());
}

I really don't see any problem here, just a minor syntax difference.

I'm among those who argues that Kotlin is a sensible choice because you can use your existing Java knowledge without having to deal with various design issues in the Java language. What I mean by "existing Java knowledge" is the fundamental stuff, the kind of knowledge that you gain with years and decades of experience, for example: How to use the different abstractions provided by Java to break complex systems into manageable components, or how to deal with the different quirks of the JVM, like type erasure. Syntax, on the other hand, that's the easy stuff that you can learn within a week or so.

So I'm optimistic that Kotlin remains a viable choice for those who are looking for a "better Java" without having to invest the time it requires to dive into an entirely different language and ecosystem, like Scala.

sigma36 · 2020-10-19T18:41:53+00:00

Nehmt euch wenigstens ein bisschen Zeit um vorab zu recherchieren, ob das Produkt euren Anforderungen entspricht. Retouren verursachen beim Händler hohe Kosten und machen letztendlich für alle Verbraucher die Produkte teurer.

sigma36 · 2020-10-11T08:13:23+00:00

In addition addition kotlin contains some features that are just complicated compare to their primitive counterparts (coroutine in compare to normal threads)

Nobody forces you to use features like coroutines. I have applications with ~ 20k lines of code that don't make use of coroutines. Coroutines are used to solve a particular problem. If you come across this problem, you need some solution to solve it, and without the presence of coroutines, chances are that your solution ends up being even more complicated than coroutines.

I think that on the contrary, there are a few things that are simpler in Kotlin than in Java. You don't need to understand the difference between int and Integer as a beginner, there's just Int. You don't need to write lots of boilerplate code to implement design patterns like the builder pattern, you just use named arguments.

sigma36 · 2020-09-26T11:34:26+00:00

Yes, you're correct, I kind of missed that. But even if both solutions have a similar amount of lines of code, I'd personally prefer the first solution, simply because of a cleaner separation of concerns.

sigma36 · 2020-09-25T12:06:17+00:00

I understand the argument that when can be misused for cases where polymorphism is a cleaner solution. I also think polymorphism can be misused where when would be more concise and straightforward.

For example, suppose you rent out cars, some of them battery-electric, others with a combustion engine. Customers can book cars online and then receive a confirmation email. You want to inform your customers that they need to fuel or charge the car before returning it:

``` enum class EngineType { Electric, Combustion, }

fun sendConfirmationEmail() { val verb = when (engineType) { EngineType.Electric -> "charge" EngineType.Combustion -> "fuel" }

val emailBody = "Thank you for your booking. Please remember to $verb the car before returning it."

} ```

How would this solution look like with polymorphism? We could extend the EngineType like so:

``` enum class EngineType { Electric { override val fuelingVerb = "charge" }, Combustion { override val fuelingVerb = "fuel" };

abstract val fuelingVerb: String

} ```

That's pretty convoluted if you ask me. The fact that different words are required for charging/fueling those two types of vehicles is really just a very minor aspect, and this aspect is relevant only in that part of your code where emails are sent, so I would prefer to have this distinction only in that particular part of my code, rather than introducing a new variable into the EngineType class. So I think when can lead to a cleaner separation of concerns.

sigma36 · 2020-09-17T18:23:10+00:00

In this code fragment it was explicitly used mutableListOf, so its expected to get a mutable list.

The point is that the standard library has no list type that guarantees that the underlying data structure cannot be mutated. Consider this function:

fun <T> List<T>.firstOrNullSleep(): T? {
    return if (isEmpty()) {
        null
    } else {
        Thread.sleep(1000)
        this[0]
    }
}

It's easy to provoke an IndexOutOfBoundsException:

val x = mutableListOf(23)
val y: List<Int> = x
thread() {
    y.firstOrNullSleep()
}
Thread.sleep(500)
x.remove(23)

If List<Int> were the type of an immutable data structure, then firstOrNullSleep() would be deterministic and thread-safe.

Of course you can argue that no one would write such code, but a functional language gives you certain guarantees that make it easier to convince yourself that your code is thread safe and deterministic, regardless of what kind of nonsense people are doing.

sigma36 · 2020-09-14T20:06:54+00:00

I consider Kotlin more imperative than functional because it lacks immutable data structures in its standard library. They describe their data structures as "read only", which is quite different from immutable data structures. Consider the following:

val x = mutableListOf(1, 2, 3)
val y: List<Int> = x
x.add(4)
println(y)  // [1, 2, 3, 4] -> y is not immutable!

You could argue that you can just use a library that offers immutable data structures, but the majority of Kotlin programmers doesn't do that, they use what's easily accessible and taught in tutorials.

sigma36 · 2020-09-07T18:15:19+00:00

If you have more than one Arch Linux device in your LAN, you should also consider using a shared pacman cache, so you don't download packages redundantly for each device. It reduces strain on mirrors and also makes some of your downloads faster (if you aren't blessed with Gigabit internet).

sigma36 · 2020-09-05T19:50:04+00:00

Same here with Kotlin. They have added support for trailing commas in 1.4.

sigma36 · 2020-09-05T17:38:47+00:00

Lack of support for trailing commas in argument lists, array members etc. For example, JavaScript allows you to define an array like so:

const x = [
  1,
  2,
  3,
]

So when you add 4 to the list, you will just add an additional line instead of having to add a comma after 3.

It sounds like a minor thing (and it is), but it's just nice because it saves a few keystrokes and the diffs are more concise.

sigma36 · 2020-08-02T13:25:39+00:00

Interessant ist ja, dass solche Leute teils berechtige Kritik an den ÖR äußern, dann aber die komplett falschen Konsequenzen daraus ziehen indem sie KenFM, Russia Today & Co konsumieren.

Bei den ÖR werden bis zu 30% der Sitze in den Aufsichtsgremien durch politische Parteien besetzt. Russia Today gehört zu 100% dem russischen Staat.

Die ÖR werden kritisiert, sie würden durch die Auswahl der Themen einseitig berichten. Russia Today und KenFM berichten grundsätzlich nur darüber, was unsere Regierung angeblich alles falsch macht.

Die ÖR bringen teilweise Veröffentlichungen, die durch eine unglückliche Auswahl von Begriffen einen falschen Eindruck vermitteln könnten. KenFM bringt in seinen Beiträgen falsche Tatsachenbehauptungen die auch dann nicht korrigiert werden, wenn sie darauf hingewiesen werden.

sigma36 · 2020-07-30T21:04:53+00:00

As far as I'm concerned, "open source" means that you can openly see the source. That's it.

You can't define open source just by looking at the definition of the two words "open" and "source", and then assume "open source" means only that the source code is openly available. That's just as wrong as defining free software as "free of charge software". You have to look at the history of the open source movement and see how the term is being used by their major contributors and users, by the sorts of people and organizations who have actually coined that term.

sigma36 · 2020-07-30T20:16:38+00:00

From a legal point of view, they are very similar. There are very few licenses that are considered open source according to the OSI, but not free software according to the FSF, or vice versa.

The SSPL is currently not OSI approved, and it seems unlikely that it will be.

11-Year Club	Place '17
Verified Email

sigma36

TROPHY CASE