skysight-inc/HackerNews huggingface dataset:
Our blog is full of examples of implementation analysis, and we have not encountered one implementation that is bug-free or leverages the complete toolset (same for us: we have just identified a bug in our implementation that relates to WebKit's user-gesture requirements on iOS versions before 17.4). That's not because of them being sloppy, it's just very difficult to get it right; that's exactly the point. For example, Uber and Amazon both did not get it right (until today). Of course, it is possible to implement passkeys without any external resources, and to be honest, we appreciate any effort, be it open-source, tutorials, or commercial applications. If you have been on an authentication team in a big B2C company and truly want to retain the trust of your customers, then you appreciate passkeys immediately as they solve one of the biggest problems... So we are also happy to see a half-good implementation as it improves security.
Posts from new accounts are dead until someone vouches for them. You can contribute to a discussion and gain points to gain access to submit stories.
Maybe. But they're a bad mental model for software developers because user based security is way more limited than what you can do with capabilities.

And they're confusing for users, too. Signal isn't another "user" on my phone. Its still me. I just decide what capabilities I grant it on the day. "Yes, you can use location tracking for now - but only until later in the day."
I've been hearing this for 20 years and I'll be hearing it until we die from global warming. The only thing that wind and solar have done is make the grid more unstable and make a lot of money for speculators on the power market.

There is a reason why every country which has reduced nuclear power has increased its green house gas emissions.
It's interesting how impressions can vary so much. This is exactly the kind of site that would be a strong positive signal to me. To me it appears old school, friendly, straight-forward.
The claim was for the aerodynamics, not what models have which.
Um.. isn't today recommended to use ecdsa for ssh keys?
A capability is not an identity. And the difference matters a great deal in how you build software that takes advantage of capability based security models.
Can anyone give a sense of how much fitter 3.5 mL/kg/min is, in practical terms? e.g. distance cycled/how out of breath?

> For every 1-MET (3.5 mL/kg/min) higher level of CRF, we identified substantial reductions in the risk of all-cause, CVD and cancer mortality.
We also identified significant reductions in the risk of incident hypertension, heart failure, stroke, atrial fibrillation and type 2 diabetes per higher MET.

> For most, a 1-MET higher level of CRF is attainable through a regular aerobic exercise programme. For example, in a large population-based observational study of over 90 000 participants, nearly 30% were able to increase their CRF by 1-MET (median follow-up was 6.3 years) without intervention.
Any recommended readings on the "unable to estimate" claim?
It seems that there is some missing tooling to make this convenient.

You can run a local bundle of HTML/JS/WASM in a web browser instance that you isolate (for example with firejail) to prevent network access. You distribute as a zip/tgz, but it's not obvious how to handle updates without a full redownload. Distributing with a full Electron-like interface is obviously overkill.

If you're running a web app that's hosted elsewhere (which will be much more convenient for most people), your web browser or the software isolation functionality (or firewall/proxy) needs to distinguish between the initial resource loads (approve) and later sneaky logging requests (ban).

There are Android applications such as TrackerControl that have related functionality (operates as a local VPN to filter all network requests and block tracking) but I don't know of convenient tools for the desktop (Linux, in particular).
I thought it's a repost of the story about a guy who prepared explosive (legally, I forgot which one, perhaps nitroglycerin) in his home lab and had a recepient with the 'thing' explode in his hands.
There are no exercises that restore joints which are degenerating. Most likely you would have gotten 5-10 more pain-free years without the running, but it would have come anyway at some point. The increased cardio health and bone density does help sweeten the terrible deal though.
I applied a while ago, the application form was pretty long and detailed, and I received only a "sorry you didn't get in" email, no details or anything. I may just not be worth even a chat with recruiter, although (obviously) I consider myself a good candidate. Is there any cooldown period for when it's OK to apply again? Can I re-apply without filling in the whole form again (I didn't get a copy)?

Btw you also post similar roles on every whoishiring thread as well as other avenues regularly. It looks like roles stay unfilled for months — is that it, there's turnaround or the team is just growing constantly and you actually hire continuously?
That's just hilarious honestly
thanks. I will do that.
Yes but the same logic about loosing the secret applies to passwords and any other factors (given we ignore a potential reset process)

Providers will most of the time allow to register multiple passkeys or other authentication means, hopefully ;-) which has its own downsides.

I am well aware how the internals work of keystores. But the benefit with "client certs" is that on mTLS you get added benefits besides where the key is stored. And that is that you can "prevent" mitm attacks.

