skysight-inc/HackerNews huggingface dataset:
I took a theater criticism class in college and the main rule I remember is "Never say something is good or bad. Describe it." or something like that. The point being even if you're personally not into something, convey the strengths and weaknesses together so others can get a better sense of whether it's for them because people aren't all looking for the same thing from an experience.
Not really a counter point because you mention a lot of other issues with f-droid that sound valid (I haven't used it myself) - but as a tangent regarding auto updates, I disable them basically everywhere because I seem to have buggy experiences too often if I allow stuff to update all the time.

I then go through the list of updates in the Play Store once a week or so and install those that I think might improve app functioning/stability. I look over and install Windows updates once a way-too-long (need to work on this).

Feel like everyone is skimping on QA these days or something else fishy is going on. In the last handful of years there have been 2 or 3 Windows updates that either permanently erased data or caused some other insane issues. I didn't get them (tbf I understand that most people didn't), partially thanks to having auto updates disabled.
From what I gather the actual lattice requires neutrons. Their current setup uses an electron source (dynamitron) on tantalum which generates gamma rays. The gamma rays have the energy needed to push neutrons around inside the lattice. It seems they're saying it would be more energy efficient just to directly generate neutrons without having to go electron -> gamma -> neutron.
> There is more than just a change of name involved with LCF: the statement "it still requires energetic deuterons" means the deuterons still have to be hot.

the original cold fusion experiments explanation was lattice confinement in heavy metal (i.e. large electron clouds) like Pt/Pd plus energetic deuterons. What was very unclear is where those deuterons got their energy. It was theorized something along the lines that high electrostatic charges in the metal cracks accelerate the deuterons, etc.

Unfortunately pseudo-scientificity got somehow attached to that research, and that for decades prevented any meaningful research into the source of those deuterons and how to efficiently increase their number and/or how to efficiently add another source. Only passage of time and the name change to LCF - marketing, yea! - has allowed to restart the research, though still without due credit to the original research.
No problem. I don't know what deaded means in this place but thanks for the discussion anyways
BSD 2.11 is still getting patched by Steve Schultz, last I saw.
This is what the beginning of economic stagnation looks like and how regime change is forced upon Russia (again). It could be worse, though. You could have a nuclear power rolling tanks through your neighborhood trying to decapitate your government and install a puppet.
This kind of feels like using continuations, here is a Haskell demo of the concept:

myMap = myMapHelper id

myMapHelper cont f [] = cont []
myMapHelper cont f (x:xs) = myMapHelper (cont . (f x :)) f xs

Of course this actually makes things slower in Haskell, either due to the growing continuation or existing optimizations in Haskell
One use case for fork()--which is used extensively on Android--is to build an expensive template process that can then be replicated for later work, which is exactly what people often want for the behavior with virtual machines. I wrote an article on the history of linking and loading optimizations leading up to how Android handles their "zygote" which touches on this behavior.

http://www.cydiasubstrate.com/id/727f62ed-69d3-4956-86b2-bc0...
> The intent of fork() is to start a new process in its own address space.

True!

> That *fork() variations that run in the SAME address space are confusing.

Why is it confusing? They are distinct and different system calls, with different semantics. They are also sufficiently similar that they are also similarly named. But there's nothing confusing about their semantics. vfork() is not harder to use than fork() -- it's just subtly different.

> A use case today for fork() might also be sandboxing apps. Certainly I expect browsers use this approach to spawn unique pages.

I wouldn't expect that. Sandboxing is a large and complex topic.*
Largest Plane Destroyed in Ukraine
I want to learn from you more.

What if I gave you 2 docker containers:

1. one with ansible loaded and ready to go

2. another one with just SSH running that you can point the above to and experiment with

If you don't know docker - that's ok! It's easy and I will set you up to do that. let me know

This way, you don't have to mess around with either installing ansible or setting up VMsVPS/hosts blah blah
TL;DR: The Russian army relies heavily on railroads to resupply. Author estimates that beyond 90mi by truck from a railhead, the army will struggle to maintain rapid pace of advance due to logistic issues.

Very good analysis, worth a full read.
You know, I think the Vision vs LIDAR is very narrow and won't be very relevant in the long-term. If you imagine the full robotaxi stack: cars, training, simulations, back testing, data sourcing, perception, driving decisions, etc, etc, the LIDAR vs Vision concerns only one small part of the stack.

Critically, LIDAR still has to be trained in the same way cameras have to - it'll give you depth information, but you still have to make it accurate decide whether some 3D blob is a person, sign, etc. LIDAR does not help you recognize street markings, interpret signs etc.

