Kakao (hopefully) won’t get to know the real names of the developers, which will prevent them from suing the devs personally.
They could try to DMCA claim the repo, but Tachiyomi is completely legal, so hopefully Github won’t take it down. Github previously helped youtube-dl after they got DMCA notices.
If anyone’s wondering why Mihon looks slightly different than Tachiyomi, the reason is this is a fork of TachiyomiSY, which has some changes/features over Tachiyomi (e.g. a predicted next chapter release date).
What I wrote is all wrong. I’ve just looked through the commit history and Mihon is a fork of Tachiyomi and currently it doesn’t have any changes besides branding and being Android 8+.
I don’t know why I believed otherwise, but it might be F-Droids 3 months old Tachiyomi build, which lacked many features compared to up-to-date TachiyomiSY.
Tachij2kfriends, I saw the mihon dev post somewhere that tachij2k shouldn’t be used anymore. Is there a reason for that? Everything is still working on my end, and until it doesn’t I intend to just keep using tachij2k unless there’s a good reason not to. I also read somewhere that the Dev for j2k said he was gonna make some changes, but I wasn’t able to verify that… Anyone know anything more? Thanks
If it works on your end, no reason to stop using it. The reason they suggested to move elsewhere is because, at the time, there was no indication that j2k had any plans for continued development. Might’ve changed since they put that out, but that’s what they sajd
The reason the Mihon de said that is because j2k is using an older tachiyomi base iirc. Updates on it have been on the slower side.
It’s still being actively worked though (as far as I know) and it still works fine, so there’s no reason to switch off of it for now. If Jay does drop it then you should move onto mihon or its forks (TachiyomoSY and TachiyomiAZ will be based off of mihon in future versions).
It’s simple. Go to Tachiyomi and create a backup. Then, in Mihon, during the first setup, it should give an option to restore backup. You can also resotre backup in Mihon settings, then go to extensions and (trust) the restored extensions.
It’s pretty much the same app at its core. So no need to change file names or formats. Everything should transfer.
This is interesting to me for my use case scenario, specifically SteamOS.
What I’m trying to do is run an emulated Everquest server (lookup EQEmu). The community there has several methods of installation of the server, Windows, Linux, and Docker. The hurdle to overcome is the immutable file system, specifically when it comes to the database (MariaDB). I think I may have found a work around via Linux brew and installing MariaDB through that (which I’ve done, I just have to make the final connection). However the Docker setup, when running it on a separate distro is stupid easy. If they make this a Flatpak, it can potentially be the solution I’m looking for.
Really the end goal is creating a Single player Everquest. I have a dual boot with it operating via Windows, but would much prefer to have it on the SteamOS side of the house.
Docker Desktop ≠ Docker Engine, and I think what you (and several in this thread) are thinking is actually Docker Engine. Docker Desktop ultimately includes a Docker Engine inside, but it does not appear you need that virtual machine (e.g. running non-Linux code). See: docs.docker.com/desktop/faqs/linuxfaqs/#what-is-t…
Docker Desktop is based on KVM, which already works with Flatpak. So this is not something new. For example, GNOME Boxes is available as Flatpak and provides a way to run KVM guests in SteamOS.
Starting with version 3.5 (the current stable) SteamOS already includes Podman with the default installation. And running the daemon-y Docker Engine “bare metal” is not going to be any easier with the immutable filesystem. While Docker Desktop solves this by using KVM, it adds another layer with performance loss, vs. just running Podman containers.
So what you want is already available, and no Docker Desktop is actually needed.
But so if Docker Desktop does include Docker Engine, does that mean I wiill now be able to run Docker (with a some performance loss) simply by installing a Flatpak, i.e. I won’t even need to touch the CLI?
Yes. If you mean “CLI” as for e.g. pacman install, it is a GUI (Electron) application, so I expect will install straight from e.g. KDE Discover and then run without you touching the shell.
Installing podman-compose with the immutable filesystem is fairly straight forward, since it is just a single Python file (github.com/containers/…/podman_compose.py), which you can basically install anywhere in your path. You can also first bootstrap pip (python3 get-pip.py --user with get-pip.py from github.com/pypa/get-pip) and then do pip3 install --user podman-compose.
I would suspect that making a stable desktop inside docker ensures it would work everywhere else, no matter what the hw/sw of the host is.
I've only known docker as a building environment that ensures rebuildability and I can't say I ever liked it. I think its popularity comes from some myth of safety and security.
I couldn’t possibly care less about Docker Desktop. Portainer is a much better solution when graphical administration becomes necessary. (Which should be never)
I don’t use SwiftKey, just tested it because you shared a tool for doing it and claimed it was able to subvert Android permissions.
You probably didn’t actually disable the permission – like I said, the idea that an app could get around system-level permissions like that, in a way you could plainly observe would be headline news. It would be astounding that you somehow uncovered something that massive.
there was some interest in my lug with the different schedulers but attempts at benchmarking all fell within margin of error from our lay attempts at measuring
I usually interpret the phrase “drop in” to mean that the replacement being referenced will also work with everything written for the original. Does “drop in” in this case mean that Immich will transparently replace Google Photos, similar to how libretube replaces YouTube? That would be amazing!
It’s undergoing massive development, it basically went from nothing to nearly full featured in two years.
The breaking change just means you need to actually do something before updating. The software isn’t quite ready to be put on auto-update yet. Honestly the way the devs aren’t afraid to break things I think has contributed to the fast development.
Just be sure to keep a secondary backup of your photos which you should do either way.
github.com
Active