m45t3r

This looks that you're using very aggressive power settings in the kernel (powertop, tlp?), and doesn't seem related to PulseAudio at all.

> My very own system did not work with Pulseaudio when I tried to switch, that was years later. I still use only ALSA because of that experience. At that time Pulseaudio was garbage, it should never have been used then. It only got acceptable later - but still has bugs and issues.

I remember the transition to PulseAudio. Initially, most things were broken, and we still had some applications that worked only with OSS so the whole audio suite in Linux was a mess. I remember that I already switched from Fedora (very broken)/Ubuntu (slightly less broken) to Arch Linux, and for sometime I kept using ALSA too.

Eventually, between switching Desktop Environments (I think Gnome already used PulseAudio by default them, while KDE was optional but also recommended(?) PA), I decided to try PulseAudio and was surprised how much better the situation was afterwards (also, OSS eventually died completely in Linux systems, so I stopped using OSS emulation afterwards).

With the time it was getting better and better until PulseAudio just worked. And getting audio output nowadays is much more complex (Bluetooth, HDMI Audio, network streaming, etc). So yeah, while I understand why PipeWire exists (and I am planning a migration after the next NixOS release that will bring multiple PipeWire changes), I am still gladly that PulseAudio was created.

You can just configure your editor to run formatter on save or with a shortcut. Not really a deal breaker.

Also, just changing to a Chromium based browser is not sufficient. Google still takes most of the decisions in where Chromium is going, and downstreams either accept them or workaround them (but for every workaround they do it is more things to keep maintaining in the long run).

So yeah, using a non Chromium browser is the only way to ensure that the Web is still healthy (i.e.: not controlled by only Google) in the long run.

What do you mean? NixOS you basically can reboot in the latest working version, so the downtime is likely minutes at the worse. Also snapshots in Btrfs/ZFS are really fast to recover too, since they're basically a pointer (again, at worse you will have minutes of downtime).

I had updates in Windows take quite a long time to complete, even on SSDs, and in Windows you also can't update the system while running (it must be during reboot). And since you can't use the machine, this can be considered downtime too.

> Linux (where do I start)

Not true, there are tons of ways in Linux where you can completely recover from a bad update. Either manual backups (even using tar works), BTRFS or ZFS, or something more fancy like NixOS (that I use).

At least I don't need to pay 99 USD a year for some "review" that clearly only works in favor of Apple (they mostly seems to approve anything from smaller developers like shown in this post, while using draconian and arbitrary rules for competitor apps like Spotify).

I don't know any distro that doesn't update browser packages in stable releases. Fedora, Ubuntu, Arch (ok, Arch is rolling release but still) and NixOS at least offer the lastest versions of Firefox and Chromium on its repository. Debian too, but I think they package Firefox ESR instead of Firefox release.

It is planned obsolescence, but not because of the usage of liquid metal thermal paste. Liquid metal is not only more expensive to buy but also to apply (it is very difficult to apply liquid metal thermal paste correctly, and also they need to take care to not spill liquid metal in exposed parts of the processor or it may short circuit the CPU; that is probably also the reason of the white plastic around the CPU). Also, liquid metal only form alloys with some types some metal and probably Asus knows this and avoided using them.

But it is still planned obsolescence because like most notebooks those parts like fans are not meant to be replaced, at all. They probably can be replaced, but is still expensive so most people will prefer to buy another notebook rather than replacing a fan or battery.

> I'm not so sure whether this is truly a benefit of FP.

Yeah, it is not. But like pure functions (that are also not necessary something from FP, you can have pure functions in probably any language out there), it is easier to apply in FP and also more idiomatic there.

Like, you can simply generate a map or dict in most languages and have it transformed and converted in most languages out there, but once things gets complicated probably someone somewhere will say in a Pull Request "this is not the idiomatic way in OOP, you should create a data object and store this data there" and blah blah blah. FP doesn't have this kinda of baggage.

This is one of the reason I think FP is better than OOP for business development.

