I’m sure this is completely unrelated to android’s recent decision to require all app developers to register with google, even if they aren’t distributing apps through the google play store: https://keepandroidopen.org/
Shizuku was how I was thinking of bypassing this for now, taking advantage of the local ADB connection and then using that to install apps instead of the normal package installation flow. But it looks like they want to take that away too.
Yes, Conda, not Anaconda. It uses Anaconda’s repos by default, which are bound by these terms of service: https://www.anaconda.com/legal/terms/terms-of-service , which require you to pay for commercial use if your org has more than 200 users.
Although it looks like if you only use conda-forge, or alternate repos then you should be good. It looks like miniforge, which does use the conda package manager, was made partially with the goal of avoiding these licensing issues.
https://isitreallyfoss.com/projects/conda/
The code for conda is all open source, but the default repos are provided under terms that prohibit commercial usage. Anaconda baits you into using it since it’s “free”, then sues:
Technically you could find alternate repos, but this is the kind of thing that should be mentioned on pages like this.
This is a pretty good question, and I can’t really tell. Based on some research, it looks like the OG Xbox was actually based on Windows 2000/NT, and modern windows is based on NT as well, so it could theoretically be a translation layer. It could also even be a straight port with no emulation.
My guess is that it’s a translation/compatibility layer + game specific optimizations/fixes. If it was a solution that worked more generally, then why wouldn’t they put more games on there?
Or, it could be that those games are easiest to support under the emulation/translation layer, and maybe it will be expanded to all games shortly like Wine is?
Firstly, did you get it working? I notice your latest commit seems to mention that you got it working
One thing I would recommend is to declare the iamb package separately in a let... in statement.
let
iamb = (mknixpak blah blah blah)
....
....
userconfig.programs.iamb = {
enable = true;
# By using "iamb", instead of pkgs.iamb, it means we are using the nixpak wrapped version here
package = iamb
settings = {
profiles.user.user_id = "@innocentzer0:cyberia.club";
settings = {
image_preview = { };
username_display = "displayname";
user_gutter_width = 15;
};
};
};
This make it so that iamb is the nixpak wrapped version instead, in the userconfig. This would probably also make it so that you don't need to declare it explicitly in your systemPackages.
Performance, it’s slightly slower compared to Bun, but it is faster than Node. But it has sandboxing, which is neat.
Deno is pretty interesting because it has built in sandboxing. By default, no code can even access the network. Everything must be explicitly allowed, including network access and environment variables: https://docs.deno.com/runtime/fundamentals/security/
Access can be scoped pretty granularly as well, only allowing access to specific websites or env variables.
I really like this model since it offers a strong protection against secrets stealers, which have hit NPM extremely frequently. No more of malicious NPM packages scraping the whole system to find secrets.
It does have a performance tradeoff compared to Bun. Bun is (was?) the fastest, Node was the slowest, Deno was in the middle.
First check if your machine is compatible with either. It’s probably not.
Yes, I do lock it down. It’s still worth securing it because “internal servers” can still get exposed and touched, even though there are less paths to them, and it’s not as punishing to slip up vs a public server. For example, One of the wireguard client devices downloads a virus, and now you have a cyberattacker with access.
Another problem is supply chain issues. If the distributor of a docker container is hacked, it’s not that bad… as long as your kernel is up to date and is protected against some of the recent vulns, that would enable someone to break out of a docker container
Blajah.zone’s lemmy instance was hacked partially becuase internal servers weren’t being held to the same security standards as the public ones:
https://pen.blahaj.zone/supakaity/weve-been-hacked
I had not patched these internal servers that nobody should have access to against this. Rebooting DB servers causes downtime, and in my hubris – I thought nobody should (nay COULD) be on my servers except me, right?
I have a comment on that post with some potential solutions, that would have cut off attack paths.
Though, I guess, it still does depend. Like if it’s just gonna you wireguarding in and no one else, then the data on your devices is probably worth more than the data on the server, so no, it wouldn’t be worth spending too much effort to secure less valuable data.
But if you are handing out internal access to people, including to some relative who keeps falling for scammers, then yeah, I’d take some time to harden the systems.
I used to use innoextract to extract the launchers, and the the system wine to run it. Although sometimes I have to run extra installers that put dlls in the right spots.
You should probably just run the installer in lutris (which ships a proton distributution) or bottles.
Edit: I can’t read smh my head.
Check this out: https://github.com/lutris/docs/blob/2b116519c5b67254733234f36ab33a60f14f1358/WineDependencies.md
Maybe this?
https://github.com/risujin/cellwriter
It’s the only thing I found in this list here: https://wiki.archlinux.org/title/List_of_applications/Utilities#On-screen_keyboards
Last updated 9 years ago though…
I am trying to use nix and firejail only, but it is pretty rough and barely documented which is kinda insane as firejail is THE tool. Unlike crabjail, bubblejail and what else is out there
I was investigating sandboxing with Nix. Here is a dump of my saved notes:
https://todo.sr.ht/~alexdavid/jail.nix
Projects to sandbox AI agents:
https://github.com/archie-judd/agent-sandbox.nix
https://github.com/myme/jaillm/blob/main/flake.nix
https://github.com/gfauredev/nix-agents-jail
https://github.com/azuwis/fence-agent.nix
github.com/kohane27/jailed-ai-agents/blob/main/llm.sh
Someone told me that if you take these things and then replace the entrypoint with bash, you get a sandboxed shell environment
Not everybody does. It’s just sometimes.
If the tarball was dynamically linked against specific distro’s libraries though, then it wouldn’t work on all distros.
They also often provide RPM packages for Red Hat systems. Not always though, and I use Arch (btw) anyways.
distrobox/toolbox
Distrobox excels for when you need some proprietary tool that ships it’s packages as a repo for Ubuntu but not much else. You spin up a distrobox for Cisco Packet Tracer, or VSCode (the proprietary microsoft one, not Arch’s Code-OSS and Unity.
Then, once you’re done, you can just delete it all.
nix doesnt have any of these, but sandboxing is hard, there is either stable or unstable, changing and configuring things is very complex. Likely no official packages. Still the method I prefer.
Nix is what I use, and it was frustrating to have to hack a lot of it into place, but I feel like it has the most potential. Unfortunately the flakes nonflakes split, in combination with the split of “distros” like determinate nix, flox, and so on, and the governance concerns really hold it back. It has horrific documentation, for the most part caused by the above (flakes are “experimental” and so can’t be included in official docs), and it is frustrating the lengths I have to go to to make stuff work that should be easy.
For example, GPU acceleration of Nix packaged apps on non Nixos systems. I figured out how to do it:
(config.lib.nixGL.wrappers.mesa pkgs.gzdoom)
But I think it’s just straight up impossible to do this via imperative package installs, outside of home manager. And it’s kind off important if you want any GUI app whatsoever to work.
But now that I have it working, I use Nixpkgs exclusively and am able to avoid the AUR entirely. To me, the AUR is a last resort, only for something like say, system level printer drivers (thankfully I’ve never needed to install anything to get printers to work). By ensuring that I only use the AUR once in a blue moon, I can make sure that I actually review the PKGBUILD when using it.
They are probably referring to the way that snap, flatpak, and distrobox are available as official packages in most linux distro’s repositories, whereas nix isn’t. I have encountered this frustration for sure. Debian and Arch provide nix packages, but many other distros don’t.
In addition to this, nix requires manual setup if you install it from the repos, which is annoying. And then you have to do further manual setup to enable flakes, and then you have to figure out how to install packages and it’s not fun.
So the main way people install nix is via the curl | bash scripts various “distros” of Nix provide.
Good practice exams will often be harder than the original test. Teachers do this in order to ensure you are prepared. If the practice test is harder, then the real test is easy. This is a pattern that I have noticed even in my college classes.
n reddit (ew) discussions are always making it like some terrifying thing.
To someone that doesn’t know that they are using Windows, yes, the tests will be terrifying and difficult to study for. Often people are scared of computers and technology, and actively avoid knowing. But now, they will essentially have to cram a massive amount of information, since they are starting from scratch. And for those trying to break into cybersecurity from nothing, that is a common scenario.
For people who already know what a virus is, and how to spot phishing links, the test will be a lot less of a struggle. Now, you should study, in order to figure out gaps in your knowledge compared to what sec+ covers, but it won’t be a nightmare.
clicks profile
Love computers, art, and nature.
You actively like computers instead of being scared of them. So I don’t think you’ll find the test terrifying.
Corelight are the zeek developers. It’s the same author, as well. They probably decided to double publish.
https://yacin.nadji.us/about/