m45t3r

Yeah. I had a LG G Pad 8.3 (2013) that I used as much as last year until the screen separated from its body and started to fail as an effect. Was using it with LineageOS (don't remember the exactly version, but it was either Android 9 or 10), and it also allowed to tweak the scheduler so the CPU would always run at pretty much the maximum speed. The battery life was obviously bad but would still get one day of reading/watching videos (that was pretty much the main usage I had for it), and thanks for the tweaked scheduler the UI was not that laggy (it was laggy, but not worse than an actual low-end device).

Also, different from iOS at least Google still pushes updates for important parts of the system (Chrome, WebView, etc.), so at least for casual navigation it wasn't horrible insecure.

Yeah, but I think the question was why EOF and "\n". It could as easily just return 1 or -1 for example, and it would make more sense I think.

BTW, there is a Firefox module in Home Manager for those who want a customizable Firefox. Like, I set my custom `about:config` flags there and every time I reinstall my system I am sure that I didn't forget that random config to enable hardware acceleration again. You can also manage extensions with it, but for this part I prefer to use Firefox Sync itself.

At least for me, this is even better than backup/restore. Generally I don't want to preserve cache or cookies between installations, I just want my config there.

> The problem I'm trying to solve is the system getting messy over time - accruing multiple versions of runtimes for programming languages, system configuration changes, pinned library versions etc., all because every other project needs some OS tuning or system-wide dependency. Eventually, I always end up hitting a roadblock where something I need now is incompatible with something I changed 2 years earlier no longer remember why. So I'd like to keep various projects and activities isolated, and to be able to just get rid of them when they're no longer needed.

Don't worry, this issue is solved with Nix/NixOS itself.

If you use `nix-shell` to setup an dev environment for which project, you will generally have a `shell.nix` or `default.nix` file in the same directory as the project. For example:

    with import <nixpkgs> {};
    mkShell {
      name = "myProject";
      buildInputs = with pkgs; [
        gcc
        python39
        lua
      ];
    }

And once you use `nix-shell` inside the directory that contains this file above, it will download GCC, Python 3.9 and Lua, and put them on PATH. If you do a Ctrl+D, it will exit this shell and you won't have those 3 programs in your PATH anymore (assuming of course that you don't have them installed in your system).

BTW, this is where `nix-direnv` enters: it will do the `nix-shell` part and Ctrl+D management automatically for you. So once you enter in the project directory, it will automatically activate the `nix-shell`, once you exit, it will automatically exit `nix-shell`.

The Python case is specially interesting because if you have Python 3.7 in your system PATH, this shell will override the system Python, so only in this project you will have Python 3.9.

To avoid re-downloading them every time, Nix will actually cache those dependencies. So to really remove them from your system you will need to run the garbage collector (`nix-collect-garbage -d`), but since they're not in your PATH they will not conflict with other packages in your system.

It is something similar to NixOS (however in this case this is system-wide):

    { pkgs, ... }:
    {
      environment.systemPackages = with pkgs; [
        gcc
        python39
        lua
      ];
    }

In this case, GCC, Python 3.9 and Lua will be available on your system PATH after you do a `nixos-rebuild swtich`. If you remove them they will be deleted from the system PATH after running `nixos-rebuild switch` again, creating a new generation.

The generation part is important: in case things break, you can go back to the previous version using `nixos-rebuild switch --rollback`. So let's say you changed Python 3.9 to 3.10 on your system but it actually broke something important (let's say it is a script that is important for your desktop, so now you don't have a desktop anymore): you can just call `nixos-rebuild switch --rollback` and everything will go back to working again, and afterwards you can commit your changes and run `nixos-rebuild switch` to commit them.

> What we dislike is everything talking about the costs, and not the benefits.

Exactly. I tried to push really hard our company to use Nix/NixOS (and maybe in our case nix-darwin too, since the majority of engineering uses macOS), but it never went anywhere (I did convert a few of my colleagues to use NixOS though).

But why? Well, onboarding is a pain in my company. We have some Ansible scripts that always break in some innovative ways, so it takes a whole day to setup a new machine for a bunch of engineers. Sure, partly of the fault is the fact that our Ansible scripts are really hacky (in some steps they still call some Bash scripts instead of using Ansible DSL for example), but Ansible is simply lacking in some places to have a really pleasant experience.

