There's some logic to wanting to assign responsibility for other's actions upon those who enable it. Like you say, to incentivize intermediates to police their users and those they do business with.
But the problem with deputizing intermediates is that it's too effective. It creates incentives to over-police and we have less rights against corporate policing than we do government policing. We would not have the internet we have today without the user generated content and moderation that section 230 enabled.
Like, as someone who grew up in the formative years of the Internet, I get it, but also, what we have is incredibly bad and it's very possible we'd be better off without it. The tech crowd does not want to admit that every single effing website that lets you post images has CSAM. Every one! The tech crowd doesn't want to admit an entire generation of our kids are screwed beyond belief by social networking. The tech crowd doesn't want to admit that Donald effing Trump got elected because our population is incredibly easy to manipulate.
Our society is very, very screwed up right now and it's very likely the principle cause is that we gave Google and Facebook complete blanket immunity, and that was an incredibly moronic thing to do.
If something needs Section 230 to exist, it shouldn't exist. Full stop.
Appreciate you sharing that. Agree with the overall concern with children using tech and I'd start with banning smartphones in school classrooms. Two observations:
Why stop with image boards? After eliminating all photo uploads, awful people still produced and shared illegal content. So then we eliminated unlicensed camera use. 'Course the real problem still happened.
Hacker News is made possible by Section 230... should it not exist?
This is false. Basically everyone that's argued this has been funded by tech companies. The reality is Section 230 is at best, an inconvenience for good actors, while being an incredible gift to bad actors. It lets a good actor avoid a possible lawsuit. (And law requires intent, Section 230 does not meaningfully protect someone who didn't intend to enable bad actors.) It guarantees a bad actor can profit off crime with impunity.
And I think the financial incentives in participating the Internet absolutely make it worth the risk for a well-run business, including one with UGC, to make reasonable risk decisions about their liability. (HN, selling no ads, nor hosting image or video files, probably has extremely minimal risk.) The marketing about the importance of 230 is crucially about protecting tech companies' immunity and ultimately, their bottom line, but it doesn't mean everything stops existing overnight.
But again, my position remains consistent: If it can't survive without Section 230, it shouldn't.
In Stratton Oakmont v. Prodigy, Prodigy ran a message board and would have escaped liability for defamation by a third-party save one problem: they exercised editorial control by moderating content.
Hacker News faces the same risk.
Respectfully I prefer a world where Hacker News exists.
Back in my day the local telephone company used waxed lacing cable for that sort of thing[1]. These days it seems that polypropylene string is popular (search on "conduit pull string").
You basically want something that is slippery and will tend to not get stuck. I have used Dacron fishing line, but that is mostly because I had a bunch of it laying around.
I wanted to reach you regarding your comment here: https://news.ycombinator.com/item?id=44547866 Would you be willing to maybe elaborate on the problems caused - I've planned to adopt Miro Sameks for an application?
DM me via my about me, if interested. Would be very thankful.
The picture in the article shows what looks like keypoint matching (ie, SIFT, SURF, FAST) between the query picture and the database. This can give an exact location if a picture of the location exists in their database.
They contrasted this with their prior technique which is more of an image classifier that can identify general location from image features. This approach does not require their database to contain a picture of the exact location.
A while back I looked at matching pursuit. At first it seemed very complicated, but after staring at it a bit realized it's simple.
- Start with a list of basis functions and your signal.
- Go through the list and find the basis function that best correlates with the signal. This gives you a basis function and a coefficient.
- Subtract out the basis function (scaled by the coefficient) from your signal, and then repeat with this new residual signal.
The Fourier transform is similar using sine wave basis functions.
The key that makes this work in situations where the Nyquist theorem says we don't have a high enough sampling rate is ensuring our sampling (possibly random) is un-correlated with the basis functions and our basis functions are good approximations for the signal. That lowers the likelihood that our basis functions correlating well with our samples is by chance and raises likelihood it correlates well with the actual signal.
Hearing in noise is both what most people want from hearing aids and what they are least equipped to provide.
The traditional solution is an FM system where you give the person speaking a microphone linked to your hearing aids. There are dedicated ones like Phonak Roger. You could probably also use your phone as a microphone if it's bluetooth connected to your headphones or hearing aids.
The tech for isolating a speaker at conversational distances exists. You use half a dozen microphone transducers (minimum; Crappy microphone transducers are cheap and quality is expensive, so just use a bunch of them), and through a combination of phase and intensity they decode relative location, and amplify that phase expectation while suppressing everything that isn't phased like that. Sound is slow, and readily susceptible to real-time triangulation. The math/processing is much easier if the parallaxes are fixed (eg the microphones are arranged in a line array on the top band of a rigid pair of smart glasses), but with a little latency it's not prohibitive for a deformable array to solve for its own relative position as well.
Often people who lose their hearing want to be able to hear in social situations such as restaurants and family gatherings. In this context, the signal and noise have similar properties and are coming from the same direction. Directionality helps but can only do so much. Noise reduction can make hearing aids more comfortable to wear but don't necessarily improve comprehension in challenging situations. Progress here is fantastic -- at the same time it helps to have realistic expectations.
Putting the mic on the person speaking sidesteps the problem -- it's like the rest of the room isn't there.
That’s more a solution for far more extreme cases, including actual hearing loss. This would be far more involved than me lining up my ears with their mouth ;)
Dan is a moderator on a forum and his goal is to maintain a level of civil discourse rather than an aggressive style of communication. It's a very specific definition of "violence" for a specific context and perhaps there's room for clearer terminology.
If talking about UI, the flip side is not to harm the user's data. So despite containing errors it needs to representable, even if it can't be passed further along to back-end systems.
For parsing specifically, there's literature on error recovery to try to make progress past the error.
1) Embedded systems typically do not allow data to grow without bound. If they were going to keep debugging data, they'd have to limit it to the last N instances or so. In this case N=0. It seems like the goal here was to send troubleshooting data, not keep it around.
2) Persisting the data may expose the driver to additional risks. Beyond the immediate risks, someone could grab the module from the junkyard and extract the data. I can appreciate devices that take steps to prevent sensitive data from falling into the hand of third parties.
It would be trivial to set it up to only delete old instances when free space goes below a threshold.
If the data can expose the driver to additional risks, then the driver can be exposed by someone stealing the vehicle and harvesting that data. Again, that can be trivially protected against using encryption which would also protect in the instance that communication was disrupted so that the tar isn't uploaded/deleted.
My favorite trick in C is a light-weight Protothreads implemented in-place without dependencies. Looks something like this for a hypothetical blinky coroutine:
typedef struct blinky_state {
size_t pc;
uint64_t timer;
... variables that need to live across YIELDs ...
} blinky_state_t;
blinky_state_t blinky_state;
#define YIELD() s->pc = __LINE__; return; case __LINE__:;
void blinky(void) {
blinky_state_t *s = &blinky_state;
uint64_t now = get_ticks();
switch(s->pc) {
while(true) {
turn_on_LED();
s->timer = now;
while( now - s->timer < 1000 ) { YIELD(); }
turn_off_LED();
s->timer = now;
while( now - s->timer < 1000 ) { YIELD(); }
}
}
}
#undef YIELD
Can, of course, abstract the delay code into it's own coroutine.
Your company is probably using hardware containing code I've written like this.
What's especially nice that I miss in other languages with async/await is ability to mix declarative and procedural code. Code you write before the switch(s->pc) statement gets run on every call to the function. Can put code you want to be declarative, like updating "now" in the code above, or if I have streaming code it's a great place to copy data.
A cleaner, faster way to implement this sort of thing is to use the "labels as values" extension if using GCC or Clang []. It avoids the switch statement and associated comparisons. Particularly useful if you're yielding inside nested loops (which IMHO is one of the most useful applications of coroutines) or switch statements.
I have used this approach, with an almost similar looking define for YIELD myself.
If there is just one instance of a co-routine, which is often the case for embedded software, one could also make use of static variables inside the function. This also makes the code slightly faster.
You need some logic, if for example two co-routines need to access a shared peripheral, such as I2C. Than you might also need to implement a queue. Last year, I worked a bit on a tiny cooperative polling OS, including a transpiler. I did not finish the project, because it was considered too advanced for the project I wanted to use it for. Instead old fashion state machines documented with flow-charts were required. Because everyone can read those, is the argument. I feel that the implementation of state machines is error prone, because it is basically implementing goto statements where the state is like the label. Nasty bugs are easily introduced if you forget a break statement at the right place is my experience.
Yes, 100%. State transitions are "goto" by another name. State machines have their place but tend to be write-only (hard to read and modify) so are ideally small and few. Worked at a place that drank Miro Samek's "Practical Statecharts in C/C++" kool-aid... caused lots of problems. So instead I use this pattern everywhere that I can linearize control flow. And if I need a state machine with this pattern I can just use goto.
Agreed re: making the state a static variable inside the function. Great for simple coroutines. I made it a pointer in the example for two reasons:
- Demonstrates access to the state variables with very little visual noise... "s->"
- For sub-coroutines that can be called from multiple places such as "delay" you make the state variable the first argument. The caller's state contains the sub-coroutine's state and the caller passes it to the sub-coroutine. The top level coroutine's state ends up becoming "the stack" allocated at compile-time.
Yeah. Protothreads (with PT_TIMER extensions) is one of the classics libraries, and also was used in my own early embedded days. I was totally fascinated by its turning ergonomic function-like macros into state machines back then.
But the problem with deputizing intermediates is that it's too effective. It creates incentives to over-police and we have less rights against corporate policing than we do government policing. We would not have the internet we have today without the user generated content and moderation that section 230 enabled.