But I guess that is a subject for another thread.
> (Yes, KeepassXC can do this too, but they've been threatened with a ban from the passkey ecosystem over this.)

Bruh

This is akin to CA/B Forum threatening to ban use of OpenSSL because it has a -nodes flag.
They mean you might not need the lambda if all you want to do is enforce a max size; if you want to do resizing/other processing then you’d still need the lambda
Also, there are many things that can be done in web3 from this to move forward. Some ideas are Initial Share Offers (ISO), Airdrops for shared links, NFT rewards, priority access rewards, referral rewards....
Thanks very much, that's great.
Is it anything else than a tree with properties for each node?

I think you could well apply jsonpath to yaml, except for the different data types, which is what makes you need xmlpath, jsonpath, file path, css and so on. If you're willing to do some automagic conversions, you could probably do that right now, if you write the code for it.
The "anti AI folk" covers a huge range of different things, for different reasons, with different timescales and concerns.

I feel sympathetic towards all of these groups, even the ones whose jobs will disappear. I felt sympathetic towards truck drivers 15 years ago, as I was expecting self-driving to arrive before 2019.

That aspect of AI alone may well lead to a re-run of "workers who felt their livelihood threatened by automation flung their wooden shoes called sabots into the machines to stop them. Hence the word 'sabotage.'"[0] — and while AI communism could be better or much worse than industrial communism, I'm fairly sure that Overthrowing The Government While Angry is more likely to lead to a bad outcome than a good one.

There are also "anti AI folk" who fear various kinds of dystopia; the stuff in this thread being amongst the options, but also "tiling the universe with smiley faces", and (please excuse fictional references, take the core ideas but don't take them too literally): The Matrix; Westworld; "I Have No Mouth, and I Must Scream"; and every story about an evil genie granting the wish you actually made rather the one you meant.

[0] Star Trek, not sure how much artistic licence they took with that etymology, though the point remains valid in the form of luddites and literal Marx' literal Manifesto.
thanks for the spam...
I got an security awareness email from my bank yesterday saying they will never SMS or email with links to login or payment, as these are often spoofed by scammers. Directly next to this paragraph was a link to the login for the bank.

I. have. no. words.
Auckland: A city with a labyrinth of underground caves
Acorn bought-in a couple of GUIs for RISC iX (Motif mwm/twm in later versions, X.desktop from IXI Ltd in the earlier release), but I'm not sure if any were exclusive, and none looked like the RISC OS GUI - I wouldn't characterise anything about the RISC iX GUI as being particularly 'Archimedes'. There's a video of someone playing around with the GUIs here: https://www.youtube.com/watch?v=8r7vgQsuoT4

If only it had been given the RISC OS GUI with BSD underneath - that would have been way easier to port to modern Unix-like foundations and may have had a healthier-but-niche future as something 'modern' beyond Acorn's existence.
Bicycle helmets are not designed for impact with a car. They are designed to handle falls to the ground. The forces are quite different.
I've always felt this is because estimation never gets treated as an exercise which might involve actual software engineering. You get handed a task you've never seen before, for a system you've never seen before, and asked "how long would implementing this take?"

You never get handed a task which is "write as much of a prototype of a system which would do this, so we can estimate how much more work we think is involved".

And then when you do have enough knowledge to reasonably estimate, people just declare with no evidence that it should be quicker anyway and then are surprised when it is not.
I read Steve McConnell's Software Estimation: Demystifying the Black Art and I can recommend it without hesitation. It is quite old by now so there might be something newer and better out there as well.
That's certainly true, and nothing wrong with doing the "easiest" first, but it's interesting that people get so focused on such small changes in risk all the while ignoring the big ones.
If we have enough resources dedicated to this problem, why are we still burning coal/gas for power on sunny days? I'm definitely not against researching carbon capture, but it currently isn't the "the solution the planet desperately needs"
street view has images from years ago depending on where the google cars are mapping in that moment, waymo needs constant mapping of the cities it has cars in, therefore needing more man-hours. furthermore the driving laws differs from country to country, and in most of the world the road paint/signs are borderline indescifrable for a human, let alone a machine.
i'm not saying that it can't be done, but it is already expensive in big US cities, it just do not scale well.
How the CSI (Container Storage Interface) Works
This is the Hyundai Motor Group that is making investments. They are the parent organisation of Hyundai, Kia and Genesis. They also make Commercial vehicles. FSD, at this point have a lot if challenges, technology and regulation wise. But it is clear that these companies see value in their offerings being able to be driven without full attention from drivers. For that, I think this is not that bad of an investment.
Thanks. We have heard that also and we would appreciate it. In my experience, it is already difficult to find a technical compromise within a team of 5 people who like each other and work together for years. Finding a solution on the current scale of passkeys is really a big effort and at the end it also needs to be implemented, so I would not be surprised if it takes a long time for this to happen. Do you have an estimate?
> Especially since Polycam can do photogrammetry now besides the LIDAR scans

It's pretty good if you can get a decent coverage of photos. I did a scan the other day of a microphone holder and, apart from some thin gaps I couldn't get a good angle on, it came out well enough to see what was going on (it was warped).
Not sure that it's "AI-based" in the way you mean, but this is why I've stuck with YT Music for years. It's gotten good at guessing what I'll like, and creating auto-playlists to match different moods which are a good mix of tracks I already know and love and new material. I keep hoping they'll take it further - it is literally the one thing I want Google to use all my personal data (listening history) for.
There was the same deal in Switzerland!

https://www.thelocal.ch/20220104/gambarogno-the-latest-swiss...

It floundered, because it wasn't just practical to do anything in such a remote place.
Given that the average computer has hundreds of pieces of software of 'dubious origin' installed on it, in everywhere from the OS to the driver to the application layer, I can't believe you are seriously baffled that most people don't think twice about adding another one... That's sourced from a reputable vendor.

Reputable, in the sense that you're already willing to install and execute a closed-source binary blob (the game itself) on your PC.
> software dev as we know it is about to disappear soon

Pushing back on this a bit. We see promises and people working on this. But I haven’t seen anything definitive yet, and LLMs have their own existential threats around amount and quality of data. Recent article involving trying to get LLMs to reason about law required very fine task decomposition to get move forward. What we don’t know is whether doing this and then handing it to an LLM is as beneficial to humans in speed/quality/feedback as simply doing it yourself. Have already seen people saying that copilot’s interaction loop short circuits actually thinking about the problem.

Regardless, hobbies outside of work are absolutely essential in this absurd time. The author made some beautiful things.
yes, but it has also to be compared to the toll of not paying for these drugs
These types of languages are a bad idea, just as XPath was. They are complex enough to be a maintenance/bug risk AND don't bring any additional benefit to just writing code in your normal programming language to do the same thing.

You can take my list comprehensions from my cold, dead hands.

There isn't a use case I've seen where these types of mini languages fit well. Ostensibly, you could give it to a user to write to query JSON in a domain-agnostic way in an app but I think it would just confuse most users as well as not being powerful enough for half of their use cases.

Sometimes it's better just to write code.
https://archive.is/txXec
Doing these every day for 2 minutes might have prevented it: https://www.youtube.com/watch?v=CF-RHMI-Oo0
I think the US is very far from that happening. Even increasing the capacity on the existing long lines would be a nice improvement.
> software engineers can't estimate how long something will take with any kind of accuracy.

Sure we can, it's always one of:

- A couple of minutes

- Today

- A week or two

- Probably around a month

- I have no idea, could be any of the above or more
Hey Web Developers!

Are you looking to supercharge your project development? Look no further! I've got FREE source code available for both front end and backend, covering React, PHP, and Flutter.

Whether you're a seasoned developer or just starting out, these resources will help you speed up your projects and bring your ideas to life in no time.

Drop a comment below if you're interested, and I'll hook you up with the code! Let's make development easier and more fun or you can check out the channel which gives source code free
I am working on coding stuff I like as escape for the absurdity of modern software. I make little games, stuff for 8 bit systems etc. Stuff that is as far away from anything modern , especially the hell of node, next, devops and ‘web frameworks’ as I possibly can. It works. It’s very relaxing, like a bonsai tree.
But sorting issues according to their rough size is precisely what makes at least basic sense. A scale of trivial (can make many of those in a day), simple (several of those a day), medium (roughly a day of work) or large (days) makes it possible to have at least basic conversation around work planning. I’m not extra sold about calling those by shirt sizes, but I’m sure we’re on the better end of the absurdity scale here :)
Agree, but I think in a B2C context, you need convenience first; then security can follow.
Still you could in Java avoid the (under the hood) memory allocation and garbage collection by reusing the same objects. If you wanted to, of course, it probably takes a bit more effort / caution at the developer's side but may provide some improvements in performance in very specific cases/situations.
> it's the haha guy again

Hahaha! :) I don't remember you. What guy are you? Some kind of abuser, right? Haha :)

In my experience, it's the people who rush to label others that are normally pretty toxic people themselves. hahahaha :)

So you're against laughter??? Hahahaha! :) I'm not laughing at you...Hahahahaha! :) Well....maybe a little bit, now. I wasn't tho hahahahahaha! :)
Because it's a surprisingly tricky topic on modern operating systems [1], and even trickier in web browsers (smooth scrolling was actually much easier to achieve on hard-realtime systems like the 8- and 16-bit home computers of the 80's and early 90s).

TL;DR: if you base your animation- or scroll-speed on the 'raw' measured time between two frames, you'll get micro-stutter because it's pretty much impossible to obtain a non-jittery frame duration on modern operating systems or web browsers, all you can do is try to remove the noise via filtering, or 'align' your measured frame duration with the display refresh interval, which on some platforms cannot be queried.

In web browsers the most important problem is that you can't measure the exact frame duration (which is fallout from Spectre/Meltdown), or obtain a precise 'presentation timestamp', or even query the display refresh frequency.

Even in the native OS APIs that provide a presentation timestamp (like DXGI on Windows or CVDisplayLink on macOS) that timestamp has considerable jitter and has not much to do with the actual presentation time when the frame becomes visible to the user.

And as soon as you base your animation timings on such a jittery timestamp you'll get micro-stutter (the easiest way to get smooth animation is actually to assume a fixed frame duration, but then your animation speed will be tied to the display refresh rate).

