The reason is simple: they'd like to reap all the benefits of a permissive licence (many people and companies won't or can't touch GPL code), without any of the downsides; but these downsides are the very reason behind the rules in more 'restrictive' licenses like the GPL.
This usually doesn't work, and in the end all they can do is complain about behaviours that their license choice explicitly allowed.
Go did exactly that, where Maven's 'Project group identifier' is an URL you control, e.g. github.com/<your-account> but also <your-website>/go-pkg or whatever you want. Other languages did this too. Flat namespaces are more of a Rust issue (among newer languages).
The real issue here is Rust's flat namespace. In Go, for example, there's no ffmpeg crate, there's github.com/someone/ffmpeg and gitlab.com/someone-else/ffmpeg, and so on. There's no blessed, unique 'ffmpeg' package, you can't squat names, and if the first package gets abandoned, you can fork it under a new path while keeping the 'ffmpeg' name. Only the import path changes.
How does having more namespaces address the other half of the issue, of having multiple incomplete ffmpeg crates and having to decide which one to use and to support?
Not entirely true. Rust (cargo) supports git-based crates and more crate sources than just crates.io (registry = "crates-io"), however crates on crates.io doesn't currently support dependencies with crates in other registries.
Now instead of having the 2nd and 3rd packages have ugly names all of them have ugly names!
There are advantages to systems like this such as trust (I can tell that you.example/pkg1 and you.example/pkg2 are owned by the same person) and decentralization. But I don't think it helps with the later packages having ugly names.
This is a bit of vicious circle. How much of that money goes even into keeping those servers running? The electricity bill alone, geez. They could do a dedicated fundraiser to get themselves two boxes that are a decade old and still have spare parts available, coming from Broadwell era, they will have enough instruction set support to cover the baseline towards which multiple distros are converging (Haswell and up).
Given their target audience, they could probably just request a hardware donation. Some sysadmin out there is probably getting rid of exactly what they need.
I am 100% sure that if they put out a call for action and asked for hardware donations they would be able to get newer stuff. Ryzen 7 1700 goes for as cheap as 50$, DDR4 ram at supported speeds (2133 MHz) is also dirt cheap.
64 bit mod is much slower than 32 bit mod. Your C program uses int32_t everywhere, while your Go program uses int (which is probably 64 bit on you machine); so this is not a fair comparison. Changing the Go program to use int32 everywhere makes it 35% faster on my machine.
Agree. And of course it's always something "surface level and uncontroversial", anything else gets you downvoted. Most subreddits (with a few exceptions) are huge echo-chambers.
I have found this not to be as straightforward as this. In particular:
1. Although `yt-dlp` consistently is able to download videos at link speed (even when the said link is in multi-gig range!), streaming the video through `mpv` will not work as well and some videos would buffer every couple chunks. But that was in the past…
2. With recent changes to how videos are served and "protected", I'm still able to download them with recent versions of `yt-dlp`, but streaming a `yt-dlp` generated playlist will reliably fail to work (this is true for the newpipe android app too.)
3. Even back when streaming youtube worked, closed captions and other such features would not work by default.
I download videos first, nowadays. And then play them with mpv anyway.
I used to use mplayer(of which mpv is a fork) to watch pirate streams of premier league games several years ago, via acestream. Since this was live, lag was a real issue; you can't buffer ahead when there's nothing to buffer yet. Eventually I figured out that mplayer had settings to do things like buffer for 2 minutes at the beginning of the stream before playing. You could also configure it by megabytes pre-buffered. This solved my lag issues very neatly. I can't remember what the settings were, it's been a long time and I don't have those config files anymore. But it should all be in the docs somewhere.
> 1. Although `yt-dlp` consistently is able to download videos at link speed (even when the said link is in multi-gig range!), streaming the video through `mpv` will not work as well and some videos would buffer every couple chunks. But that was in the past…
I still get this with YouTube from time to time. Works with some videos, others are unwatchable. Seeking also generally seems broke and is often slower than downloading even the whole video.
That's funny, for me that's exactly the best GUI out of the box. I actually did some tinkering to reduce the GUI parts even more, and added more keyboard shortcuts.
The structure, probably. In gendered languages objects have a grammatical gender, and "structure" is feminine in at least French, Italian, and Spanish (they all derived from Latin "structura", which is feminine). Non-native English speakers will sometime carry over a noun's gender when writing in English.
This usually doesn't work, and in the end all they can do is complain about behaviours that their license choice explicitly allowed.
reply