If we could use NixOS though, this would be a very different matter. I use NixOS in the same company, had the same configuration for pretty much 1 year, and also survived a broken laptop and setup my whole setup in like 30 minutes (most of time spend downloading packages actually). I even separated part of my NixOS configuration in another repository so other engineers using NixOS can also make use of it.

Yeah, it took a long time to get where I am currently, but nowadays I just stopped worrying about managing system, system update breakages, and anything like this. I can just use my system, fully up-to-date, and I know if something breaks, I can revert. It is beautiful.

BTW, thanks @easygenes. It is really much better nowadays (that goes to show how fast Nix/NixOS is improving).

I don't think it is fair to judge a project for the number of years its been around, specially for something that is really novel and innovative. Nix/NixOS is not a new web framework that most of concepts are really clear for everyone working with Web. It is a brand new concept for Operating Systems, however most people don't have a clue about system immutability and reproducibility and why this is so hard.

Of course, this doesn't excuse the state of the documentation that should be better. It is just that nobody ever documented this kinda of things before, so it is difficult to do it better.

Nix and NixOS just started to get more known and become popular from the last ~5 years or so, and I think this made the whole community aware that documentation is an issue and it is getting better and better (but maybe not at the pace most people wanted).

This is exactly what I meant with "there is one but it is slow and limited last time I tried", but it does seem that they made good progress (the last time I tried it was some months ago).

Time to try it again.

> Is either #NixOS or #GUIX usable as an OS for day-to-day use (coding, browsing, occasional gaming)?

Yeah, definitively. I use only NixOS on all my machines for about 3 years already. My machines are working so well nowadays that I rarely have to change anything [1], even during major upgrades (between stable versions).

I don't fear anymore if a machine could break tomorrow. I know that it will be very easy to restore it to a working state. Last time my working notebook broke I didn't even bother making a backup (except from some data on my Home), just installed my config and it worked exactly it was working before. Also, I don't fear changing my system: if something brokes after the changes, I can just rollback.

I use for all those three purposes, mainly coding and browsing, but some light gaming. Steam actually works better on NixOS than any other distro I tested before thanks to the isolation that Nix provides.

> a question on dev environment isolation. [...] Or is it better to just use their respective package managers on top of regular Linux?

I imagine those are part of the same question. Generally what I recommend for newbies is to start small: yeah, it is fine to continue using your respective package manager, specially if you don't need "native compilation" [2].