It's often possible to eliminate the timing jitter with 'noise removal' filters or just tracking an average over the last couple dozen frames, but those then may behave funny in situations where the frame duration changes drastically (such as moving a window between displays with different refresh rate, or when rendering stops and then resumes because the window or browser tab is fully obscured and then becomes visible again).

PS: Raylib's frame pacing code on the web is also a bit on the crude side [2].

...e.g. it just sleeps for 16 milliseconds, and relies on ASYNCIFY to enable a traditional render loop in browsers. It would actually be better to use a frame callback via requestAnimationFrame (or the Emscripten wrapper function emscripten_request_animation_frame), but this means giving up the cross-platform 'own the game loop' application model. Not that requestAnimationFrame alone solves any of the above mentioned time jitter problems though.

[1] https://medium.com/@alen.ladavac/the-elusive-frame-timing-16...

[2[ https://github.com/raysan5/raylib/blob/f1007554a0a8145060797...
Maybe to be a bit more clear than the sibling comment, the fact that it could easily be done does not mean that it is legal (in China). Google may not want to burn all bridges with China. As a private or smaller entity you can totally do this and not care, but if you're large enough you get into political squabbles.
Resident passkeys really are just the 2020-JavaScript version of X.509-based mutual authentication - naturally it's incompatible with anything but the web, sits on a weird level of the stack, and is somehow even less transparent to the user. On the other hand, certificate slots still seem to run approximately a dollar each.
I think that's pretty true in my demographic - kind of old fat, at risk of heart attacks and a casual cyclist. For us lot heart attack deaths are like 1000x+ more than cycle head fatalities. On the other hand for young cycle racers I'd go with compulsory helmets.
> when people started coming with so many unrealistic and absurd expectations and demands about what my furniture should do

There, fixed it for you.

People are the same just pay sucks way more.

I wholeheartedly endorse woodworking as a meditative hobby to forget about your day work but as a career path you are going to have some very rude discoveries.

Looking at their projects it's mostly basic carpentry level as well. Fine woodworking, the projects where you can charge five figures for a dining table (and you spend a few months making it full time), needs much more design vision and years of practice. Those 10k hours required to master a skill seem about right.

Been through a burnout 20 years ago, had to take a year off and then discovered that if you place correct boundaries and don't let people mess with you, our trade can be pretty enjoyable.
Thanks, but this isn’t my first rodeo. In the future, please more carefully exercise more discretion when whipping out the snark.

> software engineers can't estimate how long something will take with any kind of accuracy.

This is both irrelevant and wrong.

It’s irrelevant because t-shirt sizes, story points, and other abstract measures, are - intentionally - not measures of time. It’s a measure of effort, benchmarked against other units of work. Yes, this can, sometimes, give a vague indication of time. It’s also useful for other reasons, too, like weeding out whether or not everyone is on the same page with regard to what needs to be done in the first place. All of this is explained in literally any primer on the subject.

You’re wrong in saying that software engineers aren’t capable of estimating effort (or even time) with any degree of accuracy. They can. I can tell you that my Python hello world script will take less time and effort than rewriting the Linux kernel. None of the “research” and “experience” that you so confidently refer to says what you think it does. It says that there are big limitations to the degree to which timelines can be estimated. This is entirely true. But there’s nuance to it. You’re so desperate to find a shortcut to being smart on the internet that you’re spreading blatant disinformation in the process.
Got it. Im just exploring ideas. Companies put their data in third-party servers like AWS all the time.
I'd be more mad about this if building native applications wasn't super shitty these days. Xcode crashes all the time. SwiftUI is terribly documented and buggy. And lots of standard things you see apple do in their apps are basically impossible to do from 3rd party code. And its impossible to debug anything because its all closed source. And windows has about 8 different native UI libraries that all look and feel different, and they're constantly making new ones instead of making one UI be good and well supported.

I hate electron with a burning passion. But at least the web has open standards, good debugging tools and modern, performant, well documented and pleasant to use UI libraries like React, SolidJS and so on.

Just don't ask about rich text editing on the web. Oh god. Its been decades and its still so shit.
> Nowadays computers are almost never shared.

That doesn't seem very accurate, unless you're meaning strictly personal computers?
Old habits die hard I guess. Haha!
I do appreciate your input though. Thank you.