> website where people can upload videos and others can play them in their browser. What would be actually involved in doing this?
The minimum would be a stateless server handling <input type=file>, storing it in the file system and responding with the path exposed by nginx or something. The user agent will take care of the playback, be it Firefox, VLC or mpv.
Now if your average users upload high bitrate videos but have shitty bandwidth, you'll need to transcode them down to lower resolution or higher compression to save them from rebuffering. Still, no client-side scripting needed.
In case their connection quality is unstable, HLS is finally necessary for on-the-fly adjustment of playback bitrate. This is the secondary purpose of JS viewers around the web these day (the primary one being DRM). The other possibility with custom viewer is to lighten the server load by enabling P2P transfering, e.g. in case of PeerTube. Realistically, you'd either deploy the barebone one I mentioned in the beginning or set up a PeerTube instance; anything in between is probably a waste of engineering effort.
Make of it what you will, I just saw on the project censored website that protecting student data is seen by some as a major priority. The article seems more PII and cybersecurity focussed, rather than recognizing the threat of intentional monetization.
This is about digital security, i.e. protecting data from unauthorized access and use. It says nothing about protecting students themselves from surveillance and abuse by their own institutions.
This is only looking at another siloed alternatives, while ignoring federated protocols such as XMPP or Matrix. The problem can't be solved if an infra has to be the single point of failure:
1. It grows too large then it will get corrupted, e.g. Twitter/Reddit/Discord turning for surveillance capitalism and GitHub going for license laundering.
2. If it doesn't have many users it's likely to be discontinued.
On Matrix for instance, the room is replicated on all members' homeserver, and any admin can create a room alias (e.g. @foo:example.com creates #project:example.com, @bar:example.net creates #project:example.net). Like with emails, conversations can still go on even if some members' server goes down (and unlike mailing lists which are host on a single endpoint, there are multiple aliases).
One thing that has been bugging me for quite a while is that how a Zig library would be packaged downstream. AFAICT all Zig programs have to vendor their Zig dependencies which is a huge turn-off for Debian or Fedora developers. There is not an existing way to install Zig source files and IMHO this hurts reusibility (in a different way).
This is an issue with any modern systems language like Go and Rust, and it doesn't seem like this trend is going to stop. NPM will happily download precompiled binaries for certain packages, and NuGet only works with prebuilt packages (like the java ecosystem).
In current day, everyone wants their own package manager, and compiled builds to have no dependencies. While this makes distribution and building easier, it makes it impossible for distro maintainers to integrate it properly into their ecosystem, apply fixes and upgrade libraries across swathes of programs. I don't get why people can't accomodate for distro packaging in their tooling as well - many languages like python handle this just fine.
I believe we'll end up at a point where the system package manager will mean nothing - it'll manage end-user programs, which will all bundle their own versions of libraries - even ones considered "system" like libc and libX11. No sharing of (security) fixes and feature upgrades, and you'll have to learn a new package manager each time you switch languages or sometimes even projects...
Welcome in appstore land, where the system is merely a collection of independent applications with no relationship with each other.
Makes it indeed easier to build, deploy and sell software, compared to the former world of one big distribution where thousands of software packages were designed to work together.
I do believe the driving force in this trend is not coming from the users but from the producers desire to assert property of the software. Think the enclosure trend, for software.
> Welcome in appstore land, where the system is merely a collection of independent applications with no relationship with each other.
"App store" is having a centralized distro repository where you get all applications from (e.g. Windows Store), and "merely a collection of independent applications with no relationship with each other" is exactly the opposite (e.g. that's how the Windows apps were distributed before the advent of Windows Store).
You missed the ease of digital replication: one needs not participate in a sexual act involving children to replicate child pornography. It's not like it's a healthy thing to consume such material, but the distinction must be made to avoid the concept being abused by digital publishers who think one sharing an ebook with a friend would cause lost in their revenue.
If I take your apple, scan it in my StarTrek replicator, then put it back, I've not stolen anything. At worst, I've borrowed it without your consent. The fact that I can use my replicator to make as many apples as I want, which are just like the one I borrowed from you, is not stealing.
Not saying it wouldn't be wrong. But it's decidedly different from stealing.
Likewise, getting a copy of a copyrighted movie with Bittorent through the Pirate Bay is not really stealing. It may still be wrong, but since it does not deprive the original owner from their own copy of the movie, it's different from stealing.
In general, non-rival goods should be treated with different rules and laws than rival goods. Turning them back into rival goods like copyright does strikes me as a very bad idea. Artificial scarcity is… non optimal to say the least.
>If I steal an apple from you and grow more apples from it and give them away, there is no difference to the act of stealing your apple and eating it.
Certainly, but we talk about digital good here, stealing the first apple harms me (unless if I was not going to use it regardless), copying it however does not.
>RMS seams to be totally against "stealing" digital GPLed code.
Please explain what you mean by stealing here. He is against taking GPLed code, modifying it, compiling it, and then distributing the binary without distributing your modifications. He has no problem with selling the application/code. He has no problem with keeping the modifications to yourself as long as you do not share the binary. He has no problem with distributing the unmodified binary and/or code.
The minimum would be a stateless server handling <input type=file>, storing it in the file system and responding with the path exposed by nginx or something. The user agent will take care of the playback, be it Firefox, VLC or mpv.
Now if your average users upload high bitrate videos but have shitty bandwidth, you'll need to transcode them down to lower resolution or higher compression to save them from rebuffering. Still, no client-side scripting needed.
In case their connection quality is unstable, HLS is finally necessary for on-the-fly adjustment of playback bitrate. This is the secondary purpose of JS viewers around the web these day (the primary one being DRM). The other possibility with custom viewer is to lighten the server load by enabling P2P transfering, e.g. in case of PeerTube. Realistically, you'd either deploy the barebone one I mentioned in the beginning or set up a PeerTube instance; anything in between is probably a waste of engineering effort.