My take is that there are two factors at play here:
* Third party requests from the browser are problematic in general for technical and privacy reasons: it's impossible for the browser to know whether the request is privacy-preserving or not. And they need to be enabled in tooling like CSP. It's much easier not to have any.
* Third-party requests from my server don't give me any more information than I had before. I could store my logs and process them, or I can engage a third-party to aggregate my data for me. Plausible have no way to know that the requests I'm sending aren't entirely fictitious, and I can sleep slightly more soundly knowing that there's one less moving part that I need to maintain myself.
The fate of life on earth depends upon 2 corrupt fossil-fueled obstructionists.
Why is Joe Manchin even in the Democratic party?
His voting record during the Trump admin was atrocious, including his confirmation of Kavanaugh.
Maybe I'm being terribly naive, but I don't see this from a maths perspective at all, I see this as about the shape of data and about memory allocation.
If one increments pointers across an array of data, one should know the stepping size, for example.
How is this (programming/practical) side of the word "type systems" related to formal/mathematical "type systems"?
Types are a kind of constraints on what kind of logical constructs in one case, and what kinds of computational constructs in the other, are allowable. Logic and computation are related, but they are not the same. (This difference is also evident in how people think about monads in programming vs. how they are defined and used in category theory.)
essentially, serving a website to older devices that are missing the X1 certificate is broken now that the X3 certificate expired yesterday...
or?
(meaning, it's not a realistic strategy to tell clients to update/upgrade, and the cert-expired page makes you look dodgy, and mavericks ain't never getting a chrome higher than 67 and there are tons of people on that still, so...)
that will need to bootstrap first, and you won't be able to use such GC code in the initialization code for the OS.
GC code using Boehm would not be suitable for device drivers nor realtime code.
I can understand where making it available for higher level systems is desirable.
I could envision the kinds of alternative GC systems that could be inbuilt given the knowledge an OS may have about a process or a sub-system etc.
Alternatively, Objective C settled upon reference counting (ARC) and this is superior to GC where it counts.
Where do you envision the GC bootstrapping and how do you see it interacting with virtual memory and your malloc implementation?
> that will need to bootstrap first, and you won't be able to use such GC code in the initialization code for the OS.
It's all highly dependent on the interface between the language and its runtime. Hypothetically, your C# runtime (and by runtime, I'm using it in the same sense that Rust or C++ would use it; I'm not referring to a VM) could provide a function that allocates memory (C#-esque pseudocode):
public static ulong New(ulong bytes)
{
if (gcInitialized)
{
return GcNew(bytes);
}
else
{
return BootstrapHeapNew(bytes);
}
}
Until the GC is boostrapped, all allocations are made on a heap, and either manually freed or kept around until the GC takes over deallocation.
> GC code using Boehm would not be suitable for device drivers nor realtime code.
I completely agree, I just provided it as an example of a GC implemented in the same language.
> Where do you envision the GC bootstrapping and how do you see it interacting with virtual memory and your malloc implementation?
I don't see the GC interacting with userland in this case, and instead would only be used for kernel data structures. I don't really think it's a good idea to have GC in a kernel, I only wanted to point out that low-level code and garbage collection are not mutually exclusive.
For that matter, until you bootstrap GC+heap, you could just use statically allocated memory, or even local arrays (via stackalloc). This would preclude using any reference types, but you can do plenty of things with just structs and unmanaged function pointers alone in C# (it's basically the expressive equivalent of C, but with generics thrown in).
> Alternatively, Objective C settled upon reference counting (ARC) and this is superior to GC where it counts.
ARC does nothing special other than automate [myCocoaClass retain] and [myCocoaClass release], a compromise after putting a conservative trancing GC in Objective did not work as expected, given the amount of caveats with GC unaware C code.
As such, Objective-C performance related to heap management remains unchanged.
You know, it's interesting to me how much people fixate on garbage collection.
Taking Go as example, there are many pitfalls to using it in low-level situations, but the GC is, in practice, never a source of significant issues.
The real problems are:
1) The foreign function interface (CGO) requires a context switch in both directions. (Not because of GC, but because of Go's threading model.) A lot of work ends up being in trying to avoid calls between Go and C in hot loops.
2) Especially talking to the kernel, there are surprising sharp edges in the ABI and C calling convention. I once spent a week trying to populate a bit field correctly. (But other languages would have the same problems matching any C behavior that's left up to the compiler.)
3) The lack of memory fences is a big deal when trying to use kernel-managed ring buffers.
The GC, comparatively, is problem-free for two reasons:
1) A lot of embedded code uses static buffers anyway.
2) The problem of managing memory doesn't go away just because you're in ring0. The Linux VFS, for example, is heavily garbage collected, it just uses a jerry-rigged GC consisting of counting references. I'm sure if I make a categorial statement on this someone on HN will take me to school, but I think a real GC might be a net performance win in some places in the Kernel, like the VFS.
Finally, people often bring up that GC is fine for throughput, but not for latency. Fair enough, but manual reference counting is also not better: someone has to call free at some point, and if you happen to draw the short straw in a blocking system call, it still affects latency. The amortization behavior is probably different, but not in any way that I think matters to most people.
Maybe at small scales like embedded, but Go's GC has proven problematic even with static memory allocation. Some company (Discord?) ran into issues where the large heaps were scanned every 2 minutes because Go refuses to go longer than that w/o a GC check even if it has no reason to believe it needs to.
> Some company (Discord?) ran into issues where the large heaps were scanned every 2 minutes because Go refuses to go longer than that w/o a GC check even if it has no reason to believe it needs to.
"After digging through the Go source code, we learned that Go will force a garbage collection run every 2 minutes at minimum. In other words, if garbage collection has not run for 2 minutes, regardless of heap growth, go will still force a garbage collection."
The go team have done amazing work minimising mutation pause times. I'm skeptical I would ever be comfortable using it for code that close to the metal, but if any mark and sweep garbage collected language is going to one day reach a point where that's solely prejudice on my part rather than part prejudice and part technological realism go is probably the most likely candidate.
I can't make categorical statements, either. But here's another concrete observation to offer as evidence that things are not so clear cut: in generational GC, heap allocation is typically O(1). A heap allocation is typically O(n), where n is the size of the heap.
Of course that difference also tends to go away if you're using static buffers.
into one big ball of 20 year mud that just doesn't have a tractable conclusion without a clear
1) plan
2) a ton more money
3) locals assuming power vacuums we create and owning it.
It was a failed state before the US arrived, arguably, and the Taliban represent a local power that organically had arrived at the stature it arrived at.
The NATO coalition had a limited mandate from most countries and it was largely driven by post 9-11 solidarity, and largely squandered any goodwill by the time Bush and Cheney invaded Iraq for no reason.
The Afghan adventure arguably broke the Soviet Union more than any occidental efforts. The writing was on the wall before the US arrived there.
If a child can see that there's no clear goal to the war, no clear point of winning that can be determined, then it's probably not very sound, conceptually.
(aka, if you invade a faraway country it can only be held by your people moving there and keeping a large physical presence there. See what happened to the Mongol Empire the minute the Golden Horde moved on... the only remaining vestiges were things of use to the subjugated peoples like the Yam and the Yass)
Basically, a muddled war with no clear strategy or even goal was only ever going to end this way...
needs to be coupled with subsidies for alternatives, transport (public, electric vehicles, etc) and with the knowledge that a poor person will drive that old diesel car into the ground, so give them an incentive to switch.
