Daemonless is a bit the linuxserver.io of FreeBSD to me. It is a collection of standardized images.
Behind each image you have a Containerfile [0] and a compose.yaml [1]
And inside the Containerfile for Gitea you simply have a `RUN pkg install -y gitea` [2], so basically here it is the good old FreeBSD Gitea port [3]
I guess this is really a Linux/Docker users friendly wrapper on the 30 years old FreeBSD ecosystem?
When I came from Linux to FreeBSD, Gitea was one of the first service I ran in a jail to learn how it all works. What I was happy to discover is I just need to do `pkg -j mygiteajail install gitea` to install Gitea in the jail with all the rc scripts, etc.
The jail abstraction was just one option (`-y`) in pkg ! This is really the beauty of the all integrated FreeBSD. So to be honest the Daemonless have, in some case at least, made everything more complicated in my view...
They could literally take their resources and spend time to improve LibreOffice and push for open data formats, supporting the TDF, but no, they listed a bunch of controversies on the software they chose and then decided to choose it anyways?
Sometimes I think the EU is ran by idiots, other times I am certain they are a bunch of idiots.
Very detailed and props to the security researchers, but the blog post has several indicators that it was written by AI, to which point I suspect their malware analysis was also done by a LLM.
I just wish it had more human interaction rather than have a GenAI spit out the blog post. It's very repetitive and includes several EM dashes.
It is harder and harder to trust any blog post anymore, the more AI there is. I used to read blog posts because of the personality and the precision level. Now both have been taken away.
It was in part written by a LLM, but I believe some of the analysis was done by humans. You can just check where there's proper punctuation and em-dashes in the commented code
I was just installing Sylve on my mini PC and an hour later, trying to find docs on how to setup some services, found out that the forums have been defaced.
LXCs are pretty similar to jails, and Sylve makes them really easy to use. One nice trick is that you can template a base jail and clone it any number of times straight from the UI, no need to drop into a shell and script it like I used to.
Another underrated part of FreeBSD is pkg. It’s often simpler than Linux package management. For example, installing Jellyfin on Debian or Ubuntu means adding a third party repo and dealing with updates, but on FreeBSD it’s just `pkg install jellyfin`. With pkgbase, even system updates are simple, just `pkg update && pkg upgrade` and you’re done, without worrying about breaking your system.
One problem with pkg and jails, is that there aren't good instructions for how you separate the "this is the current list of pkg and their status in the repo" from "this is the current list of INSTALLED pkg and their specific state and version in this host"
If this can be documented, and work with an exterior common pkg repo state, then every jail can be updated on pkg upgrade, for it's specific pkg, when the exterior state is updated for pkg update, to get refreshed for what needs to be updated.
Right now, under bastille, I do pkg update && pkg upgrade inside each jail and I therefore have n copies of the state of the pkg repo.
Trivial attempts at this wind up with every jail having identical pkg state. I don't want that: one for plex, one for vaultwarden, one for adguard, they should have the minimum attack surface of just the pkg and the necessary dependencies.
Er, Hungary had implemented this back in 2022/23 when the Ukraine war started. The title makes it look like it's the very first country to restrict how much fuel you can buy in one go.
When something like this happens, do security researchers instantly contact the hosting companies to suspend or block the domains used by the attackers?
First line of defense is the git host and artifact host scrape the malware clean (in this case GitHub and Pypi).
Domains might get added to a list for things like 1.1.1.2 but as you can imagine that has much smaller coverage, not everyone uses something like this in their DNS infra.
This threat actor is also using Internet Computer Protocol (ICP) "Canisters" to deliver payloads. I'm not too familiar with the project, but I'm not sure blocking domains in DNS would help there.
> Remember that you are programmers and you can just program, you don't need a framework, you are already using the API of an LLM provider, don't put a hat on a hat, don't get killed for nothing.
Programming for different LLM APIs is a hassle, this library made it easy by making one single API you call, and in the backstage it handled all the different API calls you need for different LLM providers.
I'd get it if it were a hassle that could be avoided, but it feels like you are trying to avoid the very work you are being paid for, like if a MCD employee tried to pay a kid with Happy Meal toys to work the burger stand.
Another red flag, although a bit more arguable, is that by 'abstracting' the api into a more generic one, you achieving vendor neutrality, yes, but you also integrate much more loosely with your vendors, possibly loose unique features (or can only access them with even more 'hassle' custom options, and strategically, your end product will veer into commodity territory, which is not a place you usually want to be.
> There's only two different LLM APIs in practice (Anthropic and everyone else), and the differences are cosmetic.
There's more than that (even if most other systems also provide a OpenAI compatible API which may or may not expose either all features of the platform or all features of the OpenAI API), and the differences are not cosmetic, but since LiteLLM itself just presents an OpenAI-compatible API, it can't be providing acccess to other vendor features that don't map cleanly to that API, and I don't think its likely to be using the native API for each and being more complete in its OpenAI-compatible implementation of even the features that map naturally than the first-party OpenAI-compatibility APIs.)
Msot do, but Anthropic indicates that theirs is "is not considered a long-term or production-ready solution for most use cases" [0]; in any case, where the OpenAI-compatible API isn't the native API, both for cloud vendors other than OpenAI and for self-hosting software, the OpenAI-compatible API is often limited, both because the native API offers features that don't map to the OpenAI API (which a wrapper that presents an OpenAI-compatible API is not going to solve) and because the vendor often lags in implementing support for features in the OpenAI-compatible API—including things like new OpenAI endpoints that may support features that the native API already supports (e.g., adding support for chat completions when completions were the norm, or responses when chat completions were.) A wrapper that used the native API and did its own mapping to OpenAI could, in principle, address that.
Wasn't this discovered already last week, on Friday, that the threat actor had replaced the legit images with malware images? And republished 75 out of 76 tags?
No, the actor reappeared. This article is not fully updated. On March 22nd, the actor compromised their DockerHub account and published new Docker images.
So much hassle to enable sideloading that I just... don't want to use Android? Having to go through 5 different menus, 3 different warnings AND wait 24 hours to install F-Droid? fuck no.
[0] https://daemonless.io/
reply