That is the big question is: what is cheaper/faster: cheap sensors and more training, or more expensive sensors and less training. As LIDAR and training both get cheaper, it might not end up making much of a difference in the end. Companies will be successful based on how well they execute on the full stack and a slight edge in one area might not be enough to overcome problems elsewhere.
In practice their acquiescence would be required—if nothing else he would need them to agree to abandon the station.
Who will return our money?
Yes. That fantasy is really closer to 75 years old than 15, and there are as many burger-flippers now as there ever were.
I never got around to replying to this, but on the off-chance you're still following this thread (and any other readers still reading)

> This is not entirely true. Refs on lower level are pointers - when it compiles down to CIL, the resulting types are rendered as T&, and referred to as managed pointer, as opposed to T* the unmanaged pointer.

Right and I don't think anybody would disagree that CIL is not a low-level language. But plenty of high-level language features compile down to just pointers. This doesn't mean that the language offers pointers though! In that world I could say that Python offers pointers (or indeed any high-level language that compiles to LLVM and has a feature that just corresponds to a pointer).

> But since then, we've got the ability to return refs, declare local ref variables and fields (in ref structs), and reassign them. So at this point they're effectively types, with some restrictions on use similar to Rust borrowing.

No they're not. You still have the `Ref<...>` vs `ref` distinction (which is why ref fields aren't a thing), you still can't have nested `ref`s, and you still can't switch between "ref"ing and "unref"ing something, i.e. ref-ing is infectious.

Likewise the fact that refs have some linear characteristics doesn't make them pointers (in the same way that Linear Haskell doesn't mean that Haskell now has pointers). The reason why we say that Rust has pointers (apart from the raw pointers), is that they don't have any of these issues!

> To implement goroutines with CPS, you'd need to rewrite every call into CPS-style. This is technically not observable, yes; but perf would be atrocious in practice, so it's not going to happen.

Yes there are sound reasons for why Go has chosen certain implementation decisions, but those are not part of the language semantics, which is ultimately what determines whether a language feels high-level or low-level.

> And running that on top of green threads is possible but pointless, since the semantics of await requires that async context switching happens only at awaits; but the ability to pre-empt at any arbitrary point is precisely the advantage of green threads.

No current industrial green thread implementation I know of offers pre-emption, they are AFAIK all cooperative. IIRC Go's implementation yields on channel sends and GHC's implentation yields on memory allocation. I think Loom is heading for pre-emption, but it hasn't been finalized yet. But that's not really the point. My point is special syntax for a concurrency feature that is not backed by system threads does not preclude a language from using system threads, which is the fundamental relationship between Go's goroutines and any FFI that would expose system threads. Or put another way, being unable to use system threads are not a fundamental part of the semantics of Go, while being unable to use pointers are a fundamental part of the semantics of safe C#.
Point 1 is very similar in high end coffee. Sometimes very expensive coffee in the US is substantially better than what you get in the grocery store, but often it's just much different. It might taste like blueberries or strawberry candy or wine. Not necessary better, just weird, hopefully in a whimsical way.
a ginormous scripting OS, PDP/11 is.
> ...but it's just not usable in practice.

> ...this makes using packages installed through F-Droid a nightmare.

I run 2x Androids with near 80%-90% of the packages installed from F-Droid repos (to include Bromite and Bitwarden custom repos); it has quirks and is not perfect - but far from "not usable" and "nightmare" as your hyperbole would suggest.
NYSE, Nasdaq halt trading in stocks of Russia-based companies
Could you clarify what exactly is a "user registered in Russia" that you are banning? I left the country (because of the government), and now have american billing info in my account, but I still got the termination email.
This is probably (partially) attributable to the IKEA-effect [1], where people perceive better quality in the things that they partially create.

Also one of the joys of cooking is that you are experiencing the immediate fruits your own labor. There's no prolonged scrum meetings, release cycles, delayed launches, etc. It such a simple feedback loop that it's a great way to give yourself short-term gratification. I've found even food prep is cathartic to a degree.

[1] https://en.wikipedia.org/wiki/IKEA_effect
I don't think anyone has seriously explored collaborating with DoT. If they had they would have at least talked about it.

> In this case, you wouldn’t be able to rely on these external sensors being online with 100% uptime, so you’d necessarily be forced to build the capabilities to operate without them anyways. And adding external sensors and local communications and trying to deal with different standards and models and interop adds a ton of complexity.

