skysight-inc/HackerNews huggingface dataset:
>If I shoot a pool ball to strike a heavier second ball which is at rest they will end up moving in opposite directions. If "time were to go backwards" - whatever that means - they would approach at the end one would be at rest. That's seems indeed unlikely with "time going forwards" because we wouldn't be able to do that if we tried (at least not systematically).

in a vacuum no ball will ever go to rest if it's moving. It will move forever because there is no resistance.

What's happening in the pool table is that the ball is losing it's movement energy to the table. Table is absorbing it, the air is resisting it and slowly that vibrational energy becomes more and more spread out until it's basically imperceptible heat (which is also technically atoms vibrating).

What happens when time goes backwards is a bunch of tiny low probability events start happening. Heat from the background vibrating atoms by pure random luck happen to align and happen to produce motion that's noticeable. This happens from several places and by pure luck all of this vibrational motion concentrates on one place, the pool table and the ball. The kinetic vibrations just happen to push the ball slowly in one direction more and more with all kinetic vibrations by pure luck speeding up the ball. The ball being picking up speed until you with the tip of the pool cue catch the ball and ease it into a perfect stop, absorbing all the kinetic energy into the stick and your body.

All within the laws of physics but all extremely low probability events.

>There are also cases were we can prepare systems in the right configuration and produce "low probability" events even with "time going forwards": https://en.wikipedia.org/wiki/Spin_echo

When you put an intelligence in the system it's sort of cheating as you can manipulate random events to be non random and thus violate the laws of probability by intelligent choice. There's some computational theory here that states that the act of thinking itself produces entropy thus it's sort of conserved in a way but that' some other theory stuff that's another rabbit hole to dive into.
The assumption that anyone can estimate work they have never done with a reasonable degree of accuracy is just plain wrong. That is why management pretends they arent doing that either
> So... What is it seeking to optimize?

The goal is to maximize the number of tasks you can run concurrently, while imposing on the developers a low cognitive load to write and maintain the code.

> Why did you need a thread pool before but not any more?

You still need a thread pool. Except with virtual threads you are no longer bound to run a single task per thread. This is specially desirable when workloads are IO-bound and will expectedly idle while waiting for external events. If you have a never-ending queue of tasks waiting to run, why should you block a thread consuming that task queue by running a task that stays idle while waiting for something to happen? You're better off starting the task and setting it aside the moment it awaits for something to happen.

> What resource was exhausted to prevent you from putting every request on a thread?
That's really not that hard to add above. A lot of folks act like it's impossible to handle errors etc. in bash, but it's pretty straightforward -- certainly no more difficult than in any other language. The hard part, like with all languages, is deciding how to handle errors cases. The rest is just code.
Probably the most expensive proto-board looking thing around.
Libraries are nice, until you have to write the glue code between the modules and functions. But sometimes you already have the features you want as programs and you just need to do some basic manipulation with their arguments and outputs. And the string model can work well in that case.
Even if that is the case, which is not necessarily, in most cultures it would be unacceptable to not have the child join the family.

Keep in mind that this is not judgement, just a window into how different Swedish culture can sometimes be.
I think that instead of addressing and correcting the original post the author validated and confirmed everything that was said in that original post.
Wait, people are using graphql for private, not exposed, backend apis?

Who would torture themselves like that?

Isn't the whole point that your frontend can make the exact queries it needs and load the exact data it needs?

Namely, last I checked, client libraries for working with graphql are only good with JS. I tried working with graphql a few years ago in python and the only two client libraries absolutely sucked. Server libraries were great, but python clients sucked, badly. I ended up writing bare requests with a hardcoded heredoc for the query and endless square brackets to get the fields for the little data I needed.

Maybe the situation improved dramatically in the last three years, but I can't imagine so dramatically.

I wouldn't pick graphql as a private backend API in a million years. Well, maybe if ever single service was written in nodejs with no possibility of using other languages.
Yeah sure everything eventually averages out with enough sampling, and maybe queue based forecast converge faster than velocity and point based forecast.

Why? Don't know, whole article reeks of gut feeling, which is strange as data should be available since the whole point of scrum masters is clerking things out.

The problem with a queue system is not in the averages tho, but in the exceptions: say sprint or project is late, which features give you the largest impact when moved around or canned? If the customer wants to reduce cost, how do you give visibility of feature effort? Or are we in the toxic agile version with fixed scope, cost and deadline? Because then just ditch the overhead and waterfall your way trough

OH and btw this system is not gaming resistant, people may pick the smaller task first to meet queue processing frequency, and then you'd get massive frequency drop at the end.
I also reread MMM from time to time. Also Peopleware and Yourdon's Death March.
> My rough understanding is that this is similar to async/await in .NET?

Well somewhat but also not really. They are green threads like async/await, but it's use is more transparent, unlike async/await.

