He probably meant https://gitea.io ;)
48 karma · joined July 23, 2021
now…
Shouldn't that be the easiest way to distribute audio software for linux? It's just a static shared library and maybe some data.
> This is the first time I'm reading of Pipewire, and it sounds promising, but will need to have host support before it becomes a reasonable VST / LADSPA replacement.
I'm pretty sure they didn't mention pipewire as a replacement for vst or lv2 (or ladspa lol). It's benefit would be for your standalone since it supports alsa, jack and pulseaudio clients and can get decent latency.
Ah ok, I thought they have an X server running under windows, but apparently not. (Was that in some previous version? I remember reading that.)
> so presumably the FreeRDP client would be just fine on Linux.
Memory sharing would need support by the hypervisor I guess, that probably means hacking FreeRDP, rdp-wayland-backend and the hypervisor :\
Yeah, thats what I meant, you can just use kvm and your gui/audio/etc. stuff directly instead of having all the unnessecary complexity and dependency those layers bring along.
> Bubblewrap is okay if you trust your kernel
Thats why I proposed it for when you don't need virtualisation. You can ofc also use it in a VM to further restrict processes.
Why all the complexity? Just qemu/kvm and xpra, waypipe, whatever would be way simpler and in turn have way smaller of an attack surface. Same if you don't need virtualisation, just use bubblewrap instead of docker etc. It will even give you more fine grained control and you can just use your distributions package manager to keep everything up to date.
If you read the examples you'll see that they mount /tmp/.X11-unix in the container, thats where the X-Sessions Unix domain socket is. You can do the same for pulseaudio. But you shouldn't. Use Wayland and Pipewire if you are actually interested in using this as a security measure, since they are built for sandboxing.
> I thought modern browsers would need /dev/dri/?
They only need it for hw-acceleration. You can also give the container access to it if you need that.
NSA: VPN and "secure" webmail providers
CIA: They don't need fronts anymore, they have CISCO, Juniper, Netgear, etc.
Also I see nothing wrong with this except for the hungarian PascalCase…
I guess anti-fraud laws… Also, to my disappointment, someone already got banksy.io :D
My immediate thought when I read your post was GPL or GTFO, so I guess it's fine ;)
If you depend on users (attackers) not being able to modify their software or environment and poke around at each and every bit of your (publicly accessible) interfaces you are doing something awfully wrong!
> but the user needs to be authenticated to upload a database
Is registration for your service limited to a fixed amount of trustworthy people? Otherwise this isn't an obstacle.
> the lambda that extracts the data is sandboxed to access only what it needs
Using a simple serialisation format would be orders of magnitudes safer (and simpler)
> Unless there is some way to introduce a malicious side effect to a select statement in sqlite?
See all the links posted here already
Why don't they start with their own?
Server side energy consumption is directly measured by how much money it costs to run the servers. The only reason web devs waste client processing power like there is no tomorrow is that it doesn't cost anything.
You'd have to build some hardware abstraction to use with the scripting language anyways at which point you could just use the language you wrote the abstraction in imo. Is it so you can have inexperienced (cheaper?) devs do the maintainence? For all the embedded projects I worked on the high level program logic wasn't the thing that took the most effort.
Yes please save all of your personal and payment information in your browser, I don't see how that could be a bad idea.
At least it's consistent :D
For me it is: I can't copy from the URL-bar to other apps. Inside of firefox works, copying from everywhere else works.
I didn't care to investigate though as I rarely need to do that and I was pretty sure it's my fault for locking it into it's own user namespaces.
/usr/Programs (x86)/del
I mean even different versions of Word can't do that reliably...
Which isn't necessarily a bad thing. Many governments even raise the barrier of entry artificially for dangerous activitys by requiring licenses or training to operate heavy machinery, handle dangerous chemicals, install electricity etc. Using technology sometimes requires knowledge about the inner workings so users will not accidentally hurt others or themselves. Imo developers shouldn't infantilize users but give them tools to work with. Of course this naturally works better with FLOSS since there (more often than not) is no monetary incentive to get absolutely everyone on to use it.
I meant compile your whole logic and libraries into one (big) binary so you won't depend on any runtime that might ever change except for your operating systems syscalls.
> most ways to encapsulate scripts in static binaries fail miserably [...] and otherwise there aren't too many technologies that are good for this out there.
LUA is about as stable as it gets, (minimal) WASM runtimes will also probably live forever. (Or are, most likely, interchangeable if not) For both of them you'll need to build the interface yourself, so any breaking change will at least be your own fault.
> Any other options that you can think of?
Rust, or if you are a bit masochistic C or even C++. Rocket 0.5 (Rust) looks really nice (as in ergonomic) as a webserver and iirc you can statically link with musl instead of glibc.
> I'd say that it's only a question of time until Apache/Nginx/Traefik + Certbot run into similar issues
But then youll at least have http as a fallback
> So sadly if i get hit by a bus tomorrow, it's only a matter of time until my homepage stops functioning and the memory of me disappears forever.
I think what you want is a trust fund :D
Doesn't sound so stable to me…
> Why couldn't i build my personal website with some mostly static content and have it work for many years, while i'm not tied down with constantly maintaining it?
You can, HTTP still works and even oldschool HTML mostly works¹.
If you only need sqlite as a db you could easily compile a static binary that will run forever (as in foreseeable future) and serve content via unencrypted HTTP. If you then use a reverse proxy that can be automated with certbot you will have a system where all the maintenance work is done by the EFF, the reverse proxy developers and your distro's packaging team.