No, I think if you’re using the nextcloud all in one image, then the management image connects to the docker socket and deploys nextcloud using that. The you could be able to update nextcloud via the web ui.
https://github.com/nextcloud/all-in-one?tab=readme-ov-file#how-to-update-the-containers
I read through the docs. I’m not sure how this enables trusted computing.
There is concern amongst critics that it will not always be possible to examine the hardware components on which Trusted Computing relies, the Trusted Platform Module, which is the ultimate hardware system where the core ‘root’ of trust in the platform has to reside.[10] If not implemented correctly, it presents a security risk to overall platform integrity and protected data
https://en.m.wikipedia.org/wiki/Trusted_Computing
Literally all TPM’s are proprietary. It’s basically a permanent, unauditable backdoor, that has had numerous issues, like this one (software), or this one (hardware).
We should move away from them, and other proprietary backdoors that deny users control over there own system, rather than towards them, and instead design apps that don’t need to trust the server, like end to end encryption.
Also: if software is APGL then they are legally required to give you the source code, behind the server software. Of course, they could just lie, but the problem of ensuring that a server runs certain software also has a legal solution.
I think the bigger issue is the copyright violation. You can’t just take others code and change the license. That’s not how it works.
Stenzek did not do this. He either got permission to change the license of gpl pieces from their original author, or rewrote them. The edit by Leah in her post fails to acknowledge this, but it should be noted that she states the situation has a lot more nuance, and that she is trying to convince steznek to keep duckstation free software, rather thab threatening legal action against him.
reached out to the bigger community for support.
Like Near/Byuu did? And how did that go?
Although, I do agree, and I would rather have free software. But it’s clear that Duckstation going proprietary is his attempt to boycott the retroarch developers.
UPDATE on 15 September. I’ve had a talk with Stenzek. This is an evolving situation with a lot more nuance to it than first glance. The decision to make DuckStation proprietary is still terrible, and I intend to rectify this; I’ve proposedh a number of ideas to Stenzek for how to effectively retain DuckStation as a free software project. If this is unsuccessful, I’ll fully fork it myself (from prior to the re-licensing) and probably find people in the PSX scene willing to help maintain it (in that scenario, my role will only be to facilitate and provide infrastructure, while not having an active role in core development, as I already have my Libreboot project which takes all of my time). I simply wish to prevent what is currently the best emulator of its kind becoming proprietary software.
I hope she’s aware of why the Duckstation dev decided to go proprietary: An ongoing harassment campaign by Retroarch.
There is a post by Near/Byuu that documents some of the retroarch developers problems, and some of it is especially damning. I read through some of the leaked IRC chats, and they refer to Near by homophobic and racial slurs (the n word, yes), and this behavior clearly hasn’t stopped, given Steznek’s abrupt and harsh reaction.
On another thread related to this, I mentioned that many people theorize that Talreth (developer of AetherX2, PS2 emulator for android), and Steznek (Duckstation) are the same person. Although there is not hard evidence that they are the same person, their stories parallel in that both of them took code offline because of persistent harassment.
Leah Rowe taking over a fork of Duckstation is nice, but it doesn’t really do anything. People were already going to fork Duckstation, and the Retroarch team did — in the form of SwanStation.
She notes this in the email she sends:
I would also point out that a fork of DuckStation does indeed exist:
I posted about all of this on my Mastodon. Please see the following post:
Unless the DuckStation author changes the project back to GPL, I would suggest that you all boycott the project, and tell others to do the same; you could send all future contributions to SwanStation instead, which is part of libretro. I would suggest that all future works go to a fork (could be SwanStation), instead of DuckStation, while still permitting Stanzek to contribute; this way, any future abusive re-licensing could not realistically occur. The reason I say this, is because based on my own research, it seems that Stanzek’s bios against the GPL has existed for some time, so I’m uncertain as to whether he could be trusted in charge of a public project.
But, in the github reply by stenzek
I find it especially ironic, considering when the GPL was actually violated on multiple occasions, even as recently as a few months ago, nobody ever takes issue with that.
I like free software too, but this stuff doesn’t exist in a vacuum. I think this and her attempts at action, even with the edit to the post, are premature. Her taking over a fork of Duckstation is nice, but I think she, a transwoman, needs to remember why the Retroarch devs harassed the shit out of Near/Byuu: Because they were nonbinary.
If she does decided to maintain a fork of Duckstation, I hope she has a plan that allows her to avoid falling victim to the same harassment that eliminated Near, Talreth, and Steznek. Because while a Playstation emulator is nice to have, Libreboot is essential to obtaining a truly free software society.
deleted by creator
There was no CLA. The duckstation dev rewrote all gpl code, or obtained permission to change the license.
So, officially no. But there are ongoing theories in the r/emulationonandroid subreddit that they are.
I think it could be either way, but it’s unlikely that they are the same person. In both cases, harassment caused them to shut there projects down, which could be a reasanobale coincidence, or could be indicative of a larger harassment campaign.
Crowdstrike didn’t target anyone either. Yet, a mistake in code that privileged, resulted in massive outages. Intel ME runs at even higher privileges, in even more devices.
I am opposed to stuff like kernel level code, exactly for that reason. Mistakes can be just as harmful as malice, but both are parts of human nature. The software we design should protect us from ourselves, not expose us to more risk.
There is no such thing as a back door that “good guys” can access, but the bad guys cannot. Intel ME is exactly that, a permanent back door into basically every system. A hack of ME would take down basically all cyber infrastructure.
Cal state northridge?
https://wiki.archlinux.org/title/List_of_applications/Internet#Pastebin_services
That pages shows how to use curl to upload to 0x0.st.
I’ve used the pastebinit program listed on that page to upload to paste.debian.net, but it supports other sites as well.
Yeah, but idk if phones can use joycons in the double joycon mode. My understanding is that it requires either root or a physical adapter of some kind.
If I am being honest, I prefer the Switch form factor with the dumb little controllers
Android phone + Telescopic gamepad + winlator might be what you want…
(Or you can use one of the switch emulators on android…)
Because forgejo’s ssh isn’t for a normal ssh service, but rather so that users can access git over ssh.
Now technically, a bastion should work, but it’s not really what people want when they are trying to set up git over ssh. Since git/ssh is a service, rather than an administrative tool, why shouldn’t it be configured within the other tools used for exposes services? (Reverse proxy/caddy).
And in addition to that, people most probably want git/ssh to be available publicly, which a bastion host doesn’t do.
So, I’m not gonna pretend flatpak doesn’t use more space then normal apps, but due to deduplication (and sometimes filesystem compression), flatpaks often use less space than people think.
[nix-shell:~/Playables/chronosphere]$ sudo /nix/store/xdrhfj0c64pzn7gf33axlyjnizyq727v-compsize-1.5/bin/compsize -x /var/lib/flatpak/
Processed 49225 files, 21778 regular extents (46533 refs), 22188 inline.
Type Perc Disk Usage Uncompressed Referenced
TOTAL 53% 898M 1.6G 3.6G
none 100% 499M 499M 1.0G
zstd 34% 399M 1.1G 2.6G
[nix-shell:~/Playables/chronosphere]$ du -sh /var/lib/flatpak/
1.7G /var/lib/flatpak/
I only have one flatpak app installed, and du says that takes up 1.7 GB of space… but actually, when using a tool that takes up BTRFS transparent compression into account, only half of that space is used on my disk.
I recommend using compsize for a BTRFS compression aware version of du and flatpak-dedup-checker for a flatpak filesystem deduplication aware checker of space used.
I think flatpak absolutely does use up more space, because yes, it is another linux distro in your distro. But I think that’s a tradeoff people accept in order to have a universal package manager for graphical apps.
Also, you can flatpak cli tools. They are just difficult to run at first because you have to do the flatpak run org.orgname.appname thing, but you can alias that to a short command. Here is a flatpak of micro, a terminal based text editor.
(I prefer nix for cli tools though, and docker/podman/containers for services).
So based on what you’ve said in the comments, I am guessing you are managing all your users with Nixos, in the Nixos config, and want to share these users to other services?
Yeah, I don’t even know sharing Unix users is possible. EDIT: It seems to be based on comments below.
But what I do know is possible, is for Unix/Linux to get it’s users from LDAP. Even sudo is able to read from LDAP, and use LDAP groups to authorize users as being able to sudo.
Setting these up on Nixos is trivial. You can use the users.ldap set of options on Nixos to configure authentication against an external LDAP user. Then, you can configure sudo
After all of that, you could declaratively configure an LDAP server using Nixos, including setting up users. For example, it looks like you can configure users and groups fro the kanidm ldap server
Or you could have a config file for the openldap server
RE: Manage auth at the reverse proxy: If you use Authentik as your LDAP server, it can reverse proxy services and auth users at that step. A common setup I’ve seen is to run another reverse proxy in front of authentik, and then just point that reverse proxy at authentik, and then use authentik to reverse proxy just the services you want behind a login page.
I just realized… a previous lemmy post I saw appears to be this sign.
The solution to what you want is not to analyze the code projects automagically, but rather to run them in a container/virtual machine. Running them in an environment which restricts what they can access limits the harm an intentional — or accidental bug can do.
There is no way to automatically analyze code for malice, or bugs with 100% reliability.
OP is on OpenWRT (a router distro), and Alpine. Those distros don’t come with very much by default, and perl is not a core dependency for any of their default tools. Neither is python.
Based on the way the cosmo project has statically linked builds of python, but not perl, I’m guessing it’s more difficult to create a statically linked perl. This means that it’s more difficult to put perl on a system where it isn’t already there, and that system doesn’t have a package manager*, than python or other options.
*or the the user doesn’t want to use a package manager. OP said they just want to copy a binary around. Can you do that with perl?
I cannot find anything related to that in their documentation, their about page, or their whitepaper.
They talk a lot about decentralized computing, but any form of secure enclave or code verification isn’t mentioned.
Compare that to this project, which is similar, but incomplete. However, quilibrium uses it’s own language instead of python or javascript, like golem does. The docs for golem do not explain how I am supposed to verify a remote server is actually running my python/javascript code.