You can still have entities (that are plain maps, possibly annotated with types so you can keep your sanity), but the business logic now works with simple data structures: you input some data and gets another more data back. Do this transformation a few more times and very complex business requirements can be expressed. Testing is also easy since most functions are pure.

Now you need to transform the data? Ok, convert this data to another data format and pass it to serializer. Same thing for deserializing.

Traditional OOP really makes this last step more complicated than it should, since now you have an object, and the object should be opaque so you don't leak implementation details. To serializer you possible have a complex hierarchy of objects so your serializing logic is more complex too.

Of course OOP doesn't need to do this, but the FP model seems so much simpler to enforce this data processing part.

Datomic uses a similar approach by default. They called it squuid: https://docs.datomic.com/on-prem/identity.html#squuids

Unless you give me a more concrete example, I don't really think this is true.

For example, right now neither my desktop nor my notebook uses `systemd-networkd` and it works fine. Actually, since I use NixOS even basic things like `hostnamectl` or `timedatectl` are "disabled" (they work in read-only mode since those configs are managed by NixOS). But I do use `systemd-bootd` (so I can get boot information from the early UEFI until user space, try doing the same thing with GRUB+sysVinit).

The only two components that I know it can't be disabled in systemd is the init part and journalctl (because all the other parts of systemd depends on it).

> Starting as an init system and becoming a general API that abstracts low level kernel features seems like feature creep.

I think the initial presentation of systemd as a faster init system hurt it more than helped, because people started to think that systemd "was just an init system". And it never was really, even early on there were blog posts showing how powerful was its declarative approach. But it seems that the only blog post people remember is the "faster init" one (that even this one did more emphasis on the fact that systemd did dependencies the right way them the fact that it was fast).

> every other approach and dragging linux further away from its BSD/Illumos cousins

The way I think about systemd is that it make it closer to the approach of BSD and other *nix systems does. Portability is never something easy, specially when you're doing complicated things like power or network management. A good example is that all the different BSDs have difference between on how you manage networks, and the way it was on Linux before systemd was that *every* distro reinvented their own network management system (and each one was slightly broken in some fun way).

So what systemd does? They standardized everything. Now if your distro uses systemd-networkd, you can finally write a service that depends on a specific network topology that is portable across multiple Linux distros.

BSD don't need something like systemd because they're already tightly integrated, because the kernel and user space is both developed by the same team. Each part of a Linux user space used to be developed by different people, and it was the work of the distro to integrate everything. Now systemd provides a good foundation for many things in user space, and most distros stopped to ship their own solutions except for package management and some other integration bits that they need for their specific purposes.

So if you say to me that systemd is feature creep, it is as much feature creep them the whole FreeBSD or OpenBSD. And this just doesn't make sense.

I don't really understand this feature creep argument against systemd. I mean, this is not like this is a feature included in PID1, it is a new binary so a separate feature (and I am pretty sure that you can choose to not compile it too if you don't want, like almost any other systemd feature with the exception of systemd itself and journald).

Also, the way I understand systemd nowadays is it isn't an init system, it is an API for Linux systems that abstracts low level features in kernel in a consistent way (either using unit files or systemd C interface). It has an init system because it needs control from early boot so it can offer a nice interface for services. Ditto for dbus, mount system, timers, logging, etc. You can use as much or as little as you want, but if you choose not too you need to invent your own way (that was what most distros used to do before systemd).

Also, integration between those subsystems (say, init systemd and cron) was basically writing glue code, while in systemd world they're meant to be integrated (unit files of any type can depend of each other, so you can have a service that depends on a timer, a disk mount and a udev event, for example).

So yeah, you may not like the way that systemd does things, but at least use valid arguments like the fact that things are more opaque (but this is understandable, this is an abstraction layer), or that the declarative approach of systemd makes some things harder (true enough, but you can always fallback to use scripts and you still have all the power of systemd dependency system).

> Another issue is that I think I've seen some linux systems don't launch the screen locker until resume, instead of locking before suspend; that's not ideal, because the screen locker will take time to launch and lock the screen (more so if it's got a fancy initialization routine and is a large binary/many libraries to load).

