gervu

Yeah, like the cops have never gotten caught claiming someone accidentally fell on 43 bullets before. Or like there haven't been numerous cases of misattributing COVID deaths because they were inconvenient for the genocidal robber nihilists we have passing for a major political party. And that's just malfeasance, there's plenty of just plain error involved.

Having a deaths count -- which itself definitely has error bars, otherwise what the heck are missing persons estimates -- doesn't mean you have a correct attribution of those deaths. Never trust data in the absence of auditing how it got there.

Users trying to kill kernel_task sounds like an uncaught design problem. Replace the kill options in context drop-downs with "Why can't I kill kernel_task?" and have it pop open a short explanation, do the same as a feedback message if anyone tries to kill in the terminal.

If the system doesn't do that already, either nobody considered that users would try that particular nonsensical thing, or nobody cared enough to let users find out immediately instead of wasting their time thinking the computer was at fault.

"Are highly effective" is a massive understatement; they finance their campaigns and provide their unofficial retirement plans. The reward structure is what it is, and the behaviors that optimize for that reward structure are unlikely to change without somehow demolishing it and replacing it with one where the rules and their many workarounds aren't written by the beneficiaries.

"A politician is talking" should also at a minimum be treated with the same skepticism as when you encounter any other form of advertising. Even assuming the person speaking is completely ethical and aligned with your specific interests, it's literally their job to convince people of things. Assuming their job is "making laws" or "governing" is a lies-to-children version, they have to get a group of people to agree on some specific set of laws or policy for any of that to happen.

The flag button is the report button.

Flagging puts stuff in the moderation queue to be reviewed for abuse / spam. Please don't abuse it for other purposes.

Downvotes exist, but are hidden until you've posted more than some threshold I forget the exact value of.

The idea is to help prevent the downvote button from being even more of a "I don't like what you're saying but can't muster a convincing response to it" button than it already is, while making it convincingly difficult to manipulate via spam accounts.

It's much better at the second than the first, people being what they are, but it does seem to help with both at least enough to justify the feature's continued existence.

Elixir and Erlang both yield BEAM bytecode, which is what actually runs. There's zero difference other than a choice in interface design, which is why they're also completely interoperable.

Phoenix is basically a feature wrapper around Cowboy which is written in Erlang and dates to 2011 when it reimplemented Webmachine which ran on Mochiweb which I am too lazy to dig up the actual start year for beyond "had quite an install base when Rails was in alpha."

Again, potentially useful argument, but you're pointing it in a direction that doesn't make any sense if you actually understand how those work.

That's certainly an argument to be made, but I think you've overlooked the part where Erlang predates Rails by about two decades.

Wow, one character from a region that makes up 60% of the world's population? How radical. Next you'll be telling me that I should be worried because they included a black character and a female character.

If anything, the fact that anyone considers this at all notable should be a sign of just how racially biased casting is in most Western media. The world isn't nearly as white as it looks on your TV.

> ML has advanced so much in those 5 years that all my prior experience is totally irrelevant to them

Most people involved in hiring are either not involved with the work being hired for, and thus have no idea about that side of things. Or else they're total amateurs at hiring itself who have, by virtue of having some measure of authority over it, deluded themselves into thinking they are awesome at it.

Arrogance and bias will lose you an awful lot of qualified applicants.

It's not even that hard to work around that problem, if you're willing to shut up and listen. You can easily factor an objection as a concern instead of shutting them down entirely, which lets the applicant either show you that it isn't a major problem after all, or respond in a way that confirms that maybe it is.

The fact that some things are getting better doesn't change that others are simultaneously bad, or that things could maybe be more better if resource allocation wasn't so drastically unbalanced.

I seem to have severely underestimated the ability of HN readers to see basic economic data that's both well known and easy to look up like the rate at which the wealth of different demographics is changing as uncontroversial, which is...well, it's a thing.

I have a highly complex understanding of wealth but I'm also very tired and typing into a web forum with a touchscreen. Some simplification is entailed.

Particular definitions of wealth depend on what's contextually useful, and are thus quite varied. But I've yet to see one that deals with having an increasingly poor Gini coefficient in a way that makes that a desirable outcome, or which absolves people of intentionally pulling on it for their own benefit without regard for how that impacts millions of others.

People doing obviously shitty things to society are doing shitty things to society, and you'd expect a good definition or model to show as much. If you fit an elephant to the data and squint in a way that makes it sound like it's actually good, when that contradicts observable reality to first order, it's probably a bad model.

