m45t3r

Zero PulseAudio, just the `pipewire-pulse` daemon (that replaces it). Better yet, all PulseAudio clients that I tried just works (including things like `pavucontrol`).

I recently switched to PipeWire on NixOS 21.05 release. It was mostly seamless (except for some issues of not running it at realtime with rtkit, something that PulseAudio does automatically) and having access to new codecs like mSBC and SBC-XQ for Bluetooth is great.

It is very early though and lacks documentation like the article posted above says. Wouldn't recommend for everyone yet, but sure it is nice to see almost no issues in a project that is still on its early stages.

> The PSX did not age well.

Most games didn't aged well, however some of them are still impressive today considering the limitations:

- Chrono Cross: almost no loading times after the initial one.

- Crash Bandicoot: the graphics are still very charming, and there is almost no graphics 'jigling'.

- Valkyrie Profile: one of my favorite RPGs of all the time, and thanks to its 2D graphics and huge sprites it is still very good looking even today.

- Tekken 3: Very detailed character models and I think it runs at 60 FPS? Even if it doesn't, it is still impressive.

I am pretty sure that I can have injection attacks from unsanatized user inputs in any language.

Yeah it is, I can definitely type my SSID in any device that I have.

Parsing unstruted strings without escaping special characters is an issue in any language. This is completely Apple's fault.

Yeah, no user application should cause a blue screen of death or kernel panic under normal circumstances, unless it is either a bug or they're messing with something from the kernel (but in this last case, you generally need to run the program with high privilege anyway).

> For example, I wanted to just... create an arbitrary directory in my home directory (~/workspace). Does Home Manager do this? If so, how? Do I just have a shell script that is called within a package? That seems excessive. Is this not a use case for Nix? It looks like it can do arbitrary tasks across the system but the documentation is so bogged down with theory that it takes forever to find practical applications.

You are definitively trying to do too much at the same time. Before using Home-Manager (that is a community project, it is not endorsed by NixOS except by allowing to be hosted on the nix-community group on GitHub), I stayed at two years playing with only NixOS. It is only after I got comfortable with Nix and NixOS that I decided to migrate my configuration to Home-Manager. Not saying that you need that much time to use HM, just that HM assumes that you're know a reasonable good amount about Nix and NixOS.

So I would say, start with less: try NixOS first, it is kinda easy to use compared to other "advanced" Linux distros like Arch and Void. The easy things are really easy, the hard things can be really hard at first but I don't think you need to know much about Nix to be proeficient on NixOS nowadays. Also yeah, you will need to search some things, but since the scope is reduced it is easier to find answers.

I think there is Clojure and cloJure. The language is very different if you can mostly get by writing pure Clojure code, and another language altogether if you need to interop with Java constantly.