This particular issue is fixed in logind, when you ask it to lock the season/suspend/hibernate it first calls the lock screen, wait it to signal it finishes and them it proceed to suspend/hibernate.

Not saying you need systemd to fix this issue, but it is one of the things that systemd allows you to do correctly without reinventing the wheel.

Actually the original series is from Game Boy Advance, but the GBA games were never released outside of Japan.

Nintendo DS ports were the first one releases in the rest of the world.

BTW, I am a great fan of the series, really recommend it.

The author did address this later on, saying he was sorry for not adding a comment.

Anyway, no software development process is perfect, but sure the Apple ecosystem make everything worse.

I think it depends on what you're doing. Are you developing native apps with one or two person teams? iOS seems easier to start. Are you developing multi platform apps with teams of hundreds of engineers? Well, Android is much much better.

Just to give an example, it is quite easy to build Android apps in a CI, while iOS is a pain (specially because there is no way to build an iOS app in anything other than a Mac). Also, most bugs specific to a platform happens in iOS (they happen in Android too, but my experience is maybe 10 bugs in iOS for 1 in Android).

Not just Pixel, but most Android devices (both my previous Xiaomi and my current Samsung devices does this). I think it is probably part of Android CTS.

It just shows that this is possible, but we are talking about Apple here.

Did they known how to dry meat though?

Huh... This is interesting. Can I install packages using it?

Because AFAIK Apple doesn't allow installation of packages.

This is far from true. Unless Google removed the possibility of installing packages from third party sources, the situation in Android for *nix username is still far better than iOS.

AFAIK, iSH only runs in TestFlight right?

I also have many thing I don't like in every language I use, but I still use them because they're still useful. If we're talking about syntax for example, for me it is Clojure > Python > Elixir >> Ruby, but I know lots of people that thing Ruby is the most beautiful language on earth.

BTW, if we are talking about things that really goes on nerve for me it is the fact that Golang doesn't compile when there is unused imports in the module, so I can't simple comment a random line and try to compile it again. But I know people that like this because they editor are configured so the import is automatically removed. Ok I guess, but I still find this behavior annoying (I would much prefer that this was a compiler warning).

> In a purely functional language all four are purely functional, but this is (IMO) needlessly restrictive.

I concur. My two favorite languages nowadays (Elixir and Clojure) are far from being purely functional. They are functional enough that mutating state is awkward, but if you do need it it is there.

I also think having immutable data structures by default is a saner choice IMO.

> It leads to recursion where iteration is more natural, awkward choices of data structures or even plain impossibility of certain algorithms/data structures

Anecdotal, but I rarely use recursion/for loops, opting for defining auxiliary functions that works in one element and using map/reduce instead. Really, I don't remember the last time I needed recursion to solve a problem (for example, I know recur exists in Clojure, but I never saw it in the code that I work everyday).

I didn't say anything about types, but we use plumatic/schema as a "type system". It is not ideal (for once, it is checked at runtime instead of build time, so we only check types during tests and requests, otherwise the impact would be too great). It is not ideal, but it works and keeps our sanity.

> By "functions" here I mean "pure functions".

After programming for Clojure for quite a long time (~2 years), I fully share this sentiment. Using pure functions for business logic (and also using simple data structures instead of, say, classes and encapsulation) seems to generally makes the code more simple and maintainable in the long run.

> Of course the qualifier is "mostly": this isn't a dogma. Writing a 100% functional system ("going vegan", if you will) often requires you to jump through a bunch of extra hoops to get all the functionality you need.

Also this. Sometimes going fully functional makes things much more difficult, so a little of "impurity" is also fine.

This is actually something from Python's stdlib: https://docs.python.org/3/library/doctest.html

Really underrated.

Python can too, and I think most other languages are inspired by it.

https://docs.python.org/3/library/doctest.html

I am not agreeing with you, sorry. If they made good reviews, impartial reviews I could agree with you, but the way they do it nowadays could mostly be automatized (or at least do in a bulk, this is essentially what they do anyway in terms of quality).