Well, yeah nobody said it was easy. But, it does seem like something that could work, whereas we know that fully autonomous is just not possible with the tech we have today.
I feel the same. What do you say in Slack to the guy who just told you he’s handed over his tasks to a colleague because he’s joining the territorial defenses and has to go and fight? “Good luck”? “Give ‘em hell”? “Слава Украины" is what I settled on but there’s just nothing you can say that conveys the weighty emotions of that kind of goodbye.

The very least that can be done is to not cut them loose because Russian bombardment has decreased productivity.

I’ve left behind a life and all of my possessions in Ukraine but more than that I feel like I’ve let them down since I’m living comfortably in Georgia while they suffer and could possibly die.

I’ll just do what I can to help keep the project going so we can keep supporting them. The cold reality is that a startup isn’t a charity so at some point some hard decisions need to be made, but that point isn’t five days into a war.
SSH Productivity Tips
> Aren't AI models already better at image recognition than humans?

On some benchmarks, AI models are better at very well defined tasks like image classification (“label this image from a set of 8 labels you’ve seen before”) or object detection (“draw a box around all instances of class X in this image, where X is a very narrowly defined class”) They’re not even close to being able to understand unscene examples and parse out their meaning in a larger context the way humans can. (“Recognize that this object in the road is a human riding some sort of bizarre unicycle he welded himself, then predict how he’s likely to move given the structure of his custom unicycle thing”)

The bottleneck in AVs isn’t “perception” in the sense of image classification and object detection, it’s deeper scene understanding and abstract reasoning.
Like...don't they get bored??
> I'm curious to hear more. What's its purpose?

Sure! I'll try to illustrate the general idea, though I'm taking liberties with a few of the details to keep things simple(r).

Our software (see https://undo.io) does record and replay (including the full set of Time Travel Debug stuff - executing backwards, etc) of Linux processes. Conceptually that's similar to `rr` (see https://rr-project.org/) - the differences probably aren't relevant here.

We're using `ptrace` as part of monitoring process behaviour (we also have in-process instrumentation). This reflects our origins in building a debugger - but it's also because `ptrace` is just very powerful for monitoring a process / thread. It is a very challenging API to work with, though.

One feature / quirk of `ptrace` is that you can't really do anything useful with a traced thread that's currently running - including peeking its memory. So if a program we're recording is just getting along with its day we can't just examine it whenever we want.

First choice is just to avoid messing with the process but sometimes we really do need to interact with it. We could just interrupt a thread, use `ptrace` to examine it, then start it up again. But there's a problem - in the corners of Linux kernel behaviour there's a risk that this will have a program-visible side effect. Specifically, you might cause a syscall restart not to happen.

So when we're recording a real process we need something that:

* acts like a thread in the process - so we can peek / poke its memory, etc via ptrace
* is always in a known, quiescent state - so that we can use ptrace on it whenever we want
* doesn't impact the behaviour of the process it's "in" - so we don't affect the process we're trying to record
* doesn't cause SIGCHLD to be sent to the process we're recording when it does stuff - so we don't affect the process we're trying to record

Our solution is double clone + magic flags. There are other points in the solution space (manage without, handle the syscall restarting problem, ...) but this seems to be a pretty good tradeoff.

[edit: fixed a typo]
>If I had to guess, I'd imagine this is the result of perverse incentives

I think it is simply short term profit maximalization. Why give an employee a dollar more than you have to give them? Whether giving them an extra dollar now might generate an extra two dollars down the road is rarely even considered.
AFAIK git was made with an email workflow in mind. Git's the byproduct on the Linux kernel project, for better or worse. GitHub provide a fake email address that's tied to your GH account for commit stats, which is an appreciated utility.
May be it is more for the sake of their team and not you.
Disrupting the everyday lives of Russian citizens is an effective way to incite change. Some will choose to flee the chaos, but some will choose to protest and fight the regime.

Will there be good Russians unfairly hurt as collateral damage? Yes.

But the Ukrainian civilians being gunned down in the streets and having their homes blown up are also being unfairly hurt. There is very little they can do to stop it, but they've been forced to drop everything and fight.

Like it or not, you're on one side of a war. It's to be expected that your life will be inconvenienced - so have lives on the other side. You can flee - nothing wrong with that - or you can protest, but you can't hope that you won't be impacted.
The U.S. Navy has a few hundred samples built. They just put boats around them.
Zaheer from Levels.fyi here. Note that companies struggle with data as well. There's dozens of companies that solely exist to provide better data to companies around salaries (Radford, OptionImpact, etc.). All of these have limitations as well (title matching, recency of data, etc.) and generally companies subscribe to multiple providers to get a better picture of what the market pays. Companies in fact purchase data from us as well (the same data you see on site but formatted in a way that's easier for comp analysts to use).

