Removing hate from a privately-run platform is not censorship. It just feels like censorship to reactionaries because their political beliefs are hateful and do not respect the categorical imperative.

Just to complete the set of views expressed in this thread: it is censorship, and it's also absolutely necessary if you want to have a civil society. Otherwise the whole thing - society, not just the platform - evolves into competitive death threats and thence into actual violence. This includes state violence.

You can no more run a social media website without moderation than you can run a nuclear reactor without a moderator.

It is censorship. Banning any content of any form for any reason, including legality, is censorship.

What people don't want to admit to themselves is that censorship isn't always a bad thing. Realizing that requires a degree of nuance that the internet currently doesn't support.

Also: censoring your own site is perfectly constitutional.

HN commenters always seem to forget the paradox of intolerance

I heard it described once that leftist thinking typically focuses on the justice of the outcome of systems, whereas rightward thinking often focuses on justice of the system itself.

A right leaning person might say, it is just to prevent people with means from receiving welfare. A left leaning person might say, means testing can leave gaps where some people are unserved.

The right leaning person says, "it is unjust to censor", the left leaning person says, "that system has a side effect -- if you are tolerant of hate speech, others will leave".

I don't know if this holds always, but now that it's pointed out, I see it in a lot of places.

It's not being played through a desktop audio stack, they're operating on the waveform decoded from the audio file. There's no constraints relative to the "natural speed" of the source, just like for video transcoding, it's limited by compute.

You can flip through the pages of a book much faster than it'd take you to actually read them normally. But if you're putting the book in a scanner then you're still extracting information, faster than the "natural speed" of reading them.

I understand that grandparents' suggestion that the audio is actually "played back" during the process appears to be a misunderstanding, hence "Yes, but..."

My point was that the "natural speed" of video (i.e. the frame rate - clear slow motion requires more frames, while fast blurred motion will generally have fewer) does actually impact how much data must be processed. It's true of audio too (sample rate) and downsampling is a common optimization technique.

I don't understand this framing of recomps using the word "stolen". For most games the hard part and the valuable part is not "writing the code", it's everything else.

I think it's less that recompilation is stealing the code, and more that it is a piece of the puzzle to 'stealing' the game experience (the thing that you would pay for).

Emulators + ROM is one way to do that. Recompiling from the ROM is another. I think that for most people, your stance on if emulating is stealing or piracy, will well-predict how you feel about recompilation tools.

In what world would emulation (i.e. product compatibility) be stealing or piracy? In a functioning market, we would have e.g. a Steam Machine advertising fully supported PS5 compatibility (and PS4 and PS3 and PS2 and PS1 and Wii and Gamecube and N64 etc. etc.), or a Legion Go advertising Switch compatibility. We should all want competition. You shouldn't need to purchase an overpriced crappy handheld to play specific titles when a better, cheaper one could do it just as well.

I swear gamers have the most insane Stockholm syndrome. It's super common to see them say that it's a problem that there aren't enough "exclusives" for a console. Like, dude, the problem is that the console sucks next to its competition. You shouldn't want product tying to try to make you buy it. They're literally all just branded commodity computers that are locked down to tie purchases (an illegal, anti-competitive practice) at this point. This was already litigated multiple times 20-30 years ago and the big companies consistently lost every case. Sega even lost a case where a company displayed the message "PRODUCED BY OR UNDER LICENSE FROM SEGA ENTERPRISES LTD" for a game that Sega had not approved because it was required for the console to boot, and they couldn't try to use trademarks to stop someone from developing for their console.

Emulation is primarily used for piracy. Easily 90% of emulator users are using ROMs that they do not have the rights to.

Possibly, but that's kind of a trivial observation when the only company selling ROMs is Sega, and everything else outside of PS1/PS2 requires a lot of technical sophistication to use original discs, by design of the companies complaining of piracy. Gen1 iPods were probably used for 90% or more pirated material too, but that's because the music industry really didn't want to sell music files (and went so far as to include malware on audio CDs to attempt to prevent legal copies). The iPod itself was still obviously legal.

You can also buy third party products that take original cartridges, but again the companies aren't interested in selling cartridges, so no surprise if they end up pirated.

It's like the Sega case: "we made it impossible to use our hardware without violating our trademark, and then they violated our trademark. OMG!" Okay? Don't do that.

Emulators and ROMs are so normalized at this point that even Apple are implicitly OK with it.

The bots might be run in the datacenter and proxied through residential IPs as the exit point.

If they are, then that wouldn't be YANDEX AS13238. So the linked graph wouldn't show these changes.

Maybe they do use an obvious IP from yandex datacenter IP range so that you believe they can't possibly be yandex's bot?

You won't see this kind of stats on the CF page.

All it shows is direct traffic against CF infrastructure.

I don't know if anything like this has been built, but I'd imagine you could have the hypervisor capture stack traces / log buffers / core dumps when a unikernel VM crashes.