After you get more experience with Nix though, I would recommend you to start isolating your development environments. Nix has its own `nix-shell`, that it is kinda bare-bones but works well, and can be very practical once you use something like `nix-direnv` (https://github.com/nix-community/nix-direnv/). There is also this `devshell` (https://numtide.github.io/devshell/intro.html) project that is interesting.

> Also, anyone here doing desktop #virtualization? Is there a sense of running a #VM per project? Is that a viable alternative to dual-booing Windows when I want to do some Windows dev or play a game?

I put those two questions together because yes, I ran desktop virtualization on NixOS, and yes, I ran Windows on a VM to play games thanks to PCI-e passthrough (my dedicated GPU is connected directly to the Windows VM so the performance is near native) [3].

Again, I will not recommend you do to this right after starting NixOS since it is one more thing to possible frustrate you, but just so you know that it works and works well, specially because my VM configuration on NixOS is also on my `/etc/configuration.nix` and it is fully reproducible. Coincidentally I was messing with my VM settings yesterday and "broke" my VM multiple times, however I just run one command and restored it to the previous state.

However I never bothered to dual-boot NixOS/Windows, because I barely use Windows nowadays so I find rebooting my system just to use Windows bothersome. Probably not your case, so maybe dual-boot makes more sense. This article should help and seems very easy to do (again, disclaimer, not tested because I never needed it): https://nixos.wiki/wiki/Dual_Booting_NixOS_and_Windows.

About the VM per project, unless you want to do this for some other reason (security maybe?), you don't need to. As I said before, you can use things like `nix-shell` and this will already give isolation enough for development purposes.

---

Some closing words: remember, start small! Nix/NixOS is a journey. You will learn eventually what you need. However, if you try too many things at the same time you will feel frustrated. The official documentation is good, however it kinda assumes that you know what we are talking about already, and it is also very big and not well separated in steps, so it feels overwhelming for newbies. To supplant this there are many blog posts, however some of them are out-of-date (it shouldn't be too much of an issue though, since Nix tries really hard to backwards compatible).

You will eventually need to learn the minimum of the language to read the source code. It is less difficult than it seems, because while Nix as a language is strange at the first glance, it is a very well designed DSL for the domain. After sometime editing your own configuration you will naturally learn the Nix language, and can start to understand what is happening.

For where to start, I recommend trying to replicate your current system in a NixOS install. If you already use another Linux distro try to get the same desktop environment and packages that you already use. If you're coming from Windows/macOS try Gnome or KDE. Just tweak the system until you're happy with the result. Eventually try Home-Manager to manage your Home configuration in the same way as in NixOS (fully declarative), and once you feel happy, you can try Flakes (making you configuration fully reproducible). This process can takes months or even years, but don't bother or rush, just continue your journey. It really pays off in the long run.

[1]: well, I am on a "coding spree" right now so I am doing many changes, most to refactor some things that I wasn't happy before; but before this coding spree my configuration didn't change significantly for almost a year.

[2]: what I call having to compile C/C++ libraries in an another language like Python (giving it an example here, almost any language has a similar mechanism since C/C++ ecosystem is huge), that generally needs to dynamically link with whatever you have in your system installed. This is possible on Nix/NixOS, and easy once you know what you're doing, but it is different from anything else so it does trip newbies.

[3]: if you're interested on this approach, I used this guide when started: https://forum.level1techs.com/t/nixos-vfio-pcie-passthrough/.... To get it fully reproducible it though, there is no way on NixOS itself yet, however there is a good guide here: https://nixos.wiki/wiki/NixOps/Virtualization#Setting_Up_the...

> Crazy thing about NixOS is that it's so good, all the bad parts can be excused. I like to go on forums and complain about how the Nix configuration language is horrible, and there's not much documentation on how to get general things done.

I don't think it is fair to say that Nix as a programming language is horrible, IMO, as a DSL it is pretty good and fits the domain well.

It is a strange language at first and it takes some time to learn all its quirks. Also, it lacks better tooling, things like LSP for example (there is one but it is slow and limited last time I tried). But just claiming the language is "horrible" is really unfair.

> It is, as far as I know, the only cross-distro package format that is designed to be cross-platform (desktop, server, IoT) and with built-in sandboxing. Moreover, it is feasible to base a distro off of snap alone (Ubuntu Core, designed for IoT).

It is not really cross-distro though, since different from Flatpak, Snap assumes many features to be enabled for sandboxing to work (like AppArmor [1]): https://wiki.archlinux.org/title/Snap#Installation. Flatpak only assumes, AFAIK, user namespaces support on Kernel.

[1]: This can be really problematic if your distro is using other MAC like SELinux, since while they're really not designed to run together.

As you said before, you can use tabs. You just need to use tabs everywhere (on Python 3, on Python 2 you can pretty much mix tabs and spaces, however this is a very bad idea).

Yeah, Python even support tabs. On Python 2 you could even mix tabs and spaces, but this turned out to be a very bad idea.

So Python 3 enforces that the whole file uses either X number of spaces or tabs, you can use either of them.

Before MangaDex we had Batoto (the old Batoto before some sketchy company bought the name), that was kinda of the same: serving high quality manga for most scanlators that wanted it (and also avoiding hosting pirated chapters from official sources, so kinda the same as MangaDex nowadays). As far I remember Batoto closed because of pressure from companies and also because of the high costs related to run the site.

So yeah, considering how fragile maintaining a site like this is, it is always a good idea to sync your progress in a third party so it is easier to migrate if something goes wrong.

> And while it works fine for reading, it kills any interaction with the hosting sites. No chance for monetization, socialization or anything else that can help sites survive long-term.

BTW, MangaDex doesn't have monetization because it is strict a hobby and also because it is a gray area to monetize about this kinda of work [1]. Also, their Tachiyomi client is official (MangaDex v5 API was tested primarily via their Tachiyomi client before they finished the Web interface).

[1]: both for companies (that has the copyright from the works hosted on those sites) and the scanlators (the fans that does actual work of translating those chapters). Sites that host those chapters and monetize are pretty much monetizing on work from other people.

Nice, didn't know about this (there isn't much information about MD@H after the rewrite).

BTW, how can I register my VPS on MD@H? Before we had a dedicated form on the page to register interest, at least after the rewrite I didn't find it. Is it only using something like Discord?

They're probably more limited by bandwidth than requests per second, but anyway you look the number of requests are still impressive considered the budget.

BTW, the site is not just fast: they serve images on high quality (same as the original [1], that can be multiple MBs per page [2]) at an pretty impressive speed too.

[1]: before someone asks why they don't optimize the images, this is by design since they want to serve high quality images. There is an optional toggle to reduce the image size, but this is disabled by default.

[2]: for those not familiar, the average number of pages on a manga is something like ~20, and this can be read in ~5 minutes depending on the density of the text. So you can easily consume 50MB+ per chapter.

There is the MangaDex@Home, where users can serve part of disk space/bandwidth to help serve (mainly old) manga chapters. It does need to be something that is running 24/7 (e.g.: not a PC that is shutdown frequently), so something like a VPS or a service is recommended.

> I hope this doesn't displace Samba.

It doesn't seem to be the objective. For one, this is a very old version of SMB protocol (v3, while SMB doesn't have big releases anymore the current one is v4). Also, Samba have the user space tooling that this project explicitly doesn't want to reimplement. And it seems that both implementations are compatible with each other.