The reality is that there is tons of nuance that goes into pricing a job / candidate effectively. Each candidate has unique skills even if two candidates have the same title, level, etc. That's why it's almost never a fixed number and often a range.
Yeah, we're using Heroku, which host all of their own services on Amazon's EC2 (meh), which was an unfortunately short-sighted tech decision early on that we're looking to remedy. We're hoping to transition to Azure or Google Cloud. Any recommendations?
Nullable types... they have the same problems as null pointers: if you don't care about handling the case they are null the program will crash, if you handle it, you can handle it also for null pointers. Well, they have a nicer syntax, and that's it. How much Rust code is full of `.unwrap()` because programmers are lazy and don't want to check each optional to see if it's valid? Or simply don't care about it, since having the program crash on an unexpected condition is not the end of the world.
https://en.wikipedia.org/wiki/Amazon_Sidewalk
That isn't fair either though. I can see the ISP I quit using 15 years ago letting someone else have my old email address, but now they can claim to be me.

I don't know how to handle this situation. It is somewhat easy to verify that a commit today comes from an email address I control now. However if I claim an unverified commit from years back is it really me just because I now control that email?
The people holding the guns are still just people though right? I think the point of these economic pressures is to eventually have those people with the guns turn around and point them on Putin.
If we manage to get through this chip shortage and then China decides to invade Taiwan and we lose TSMC, I'm gonna fucking lose it. Everything feels so fragile right now.
Right, shells are no threaded and they tend to have small resident set sizes. Even in shells though, there's no reason not to use vfork(), and if you have a tight loop over starting a bunch of child processes, you might as well use it. Though, in a shell, you do need fork() in order to trivially implement sub-shells.

fork() is most problematic for things like Java.
> Ansible has a very low barrier to entry in terms of dependencies that need to be installed into the machines you want to manage: they need to have python 2.6+ or python 3.5+, and you need to be able to connect to the machines over ssh.

I understand what you're saying but do understand that to other people these can be concepts that they arn't familiar with or might actively struggle with

That said - were there any obstacles you faced when you started with Ansible?

What could have been better (tooling/docs/training/etc) to get you upto speed better/faster?
This is really wrong. I'm a Russian national, and I'm not supporting aggression towards Ukraine. In contrast, I've spent last two days in police after being detained due to the fact that I dared to express my condemnation in public protest.

I am not my government, and apart from starting a one-man revolution with a pretty obvious result, I'm doing everything I can to raise awareness, condemn actions of Russian government, and put an end to this. I've been doing so since 2011, back when I was a college student.

Namecheap -- this is a low move. While I do understand that your company has a lot of Ukrainian employees, all of which are in grave danger, you're not doing anyone a favor by making a shitty life of most Russian nationals even shittier.
I'm in the US, also got the email.
I don't know. I've found mis-en-place to be a great help when cooking at home and I've never worked as a cook in a restaurant or caterer. It helps with timing and it is also just nice to feel like the cook itself is simply "going downhill."

Now, for qualifiers, I live in a full house so things aren't always where I left them (so simply removing searches is useful) and I do cooks both small (just my meal) and large (for the whole group or pre-cooking meals for the work week).
That's because Kyle competed with MIT in the DARPA Grand Challenge, which is where the architecture for the modern driverless car was battle tested. LIDAR was by far and away the enabling technology in those competitions. Every team that finished in the DUC had a Velodyne 64 LIDAR. They are that important.

For whatever reason, Tesla has decided to eschew this hard-earned wisdom, have treated their customers and the general public as an extension of their corporate research lab and their customers and others have paid the price for it with their lives.

During the DUC, contestants competed in an abandoned military base in the middle of the desert. In that environment, the vehicles were outfitted with all matter of flashing lights, emergency stop procedures, and all humans had to clear the area. That's what robot research was like in 2007. And our cars didn't have a verified track record of deaths!

Little did we know at the time, we could've just held the DARPA Urban challenge in the middle of downtown SF. Apparently we wouldn't even have needed to inform the unwitting public that an experiment involving a 2 ton machine that has killed people in the past was taking place in their midst.
I've been out of it for a while, but my understanding is that humans are still better at video recognition and extracting high-level information from moving videos, while the state of the art CV still tends to focus on rapid frame-by-frame static classification, with some semblance of persistence and motion strung together at the end.
Personally I think this submission and the other one[1] that probably made it to the front page are excellent :)

[1] https://repography.com/blog/go-first-commit
Your reference doesn't seem to be relevant to your claim.