I'm not a security researcher but I know that VMs have been the tool of choice to step through malware execution for at least the past 15 years. I recall coming across ida extensions for it.

> you should design it so that your language is easily and correctly statically checked.

You do that by making the type system more sophisticated.

If you have a really important invariant that you really don't want to be violated due to run-time behavior/input, it's a huge benefit to have a compiler that can statically check that it actually can't be. That's one of the main benefits of having type systems, not just describing the shape of data structures in memory.

You can perform static analysis outside of the compiler without putting things in the type system?

C is a bad language to do this with for various reasons, but as a simple example:

    char* buf = malloc(SIZE);
    free(buf);
    free(buf);

There is absolutely no reason why static analysis should not be able to see what the problem is here.

Sure, but what it is that makes you believe the compiler shouldn't be the one doing that analysis? Should it catch

``` ((void()(void) free)(buf); ((void()(void) free)(buf); ```

It's been my experience people invested in static analysis think of it like some wholly additive extension.

Compiler-independent static analysis is code applying rules. Someone has to write all the rules, align them with the language and the compiler. The user rarely reads the static analyzer's code or full rule definitions and is blissfully unaware of the full set of disconnects, inconsistences, and gaps between the coverage of the two.

They only notice divergence in the analysis when it generates a false-positive warning or error.

Static analysis adds compilation overhead. Sure, but I'd hazard that re-reading and in to some degree repeating the parsing/translation process that the compiler is going to do also introduces overhead.

There are some languages that demonstrate sta-by-compiler capabilities with heinous compile times, but it doesn't have to be that way. We can engineer better, but at some point it requires a price. Better comments, boilerplate of some kind or another, annotating intent over idiom.

A complex type system isn't ideal; with the right set of primitives you can achieve sophistication without complexity.

``` Freeable buf = malloc(SIZE); free(buf); // compiler error, you didn't check buf isn't valid. free(buf); // compiler error still if you fixed the above, free makes buf invalid. ```

"Making the compiler do STA makes it slow". I don't think that's proven one way or the other. There are examples both ways. "complex" type systems frequently have slow compilers, but if you look more closely that's usually because they're trying to compensate for the disconnect between organically emerged complexity in their under-designed type systems.

If it's so great, why does rust not put everything in MIRI into the compiler?

Miri is a runtime thing so it can’t be in the compiler.

The compiler could interpret all unsafe via it but then it would be very slow, defeating the point.

"can’t be in the compiler"

Can't is a strong word. You could 100% put it in the compiler. Yet you don't (for the reasonable reasons you give). The line between compiler static analysis and non-compiler static analysis is a design decision. "defeating the point" is a subjective and pragmatic decision, not one rooted in safety absolutism.

I didn't really phrase this particularly well: I meant that you cannot determine this stuff at compile time because it is inherently a runtime analysis. Of course the compiler could emit the Miri interpreter into a binary if people chose to put the pieces togehter that way.

uintptr_t x = opaque((uintptr_t)p); free((void *)x); free(p);

How will you find such violations if opaque comes from so or some ffi, so compiler can't see through? you can't. It's heuristics. Sound type system is much stronger

*ffi

Christ. Even rust makes ffi unsafe.

I mean you can annotate it if you want. Just tell the analyzer in a separate file, get the variable at this line on this file has these guarantees.

You could even annotate dependencies that didn't use your static analyzer. You could track custom invariants that your language designer didn't put in the type system.

> Even rust makes ffi unsafe.

Which is why every library that wraps C APIs provides safe wrappers that express the implicit expectations within Rust's type system. Yes the low-level calls are unsafe, of course they are, but then we expose them with a safe interface that consumers actually use.

typesystems can be considered a kind of static analysis

ok but what if you call

buf_create(SIZE)

and

buf_destroy(buf)

now the compiler has to infer that buf_create creates a lifetime and buf_destroy destroys it.

we're back to Rust's Box.

Congratulations, you have hit upon one of the reasons why c is a bad choice. Other languages make this easier.

How could that possibly work without a semiconductor?

So why does the government get to do all of those things? Especially when they've already demonstrated that they're not very good at using them to achieve the stated goal of improving security.

This is a dishonest comparison. The atmosphere warming has a much more immediate impact and the ocean isn't a perfect heat sink.

Air has a specific heat (~1) less than a quarter per unit mass than water (~4.1). The atmosphere has a mass of ~5 billion kgs and the ocean has a mass of ~1.4*10^21 kgs.

It requires a lot less trapped energy to warm the atmosphere by 1 C than the ocean. We're well on track for 2.5 C increase since preindustrial levels.

Yes, it'd probably be compiled into very machine code. However defining an enum for it puts the intention into the source code more explicitly, so that's considered the more idiomatic way. You'd probably have a `fn peer_id(&self) -> Option<Inet4Addr>` accessor that you'd use in the case where you'd want the Option.