ATsch

This is a pretty weird question considering the mountains of documentation of authorities doing just that. This is not some kind of hypothetical that needs extraordinary justification.

At this point most of them do, but also require customers to explicitly opt-in. I think cloudflare is the only exception there, it won't even let you opt out unless you're on a paid plan.

That is not advisable right now as you'll cut off a lot of users. Some providers like unglei.ch do offer an IPv4->IPv6 proxy if you absolutely don't want to deal with IPv4 though.

Not sure what you mean, but there's definitely no need to type addresses anywhere.

Router Advertisements propagate the subnet information (prefix, dns server, etc.) to clients in the network. Prefix delegation allows downstream routers to request subnets from upstream routers. MDNS lets network devices announce their services to the subnet.

IPv6 has Stateless Address Auto-Configuration (SLAAC) as preferred method for address assignment. This allows clients to generate addresses for themselves as needed. For that to work efficiently, the address space needs to be sufficiently large that collisions are unlikely even in larger networks. Because of that, it mandates a subnet size of /64.

More generally, a big difference in v6 is that you no longer have to plan subnet sizes at all. Whereas previously you'd carefully choose the next available address to minimize address waste, with v6 you can just assign the addresses in whatever way makes sense to you.

That's to be expected. All it does is ensure the accuracy of the email sender. Which finally lets you attach reputation to domains instead of addresses.

We used up 256 /8 blocks in roughly three decades. That's roughly 9 per year. Even if we are more conservative now, freeing up a /8 here or there will not significantly change the situation. 32 bits are woefully inadequate no matter how you slice them.

> By that logic, what are firefighters doing but censoring homes?

Not inherently, but a disparity in which fires get prevented and put out and with which priority might constitute censorship, just as a disparity in which types of programs are identified as malware might. Many historical examples for the former instantly come to mind, from one library in alexandria to a sexual research institute in nazi germany. Not to imply that this is comparable to those in magnitude of course.

(On second thought, that also applies to systems of explicit censorship, where all media has to be approved but media that exhalts the government line has a higher chance of being approved than media that does not comment. As well as our system of implicit censorship, where every film company has to make money, but a movie produced with approval and material support of the US military has a significantly higher chance of being financially viable.)

That is the exact opposite of what I'm saying. Saying the market place of ideas was an utopian dream that failed is like saying the divine right of kings was an utopian idea that failed. At best, it is something people were conned into agreeing with.

These ideas weren't invented out of thin air, but to defend things that are hard to defend on their own merits. And just as the devinity of kings mysteriously only brought rights and no responsibilities, it is equally telling that the only time the "marketplace of ideas" is ever brought is in the context of why we shouldn't be doing anything about all of the hate speech.

I wouldn't say it has failed, but succeeded. The framing of the "marketplace of ideas" has really always been about paving over power dynamics and justify continuing harm by appealing to something external. In your marketplace of ideas, the hundreds of abstract individuals that are hararassers are equally as valid as one abstract individual just trying to live their life. It's working as intended.

You really don't need to do much to catch their ire. It's enough to annoy one wrong person, especially if you're vaguely trans or some other minority.

I don't think that will happen just because the real problem is how software like this is usually bought. They'll ask 20 departments for their (heavily conflicting) requirements and then chose the one that ticks the most boxes without paying any attention to usability, which automatically means jira. To compete with that you'd have to do the same thing as them, at which point your tool end up just as unusable. (also see: gitlab)

AFAIR the reason this database is stored as SHA-1 hashes is because that's what a large amount of the original data dumps contained. Moving to a harder hash would have required cracking all of them first and wouldn't do much more to ensure the database can't be directly used as a password list for attacks.

I have never used svlogd but at it looks like it does read logs from it's stdin, which is a solid step forward as it avoids much of the pitfalls caused by applications writing directly into log files.

Collection is just the first part of a log system though of course.

> Just writing stuff to a file was fine.

Haha, I wish. Then that file becomes too large. So you want to truncate the start. However, removing bytes from the start of an open file is a bad idea. So you open a new log file every day instead. You really want to compress the old log files too, to save space. So now you can no longer just grep the logs as before. You're now also duplicating code and configuration for every daemon. So you write a daemon called `logrotate` that does this centrally instead. Into which you then copy the log paths configured for every program on your system and how long the logs should get kept. However programs don't much like it when you move the log files out from under them. So you patch every program respond to a signal by checking whether it's log files have been moved. Which then breaks for multi-process daemons. You come up with a whole buffet of ugly hacks to make that work most of the time.