If you can get by mostly writing Clojure code (either by wrapping the Java libraries that you will use on helpers, or by using third-party libraries), it is a great language, even if in the end it is a very different from any other Lisp (but I'd argue that the changes are for the better, for example first instead of car, thread macros, protocols, immutable data structures). But yeah, for sure Clojure is much more optionated than any other Lisp.

Now, if you need to interop with Java code constantly, yeah, Clojure can be a pain. A good chunk of the code you will write goes to appease the alien structure that is the concept of Class on a FP language.

So now I am promoted to "Google support team" just because I bought to the discussion some observations from my own company? But you bringing your own observations does not put you on "Apple support team"? This seems completely fair /s.

Well, my point in the end is that even with all the issues that you pointed (some are true, some we didn't hit because we don't use those features), we still see more issues on iOS even when they're a smaller portion of our user base.

Heck, even if we got the most problematic Android phones for us (Asus budget phones comes to my mind), it is still has less issues than iOS.

You know, even if you're right we still see much more issues in iOS. For example, a simple Xcode minor upgrade can randomly break some flows.

> - Perfectly working code that needs to be rewritten just because

This issue is much more frequently on iOS than Android, since iOS deprecates features much faster and there is no compatibility layer between versions.

We have "been blessed" with OEM deviations from AOSP (we have a big number of clients and most of them are using Android because of regional characteristics), but still we have way more issues with customers using out-dated iOS versions than users on those devices. For comparison, we have way more iOS issues than Android ones, even if Android is the vast majority of our user base (~70% of our customers).

Anyway, even including those cases it is still very far from J2ME days.

We have many more issues supporting multiple versions of iOS than supporting multiple versions of Android. But neither are not even close to the nightmare that was J2ME.

I find it really bizarre that it takes hours to run whatever background process iOS has after an upgrade, especially because in Android's case this is AFAIK rebuilding the Dalvik bytecode while iOS should use a compiled language (ObjectiveC/Swift).

Does someone knows what is iOS doing at the background?

This is how Android shows it, and I think it is quite good because the phone feels slower while finishing the upgrade.

I write Python for years (including messing code) and never feel the pain I found when I edit an even a slightly complicated YAML file.

The issue is not really the significant indentation of YAML, it is more of the ambiguity of the syntax plus the fact that YAML is a serialization format so it doesn't have many ways to reduce repetition. Now those issues coupled with the significant indentation makes YAML a mess, but those issues doesn't exist in Python.

I think the point is that he isn't necessary living in Germany either.

Well, there is another reason for optimism: Wayland is supported in ChromeOS and WSL2, and it seems to be the base for any modern integration with other operational systems (macOS ARM maybe?).

> The sad thing: I've been hearing/saying basically this for decades.

I don't think Linux distros will ever be popular compared to the commercial OSes, since for one thing to be popular nowadays you need to invest money in many things like branding and marketing so something is mainstream.

But looking in another way, in the past I would say that desktop Linux was dying, and nowadays it is more live than ever, so this is something.

The fact that he said "people keep fiddling with the mask and they keep touching their face" is exactly what I said about context: we still used to think that using alcohol and disinfecting surfaces are more effective than avoiding direct contact (at least for the general public). We now know that this isn't the truth, disinfecting surfaces are barely recommended nowadays since we know that the virus is airbone so masks and social distancing are the recommendation.

Yeah, thanks for the correction.

The fact that they're not NULL terminated and the slices itself have length information is already a great improvement over C.

There is env -S that supports multiple arguments. This was always an extension available in BSD I think, and it is available now in recent versions of GNU's env.

Also, context matters. OMS avoided recommending masks at the start of the pandemic since no study showed the efficacy of it, and there was no mass production of masks yet. So recommending it for general population would only generate shortage of masks for those who needed (frontline medics and nurses treating the cases). So this is why they're so against it.

There is a big difference between OMS and populist leaders like Maduro/Bolsonaro/Trump.

What OMS said about masks and asymptomatic cases were the best we known about the pandemic at the current time (we still didn't have many studies on how the virus propagated). Once it became clear that masks helps and asymptomatic cases are super spreaders, OMS changed the tone quickly.

Populist leaders say things about remedies that study after study shown that there is no efficacy and they never change their tone because it would mean they're wrong. Instead, they simple jump for the next "miracle" solution.

Reference: https://twitter.com/Foone/status/1372945388664066061

I think non_sealed would be better than non-sealed though, because AFAIK there used to be no identifiers with hifen before.

This is very different from a sudoers file though. Apple has full control of how those things are configured, so they could easily migrate the values if they want, for example.

The fact that they doesn't shows either a malice from them, or at least very sloppy engineering/product management.

Because this kinda of attitude is really bad, and if it was a product from any other company (like Google) I am sure that people would say that this is proposital.

I am sure that a project that is 21 years old has much less bugs than a new project that had its first release one year ago, independently of the language.

Wouldn't busybox (GPLv2) or toybox (BSD) be a better choice than an very incomplete Rust rewrite?

To start, both of them were write with embedded applications in mind, busybox is feature complete since distros like Alpine and OpenWRT use it (not sure about Toybox, but I know Android ships it).

BTW, both of them cover way more tooling than coreutils too. Busybox for example have a primitive init system and a vi/vim clone. You can also of course disable them during build time.

I am just waiting the release of the next NixOS stable version, since the integration in the current stable version (20.09) is still lacking some important features.