1,860 karma · joined August 25, 2010
If MinGW isn't already supported, if probably expect to have to take that over yourself.
I have used this sort of thing a lot though, and something I often find both essential, and overlooked is you really need something like `cr_task_sync_and_do_work` that isn't just entirely blocking on the current thread. Since as you build systems on this sort of API, you very quickly get bound by threads just stuck waiting on their children jobs.
Having said that, I realize that complicates the implementation quite a bit. The most elegant approach I have seen is one where you put tasks on fibers, and when you sync, instead of entering a sync loop, or waiting on a mutex, you instead suspend the fiber in the awaiting job, and put it back on the task queue. This was detailed by Naughty Dog in their Job System talk at GDC: https://www.gdcvault.com/play/1022186/Parallelizing-the-Naug...
The problem I've realized is that for many core Nix developers, the source is the documentation. Which doesnt scale.
We implemented a deterministic approximation, and moved on. But I learned something important about trig functions that day.
I'll agree with you that starting with static type systems is an early optimization. But if it's premature or not is clearly context dependent. And it is often "right on time" optimization. Just as are many things engineers like to deride as "premature optimization".
It's not premature if it's known to be needed and the cost of doing it later greatly outweighs doing it now.
It's pretty much just that cross site requests are disabled.
I have a little compiler from 10+ years ago I was working on. And I recall after I had put it down, and tried picking it back up just maybe a year later(?) The interfaces I was using in llvm all changed. It really took the wind out of my sails for jumping back in.
You and I, who are both working off of main, and who have both separate merged in a few patchsets that are relevant to our shared module of interest. We can merge and compare our branches, and the differences in terms of nursing patches without having to be rigorous about reconciling or histories.
A rebase is never required in Git. (people/maintainers may disagre) but a merge will always do.
Having said that. In your scenario provided, a pull + merge/rebase will be required. It will then resolve automatically, and without conflicts. But a human has to be involved to provide a strict sequence/dag of the those commits.
I mean, that sortof what nix (and I assume guix) is though, right? As long as your ok with the binary cache for a replacement for apt/rpm (with the caveat that sometimes pkgs can be built on .deb or .rpm)
2. Continuing on that, QT is still good for large desktop GUI projects. It doesn't seem it's well bound to Rust, and Rust is still trying to figure out their comparable UI story.
3. Ironically, in some certain circumstances, with good discipline, (And mostly interfaces that looks like C) C/C++ can compile faster then Rust.
With a good DMCA takedown story and compliance, you could potentially claim the copyright is responsibility of your users. And maybe you'll be too small, and the content, in general you are making too inconsequential, or even helpful (marketing wise) for anyone to care. But this is definitely be a project I would get a proper legal analysis of and have clear procedures and plans in place for any issues that may show up.
CDNA docs, for instance: https://www.amd.com/content/dam/amd/en/documents/instinct-te...
I think this illustrates a bit the tragedy of git's (lack of) UI. Since the reflog is a feature, not an exposed hidden internal. It's simply a log of what a reference, say HEAD, or a branch, has pointed at. It's meant to help you figure out what happened, or get back to a place you lost through some other operation.
I'm curious a bit though, here, and in other posts in HN, I often see that HMAC, a symmetric key is preferred, going as far as suggesting, in JWT, that other algorithms should not be implemented. Why is that? What are the problems with say RSA? (Ignorning that I'm not sure Asymmetric keys work with Macaroons design at all)
From my perspective, Asymmetric keys have been a great boon, in that I can keep the private key, secured on my single auth server, but then freely distribute the public key to the edge, greatly increasing responsiveness, and reducing the bottleneck on the Auth server.
Is there some security concern I've been missing?
So, while this is the first time I've heard of ubicloud, I use gha extensively.
Abd frankly, I think it's just because Github has a crazy markup on their actions compute over the raw compute. Taking a quick look, it appears that their base rate is like $0.008 per-minute!! That's a rate that wouldn't look crazy out of line with EC2's hourly rate.
I've worked on projects where we saved significant money, and improved build times just by launching a single EC2 instance and connecting it to Actions.