Based on your quote, I think you may've meant to respond to the other reply.

But a great many people don't have washing machines or air conditioners. You can rent the former, at the cost of more money and time. People die every year from lack of access to the latter.

It's not like air conditioners themselves are necessarily insurmountably expensive, although that varies by location, but you have to factor things like socioeconomic access to housing that comes with or allows it, as well as the cost of power to operate it sufficiently, plus having it be affordable enough that you already have it before it's a heat-stroke-and-die problem for you to not have it.

Sixty year olds with bad hips and fixed income don't generally go out and buy an air conditioner because it's hotter that year. Not everyone is a healthy twenty year old male with flexible disposable income, and sometimes people die because of the assumption that those form a useful ideal model of the overall population.

We have lots of abundance. The problem is that the future is, as they say, not so equally distributed.

It's hard to solve things like poverty when a tiny minority is hoarding most of the increase in wealth, and in fact often profits or draws political power from maintaining inequality in its various forms.

Between Elixir and Erlang, there's no difference because it's all BEAM bytecode when it runs.

Between arbitrary individual functions you might encounter, there can be differences, but only in the sense that it could happen between Erlang and Erlang if the functions had different implementations or degrees of optimization or optimization choices.

Worth noting for prospective adopters is that you can seamlessly call Erlang functions from Elixir by adding a : prefix, such as :random.uniform(), and there's no weird overhead or surprises involved.

It's often worth parsing "people would like" as "marketers think people would like."

Or even, "although people would like, someone's trying to maximize profit margins."

And that second one is notably is taken within the scope of that quarter, or the next few years that they expect to work there, or even the next few decades before they expect to retire. Which often conflicts with longer-term sustainability problems like retained biodiversity.

The two named species from the research are Homo sapiens denisova and Homo sapiens neanderthalensis. We're Homo sapiens sapiens, because we ate the wise-wise fruit.

(The other two are nameless data ghosts at this point, due to lack of corresponding archeological records, but presumably Homo sapiens whateveris and Homo sapiens someotheris.)

It's kind of open to debate whether those should be independent species, or their own species, but basically we're all Homo sapiens of one sort or another unless you want to get into a long unresolvable highly technical argument about it, which revolves around what precise definition of "species" is useful in some arbitrary context.

Addresses that are obviously professionally inappropriate are one thing. Otherwise I pay approximately zero attention to them, outside the context of "do I have the right one" and "how likely is this to be a phishing email."

In the context of picking one for myself, I would also worry about usability factors, like if people are likely to confuse one thing for another, or not doing things like putting a long random character sequence as the user name.

"Pseudonymization but with an extra syllable" sounds just as confusing as the other two. I wouldn't be sure which of those words I was looking at on first glance, which is what you'd need for it to be casually readable.

Pseudonymization already refers to reference by pseudonym.

Pseudonimization is bad terminology in that it's indistinct from the above, to the point that parent has already mixed the two up while in the process of recommending it. And it'd be worse verbally.

"Pseudo-anonymization" could work, but something like "breakable anonymization" or "partial anonymization" might be better in that it's more obvious to a reader and doesn't rely on familiarity with technical terminology to convey the idea.

I'd go with breakable, myself, since it's most to the point about why it's a problem.

Pseudo is etymologically correct, but that doesn't necessarily help us much when the goal is ratio and ease of understanding by a wide population of readers.

Partial could work in the sense that you did part of the job, which people would hopefully understand is a bit like having locked the back door for the night while leaving the front propped wide open.

And there are probably other good options. If I was writing about this topic often, I'd strongly consider brainstorming a few more and running a user test where I ask random people to explain each term, then go with what consistently gets results closest to what I'm trying to discuss.

It seems like a lot of things that sound an awful lot like fraudulent practices from a lay perspective don't actually reach a useful or provable definition when it comes to legal liability.

But saying something is sold by a specific party which I then choose to do business with, then substituting goods that are likely to be from any of numerous other parties, some of which I may be explicitly trying to avoid doing business with...I would at least be interested in hearing why that doesn't count as fraud or false advertising or some such, or maybe some trademarks issue.

At least, I'd love to hear a less rage-inducing justification for putting up with allowing this behavior than "it was buried in a ToS somewhere that lying about who my goods came from is okay, actually."

Automation of any sort will sometimes accidentally your data, whether due to periodic hiccups, system instabilities and bugs, operator misunderstandings or errors, or random cosmic ray strikes.

The exact reason it blows up isn't even necessarily all that important, other than in its effect on what you should be doing to reduce the probability of downtime. Well-engineered systems are routinely developed from less than completely reliable parts. Stuff fails, we design for it.

