MobiusHorizons

Ah nice!

does this mean if you want to add some print statements for local debugging inside a pure function that you will have to remove pure from the whole callgraph? or is there a way to treat it as just a warning?

it seems like in this case SIMD is one of the biggest reasons libdeflate beats miniz-oxide. at that point you are either using assembly or a library of functions that maps in names and functionality to the assembly. I think C isn't really better than other languages in that regard. Its not like its using auto-vectorization to get that SIMD support.

I would argue the effect is more pronounced in non-public companies that have private investors. Private equity especially does this, but VC backed startups also display extreme return on capital seeking behavior (albeit through growth rather than hollowing)

> While the power itself is the perfect example of the opposite, where the market should (according to theory at least) be perfect.

Markets don’t seem to want to solve for outlier situations like extreme weather events or significant hardware malfunctions. Basically I’m talking about what happened in Texas. When it’s a safety issue, it can be hard to align incentives to make planning for outliers worthwhile to market actors.

That seems much more sensible than what is being discussed. Sure fair use offers some protections, but youtube the platform is not required to protect individual youtuber revenues for fair use. Fair use effectivly entails an exception to the normal rules, and as such, requires actual judgement on a case by case basis instead of being something that can be scaled like content id. If you actually got sued, you could use Fair Use as a defense in court, and the judge would decide if you are right or not. In the case you are discussing, no-one got sued because youtube handled it without a court, so fair use never really comes into play.

What is being discussed would be more like if a court tried to get Google to take down individual spam bot youtube accounts that had popped up that same morning. Its rediculous because the legal system doesn't move that fast (nor does DNS), so things that require that level of heavy-handedness are typically much slower processes taking months or years.

Most home computers from the 8bit era shipped with basic on the ROM, and people used it for memory mapped hardware access with peak and poke commands. It was basically the operating system for some of these computers.

> The actual question is whether people wanted to contribute and the process was what kept them away or talent to enact the change.

My point was basically that this question misunderstands the purpose of large open source projects. They are not primarily things people have a right to contribute to, but rather things we want to improve for everyone. Anyone has the right to make changes to the Linux kernel for their own purposes, but contributing is not a right. It is primarily for serving the public good.

I’m not surprised the processes discourage some portion of would be contributors from contributing. I just don’t think that is a problem.

The op asked because a usb microscope is basically unsuitable for seeing something this small with much clarity. From other replies it sounds like the purpose is for automated positioning which makes more sense.

That really puts it in perspective in a nice way, thank you. These multiples really give a distorted sense of scale even when you know current production is not what is being valued

The Linux kernel project is not hurting for contributors nor was it prior to LLMs. The processes you describe as roadblocks don’t seem to have been preventing the Linux kernel from getting code contributions. Maybe they don’t need or want more easy onboarding or broader audience?

Aliexpress / Temu most likely. People already buy cheap Chinese radios from those places now, since they can be cheaper than ebay.

Yeah that’s what I was thinking. I didn’t think of the traps until I read the sibling threads, but even that doesn’t seem like an impediment.

The behavior at the bit level seems very well defined based on that excerpt. You would need to know how signed integers are defined to know what the numeric value of the result would be. That sounds like it would be implementation dependent, but also completely predictable. Am I missing something?

I would be very curious to know why such shifts would be UB as opposed to merely implementation specific.

I guess I can understand that signed shifts bump up against how the hardware represents signed numbers at the bit level, but it’s not like the assembly is unclear on any given platform.