Then you install a program which doesn't come with a logrotate config. Then you decide you'd really want a more structured way to analyze logs than writing fragile regexes. Then you want to run something as a non-root user. Then you have an ephermeral batch job. Then you want to ship off all of your logs to another location and really don't want to duplicate the log paths yet again. Then you want to see what happened just before the server crashed last boot. Then you run two of a daemon and give them different log paths. Then you want to look at your kernel and application logs together. Then you want to delete just last month's logs to free up some space. Also wouldn't it be handy if there was some kind of index to make things faster? ...

It sounds like what you ran into are the effects of the general trend of doing more in early boot, as https://freedesktop.org/wiki/Software/systemd/separate-usr-i... elaborates on, which is independent of systemd

I'd assume the lackluster selection of operations and how deeply nested some of the information is within the type. Definitely not the most ergonomic thing.

My personal favorite is probably the python ones. Only annoyance is difficulty of creating modified objects from existing ones.

The other way of looking at it is that the companies haven't entrenched a monopoly yet.

That's great to hear! Hope you're right.

It's less that you need to store many of them at the same time, but that it increases the amount of garbage collections. If you can create half as much garbage per packet or request, that's double the time until you hit the threshold for gc invocation.

I can't tell if your're being sarcastic but it's hard to find a program that uses UDP and doesn't at some point store IP addresses in a hashmap. Many more will do the same for per-IP rate limiting. I think those are reasonable use cases for go.

I think being able to compare or hash IP addresses is a pretty baseline feature for an IP address type. I don't think that's some kind of unpredictable hindsight or tradeoff.

I am not saying that the type is unusable. Plenty of high profile software has been written with C strings too yet we almost universally recognize them today as a mistake.

What I'm saying is that the design flaws of net.IP, the absence of which would have benefited the whole ecosystem, fall into a familiar pattern that can be learned from. It is good to see that addressed, even if by third parties.

Reading the description of the stdlib type, I can't help but be reminded of the statement that the go way of solving a problem is to ignore real-world problems and half-ass things for the sake of a simplicity that merely pushes the complexity elsewhere. It certainly does seem to apply here too. Glad this library exists now though.

Hey, thanks for the detailed comment. I should note I didn't intend to create the impression that GPUs and CPUs architectures were completely interchangeable. That's obviously not true, because of the fixed function hardware alone. The intent was more to give a rough idea of what "CUDA Core" actually means and roughly how those concepts map to what we know in CPUs.

> Yes, "CUDA Core" is (was?) analogous to "FP32 ALU" - (it may have transitioned to FP16 nowadays to double the count?)

It's still FP32 ALUs (NVidia disables FP16 in the driver for gaming cards). The doubling between Turing and Ampere is due to the combined int/fp units being counted as CUDA cores. This also means that for int instructions, the expexted performance is not actually increased, another reason the "core" term is unhelpful.

> But, single GPU "Compute Units" often have 2-4x that (up-to 64 FP32 ALU)

Yep, guess I should have left that AVX2048 joke in there for you. It just wasn't very important IMO.

> Also, for accuracy, vis-a-vis "independent parallel threads of execution like on CPUs", even the 64-core Threadripper has 128, not 64.

I did not consider SMT here because while relevant for keeping the ALUs fed with instructions, they don't increase the amount of raw peak compute possible. Those 128 threads can still only issue 64 avx instructions at any one time, which is what really matters here.

My primary objection is not to the SIMT model, but NVidia reusing a term with an established meaning ("core") for something completely different and incomparable. Other companies terms like "execution units", "compute units" and "stream processors" (although perhaps not as much the last) are much more truthful about the nature of GPUs without hindering the programming model at all.

I definitely agree with it being a useful model, after all that is the the way GPUs are presented to programmers. But when getting into detailed performance comparisons, especially with CPUs, that simplified model breaks down quickly and becomes a hindrance. Which is why I think it's unfortunate that NVidia (deliberately) uses the term "core" that leads people to believe they can make a direct comparison to CPUs. Comparisons that coincidentally lead people to believe GPUs are much more special than they actually are.

"CUDA Core" is a misleading marketing term. It merely counts the number of FP32 ALUs. If you measured CPUs this way, you'd have up to 16 "cores" per core. If you count it that way, that makes this CPU is roughly as powerful as the GTX 400 series with it's "512 cores". A brief look at benchmarks seems to confirm that.

Conversely if you counted a GPUs independent parallel threads of execution like on CPUs, you'd max out at a very comparable 64 "cores".

I'm sure every project having it's own buffer, list, config, logging, hashmap and endianness implementation helps a lot with that :)

I personally found it annoying enough to install clipman[0] for my sway setup. Especially with short lived applications like calculators etc.

[0] https://github.com/yory8/clipman