So there are no special "async methods". You just instantiate a "VirtualThread" where you normally instantiate a (kernel) "Thread" and then use it like any other (kernel) thread. This works because for example all blocking IO API will be automatically converted to non-blocking IO underwater.
Rubbish. Comprehending this material has been well within the capabilities of 16 year olds for as long as the material has been taught. For your premise to hold true there would need to have been a significant diminishment in children's linguistic and reading skills which would no doubt be reflected in all manner of standardized testing across the cohort. If someone's struggling with the material it seems more likely that either it's being taught poorly or they simply have no interest in engaging with it. Curb your enthusiasm for revisionism, not everything should be easy.
I don’t get what you’re complaining about, federated learning for ads is a big step forward for privacy if it gets adopted, it will allow being way more strict with third parties on websites and other storage mechanisms.
> speed run to burnout

This is especially true when you're working at the extreme ends of the spectrum. Whether it's a startup or shithole corporate environment full of lazy shiftless bastards, picking up slack for incompetent management is not ok.

I'm saying this for the benefit of probably about half the people reading this right now. Enough is enough in this industry.
You're missing the slightly lower tax rates that Marc could be paying if Trump were president!

I mean, sure, Trump might think any election that he doesn't win is fraudulent and that he's above the law, but what's truly important for America is that Andreessen Horowitz co-founders pay slightly less taxes.
The iOS implementation of this feature is perfect.
As discussed in another thread already, it seems my own Belgian system differs very much from the US system. (I basically found out with this discussion :D)

And to be honest, I have no idea how you can make the US system work, so I probably agree with you. Come to Belgium and let your kids study here :D.
no but it's super super janky and simple hodgepode of stack overflow and gemma:27b generated code, i'll just put it in the comment here, you just need CURL on your path and vim that's compiled with some specific flag

function! GetSurroundingLines(n)
let l:current_line = line('.')
let l:start_line = max([1, l:current_line - a:n])
let l:end_line = min([line('$'), l:current_line + a:n])

let l:lines_before = getline(l:start_line, l:current_line - 1)
let l:lines_after = getline(l:current_line + 1, l:end_line)

return [l:lines_before, l:lines_after]
endfunction

function! AIComplete()
let l:n = 256
let [l:lines_before, l:lines_after] = GetSurroundingLines(l:n)

let l:prompt = '<PRE>' . join(l:lines_before, "\n") . ' <SUF>' . join(l:lines_after, "\n") . ' <MID>'

let l:json_data = json_encode({
\ 'model': 'codellama:13b-code-q6_K',
\ 'keep_alive': '30m',
\ 'stream': v:false,
\ 'prompt': l:prompt
\ })

let l:response = system('curl -s -X POST -H "Content-Type: application/json" -d ' . shellescape(l:json_data) . ' http://localhost:11434/api/generate')

let l:completion = json_decode(l:response)['response']
let l:paste_mode = &paste
set paste
execute "normal! a" . l:completion
let &paste = l:paste_mode
endfunction

nnoremap <leader>c :call AIComplete()<CR>
I think he was making the same point as you: writing for virtual threads is like writing for single-threaded blocking code.
Godot is optimized to actually build your game, the cracks start to appear with everything that’s not explicitly about building your game (codec support, shipping to non Desktop platforms etc).
Unity is really good at abstracting the finicky shipping stuff away but lousy to actually build a videogame with.
Thank you! I have no experience with Shrinkray, but Hypothesis is great.
No support for code blocks still:

```java
String x = "xxx";
```

No quoting:

The docs for `libfloof` state:

> The floof is 4 bytes long, at most.

And when I type `code` with backticks at the start of a line, the word 'code' is formatted as code as expected, but auto-correct automatically capitalises it to 'Code' — which should never be done with code fragments.

So this is basically just headings, italics, bold, and links?

It's really annoying when you need to share technical documentation with lots of code and code-like content with people and they've started doing the spec in Google Drive. Just give me working Markdown.
Wlroots 0.18 Brings New Wayland Protocols and Support for GPU Reset Recovery
Is that what I'm supposed to tell to all those Outlook users?
They can put such things in a company blog for those who are looking for it, it doesn't have to be on the front page. Google, Cloudflare, the previously mentioned Mullvad, etc take this approach (and they often wind up submitted to the relevant audiences). This strengthens their brand trust in terms of security among key groups.
> What about parents? That would seem like a natural market for a product that could replace expensive private school tuition (or paying high property taxes in order to be in a good public school district)

Quality of education is one factor among many when making the choice to send your child to a private school or move to a prosperous community with well funded public schools.

Another major one is social clustering, premised on the expectations that children will pick up beneficial cultural traits from similarly higher privilege peers that will help them advance.