It's certainly not reason not to use it, if it's resulting in a net positive gain in your ability to get things done and maintain control and transparency over your deployed systems.

But it's certainly a good reason (among a long list of good reasons) to make sure you have a good backup routine in place, including regular testing of both their integrity and your ability to restore a working prod system from them quickly.

That sort of implies that there was some river of theft intent that they were keeping dammed up.

Which, could be the case, or it could be that announcing the policy change was the equivalent of announcing your upcoming month-long backpacking tour on Facebook after posting your address and photos of most of your valuables.

(It might be less declaring open season on theft, than a perceived increase in vulnerability triggering a surge in attempts to exploit it, more of which succeed than usual due to some actual increase in the odds of successful theft, complicated by the additional security risk posed by the confusion associated with a major policy change.)

You'd really need to dig into the surrounding data to find out which model is valid and in what proportions.

Unpopular opinion? Nah.

It's fairly well known that they're problematic at best, in that they epitomize the practices of an industry obsessed with exploiting younger workers, crunch time, and gender imbalance.

This article hits most of what I'd have to say on and around a question like this. It does discuss Java, not Kotlin, but Kotlin is JVM so it really doesn't change the answer meaningfully.

https://rclayton.silvrback.com/speaking-intelligently-about-...

There is no "but you're good enough for the grant if you're good enough for the core" or "lose the 15k" or whatever. It's not there to be an independent program, it's there so they can cover bets they otherwise lack the space to engage.

Think about it in terms of logistics.

They go over applications, which are attached to core program applications, so they decide who to accept, then they grab the pile that was good but couldn't fit and award grants to some of those that sent the auxiliary application for a grant. Then they send award letters for both.

After they've sent letters, whose grant do you propose they retroactively deny to make room for someone who got the main prize but changed their mind about accepting it and just wants money?

They could hypothetically set it up so you could pick one, but that adds a bunch of extra work to administer it, plus you'd get people trying to game the process by sending in core program apps they don't intend to follow through on. So it doesn't make any sense for them to do it that way.

The longer I've been around open source, the less it's seemed like some ideological adventure where we extend human knowledge and capabilities for its own sake, while looking more and more like a set of intentionally confusing layers of abstraction and indirection around companies with plenty of money to spend on more engineering hours contriving to buy those hours well at below minimum wage by selling people on the above ideological vision.

Also, I'm going to guess that's something like five active contributors signed up, not five full-time engineers, meaning the actual number once you do the math for availability and such is probably closer to half an engineer. Could be five, but Heartbleed kinda put paid to reasoning like "pip is important, surely it has the funding for dedicated contributors who aren't distracted by something else being their real job."

Because users never wanted mathematical randomness. They wanted variety.

Not that saying "random" is wrong, but users mostly mean it in a colloquial sense, while programmers are apt to interpret it in a technical sense. But one leads to math.urandom() and the other to shuffle algorithms.

Malware happens because arbitrary JavaScript and bad browser API decisions. Popping background requests for stuff you don't actually want to run or display doesn't require executing arbitrary JavaScript.

That's the direction of your mass-energy vector, not seconds.

A bit like complaining that UTC is wrong because it doesn't match your local Solar time.

No downtime is "unicorn feathers" territory. Extremely low downtime requires redundant systems and a dedicated support team actively trying to head off potential problems. And Gmail still has downtime.

But you're asking the wrong questions. Email itself has retries built in, it doesn't need perfect uptime. What you should be asking is how badly Gmail deciding you might be a spammer and not caring about fixing that for one person is going to torpedo your deliverability rate.

Workers hanging is a thing that happens everywhere. (You might not have enough resources if it's happening often, though.)

You should design the workers so that what needs to happen still happens in the event of expected failures, or so that it at least fails gracefully and with a useful paper trail. Failures happen, good engineering anticipates and plans around them.

For example, you could schedule up to three attempts spaced at least five minutes apart, set a timeout on jobs so they don't stay open indefinitely (appearing to hang), have jobs that still fail get routed to a dead queue, and make sure worker code behaves appropriately in response to internal errors and improper input data (such as getting an HTTP error or unexpected MIME type) while logging any unexpected states for later review. Most of the point of a library like Celery is that it makes common strategies like these easier to implement.

You mentioned in a reply that the jobs are requests to external websites. The rate of errors from that is going to be like a thousand times all other sources of jobs not completing as expected unless something is hella weird with your setup.