Chabsff

I admire your optimism. The only times section 230 has been brought up on the hill in the last decade as been in, admittedly performative and doomed to fail, calls to get rid of it entirely.

Public availability of large transformer-based foundation models trained at great expense, which is what OP is referring to, is definitely unprecedented.

Similar to how all the kids today only play itch.io games thanks to Unity and Unreal dramatically lowering the bar of entry into game development.

Oh wait... No.

All it has done is create an environment where indy games are now assumed to be trash unless proven otherwise, making getting traction as a small developer orders of magnitude harder than it has ever been because their efforts are drowning in a sea of mediocrity.

That same thing is already starting to happen on youtube with AI content, and there's no reason for me to expect this going any other way.

No offense, but this is absolutely delusional.

As long as people can "clock" content generated from these models, it will be treated by consumers as low-effort drivel, no matter how much actual artistic effort goes in the exercise. Only once these systems push through the threshold of being indistinguishable from artistry will all hell break loose, and we are still very far from that.

Paint-by-numbers low-effort market-driven stuff will take a hit for sure, but that's only a portion of the market, and frankly not one I'm going to be missing.

It's really not.

Don't get me wrong, this is insanely cool, but it's still a long way from good enough to be truly disruptive.

To be fair, it makes sense when you look at the use-case that spawned margins in the first place: <h1/><h2/>, <h1/><p/>, <h3/><h4/>, <h3/><p/>, etc... It does make for a fairly elegant way of handling all of those permutations with a reasonable amount of attributes. That comes in to play particularly in cases where you don't have control over which will show up in the wild (e.g. when dealing with Markdown content)

Nowadays, small essentially means realistically useable on prosumer hardware.

I think the most reasonable issue many people have is that, from a utility deployment perspective, inconsistent delivery of service is bad enough in of itself and should be fundamentally actionable without having to involve any discrimination laws.

Who cares why ISPs are failing to provide a basic service to a chunk of the population? The government should be in a position to force their hand based on the fact that it's happening at all.

And I can see both sides of the argument here. One one hand, yeah, it sucks to be doing the right thing for the wrong reasons. On the other hand, government agencies' capacity at putting pressure on private enterprise has been severely neutered, and if this is what it takes to get essential services delivered, then whatever, I'll take it.

While I broadly agree with you at surface level, you are missing a piece of the puzzle.

The issue is that FCC is, correctly, treating broadband as a utility at a level comparable to electricity/sewer/drinkable water. And as such, ensuring that underserved people get access to the service is more important than punishing contractors for failing to deliver it.

I do agree that the discrimination hand-wringing is unnecessary, and a good "Deliver the service to everyone, assholes" should be plenty in theory. But if leaning on those laws is what it takes to get them to comply, then whatever. Results are what matters.

Coax runs in residential houses tend not to go through conduits, and often squeeze through holes in joists just barely big enough for the cable. Not to mention that, in my experience, they also tend to involve splitters in the absolute most random of locations.

Running Ethernet alongside it is rarely any easier than fishing from scratch.

The befuddlement goes even farther for me. LLMs are, effectively, black-box systems that interface with the world via a stochastic parrot interface.

You'd think that software engineers would be a group that easily understands how making radical assumptions about implementation details when looking at nothing but an interface is generally misguided.

I'm not saying that there isn't a strong case to be made against LLMs being intelligent. It's pointing at the stochastic parrot as evidence enough in of itself that confuses me.

At the end of the day, analytical Fourier analysis doesn't get nearly as much practical use as numerical approaches, and you don't really need THAT much background to make sense of DFTs.

I know that, for myself, revisiting Fourier Analysis after going through DFTs in my numerical analysis classes made a lot more sense, and I kinda wish I had started with that angle in the first place.

It is fair to assume that it'll eventually stabilize at some, probably meta-stable, equilibrium.

And both of them contain a bunch of protons, yet neither, nor their combination, behave like loose protons (aka Hydrogen).

From what I can tell, it's a for-profit company for a single dev that is attempting to get by through nothing but GitHub Sponsorships.

Said sponsorship is a requirement for using the pre-hosted files for commercial uses in a SaaS-like manner.

But some of the wording in the faq is a bit confusing. E.G. There's a whole section about "Why don't you just sell plans for the hosted API?" right after detailing how to sign up for said plan for the hosted API.

The head-scratcher is more like: If it's a non-profit, they (and I) would have expected a .org, which, unlike .net, has been used consistently over the years. But I get your point in general.

Have... have you ever seen Goatse? (If you haven't, please don't look it up just for sake of this and take my word for it)

It's the reference example for what a "shock image" is. How in the blazes is the choice of that particular image over practically anything else based on anything but its capacity at causing distress?

The blog post both acknowledges it as such, and even says "Let this be a lesson to you", making it clear that its use is specifically meant to be go beyond stopping people and actively punish them. And even if it weren't for that straight up confession, it'd STILL be patently obvious that this is what they are doing. We are in clear-cut "shotgun booby trap" territory here. As others have pointed out, there are subtleties at play over who is ultimately responsible, but the author's intent to cause distress is not in question in any way shape or form.

As much as it's fun to see vigilante retribution like this (and boy is it!), that does not discount the obvious legal exposure at play.

And, especially in the context where the same result could have been achieved as easily without resorting to law-breaking, how does that constitute a license to break other laws?

> The EU Data Protection Board, the European Parliament’s Research Service and the EU Council’s Legal Service say they are warning of chat controls. Ursula von der Leyen is not interested in these opinions <clown and red flag emojis>

This is straight up crass and off-putting. These shitposting emojis do not belong in a serious pitch.

If your system has the notion of users at all, then most of that red tape is unavoidable, no matter how privacy-respecting you are being.

Either a solid and affordable PaaS solution or at the very least a single global international standard is sorely needed here. The current model is barely sustainable as it is, and it's getting worse, even for privacy-respecting endeavors.

I meant error "in the code".

A chunk of C that causes a signed overflow has an error in it. Seemingly, so does Rust code according to the behavior described in the post I was replying to.

My point is that I question how big is the value gain from having a predictable fallback when we are already within the realm of "this code is considered wrong". This isn't unlike the various arguments against the value of compiler warnings.

That being said, I agree that it's preferable in general, but the difference seems rather marginal to me. That is, within the context of what I'm replying to. I wouldn't be surprised if Rust had a few additional tricks up its sleeve to address this.

> It only does so for debug mode. In release mode, it uses modular arithmetic.

So it's still treated as an error, just one that has a predictable fallback. I'm really not sure how that's much different from `-fsanitize=undefined`. Broken code is broken, even if it breaks in a predictable manner.

Now if the modular arithmetic had been enshrined as the expected behavior without being treated like an error to be caught, it'd be another matter.

Yes, you can tell the compiler to generate predictably-behaving output for non-compliant code. However, that code is not valid C anymore, but a dialect.

Since this is a discussion about what C is and is not, I think it's fair to limit ourselves to the actual language as-is.

It's not really a question of whether or not it's feasible, but rather: If the hardware were supports such operations, would they be expressible within the language? If they are, then we should point at the accessibility of the functionality rather than C.

In this case, I could definitely see `set_cache_behavior(ptr, len, options)` being perfectly reasonable, so I'd argue that, again, the fact that we can't do it is more a property of the environment than the language itself.

A lot of that is just a property of modern OSs, with good reason, intentionally not exposing these features to userspace processes. It's not really a function of the language itself.

You may think that intuitively, but actual studies actually indicate the opposite. Usage of CSAM material leads to increased risks of contacting and abusing children.

This needs to be balanced against rights to privacy and expression, which I personally think take precedence, but pretending that it can serve as harm reduction is just not correct.

Oh, my bad. Thanks for the clarification.

In that case, I would heavily disagree with your suggestion. Your "chill" PM is likely actively running interference on your behalf in order to allow you to spend time on such endeavors. It's a great thing when you can have such a partner, but most PMs (in my experience) are not willing to put themselves on the line like that.

> But I've got chill PM ...

Have you considered that perhaps your personal perspective is not exactly representative of large swathes of the industry and that many (if not most) workers do not have the agency and/or leeway to place place themselves in a comparable situation?

I wouldn't be so cut-and-dry with your assertion that the parent post is "lying".

"integrated" in the sense that the SDK comes with a compiler, but it's not integrated in the same sense as OpenGL where the compiler is part of the driver.

If you can compile that code, then you necessarily have the compiler at hand. You can't make a simple single code file example though. The build system has to get involved somehow.

FWIW, I think this is a good thing. Any non-trivial 3D project is going to involve some kind of asset baking sooner or later, which makes the barrier of entry to that negligible. At the same time, driver-driven compilation is just too convenient and sticky. That's a bad combination.

Seconding the first recommendation. WebGPU is currently the sweet spot between classic and modern approaches.

Also, don't be fooled by the name. While WebGPU was designed for the web browser, there are already some solid native implementations (wgpu and Dawn), and can definitely fill in the same role as Vulkan/DX12/Metal for most casual usages.