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

oh please, 9am should be whenever I log into my work computer.


voiceover on that video sounded like it was ai generated lool


> While somebody from Palestine side did fire the opening salvo on oct7.

Now, that's a re-writing of history if I've ever seen one.

> Israeli and Palestinian deaths preceding the 2023 Gaza war. Of the Palestinian deaths 5,360 were in Gaza, 1,007 in the West Bank, 37 in Israel. Most were civilians on both sides.

Quote from https://en.wikipedia.org/wiki/Timeline_of_the_Israeli%E2%80%...

See the chart on the top right with the orange bars


I do understand that it was not the first first salvo.

And that blockading policy and financing of anything but fatah and bunch of other stuff influenced today situation.

But you must admit that oct 7 was unusual escalation. Which now are used as the reason for current idf actions.


I think this bit gives it up:

> And now, with Iran's nuclear ambitions supposedly neutralized in a single blow, we can all relax. The threat is gone. No strategic aftershocks, no long term consequences, no unintended escalation. Just peace, stability, and a region completely satisfied with the outcome.

Sounds like sarcasm to me.


Yeah, other than that paragraph I think it's a perfectly reasonable sentiment.

The threat is obviously not "gone". Just substantially reduced. And we can't relax, we need to be vigilant to make sure they don't rebuild. But this certainly does seem to have been a relatively simple solution to the problem of Iranian nuclear armament.

Diplomacy is of course still a better long-term solution. But even diplomacy is a lot easier when you get to start the negotiations from a position of "No, you can't have nukes, period, regardless of whether you agree to any sort of deal or not."


No, it's really not better to start negotiations from a position of "we may unilaterally withdraw from any agreements you sign and comply with, then bomb you regardless of whether you are pursuing nukes."

This has unambiguously increased the imperative for Iran (and every other country) to acquire its own nuclear deterrent.


been reading / work with elixir and was interested in finding out the cause of high cpu usage.

TLDR: BEAM VM uses busy waiting under the hood to achieve fast response time when dealing with requests. you can disable it by setting a few options in the VM.

Edit: Interesting thing here is that there's no significant latency difference when toggling busy/wait, so not sure why that's the default.


It's because their test is bad at testing this behavior, this behavior is useful for a "bursty" traffic pattern. The point is to keep the OS scheduler from expensively context switching out of BEAM when it's idle, requiring an expensive context switch back when a new burst of requests comes in. You'd want to send it a heavy burst of 1000 requests at random delays, or something.

The only time you'd want to disable it is if you're under a CPU quota, or if you have some other important OS process that's not getting enough CPU.


That's strange. I understand busy waiting for up to some milliseconds so you don't yield too soon, but if it busy waits all the time by default it's just a bad neighbor.

All that said... A while back, inspired by an argument here on HN, I tested waking up a program 100 times per second and I was shocked that it didn't really show up in CPU usage nor power usage. Maybe an easier way to get started with async code, since you don't have to mess with wakers


When coming from telephony and high availability, you don't put neighbors in the same hardware. This is BEAMs way of overcoming shortcomings in the CPU and OS schedulers. And you can turn it off with a simple configuration


> When coming from telephony and high availability [world]

That's a good point, its pretty easy to forget BEAM's heritage from the telecom world. The defaults on the VM are for that use-case, I'm so used to thinking of everything from a web perspective that I didn't even consider this, despite knowing of its history.


for your sanity stop replying to invalidname, that dude is in every single Israel / Palestine post, with non-stop commenting. I think he's (she's?) paid to astro-turf here. Just look at their history, and then look at mine for a convo that I have had with them in the past.


what exactly is present in intellij that isn't available in vscode / neovim with lsp / newer emacs? I ask because, I use(d) intellij for java and maybe i'm not using most of its capabilities or they're hidden away in plain sight, but i haven't noticed anything special aside from the slow ui.


For me there are two axes that are lacking (based on Scala and Elixir usage):

1. The feature set is just far weaker. If an LSP implementation and the client both hit 100% coverage, then you might end up having the same refactoring, code generation, follow definition/load docs/infer typing support. But of course the Elixir LSP matrix shows that basically none of the LSPs offer a complete feature set and you basically get to pick which features are missing. What about debugger support?

2. This could be viewed in some ways as a recapitulation of point one, but I actually appreciate the Integrated in Integrated Development Environment. I very much dislike when adopting a new technology having to cobble together a disparate number of tools to create a good editor experience, especially in a time where as a novice I'm actually not at all qualified to understand what a good editor experience would be! I actually call this the Clojure Problem, which is that many Clojure devs decide they have to learn emacs or a complicated fireplace.vim setup in addition to Clojure and wind up learning neither.

Regarding speed, don't get me wrong, I empathize with complaints about it and whenever I'm doing C# work for one of our services I'm reminded of just how slow developing Scala can be in particular. But I don't think of LSP approaches as fast, either. Perhaps they are async and don't block the UI, but now I'm just sitting here typing and getting constantly out of date feedback from the editor as it and the LSP catch up to whatever text has been entered.


unless I'm doing some basic front-end stuff, i've found that AI code assistants are an absolute waste of time.


i've worked at a 30-50 person company that was (is?) super inefficient. at some point there were more directors, managers and product people than actual engineers doing the work. i remember specifically that at one point there was a team of 4 people with 1 engineer and 3 different "stakeholders"!


Probably the product people would argue that these stakeholders need to be better product-managed, while you seem to be thinking it needs more engineers... and now we're off to the races...


to expand on the parent's comment a little bit as well, most of these canadian bank accounts also have fees per interac transaction depending on the account. The richer the person, the more money in your account and more fees you can get waived. until recently I would not send interac e-transfers because it would cost me $.50 per transaction after the first 5.


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

Search: