skysight-inc/HackerNews huggingface dataset:
> package managers are pretty similar. The major difference with Arch is you're heavily recommended not to do partial upgrades, but pacman will do it if you really want to. That's a difference in update philosophy between batched releases and rolling releases, not a difference in the package managers.

No it’s a difference in package managers. Pacman doesn’t take into account library versions when resolving dependencies, it’s why partial upgrades aren’t supported because the only way to ensure every package you have installed is linked against the version of its dependencies you have installed is to have every package on your system come from a snapshot in time of the whole repo package tree.

Better package managers don’t have this problem and understand how to not break your system with partial upgrades. This matters as soon as a new version of a package has a bug and you want to downgrade it, or you build and install a package from the AUR which, when you later update your system, could need rebuilding to continue working, but pacman has no way to tell you when this is the case.
> an incredibly low outcome of success

Why d'you think? Helion has been super successful with their demos so far. The timelines are optimistic but I don't see why you'd expect the technology itself to fail with, say, >80% probability.
I'm really sorry to hear that. This post is bringing back memories of my uncle. He had a two year battle with battle with brain tumour, and he was the smartest person I know, Principal scientist at Qualcomm.

After learning about his terminal cancer, I didn't know what to do. I distracted myself with work not knowing how heart broken I was. Finally after two months, it took a very intense yoga class to break me open and let out the tears and face the grief of losing him.

As others have mentioned, talking to a therapist will help you navigate the feelings so that you can be more present with her, in whatever capacity you can.

I have such fond memories of the little things I got to do with him. The little big things.

take care of yourself <3
There are many misconceptions about async python I keep seing again and again. I'd like to offer an alternative point of view:

- async python is faster, but for a very specific niche of workload. Most tasks you do don't fit that workload at all. Which mean most of the time, you should NOT use async Python. And it's ok. Don't make your code complicated when you don't need it. Chose a tech for the need, not the hype.

- async python is not just for performances. It helps with making some specific kind of concurrency easy to reason about, because the context switch is explicit, and the chain of event can appear linearly in the code, thanks to await.

- it's ok to have some sync processes and some async processes. It's not one or the other.

- async is not a replacement for threads or processes. In fact, there are good use cases for having several processes, each with several threads, each with one event loop. Which also means that if you benchmark your WSGI code with 16 workers, you should do so as well with your aWSGI one.

The corollary to this is that some web site loads are very well suited for async (e.g: an SPA with a lot of connectivity which delegates long running code to other services), but a lot are not. If each request makes a long SQL query, seeks the hard drive, dynamically performs i18n and adds some calculation on top, it may very well block the event loop for too long, killing any benefit.

So when would you use async python ?

- For performances, when you need to maintain numerous long connections. E.G: doing websockets ? Use asyncio. Serving static files without nginx ? Use asyncio. Want to create a web crawler and your memory budget does not allow to open 10000 threads ? Use asyncio.

- For the interface, use the async/await keywords everywhere you need need inversion of control for I/O. It's not just about perf here, it's also a mechanism to delegate arbitrary parts of your code with a common standard interface around a fancy state machine + scheduler. You can use that to abstract all your I/O and switch backends at will, while offering callback inlining.

But again, you have awesome threading and multiprocessing pools with python. Not to mention tools like zeromq, scrapy or celery, which do a lot for you. Don't run to async just because "it's faster".

Having async by default in frameworks like fastpi opens up a ton of possibility though. Live settings, pub/sub between processes, websockets...
Budapest, with a side spot in Spain, and my ski pass in the Alps
The impact of the name on the child/teen/adult is often overlooked. Great to see you've considered the negatives, especially how the name/initials could be used against them.
If you are asking him what use case he is describing there, it's dark net markets. Buying and selling of drugs and other items via TOR using crypto currency.
Statistically, gun owners are far more likely to be injured by their own weapons than the weapons of others, and the sheer availability of firearms forces law enforcement officers to escalate situations far more quickly than they otherwise would. It follows that people who are walking around with guns live in fear of confrontation with other people who have guns.

I have had five personal relationships with people who have died due to firearms. They are as follows:

1. My cousin, who killed himself while hunting ducks

2. My childhood friend, who killed himself while cleaning a rifle

3. My childhood friend, who was killed by cops after falling asleep at a railroad crossing and dropped his phone in the car when the police approached

4. My uncle, who committed suicide

5. Another childhood friend, who was drunk and disorderly and shot to death by cops while unarmed in the front yard of his house

On the flip side, I don't personally know a single human being whose life was either saved or made better by possessing or being around someone who possessed a firearm.
Hard disagree with the reasons given for "2. Orchestrator Lambda." While step functions are very useful and have a variety of uses, they're also VASTLY more expensive to run (the cost continues to go down but last I checked, 2.5x more expensive). Orchestrator lambdas are extremely useful, and given care in code, architecture, separation of concerns they can be extremely useful and very light. The author's point on this seems more like "I haven't seen this done elegantly" or "I tried this and my code became unmanageable," and doesn't provide solid evidence for an argument against them. The argument made could apply to any unit of infrastructure that contains code.

I believe "4. Lambda functions calling Lambda functions" speaks to what I believe are the author's shortcomings for #2, with the caveat that "Cost" is definitely a consideration, as waiting for a waterfall of lambda calls will incur more cost. Call-it-and-forget-it is the more cost-efficient method for lambda-to-lambda. I trend more towards pub-sub for this scenario if the call-stack is more than 2 lambdas (e.g. lambda calling one lambda, end of stack). The author doesn't mention SNS curiously, which would suggest some inexperience in this theater. SQS can be used if payload process explicitly calls for the capabilities of SQS, but bare SNS is much more suited to light pub sub duty.

Overall, this seems like a rather reductionist article written for the SEO keywords rather than content. Anyone happening across this should deep dive "the why" behind each of the claims before taking it at face value. And I wish the article stated that at the very top.
No, it does not. It is information asymmetry.

A good employer assumes that only bad employees are left in the market. As do good employees think that only bad employers are looking via job ads.

Hence more and more god jobs are filled via referrals from fiends etc. I basically think the same about job ads. Why bother applying?
Last time I checked, everything is still running on von Neumann/Harvard CPUs. Did I miss a major revolution in computing?
I think about this a lot as I have been fully remote since 2019, but have yet to execute on a family move.

If I didn't have a dog, I would definitely spend a few years in places like Portugal, Thailand, Vietnam, and other countries in which I could have a nice experience relatively cheaply. The time zone is a bit of a challenge though, as work starting at midnight makes it hard to enjoy.

For settling down, though, I would have a hard time living too far from a big city. I've tried to live the quieter life, but I just need the energy that comes with those large communities. Boston, NYC, London, Toronto, Chicago. Preferably a small town house near public transportation.
The isotope of helium they want to use doesn’t exist on earth in significant quantities. They want to make their own by running another fusion reaction between two deuterium nucleii. Deuterium is plentiful but this reaction will take energy and “activate” (make radioactive) some components of their feeder reactor.
Every component now needs a ref. Isn't that a problem?
My wife is also pregnant and this is the first baby-name app I don't hate.
Also one factor slowing some studies has been the need to wait for test cases: you can't infect people with, say, Ebola so you need to wait for enough people in your study cohort to contract it naturally to get enough data to say whether a vaccine candidate is having an impact. During a pandemic, it's sadly easy to hit a statistically-significant number of infections.
>There is no way the risk is as high as hiring managers estimates

For programmers? A programmer who is irresponsible and isn't tightly bound by process or peer review can absolutely wreck your small/medium sized business.

Have you seen the sheer amount of companies that don't have backups or aren't sure if their backups work? Additionally, consider how the community considers killing production a "tee hee we all make mistakes" thing
CircuitMess Ringo – DIY Mobile Phone Kit
> The parent statement was not literal

Correct. Instead it was agenda driven sarcasm, which while not forbidden on HN, adds nothing to, and always lowers the quality of discussion.

Rather than take the emotional bait and be sarcastic in return, the person who responded pointed out the misrepresentation that was behind the sarcasm, which is the most civil way to address it.

Their response was far more measured and constructive than the "take it to Reddit" response that the parent comment type usually elicits. There was absolutely nothing stunning about it - rather it was a standard civil response method in a debate whose civility has been lowered through sarcasm.
There are many support forums for cancer, often specific to the type of cancer. Please consider joining them.

Those are of great help is many ways - they can tell you what to expect during various stages of the treatment, long term issues, clinical trial information (may be important if you're eligible), as well as support and success stories. People are always super helpful if you ask them questions.

In addition, if there's an inherited risk for the type of cancer, get yourself tested at the appropriate age.
Works at Facebook, opinions are my own.
I find this article highly speculative. Facebook or Meta has not said anything on future uses, but that's for a lot of other things. Company hasn't said anything about not making weapons in the future as well.

In my opinion facial recognition technology has genuine uses, however from the privacy perspective, I personally would want all of these models to be running on my device. Google does it and so can other companies including Meta, and I find that completely fine as long as it's relevant to me and I have an option to turn it off.
It's not an internal password, it's more loosely password-protected. I've shared it with the permission of the teacher involved. This book will also be phased out soon.
I've been thinking about this for a year and haven't found any downsides
I work in data science and engineering, so not using python is not really an option. I'd love to use Julia and Rust instead, but the ecosystems and users aren't there yet.

Python continues to earn its reputation as the second-best option for most problems.
> since the concept of owning means of production is a core part of capitalism and IP is a means of production

Means of production are scarce property which is used (and consumed—even if only for a time) in the production of other goods. "IP" is not a means of production because it is not scarce. This also implies that it is not property, despite the misleading name. It's a social engineering project instituted by governments and not a core element of capitalism.
Folks looking to implement the outbox pattern with Apache Kafka may find the support provided for it by Debezium useful: https://debezium.io/documentation/reference/stable/transform....
Debezium is implementing log-based change data capture, i.e. there's no polling on the outbox table.

There's also an extension for Quarkus (https://debezium.io/documentation/reference/stable/integrati...) which makes it very easy to implement the pattern in Java applications.

Disclaimer: I work on Debezium
New York Federal Gold Vault – More gold than anywhere else, ever.
Do any of these projects have more than 1-2 active maintainers?
Thanks for the link.

Overall a good article, yet I also think it's important to emphasize strong social connections, as well as mindfulness and mindset training.

For the things which help to live a great life, we also have some evidence-based information which I find insightful:

https://en.wikipedia.org/wiki/Blue_Zone

https://en.wikipedia.org/wiki/Grant_Study
I would have a much more charitable interpretation. At its heart, most organizations are always on the lookout for great people. It's a really bad sign if you don't have room to hire someone great if you find them.
Don't get too hung up on this toy example being a database.

The bottle neck could be any form of downstream service, possibly one you do not control.

Not everything is a CRUD app running in the cloud.
Even big carriers with automated workflows get this wrong, e.g. put "Rémi" in your Amazon address, get a confused UPS driver looking at a "RÃ©mi" label.
I think we can safely leave that to the next generation to clean up, like with all those other contaminated zones.
For me, it's when the kids get vaccinated.
We live in the future that people who wrote Snowcrash were dreaming about. It turned out to be a lot more boring than a novel -- who would've guessed? -- but it's still cyberpunk AF for insurance companies to be limiting payouts in event of cyberattacks. For... checks notes... Auto rentals and cell phones.

Straight out of Deus Ex.
It's absolutely possible to have JavaScript coexist in a potentially hostile environment. We utilize a secure reference cache for Transcend Consent so that potentially malicious scripts cannot interfere with the operation of our consent manager.
Google Temps Fought Loss of Pandemic Bonus. and Won
It was a hybrid of low-effort vulnerability scanning and targeted inventory scraping. Many dealerships in the automotive space will pay gray-hat third parties to scrape and compile data on their competitors.

The irony for us as a provider is that it's one of our customers (party A) paying a third party to scrape data from another one of our customers (party B) which in turn affects the performance of party A's site. We've started blocking these third parties and directing them to paid APIs that we offer.
I agree and I really like that way of framing it; I want interfaces and contracts strong enough that I don't have to care about the implementation.
Facebook: we're moving away from this ethically and morally reprehensible technology

under their breath because the IP is better held in a different part of our corporate structure.
and forcing people to work with walking bioweapons is not a choice either, so I don't see your point.

losing a job is not nearly as problematic as killing people because someone couldn't be arsed to take a couple jabs.
The only way this could even conceivably be done in a scientifically valid way is randomized controlled trials, which would mean not giving the same interviews to all candidates, which is only possible if hiring at a large enough scale as to even be able to sample meaningfully from multiple "interview type" groups, and it would of course require it to be legal to give different interviews at random, which I'm not sure is true. I guess as long as it's actually random, you're not discriminating against any specific group, but it isn't exactly fair and you risk killing goodwill of your employees when they realize you're running experiments on them.

Of course, it's really not possible at all to do this at the level of rigor expected of, say, clinical trials. Each new hire will know what type of interview you put them through, and there is no reliable way you can prevent them from telling others.
On the home page:

"How to Protect Your Family from Cyberbullies"

In the details:

"8. Make sure you have the coverage you need.

If, despite everything you do, your child is a victim of a cyberbully, your child may become distressed, anxious, depressed, or worse. Make sure you have insurance coverage that can help you put security measures in place, provide your child with counseling, and even protect you if your child happens to be the bully."

Hmmmmm. Are they planning to sell special cyber coverage?
I mean we currently have Google and Facebook clawing the entire web, and plenty of us are using BBSes and newsgroups to get away from them.
Helion might not work out like they hope but if it does, it'll use aneutronic fuel, producing only 6% of its energy as neutron radiation. That's low enough that they don't need a heat cycle, which gives them a shot at a pretty low cost per kWh. I think they've estimated four cents, which is pretty good for scalable, dispatchable power without batteries.

The UK recently announced a regulatory regime for fusion, with significantly lighter requirements than fission since safety and proliferation issues are much less troublesome. That would be even more the case for aneutronic fusion. Possibly the US would be silly enough to get in the way but many other countries certainly wouldn't, including China.
Thanks for the feedback on the ads! We've been experimenting a lot with different ad formats recently. I'll make sure this is fixed. (Update: Fixed now, thanks again for the honest feedback)

In a comparison between IHP and Yesod I think that IHP is designed for people that have only very little to no haskell experience. IHP brings a lot of conventions and code generators to get you up and running very quickly, while Yesod gives you more flexibility (flexibility might be more challenging when you're just starting out with haskell. E.g. what DB library do you want to pick? In Yesod you have many options, in IHP we'll provide one out of the box). Check out the IHP documentation and compare it to the Yesod docs, you'll quickly see the difference :) Also if you want to check out some reviews of people already using IHP, you can find a few longer ones on our G2 page https://www.g2.com/products/ihp/reviews

> Can I create rest and especially graphql apis or is it more focused on building old-school server side rendered pages?

At the start IHP was focussed a lot on server-side rendering. Now you can also use it for building REST APIs. GraphQL is not yet supported, but it's coming in the future.

We're also right now working on a generic REST API layer with a bundled JS SDK. It will allow you to query your database, create and delete models and keep everything in sync with a realtime sync engine.

Here's a JS code example:

const tasks = await query('tasks')
.orderBy('createdAt')
.fetch()

On the backend we use Postgres Row-level-security Policies to make sure that a user can only access his own data.

Here's a demo react component that uses the new JS APIs: https://github.com/digitallyinduced/ihp-datasync-demo/blob/m...

Docs are still in progress, but here's a draft https://github.com/digitallyinduced/ihp/commit/39baa4aa23cc6... :)
> A bigger worry is that async frameworks go a bit wobbly under load.

Async should generally be better for throughput because you can complete work items without interruption, whereas context switching will give all threads a chance to make progress. Async will start to have issues once you do any sort of non-trivial processing in the event loop. The irony is most cases employing async are latency-sensitive, not throughput-sensitive.
And unfortunately the window for this closes before a skeptic will get desperate. Once people go on a vent they appear to become open minded to other treatment options.
HeadlessUI is one of the newcomers, with a lot of name recognition due to its affiliation with the wildly popular library Tailwind. The term has been around much longer. The first commit of the awesome list was over 3 years ago, and I suspect the term was already fairly established at that point: https://github.com/jxom/awesome-react-headless-components/co...
Try to understand why this viewpoint exists. We are all logical people. The difference is in the trust of public media and government. Both sides of the argument are mostly right in what they believe given the information they are consuming. My suggestion - read sources from both sides before deciding that anyone slightly against Covid hysteria is misinformed and is an anti-vaxxer. Second suggestion, anti-vaxxer is a really misleading and extremely divisive term.
I can’t tell if your first list is misconceptions or your rebuttals to misconceptions. You said it’s misconceptions but I think it’s your rebuttals.
I agree absolutely.

It's always a matter of choosing the least worst solution with Python, and additionally patching over shortcomings of the language with afterthought-tooling.
This is not cyber insurance, so this isn't exactly surprising? There is separate insurance for Cyber.
>> these organizations have mostly trended in the right direction

[citation needed]

Not sure how many times the government and pharmaceutical companies have to be proven horrifically, detrimentally corrupt before people become concerned enough to push back. For many, the answer is "after it's too late".
Intelligence officers, not to be confused with Intel, the company. I don't understand why a headline would not use the full word.
The biggest advantage of running a Haskell shop is probably that it imposes a strong intelligence filter on the devs you hire.
You don't have to divulge company secrets, talk about public knowledge from the company, ie frontend design (React, Angular, whatever), any outer facing APIs (REST, SOAP, RabbitMQ, whatever) and stuff that is public knowledge, ie. stuff from blog posts or general knowledge (like GCP/AWS/...).

Besides that, you can always just not say what company something occurred at or be vague enough.
Why no integration with Strava?
Ha, awesome. I went through the exact same thing of getting a bit stuck on names and trying to solve it algorithmically. My approach was using very simple Bayesian classifier to try and find sounds and spellings you liked.

https://twitter.com/lemonwatcher/status/1286082683412582403
I don’t see anything dishonest about the post, they say clearly ‘2+ years of experience with React projects’, that’s about as entry level as it gets.
It's a defensive strategy, so others cannot enforce vague patents against them.
With the original question being about measuring correlation between interview performance and actual long-term performance on a job, I'd love to see the numbers you are basing your opinion on regarding testing for "production skills" and long-term job performance.