Hacker Newsnew | past | comments | ask | show | jobs | submit | dpifke's commentslogin

I use uBlock Origin for this, something like:

  news.ycombinator.com##:matches-path(/^/item\?id=/) tr a.hnuser:has-text(/^dpifke$/):upward(tr)
This mostly works, but only kills the user's comments and not replies, so it sometimes can be confusing.

Here's another implementation:

  news.ycombinator.com##.default:has(a[href="user?id=dpifke"]) .comment

It's off-topic, per https://news.ycombinator.com/newsguidelines.html:

If they'd cover it on TV news, it's probably off-topic.

This submission is literally a TV news broadcast.

There are lots of other places on the internet where this is on-topic, I wish people would have their debates there instead.


Since it was censored in some significant parts of the world, including Silicon Valley, it could arguably be on-topic.


Strong disagree.

Gay porn is censored in a lot of Muslim countries, that doesn't make it on-topic for HN.


Generally, porn isn't included in "anything that good hackers would find interesting". Censored news arguably is.


Lots of hackers find porn very interesting. In fact, my first "real job" as a hacker was for a company with ties to the 1-900 industry that had decided to expand out onto the internet (not just to sell porn). Stories about porn would be interesting, submissions of nothing but pornography itself ("because it's censored!") are not.

I would be more sympathetic to the argument that this is relevant if the submission was an article about media censorship, or CBS's audience or leadership, and how said censorship, audience, or leadership relates to technology or emerging trends in media.

But this is literally just a controversial TV news broadcast, that people of one political persuasion say was "censored" and people of another political persuasion say was held off the air "temporarily" until it met network fact-checking standards. That sort of political bickering is most uninteresting, and is most definitely not why I've been reading HN for the past few decades.


Hackers generally appreciate links to hard facts and analysis that are not available through popular channels.


This seems similar to the "Is Github Down?" submission problem, where the submitter simply links to github.com.

That's a poor submission, because by the time most people click on it, Github will no longer be down.

There might be an interesting discussion to be had about outages at Github, but the better submission would be an article or blog post about the outage, not just a link to the site and a three-word title.

If someone wants to write an article or blog post about this news broadcast, which links to "hard facts and analysis not available through popular channels," that seems like it might be a worthwhile submission. But just a link to the broadcast by itself is not leading to interesting or on-topic conversation—the top comment right now is an ad hominem attack against Larry Ellison, without any supporting facts or analysis that he had anything to do with this story at all.


The HN guidelines don't mention a submission's suitability for discussion, only comments.


The very first subheading is entitled "What to Submit." I quoted it in my initial reply as rationale for why the people flagging this submission as off-topic were justified.


"On-topic" and "suitable for discussion" are partly overlapping sets.

That's why the Submissions guideline section addresses being on-topic but not suitability for discussion.


As someone who has moderated online communities in the past, I recognize the value in having a page like this, to which you can point people if they want to enumerate such trifles instead of discussing the episodes or series themselves. Rather than just say such discussion is off-topic, you give them a separate, on-topic place to discuss it.

(I don't actually know if that is how this page came about, but it seems similar to other wiki pages I've seen used for such a purpose.)


At an untowered field, saying the airport name at the beginning and end of each transmission is standard phraseology.


In phonetics?q


Typically, at an untowered airport, it's something closer to "{airport_colloquial_name} traffic, {your_aircraft_type} {your_n_number}. {MESSAGE}, {airport_colloquial_name} traffic"

So, "Columbia traffic, Cessna november one two three alfa bravo [N123AB], three mile final, full stop, runway one eight, Columbia traffic"

At a towered airport, you'd say "Columbia tower" instead, and you don't have to repeat it at the end of your message.


If it causes more than $5k in damage. Otherwise, it's a misdemeanor.

But you probably don't want to be investigated for either.


A deliberate act of revenge against a former employer... wouldn't be given much benefit of the doubt by the courts.


https://unpoly.com touts "progressive enhancement."

Third link on the page ("read the long story") points to https://triskweline.de/unpoly-rugb/, which renders as a blank page with NoScript enabled.

Sigh.


It's because of the demo wrapper/layers. Try just the raw demo: https://unpoly.com/examples/modal/preview.html

Still not perfect -- the demos should work too. I love the idea of a progressive framework and am willing to work around a few things to get it.


Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.

(quoting https://news.ycombinator.com/newsguidelines.html)


Shouldn't you be out protesting your local chess club instead of posting on HN right now?


We do use gyroscopic power storage, see e.g.

https://h-cpc.cat.com/cmms/v2?f=subfamily&it=group&cid=402&l...

https://www.activepower.com/

...and probably others.

(A couple of decades ago I worked for a company that was a tenant at a datacenter that used these instead of batteries; it's not new or particularly exotic technology.)


Related: https://pkg.go.dev/crypto/subtle#WithDataIndependentTiming (added in 1.25)

And an in-progress proposal to make these various "bubble" functions have consistent semantics: https://github.com/golang/go/issues/76477

(As an aside, the linked blog series is great, but if you're interested in new Go features, I've found it really helpful to also subscribe to https://go.dev/issue/33502 to get the weekly proposal updates straight from the source. Reading the debates on some of these proposals provides a huge level of insight into the evolution of Go.)


I have to wonder if we need, say, a special "secret data" type (or modifier) that has the semantics of both crypto/subtle and runtime/secret. That is to say, comparison operators are always constant-time, functions holding the data zero it out immediately, GC immediately zeroes and deallocs secret heap allocations, etc.

I mean, if you're worried about ensuring data gets zeroed out, you probably also don't want to leak it via side channels, either.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: