skysight-inc/HackerNews huggingface dataset:
Every HDD since the 1980s has guaranteed atomic sector writes:

> Currently all hard drive/SSD manufacturers guarantee that 512 byte sector
writes are atomic. As such, failure to write the 106 byte header is not
something we account for in current LMDB releases. Also, failures of this type
should result in ECC errors in the disk sector - it should be impossible to
successfully read a sector that was written incorrectly in the ways you describe.

Even in extreme cases, the probability of failure to write the leading 128 out
of 512 bytes of a sector is nearly nil - even on very old hard drives, before
512-byte sector write guarantees. We would have to go back nearly 30 years to
find such a device, e.g.

https://archive.org/details/bitsavers_quantumQuaroductManual...

Page 23, Section 2.1
"No damage or loss of data will occur if power is applied or removed during
drive operation, except that data may be lost in the sector being written at
the time of power loss."

From the specs on page 15, the data transfer rate to/from the platters is
1.25MB/sec, so the time to write one full sector is 0.4096ms; the time to
write the leading 128 bytes of the sector is thus 1/4 of that: 0.10ms. You
would have to be very very unlucky to have a power failure hit the drive
within this .1ms window of time. Fast-forward to present day and it's simply
not an issue.

^ above quoted from https://lists.openldap.org/hyperkitty/list/openldap-devel@op...
Dioxus is also a vDOM based framework (like React). Leptos is a fine-grained-reactivity framework (like SolidJS/Svelte).

They are both _way_ faster than React, and they are both faster than Vue and Svelte by a larger magnitude than SolidJS is faster than either of them.

That is not because Dioxus/leptos have less features than Yew. I'd actually argue they are more feature-full [1].

For icing on the cake: the most "bare-bones" WASM/Rust based entry to the benchmarks, "sledge-hammer", is as fast as the most bare-bones JS entry.

There are valid reasons for not using a Rust frontend framework (over-the-wire size, compilation speed, ecosystem, ..etc), but execution/DOM-manipulation speed is not one of them.

[1] I've used leptos, and tried out Yew, and have read through the docs of all three.
> The pyramids of Egypt contain hieroglyphs that were chiseled in stone thousands of years ago. The ideas hieroglyphs convey are more important than the type of chisel that was used to carve them.

Actually this is false. There are no hieroglyphs in the Pyramids. This is one of the reasons there is a theory they were built a long time before the classic Egyptians.
The hardest part of debugging Python is "hitting the wall" when you come to a native library (compiled C code). And Python has achieved a lot of speed-ups from Py2 to Py3 by adding more compiled C code. This is a real blocker for understanding the foundation library.

On the other hand, in Java, with a few exceptions around Swing (native painting for GUIs) in Java, almost everything is written in pure Java, so you can debug all the way down if need be. It is a huge help for understanding the foundation library and all of its edge cases (normal for any huge library). Modern Java debuggers, like IntelliJ, are so crazy, they will decompile JARs and allow you to set debug breakpoints and step-into decompiled code. It is mind blowing when trying to debug a library that you don't own the source code (random quant lib, ancient auth lib, etc.).
Depends on what quality you optimize for. The quality of the execution, the quality of cost controls, etc.

If you mean the quality of each unit of the product, then yes, you're largely right. You just need enough quality to let people buy from you, and any corner you can cut without losing sales is profit. However, often a startup needs to push the quality bar at first to be competitive with large existing incumbents in a market segment.
Touchscreens must avoid subsuming required, frequently used, or emergency controls. If/when car designers violate this rule, the interior UX is fundamentally unsafe and/or unusable.
> Tesla is Apple and BYD is like One Plus (bad analogy because One Plus doesn't sell many cars)

Yeah, it's a very bad analogy, nobody on budget buys a OnePlus 11. A One Plus 11 is 1- just slightly cheaper than an iPhone 14 and 2- is technically on par https://www.makeuseof.com/oneplus-11-vs-iphone-14-plus/ - almost a counter example ironically
I'm an order of magnitude more afraid of a regular cop back in America than any police in Europe.
"Extreme algorithmic research combined with a high LOK of Linux syscalls and platform specific optimizations is what allows this to exist."

No, author's extreme boredom and/or free time allowed this to exist. Nothing else.
I'm surprised most theaters haven't gone bankrupt by now (not because of subtitles)
The biggest issue with biters, IMO, is that their density continues to ramp beyond you capping out your ability to efficiently eliminate them.

In my (normal level biter) space exploration run, my buddy and i didn't run into any problems clearing out a large swath of space to build by rushing artillery and flamethrower turrents. The problem became the tedium of expanding our territory to keep the pollution cloud contained by manually firing artillery.

IMO, the problem should be solved by giving the player better tools for artillery automation. The auto-firing artillery is both too short range, and has a tendency to anger a bunch of nests at once. Instead, it should focus on eliminating one nest cluster at a time, and maybe allow for circuit-controlled timing of when to move into the next cluster.
I'm somewhat confused by wet-bulb calculations. Here [1] is a calculator for converting temperature+humidity to approximate wet bulb temps. Today's weather forecast in Houston is a high of 38 with a humidity of 85%. [2] That's an approximate wet-bulb temp of 35.66?

This article, among a slew of others, are now claiming that's supposed to be lethal? I mean it's uncomfortable, but you're not going to die in that weather in 6 hours. Depending on the season that's a perfectly normal day in many parts of South Asia, and that's been the case for decades.

So, what gives? My first assumption is that the calculator was broken, but another one [3] gave an identical figure.

---

[1] - https://www.calctool.org/atmospheric-thermodynamics/wet-bulb

[2] - https://openweathermap.org/city/4699066

[3] - https://physicscalc.com/physics/wet-bulb-calculator/
I guess it's your right to believe that as long as you want, the evidence is that it's beating people at every exam like AP exams and GRE exams and bar exams and medical certification exams and not only like regurgitating facts but it's also superhuman level in theory of mind. And all that comes from just an architecture that reads every text and uses a lot of GPU power.
Something like 60% of jobs can't be performed remotely. And of the 40% remaining, I think it's safe to say not all of them are allowed to be remote (due to office politics / management bullshit).

A couple potentially relevant sources for that:

https://bfi.uchicago.edu/wp-content/uploads/BFI_White-Paper_...

https://www.forbes.com/sites/traversmark/2020/04/24/what-per...
Also, creating a subclass just to add extension methods is definitely boiler plate. Util classes too, though they are useful for packaging functions at least.
It‘s more likely about 2.6%, since elite riders would ride 40k in about 45‘ in reality (Tour de France riders have an average speed of up to 54kph during time trials).
Why? What purpose would that serve?
> The solution offered provides an external system that provides a way to determine if someone did something even if Wikipedia tries to hide it later.

No it doesn't.

This system is signing the revision id number (im assuming based on the video). There is not neccessary any connection between the signer and the revision id. There is no way to verify if the revision id was ever valid (typically revision ids are sequentially increasing numbers but there are edge cases where that is not true. And i dont mean censoring edge cases, although there are systems on wikipedia where pages can be deleted or revisions hidden)

So what does this system actually prove? That someone at a specific point in time signed an integer. Maybe that integer corrdsponds to a edit they like, maybe it doesn't. Maybe they never read the edit. Maybe the edit never existed.

This whole thing is seriously stupid. It is a non-solution to a non-problem. The problem they are trying to solve doesn't exist and even if it did this wouldn't fix it.

I mean hell, at the very least you think they would sign a hash of the edit instead of just an id number.
It is almost as if stock prices fluctuate over time. Who'd have thought...
My local CS uni always put an emphasis on Erlang and that was weird to me until I learned there was an Ericsson HQ down the street
Perl is such an interesting language. It's the first language I learnt seriously (pity me) and despite its quirks and failings, it was always a huge amount of fun.
bitcoin is saving it, they installed so many subsidized bitcoin mines there and now they can use that power infrastructure during the heat wave
> "and most importantly the WYSIWYG, mouse-driven graphical user interface provided by the Alto"

This should be better, "available on the Alto". Neither was this in the/any OS, nor was Smalltalk or Bravo/Gipsy for the matter the sole software available on the Alto. The wording suggests a consistency, which simply wasn't there.

Notably, what was going on at PARC wasn't a secret: PARC published papers and key developers at Apple, like Bill Atkinson, were familiar with at least some of them. The latter were also those, who wanted Jobs to see this in real live and who accompanied him on the trip, and they came prepared. Moreover, numerous tours to PARC and its software had been given to outsiders before (compare A. Goldberg), some of these tours even more complete. However, Jobs was the first – at least in part (he later said, he totally missed out on the network and its importance) – to grasp what he was shown, which in turn convinced some of PARC personal like Larry Tesler (who was giving part of the presentation) to switch to Apple, in order to see this technology become a reality. (Jobs getting the GUI must have been some of an experience.)

Obligatory link in this context (a series of polaroids from Lisa development): https://www.folklore.org/StoryView.py?story=Busy_Being_Born....

(Mind bitmapped graphics being documented before the visit and, probably also before this, a first prototype of a windowed document. It is also interesting to see how the influence of the PARC visit shows also as some of a distraction, and it's only when they gradually inch back towards the original window design that things start to come together. May we interpret this as a process of emancipation from PARC's influence?)
It's also very... American to not think mention the absurdity of machine guns at airports, even in the hands of humans. Even if lethal force is required, would you want a security person (not a trained policeman) to "start blasting" and spraying bullets with a machine-gun?
Immediate contact and for quite a while until you brush again. Leftover sugars are turned to acid by mouth bacteria.
> This is an interesting stat, but I think it's misleading - the vast majority of cost for solar/wind is upfront, so it will naturally appear more expensive in the short term even if it's cheaper overall.

Very good point!
> I wrote a perfectly lucid response which you ignored completely.

I wrote why, and you definitely literally ignored what I wrote.

> Who are you quoting (and what is it even supposed to mean, besides)?

I'm very shortly representing what you wrote. So it's for you to answer what this means.

> Nope

Yup. Otherwise you wouldn't resort to bad analogies.

Anyway. This is going nowhere.

Adieu.
Hmm, tell that to the millions of people living in the UK in terraced/town houses where the only charging option is to drag a cable over the public footpath to the road side....if they manage to get a parking space directly outside their home.
It's not a "GoPro", it's a static spy camera requiring external power. And 2K is just 128 more horizonal pixels than HD.
> What if Wikipedia started charging or restricting API access?

Wikipedia has a downloadable data dump that would cost almost nothing to serve to Google, and it has an organisational mandate to make that data available. If they decide to charge for access to that I'm sure Google can afford it. Let's not throw around completely unrealistic hypotheticals.
What is the motivation of anyone to make a website at this point? I don't see it.

I've not seen very much discussion about the issues these LLMs are going to cause, this article is sort of talking about it - twitter and wikipedia could restrict their content, but - what about the millions of webmasters who ultimately created what the web is today?

What is the motivation of anyone to really create content any more, apart from for actual social discussions on social media? LLMs will steal the content, and no one will read it.

I really don't know what this will bring in the future. Will online content fizzle out in 2-3-5 years and fresh content will just disappear? Will LLM only be good up to 2025 data?

This is a massive problem that changes the web as we know it, yet I don't see any discussion of this. Mark Andreeson bought it up for a sentence on lex Friedman, but that was it. He didn't know the answer.
"I followed the instructions and it said I didn't have grunt installed. Now I'm
an old guy so I didn't really know what grunt was and my grunt files weren't
right or something. So I googled a bit and I found out what grunt was.
Grunt's... I still don't really know what it is."
--Joe Armstrong, https://www.youtube.com/watch?v=lKXe3HUG2l4

The other day I ran `gem install wayback_machine_downloader`. I never liked Ruby the language enough to get into its ecosystem, but I note that said ecosystem has from an outside perspective remained remarkably stable. gem is still the thing to use (dear god Python what became of you), Rails is still around... I'm waiting to work on a new project with a complex enough front-end that justifies more than 0-30 lines of JS, then I can be happier with HTMX instead of whatever giant framework is most popular these days.
And, the most important fact:

* Europe is a diverse place and such statistics vary a lot by country. You can't talk about the Netherlands and Romania in such a generalized way, you'll gloss over a lot of details.
German Autobahn, for those handful of sections without at least temprary speed limits. And on tracks, but let's be honest, vehicles like the Plaid, and similarly heavy vehicles, suck at tracks. Going fast in an almost straight line is easy.
I struggle to see how 10 bits of check data will help much. I guess if the extra bits aren’t persisted to storage it doesn’t hurt so why not?
> I have, and I continue to. It's not hard.

I also write JavaScript code without NodeJS and package.json. It's not hard when the code is simple. But it doesn't scale. For a complex code, I want a linter, I want automated tests and coverage, I want to split the source code over many files... NodeJS is the standard requirement for all of these.

> Firefox, a serious desktop application by any measure, was written in JS from the very beginning. (Yes, really. A combination of JS and C++, at least

At the very beginning, this web browser started under the name "Netscape", and JavaScript didn't exist yet. Mozilla forked out of Netscape in 1998, and there was little JS in the source code at this time.

> it predates Node and all of the bundler/package.json stuff that you are implicitly arguing is somehow unavoidable.

Firefox doesn't use the standard bundlers of the Node ecosystem, but it's because it has its own build systems and bundlers. It's a beast that needs 30GB of disk to compile, with a custom build system written in shell, Perl and mostly Python, with many tests systems (including for "mochitest" JS code).

For instance, among the dozen of linters that Firefox uses, there is eslint, which a normal JS project would install through a package.json.

> JS. It's a much nicer—and more thoughtfully designed—language than it gets credit for.

JS was notoriously designed and implemented in a rush, because Netscape was under pressure from Microsoft. It also suffered from legal constraints that block the adoption of some Java concepts. Once LiveScript/JavaScript was born, its evolution was chaotic since the browsers war prevented any consistent progress of the language. After it settled, Ecmascript did enhance the language at a fast pace, but it cannot fix the many inconsistencies and design flaws.
True, also ate a lot less sugar.
AliExpress photoshop hands are the best.

AI hands are usually missing digits and have webbed fingers.
We did Scala at an old job and various kinds of implicits got us into so much trouble. I think if you use them judiciously, they'll be fine, but you need quite a bit of experience and maturity to use them judiciously, which most of us lacked.
Security researcher vents over RUCKUS Networks bug, botnet
In particular, deployment via terraform and friends feels incredibly like living in the days before linkers were discovered.
As any now typical text of this nature, it cites very little real data.

Here is an article on how recent historians believe that English male height during the Industrial Revolution went down due to malnutrition:

https://www.economist.com/free-exchange/2013/09/13/did-livin...

Historians now think the Industrial Revolution was a giant economic boom where the majority of individuals actually became poorer.

Here is an Indiana University paper, consistent with the findings of others, that automation did reduce manufacturing jobs

> The basic takeaway from the Ball State work is that both forces—offshoring and automation—are in play in the massive occupational realignment due to hit the U.S. economy, but automation is dominant (Wells, 2017). This assessment, that automation is the greater threat, is consistent with their earlier work placing the loss of manufacturing employment on increases in productivity

https://www.ibrc.indiana.edu/ibr/2018/fall/article2.html

This was all around the Trump years when the media and academia were happy to say “China didn’t do it”. Even the NYtimes said it at the time.

https://www.nytimes.com/2016/12/21/upshot/the-long-term-jobs...

Yes we can find jobs for people if we keep trying. But the jobs that we find in a post-scarcity services society are often precarious and meaningless - and people know it. Agriculture and manufacturing, which are the two job categories that really matter, do lose jobs to automation because we are squeezing them for profits all the time through all available methods.

To say that everything will be hunky dory with AI is just the same as saying the steam engine won’t take your job. That was BS in the 1800s and it’s BS now. And yes people did lose their way of life and they did become poorer, as demonstrated by the current studies on the matter.
Things like this mean I just can't regard Tesla as a serious car company.

They're a company that mostly makes cars, sure, but they (and investors) clearly view themselves as something else.
That's all just false. Just because you're single-writer at the application level doesn't mean the OS isn't queueing enough writes to saturate storage at the device level. We've benchmarked plenty of high speed NVMe devices, like Intel Optane SSDs, etc. showing this.
http://www.lmdb.tech/bench/optanessd/
> it is becoming less and less of an issue with the new GC work coming online

I feel like I've been hearing this same line for 20 years now
You're right, I was subconsciously replying to other comments about evils of passing parameters by reference.
Interesting. Do you need to put the extension method in a utility class at all though? Could we put it in the Main class in the example?
My favourite one is the ghost cities. Sure some are still under-populated/didn't work out as well as planned but by and large the pre-building of cities/districts has worked out well.
As the Docusaurus maintainer, I stand by behind these ideas. Markdown is a portable format, and I'd like to make Docusaurus/Obsidian work well together in the future.
My complaumtnis that typing shouldn't be optional.

With Node, not only is it optional, it's a third party dependency.
That problem seems very solvable if they don't need to monetize your data. You might, for example, turn off search history and the use of search history to guess what you might mean with new searches.
As already discussed yesterday [2], the W3C charter for web annotations has completed with a Recommendation (final) status, that's what happened to it. The Open Annotation Group, on whose work it was based, has a github repo [1] (with last material updates around 2015/16) where it has maintained annotator and other libraries that are or were used by hypothes.es and other services. I have my reservations about using JSON-LD for this purpose, having the vibe of W3C looking for problems to their solutions, like they did with XML all over ie embedding JSON fragments into HTML script elements for metadata (!) when there's extensibility in HTML and/or RDFa already.

Sadly, it's safe to say it never quite took off, and the only collaboration effort that has seen some use in quantities remains the much more modest pingback/linkback protocol. It's not clear to me, though, whether pingback is/was only popular because it could be exploited for DDoS attacks.

[1]: https://github.com/openannotation

[2]: https://news.ycombinator.com/item?id=36560937
How to think about async/await in Rust
That off the shelf stuff is some Dell hardware (and fireware from 7 different venders) with some VMWare stuff on top, I can guess why somebody would go for Oxide.
Use your own Reddit API credentials in Apollo
> Using WebAuthn, you're able to use a single authenticator (like a Yubikey, for example) on any site that supports the standard. This way, as a user, you don't need to have passwords

Security people are literally delusional.
That certainly seems way better than the old way of having to include the inscrutable line noise to construct, fill and then bless a hash reference in every single class, which is what we had to do back when I programmed perl.
Perl 7 plan has been abandoned?
Perl, like Tcl, comes from the Walter Bishop Era of IT, where things were apparently batshit crazy at times but they managed to do things we now fail to replicate :D

Now, much effort is spent in making sure that a single team member cannot get weird ideas and do too much on their own.
For the moment it's tied to my data model, but I don't see why I can't provide a sort of wrapper :)

I'm just not sure if at that point it makes more sense for you to just create that part yourself
Thanks for providing your data point!

If you're having another go, I'd recommend checking out sledge-hammer[0], a wasm-bindgen alternative that the folks behind Dioxus have been working on. It's a faster, but more limited version. Best of luck!

[0] https://github.com/Demonthos/sledgehammer_bindgen
There is also a healthy fear of change in the java community that could explain it.

Nice jab at the end! Java (well, really Sun, then Oracle) prioritises backwards compatibility over every other goal. So, does Win32 API. Does DotNet do the same? I'm unsure.

This also explains why it took so long for Java to get lambdas. And, generics with primitive types, e.g., ArrayList<int>, via Project Valhalla. It is a super hard problem to upgrade Java without breaking old stuff. Hence, it is a multi-year R&D effort.
My wife is related to the Panhard family and many of them are collectors of the brand. There are 2 CDs in the family, perfectly restored. That car is indeed magnificent. The main problem is there's only a handful of mechanics who know and can work on such cars (leaving out the absurd money it requires). Replacing pieces can be an industrial endeavor to set up a factory line to craft new copies of the needed pieces.