It does seem to me that the main objective here is to have a very efficient implementation of SMB for embedded devices.

> Hate to break the news to you but the Canadian healthcare system collapsed a long time before Corona. Just ask anyone who has been to a hospital in Toronto before Corona.

And the solution for an already collapsed health system is to overload it even more with a pandemic, right?

Exactly. It is kinda obvious that someone is doing something wrong with the code when they're doing a generic catch (sometimes it is fine, but this will at least raise some eyebrows).

However it is very easy to do the wrong thing using Golang. Just one random library doing `fmt.Errorf` without the `%w` verb is sufficient to lost all information from there on. I would much prefer some kinda of annotation that does the correct thing by default (wrapping the error) instead of the "every error should be explicitly" approach of Golang.

> The letter goes on to note that Xsolla has partnered with multiple HR agencies to "help you find a good place where you will earn more and work even less".

Sure, if I worked on this company I would like this option even if I was considered a "engaged employee" by their own classification.

Double check that you're running PipeWire with rtkit (this is the default with PulseAudio, AFAIK it is not the default yet on PipeWire).

It is really important to run a sound daemon with realtime privileges. This is the only way to ensure no cracks.

Probably TLS version and maybe Google wants to drop Google Play Services from very old devices?

Yeah, sorry, what I meant was that in conclusion it was better to be vaccinated considering the studies we have (not a TL;DR).

However there are many more studies of variations for vaccinated people than for natural immunity. It may be because the laboratories themselves are interested commercially for those studies, while natural immunity doesn't bring them any commercial benefit, but this doesn't change from the information we have right now.

So TL;DR, it is just better to be vaccinated right now.

Yeah, probably. Kinda like a Xbox Series/PS5 CPU lite.

Unless a big vendor (coff Microsoft coff) decides to enable it by default, them it becomes meaningless.

Even on Windows you wouldn't release a game that works on Windows older than 10 nowadays, you can assume a reasonable up-to-date distro. I am quite sure Steam Runtime works at least as far back Ubuntu 16.04, the oldest distro that I can think someone would want to run Steam on it.

> multiple monitors

If both monitors have similar configuration (DPI, refresh rate) it is fine (Xrandr fixed many of the issues that X previously had). If the monitors have different configurations it isn't, but this problem will reflect even on the desktop and I am sure that nobody will report a problem that they have on desktop as a "game bug".

> full-screen programs

X doesn't have a concept of full-screen, but anyway, it mostly works fine if you grab the root window (that of course you shouldn't write code manually to do this, your game engine probably will do it for you automatically).

> low-latency input

X latency is fine for most games, and in many cases you will not use X to handle input anyway. Also, if your game really needs low-latency (only a minorit of genres do), you can bypass X.

Anyway, I was not referring to specific X or PulseAudio problems that you will if you put things on container or not. I am just saying that even if steam-runtime doesn't built-in those libraries it is not much of a problem since those APIs are stable.

Both PulseAudio and X.org are in general stable, don't know about Wayland but I don't think many games target it yet.

The major issue is OpenGL drivers, they can be a pain on Linux (specially proprietary ones like NVIDIA).