m45t3r

> systemd-boot (AKA, gummiboot) is leaner, for sure- much in the same way a bicycle is leaner than a truck.

I think this is the perfect analogy why systemd-boot is better: you don't want to use a truck to get to your local bakery, it is going to be either a walk (ESP boot directly with kernel anyone?) or with a bicycle.

This makes sense since it should avoid two issues:

- Sites that try to detect mobile by looking at "ARM" in user-agent string

- Sites that try to parse the macOS minor version for some reason and would be confused to see something like "11_0"

BTW, user-agent is a hell anyway. Just looking at this user-agent that OP posted, macOS still identifies itself as "Mac OS X", still is based on Mozilla/5.0(!), still identifies itself as KHTML enginee (compatible with Gecko), and so on...

Nice. Just discovered that you can open videos from the official YouTube client by using the "Share" menu and selecting NewPipe. It has multiple options, including download/open/open as popup.

This make it much more useful for me, I can still have access to my YouTube account but I can open the actual videos in NewPipe and skip ads/have more control of the playback options.

Also, this bug from official YouTube app does not happen in NewPipe, making it much more useful to me since I use a custom caption settings because Amazon Prime Video (but they look horrible in official YouTube app because there is no outline): https://www.reddit.com/r/youtube/comments/e935yz/bug_caption...

> There is an horror story about an Android One Xiaomi phone

Which one? I had a Xiaomi Mi A1 and nowadays I have a A2, both are fine Android One phones that still receives updates (in the case of A1, only security ones, but the A2 received a Android 10 update).

Yeah, Xiaomi may take a while to update their phones in Android One program, but otherwise it is fine.

> The larger picture is that you can use PNG or SVG anywhere you need transparency, which are also better suited for the content that has transparency.

It is pretty common to have anime characters where you remove the background to use as reactions, and while you can use PNG in those cases it makes the images huge. WebP makes it ideal for those cases, this is even the case that I saw this being used in some image boards (specially also including animation, another thing that is popular).

Just because you can't think in a use case there isn't mean that there isn't a use case.

This is how I am using my Raspberry Pi (running Pi-hole) too: overlayFS. It means that I lost the statistics after a reboot, but it also mean that I don't care if the power in the house is suddenly lost either. I also enabled watchdog support so my Raspberry Pi is probably the most reliable part of my network.

The problem is always standards. I want transparency to work correctly everywhere, not just in one application and broken everywhere else.

Even if transparency was add to JPEG right now, it would take sometime to become available everywhere, and you would have tons of legacy devices showing broken transparency.

The advantage of a new format that supports transparency from is interception is that every device that is compatible with it will display it correctly. So there is no issue with some devices supporting the format partially.

This is a decision of your distro mantainers, they could also default to unbound, dnsmasq, bind, or anything else. They use systemd-resolved because it probably solves some problem for them, even if this problem is reduced burden of maintenance.

The fact that `KillUserProcess` is default to on is not something that systemd forces to your distro, there is even a flag to disable it at build time. It does makes sense in many situations (like IoT, embedded, etc.), that is why it is on, but distro mantainers also needs to know what is better for its users (that anyway is a really small part of Linux users, embedded is much bigger).

Thanks for the article to remember me of the existence of this project. I decided to do a setup in my home network using an old Raspberry Pi 1 that I had. Mainly because the router of my ISP screwed up really hard in its DHCP server, so I decided to disable it and use Pi-hole's one instead.

I tried to make this setup as robust as possible, using OverlayFS [1] so root is read-only unless I remount it (to change configuration or upgrades) and with a watchdog so it can auto-reboot in case my Raspberry Pi is unresponsive. Pretty happy with this setup and it my internet seems more responsible than ever.

[1]: https://yagrebu.net/unix/rpi-overlay.md/wiki/Setting_up_over...

> Are user processes allowed to run after logout? Which DNS to use during startup? What logging in should look like? In each such case, existing behavior which was widely considered as not broken was replaced by a different behavior, often even without an escape hatch. The new behavior(s) in such cases should be made possible, but the default should be the old behavior.

All those examples you gave are possible to disable in systemd, and in the case of DNS and user process after logout, they are not even the default.

: Killing of user process are enabled by default in upstream but disabled by default in every distro that I know. And systemd-resolved, even if it is build by default, is not enabled by default even in upstream.