Edu software can't provide the social benefits of exclusive schools (whether they are private or public). Parents know that which is why if they can afford to, they avoid underperforming schools.
I wouldn't be surprised if alot of the viewbots are using the same pool of IP addresses. Blocking VPNs, VPSes, tor, and ranges with large amounts of bans would probably help.

On the other hand, twitch keeps firing employees, so they probably just ban the stream account every 20 minutes because they don't have the manpower.
This just reminds me of my theory of Microsoft's checklist-driven development:
Some PM writes down some single-sentence description of a feature (e.g. "Share Wi-Fi passwords with contacts") and the developers just read the list and find the single least-effort way of implementing it.
Once done, they can tick the item off the list and go home having done their job, although often in the most excruciatingly stupid way by damaging their users' experience.
I do not see how else could M$ so often add features in a way that actively make their products worse to use.
Wow, I would have killed to have access to something like Claude when I was in school. I would have spent a lot less time stuck on problems or topics.
> An async method, basically does the same, but it means your logic doesn't have to handle the polling, orchestration, selection, ordering, etc.

In order to take advantage of that, I'd need to create one `async` method for each handshake with the TURN server, right? Like every `allocate`, every `refresh`, every `bind_channel` would need to be its own async function that takes in a `Sink` and `Stream` in order to get the benefit of having the Rust compiler generate the suspense-point for me upon waiting on the response. Who is driving these futures? Would you expect these to be be spawned into a runtime or would you use structured concurrency a la `FuturesUnordered`?

A single `Allocation` sends multiple of these requests and in the case of `bind_channel` concurrently. How would I initialise them? As far as I understand, I would need to be able to "split" an existing `Stream` + `Sink` pair by inserting another multiplexer in order to get a `Stream` that will only return responses for the messages that have been sent via its `Sink`, right?

I just don't see the appeal of all this infrastructure code to "gain" the code-gen that the Rust compiler can do for these request-response protocols. It took my a while to wrap my head around how `Node` should work but the state isn't that difficult to manage because it is all just request-response protocols. If the protocols would have more steps (i.e. more `.await` points in an async style), then it might get cumbersome and we'd need to think about an alternative.

> > It is doable but creates the kind of spaghetti code of channels where concerns are implemented in many different parts of the code. It also makes these things harder to test because I now need to wire up this orchestrating task with the TURN clients themselves to ensure this response mapping works correctly.

> I read through the node code and it feels a bit spaghetti to me as an outsider, because of the sans-io abstractions, not inspite of it.
> That comes from nature of the driving code being external to the code implementing the parts.

It is interesting you say that. I've found that I never need to think about the driving code because it is infrastructure that is handled on a completely different layer. Instead, I can focus on the logic I want to implement.

The aspect I really like about the structure is that the call-stack in the source code corresponds to the data flow at runtime. That means I can mentally trace a packet via "jump to definition" in my editor. To me, that is the opposite of spaghetti code. Channels and tasks obfuscate the data flow and you end up jumping between definition site of a channel, tracing where it was initialised, followed by navigating to where the other end is handled etc.
> Haven't you heard of quantum mechanics.

Haven't you looked at the article I sent which says "quantum" in every other page. Haven't you heard of its author Roger Balian and his (two-volume) book From microphysics to macrophysics: methods and applications of statistical physics.

> Statistical mechanics is just a study of the application of probability to that macro phenomena. We still don't know why all of it works.

"We" may "know" different things - and have a different view on the relative importance of what is known and what it isn't.
I find this very interesting. I'm not a native English speaker but I would say I have native level proficiency. I just finished (literally yesterday) going through about 20 of Shakespeare's plays. Moreover, I did it in the audiobook format, where I didn't just have to follow the story, but also constantly figure out who's speaking. This wasn't a walk in the park and I had to familiarize myself with each play before listening to it. But - I found most of it perfectly understandable and often relatable. A fascinating difference in experience.
Imgur has lasted a good while.

I’d argue that having a service that exists in any form is a success. The fact it’s used so heavily despite your opinions and being loaded with ads means people value it and are better off than if it never existed. If the creator here could create the same but with no monetary upside directly, even just having the notoriety and putting it on his resume would translate to dollars indirectly. It’s a side project, chill.
I’m an external examiner for CS students in Denmark. One of the places I do this is some form of “gaming CS” education. Which tends to produce some of the poorest students, but it does give me some insight into what they build.

In 8 years I’ve never seen a successful Unity project despite them actually being taught Unity. The only “finished” game I’ve seen was for Robolox, but in general the students who chose to do pygame fared decently. I haven’t seen a Godot project, so I’m not sure how much help this is outside telling you that Unity is probably not as “easy” as you might think.
zfs create. All better.
i think this is lovely … one idea would be to build a raku Grammar for your language (which would be also ~23 lines I suppose) … that way you could make raku Contact objects and easily add international variations. also you could write an export (ie print) method to output from Contacts to your language. disclaimer : I wrote the raku Contact module https://raku.land/zef:librasteve/Contact and would be happy to help.

