(Founder) Named pipe that operates at the level of records, is durable regionally, you can read from any sequence, and lets you do concurrency control for writes if you need to.
I know at least one of the maintainers in the list, I know they live in the US and their project is something they maintain as a hobby with no expectation of retribution, and I know they are probably ecstatic to receive a small grant.
Yeah, it's not much. But the publicity and the methodology and the possibility of others doing the same is more impactful than just the financial resources the author had.
Thanks. That's a start experiment - I am going to donate more using this approach in the future and hope that other people will join me in this non-profit initiative.
While any particular donation I made to OSS maintainers is small, it seems important that the recipients get more attention and maybe will be less likely to burn out in the future. For instance, some of them (btw, from Nebraska!) did not receive anything for 18 years of contributing to OSS before last week: https://www.linkedin.com/feed/update/urn:li:activity:7269812...?
"just a hobby, won't be big and professional like gnu" which is a quote from Linus's Linux announcement on Usenet in 1991.[1] He didn't know it was going to be big at the time, making it an ironic statement after the fact, and that could also be the case for any new OS from scratch such as this one.
I don't think it was a perfect storm going on , but rather since today Linux is popular & strong , you are retracing it to it having a perfect storm and nothing can come close to it .
That being said , I still think that this wouldn't reach mass adoption "just for being an alternative to linux" and that this has to have a specific purpose
For example serenity os has a really cool old - ui and some people think its a fun os in general , out of which came the ladybird project.
Redox os is trying to write it in rust , something which can have some practical meaning in my opinion
Not really. I don't see how Linux being popular & strong today had any bearing on people's willingness to contribute 33 years ago.
Writing an operating system is challenging. Not as challenging as a compiler, but certainly more work (so much hardware, so many specifications ugh).
In 91-92, people were clamoring for a free, unencumbered 386 Unix. Enter Linux.
Every successful (non-commercial) OS undertaking needs and has a hook.
Redox? Rust (enough said).
Serenity? Live coding and mental health (no knock there).
And on the flip side, look at ReactOS. Languishing. Painfully slow 15+ years in development, and people would still rather pay Microsoft or roll the dice running applications under Wine. It's hook just isn't strong enough.
Again, not to knock this guy, because just the fact that he wrote his own AML interpreter is super impressive to me (I've floundered around in those same ACPI specs for far, far (far, far) too many sleepless nights), and never put out 1 line of AML code. So mad props.
But there's just no hook. C++? Passe. No microkernel / hypervisor / <insert_feature_here>? No capability model?
It'll be tough. But I know that OS'ing is a labor of love, even if not a single other person cares. Cheers.
The problem is 100% ffmpeg, Go has nothing to do with it other than it's being used as a better shell script. Also some errors are checked and not others, and a large amount of files are opened and never closed
I agree that Go is not at fault here. However, I don't think FFmpeg is at fault either. It's just a fact of life that you can't seek in a stream with no buffer. As for the error handling, I purposely leave that out of my articles. Obviously, you shouldn't do this in production code.
In this particular case, it's just combining two tracks though. Could just do this directly in golang without using ffmpeg and not deal with it's shortcomings in such a manner.
It’s fairly easy to get into an irrecoverably broken state using an intermediate-level Git operation such as an interactive rebase (as of a couple of years ago). (It’s probably recoverable by reaching into the guts of the repo, but given you can’t do the rebase either way I’m still taking off a point.) The distinguished remote URLs thing is pointlessly awkward—I’ve never gotten pushing to places where those remotes are inaccessible to work properly when the pushed commit updates the submodule reference. (I believe it’s possible, but given the amount of effort I’ve put into unsuccessfully figuring that out, I’m comfortable taking off a point here as well.)
I like git submodules, I think they’re fundamentally the right way to do things. But despite their age they aren’t in what I’d call a properly working state, even compared to Git’s usual amount of sharp edges.
reply