Yeah, startup times is something that you don't really notice until you have a system that is really fast and responsive, and them you simply get annoyed by when you're using a system with slow startup times again or get accustomed again with the slowness.

Startup times didn't bother me too much, but nowadays it does, specially for things that my brain assumes that should be fast. This is why, for example, both my Neovim and Zsh configuration is tuned to start in <0.1s:

    time zsh -c exit
    zsh -c exit  0.00s user 0.00s system 84% cpu 0.007 total


    time nvim -c qall
    nvim -c qall  0.07s user 0.02s system 100% cpu 0.081 total

It does makes a massive difference, for example spawning a new shell is instantaneous and when I know that I will make some small changes I much prefer to open a file in Neovim than Emacs (my main editor/IDE nowadays).

Apple could simply, you know, provide an API so browsers could query this option and do something useful instead of being anti competitive.

Android is kind of the same: by default, no data connection is made unless you explicitly change the USB mode from charging to something else.

Not really. Android has a similar feature for years and no application can abuse this system since this is all controlled by OS.

All web browsers in iOS run the same engine (Safari). So while Google should fix their layout, this is a very good example on why Apple should allow alternative web engines in their OS.

This was the shortcut to Amazon website, not the search lens that already died in the transition from Unity to Gnome.

https://www.omgubuntu.co.uk/2020/01/ubuntu-removes-the-amazo...

For security reasons you say? No.

I mean, LD_PRELOAD is very useful. I used libfaketime once to debug a problem in a project that I worked that only happened when you run the test suite in a specific range of time. This power is very useful.

Can it be abused? Maybe, however you should assume that your environment is trusted or there is way worse ways to modify a process that is running in your system. In some of them it doesn't matter if the binary is static or not.

Well, I concur with the points from the article, since while I don't like Golang as a language I really like its tooling (BTW I am really craving for a more powerful language that compiles to Golang. And specially I like the focus in Golang to produce truly static binaries (they're not even linked with libc!).

And while Golang may not be the fastest language out there, it is fast enough for most use cases. I mean, Python is fast enough for most use cases, and Python is one or two orders of magnitude slower than Golang.

So yeah, I think their compiler decisions are fine. They may or may not be the best decisions, however the article is not talking about the compiler part of Golang, so yeah it can still talk about "undervalued technology".

Which is perfectly fine explanation. I mean, it is their programming language, not yours, they can do anything they want.

And while Go compiler may not be perfect, it works well enough.

> It is no different than the requirements to provide newer builds updated to specific Android target versions, or being 64 bit only that Google keeps forcing devs to move forward.

That is basically saying that this is a big work for everyone involved (developers, Google, OEMs). This is exactly my point.

> Any application that depends on syscalls isn't portable across Android devices anyway.

The application does not necessary call a syscall directly, the problem is that the NDK calls a syscall as an implementation detail (for example, for lock primitives eventually the NDK must call the Linux lock primitives too, there is no way out).

So if Google needs to change Android kernel, they need to implement the same quirks of the current syscalls, or the slightly change in behavior will break random applications.

My point was never calling syscall directly, however for sure some applications call syscall directly too.

I have high blood pressure, and this is a step at the right direction. Current home devices to measure blood pressure are not really convenient, so I tend to only measure my blood pressure at home.