https://docs.raku.org/language/grammars
We just have to iterate in the "markdown support feedback/help" pulldown I guess. because without ```code``` it's not useful.

Looking at you HN... (ok at least we have 2 indents codeblock)
There ain't no such thing as a free caves!
Selection bias. I'm sure there are lots of people who are really good at CUDA and don't have those kind of assets. Not everyone knows how to sell their skills.
Now these are the insights I'm looking for when it comes to "second generation" SRS software suites. When you focus your attention on a specific niche, like mathematics here, you can get some serious improvements in retention just by using the shape of the subject to your advantage like this.
> In a more technical community, it's natural to think that most people care about "values" when it comes to tech.

Do people actually think that? I know people sometimes joke about an HN bubble but I never really took that seriously. People are using stuff like AWS and Azure which probably wouldn't be the case if "values" was more important than what is most convinient. (relatively) few people today set up their own email servers and instead use Gmail or whatever.
It's great as a learning experience for the author, but it would be a good idea for the author to take a look at a JSON spec and see if the regular expressions used by the lexer support the whole spec and don't accept non-legal JSON. From a cursory glance, it seems like exponents in floating point numbers aren't supported, nor are escaped quotation marks in strings (`\"`). I think it supports string escapes that are valid in go, but not in JSON like `\xab` and 8-hexdigit unicode escapes `\U1234abcd`.
Not sure how that would play out for cases that were declared a national cyber threat. But I agree with your statement. Government should cover for their recovery or hell bring them on board to work for the gov. Maybe that would require some kind of unrealistic clearance but it could work.
I'm a keen cyclist (doing and watching); the elite differentiator is aerobic capacity (anaerobic for sprinters) not skill. Going fast up a hill wins GC and require no skill. Going fast down is more skilful but less important.
Excellent analysis. I know you are not in the domain of health care, but would you be able to give a similar analysis for health care tech? And likewise anybody else?
The proposed queue system seems somewhat orthogonal to story points to me. You could easily do the queue thing with or without story points, or vice versa.

With the pure queue solution, you still need to make sure the tasks are all "small". The problem of defining "small" is the same problem that makes story points so unreliable and confusing. So I suspect the kicker here is just having a group of motivated and competent people.
The bit where it broke down for me was where they initially make the (great) point that agile falls down where small story points for simple tasks (which is accurate) are added to large story points for complex tasks (which is much less accurate), leading to a net inaccurate estimate. So the take away is to break down complex tasks.

Then they introduce queues, which are made up of small tasks.

I admit I stopped reading at this point. Is the useful thing the queue, or the fact everything is now broken down into small tasks?
I am assuming your product is HockeyStack.

Why do you need Clickhouse? Why do you need to store 20 billion rows of data? Even if you do need to store that much, why isnt something like Postgres sufficient?

If you’re doing revenue attribution based on things like website visits, or activities, and only have hundreds of customers, then i imagine at worse you are processing a thousand events every few seconds? Mostly writes. Seems you can do something around caching events and bulk inserting to optimize things. Still think using Postgres is possible here. If you need to scale horizontally, you could shard based on customer ID too. If you need to do analytics on this data, Postgres should still be usable as long as you create the right indices
I recently was running a variety of compressors over the course of days, and using Bash was great because, it doesn't parse the whole file before it starts running - I could edit and reprioritize next steps while the script was running. "Oh, that one's not working, skip the slower version" or "oh, space is an issue, work on freeing that up." It's a weird hack I wouldn't suggest in production, but it worked well for me.
Collectibles market valued at estimated $622B
The breaking changes part from the original article was clear to me. The author was saying that if you control the API and the client, it’s often quicker to release changes that are not backwards compatible as long as you can coordinate the release of the two. Then there’s no need to version at all. Sounds like this is harder with graphql than REST.
I'm surprised Ford-Fulkerson was published as late as 1956, because surely they were using something similar for the strategic bombing campaign in the 1940s, and on the other front, Kantorovich was using max flows like a madman to keep Leningrad supplied under siege...
it can do a much better job because there isn't a security boundary. OS thread scheduling requires sys calls and invalidate a bunch of cache to prevent timing leaks
Idris JVM 0.7.0 Release
Pothos + graphql Zeus gives us the ability to expose a prisma like interface to the clients with the ability to curate what fields are exposed and maintain the ability to setup field level security.

Oh, and we get DB schema to frontend propagation of changes to the type.

This is by far the best experience I have had for private APIs - Where we don't need to maintain backwards compatability.

I do get that the HN crowd is super adverse to graphql, but I fail to see other arguments than matters of taste.