However, this is not what I want. I want a device that measure my blood pressure continuously (not necessarily all the time, let's say each 15 minutes). Why? Because I want to know how my behavior impacts my blood pressure. For example, does eating salty foods really increases my blood pressure, and for how much time.

Anyway, I still want this device since it seems so much better than what is currently available.

While the performance of Erlang was not the best between the contenders, I really like the behavior of Erlang here: load makes almost no difference in latency, so while you're serving less clients, you're guarantee to be serving them well.

This is a much better behavior than having random spikes in latency, which translates to a small but significative amount of users complaining about that your application is slow. Erlang is the contrary, every user should have the same experience, nonetheless of the load of the server.

> Having to recompile doesn't make the applications kernel dependent, now to consider porting such applications from macOS to Linux to Windows, kernel dependent?!?

So you concur with me that if Google changed the Android kernel it would be a big change? Just imagine, you would have to recompile all applications using NDK to work with this new Android. It is not something trivial, sure they can make it work, however it would probably need quite some time with Google making obligatory to having developers to ship both Linux and new Kernel binaries.

And even them, you can't make sure that everything will work. A small change in behavior of a specific syscall may break a random application somewhere that depends on it, because even if this syscall is not directly used, Android NDK uses this syscall to implements its API. Now multiply this for the number of NDK applications that Android have and you will have a huge amount of breakage.

So yeah, Google can make it work, however it is not as trivial as you think.

> And the point wasn't that it isn't profitable as such, rather it isn't the money maker that some here are making waves for, rather a wannabe versus the revenue made across desktop, consoles and iOS.

Sure, we can concur at this point. However the market for Android gaming is still more expressive than you seem to think (not wannabe by any means, but lower than iOS sure).

> Google Play already does binary translations from ARM into x86.

It is not libhoudini [1]? AFAIK, libhoudini is not something that Google Play embeds on binary for distribution, it is a library that ships on Android x86 devices (and another AFAIK, it is proprietary from Intel so they only ships on Intel devices).

So while Google could have a similar approach if they want to ship another kernel for Android, the work is not as trivial as you seem to think.

> Also the whole point of ISO C, ISO C++, OpenGL, Vulkan, OpenSL is to be OS independent.

Yeah, it doesn't mean you don't need to recompile your software. You can't take an game written for Windows in OpenGL and run in Linux without recompile. This is my point.

> Game studios are not a charity, they develop games for profitable markets, not for large userbases that don't pay for games.

Well, Android seems to be pretty profitable? It is not the most profitable platform sure, however it sure makes enough money because almost everyone ends up creating games for both iOS and Android.

You seem to imply that making games to Android is not profitable, however it sure seems to be. Or Epic Games, EA, ActionVision, and many other big names in game studio are a charity.

[1]: https://commonsware.com/blog/2013/11/21/libhoudini-what-it-m...

> There is no Kernel API for userspace as official supported NDK API. If you call any Linux API you are the one to blame if anything changes, even across devices.

Yeah, I never said that you should directly access the kernel API using the NDK (however you can actually). I said that just the fact that the NDK is compiled to native code means that the code depends on the Linux kernel, and changing the kernel would mean, at minimum, a recompilation. Android NDK only guarantees an API, not a ABI, and those two things are very different.

So no, it is not like changing the kernel would have zero impact in Android game market. It would actually have a huge impact, since almost every game would stop working until being recompiled (games that does not use the NDK would probably be fine, however few games are not native). And of course, for backwards compatibility purposes you would need to have multiple binaries (however this is already true nowadays since Android support multiple architectures outside ARM).

> No it hasn't the biggest gamming userbase, as proven on a market analysis report I just posted.

I never said it was the biggest gamming userbase, I said it was the biggest userbase. Even if Android doesn't have the biggest gamming userbase, just for the fact that that you have a big userbase as big as Android have means people will develop games for you.

> Android is such a pain to develop games for, that Google has started a Android Games initiative only in 2019, to appease the growing complaints from game studios.

This is actually irrelevant, Android could be the worst environment to develop however since it has the biggest user base it still has people wanting to develop to it.

> Finally, the only Linux that Android has is the kernel, which Google could replace tomorrow and user space wouldn't even notice.

This is not really true, specially considering for games. For one, since most games use Android NDK, you can't simple swap the kernel and everything will magically work. You will at least need a recompilation, and this new kernel API must be bug to bug compatible with Linux or things will strangely broke.

For another, there is things like the discussion of spinlocks/mutex/schedulers like this one of this topic that, as shown, can make a big difference. It could be better in a kernel optimized for latency, or it could be much worse, making games that today are playable in low end devices a complete shitty show.

It is not that stderr is faster, it is that it is unbuffered by default (while stdout is buffered by default). If you flush your output after printing to stdout, you should get a similar result.

And well, I am thinking you're talking about "much faster" for small amount of text (small enough to not fill the stdout buffer). Actually printing huge amount of text to stdout should be much faster than printing to stderr exactly because of this buffer.

For this specific case, nothing, however let's say you need to know when the user got a specific scope and from who. You probably can answer this question in SQL if you prepared your database to do it (i.e: a changeset table), however in an event sourcing architecture you would gain this information for free.

However, just because you're using event sourcing doesn't mean you don't have a database with the current state of your entities.

Yeah. When you start anything remotely complex with GraalVM it starts to break, i.e.: anything related to eval (and this wasn't my code actually, however a good part of Clojure ecosystem depends on eval).