gary_0

It's my guess that they don't want to. A decade ago when AMD's CPUs had trouble competing at the high end, they ceded that market segment almost entirely, and now they're doing the same with nVidia. And Intel is basically a dead company. Neither of them are going to risk the capital and internal shake-up necessary to actually compete with nVidia. And anyways, there's only so much TSMC capacity for high-end chips, and Apple and nVidia have already spent infinity dollars reserving most of it.

Underrated in proprietary and non-software tech, too. It's horrible when infrequent tasks turn into bespoke shitshows every time they crop up because nobody wrote down how to solve the problem. Having to figure things out from scratch every time is ridiculously inefficient. Even worse if it leads to customers having slightly different copies of the same kind of software or device configuration because there's no documented process to follow. I know from experience.

Chips that old would be on a ~100nm process node, which is ancient. Anything using Flintstone transistors like those isn't going to hold up.

> the pentium 4 engineers probably felt like the smartest people alive

The P4's NetBurst architecture had some very serious issues, so that might not be true. NetBurst assumed that 10GHz clock speeds would soon be a thing, and some of the engineers back then might have had enough insight to guess that this approach was based on an oversimplified view of semiconductor industry trends. The design took a lot of stupid risks, such as the ridiculously long instruction pipeline, and they were always unlikely to pay off.

Longer than that, for sure. They were deploying ML systems at least as far back as 2011.[0]

[0] https://en.wikipedia.org/wiki/EdgeRank

Unfortunately a C compiler isn't going to know what to do with your probably-unaligned pointer to 5 floats that you're doing mostly horizontal arithmetic on. And SIMD instructions provide zero benefit if the data is spread out in memory, as is the case for most C/C++ application code.

Otherwise, if you want to smack proper vectors and matrices together at high speed, libraries like Eigen or DXMath already abstract away the SIMD details and work great. For nitty-gritty stuff like codecs, that's always going to be handwritten with intrinsics (or ASM), and that's fine. And libc functions like memcpy already use the fastest, fanciest instructions. It's mostly a solved problem.

Lastly, for a lot of tasks, regular math instructions are plenty fast. On modern CPUs, you need to be doing a lot of math before worrying about SIMD is worth it. And once your program becomes particularly math-heavy, you'll probably want to use the GPU instead anyways.

Not open source. "You will need internet connectivity to validate your AccessKey with Picovoice license servers ... If you wish to increase your limits, you can purchase a subscription plan." https://github.com/Picovoice/orca#accesskey

I almost get the feeling the only thing Intel thinks it has left in terms of value is the brand name itself; a blue sticker to put on consumer/business devices, nothing more. I also would have liked to see Intel continue to pursue its own GPU technology but the engineering culture required to keep that going might have died a long time ago, and the MBA vultures running Intel are only just now burying it for good.

No real mention of GPUs, instead they're "revitalizing the x86". Reading between the lines, my guess is that Arc is getting cancelled soon. (Don't spend it all in one place, NVDA shareholders.)

Apparently the treatment costs $3.2 million. https://en.wikipedia.org/wiki/Delandistrogene_moxeparvovec

Apache was quickly spun off from its NCSA roots to become its own thing. There's a lot of history here that you're twisting around or ignoring. I'm not even American but, while lots of other countries made their own contributions, it's insane to argue that networked computing would have advanced anything like it did without the US's innovations borne of their (former) attitude of experimentation and exploration.

Not to mention almost all the breakthroughs on top of the initial Web happened in the US: Mosiac, Netscape, Apache, Yahoo, Google, etc. Many of them started out as "non-essential" research projects.

The Marginalia search engine or archive.org probably don't deserve such treatment--they're performing a public service that benefits everyone, for free. And it's generally not in one's best interests to serve a bunch of garbage to Google or Bing's crawlers, either.

Technically with lossy compression, the amount of information conveyed will likely change. It could even increase the amount of information of the decompressed image, for instance if you compress a cartoon with simple lines and colors, a lossy algorithm might introduce artifacts that appear as noise.

I'm really curious what year this webpage is from. My guess would be the mid to late 90's, but it would be interesting to know for sure.

Shor's algorithm suggests that a lot of encryption doesn't actually work, but of course it requires a quantum computer that hasn't yet been built, and may not be practical to build, so fingers crossed. At least there are quantum-resistant encryption algorithms, and OTPs are still provably secure like you say.

I think the blog post is arguing against a volley that happens all in one instant, requiring all the archers to synchronize perfectly. This seems pretty easy to argue against because while movies do it because it's dramatic and cool, it's harder to justify in actual combat situations (and the post goes into great detail on the pros and cons).

However, it seems a lot more reasonable to suppose that archers were sometimes told to hold until a given strategic moment. In that case, you might see something resembling a volley when, say, an advancing enemy reaches a particular position and the archers begin loosing. But I don't think that's what the post was talking about.

Using 2024 numbers for ARM might not give a clear picture, because that was many years after major companies like nVidia and WD already switched all their major internal chips to RISC-V. ARM's lunch was already partly eaten; many billions of RISC-V chips were already in the wild in 2024. And companies like Tenstorrent have been building high-performance stuff on RISC-V for a while. If Jim Keller thinks RISC-V is worth it, the advantage must be worth more than 1%.

Their blog looks like it's integrated with Bluesky, where they have 15K followers, so that's where the activity is coming from. It's not uncommon for high-profile devs to get that much engagement there.

Apparently the FAA database that tracks accident investigations is down also, and probably a bunch of other systems that regular people aren't aware of that various organizations rely on.

If this was a Chinese cyberattack, it would be the scandal of the decade. But it's on purpose.

It is standard practice to translate software into many languages, whereas road signs cannot be.

The future has been here for a while but remains unevenly distributed.

> by not intervening he essentially endorses that getting rust into the kernel requires consensus from all subsystem maintainers

And let's not be obtuse, some of those subsystem maintainers are staunchly opposed, so "it's up to them" is obviously an indirect way of saying "no rust". I don't blame those maintainers for balking at a whole new very different language, but Torvalds has a choice of telling them either "suck it up, buttercup" or "I hear you; rust is gone". Instead, he's just letting things fester.

Positive, yes, but can you point to where he says R4L is here to stay and an integral part of the kernel? He needs to commit, or drama like this will continue to boil over. He also seems content to let the C-only old guard give the R4L guys a hard time. If you only enforce the rules on one side of a conflict, it makes it pretty clear which side you agree with.

The Rust drama is an uncommon failure of leadership for Torvalds. Instead of decisively saying "no, never" or "yes, make it so," he has consistently equivocated on the Rust issue. Given the crisis of confidence among a sizeable (and very vocal) contingent of the Linux community, that decision has backfired horribly. And it's quite out of character for Linus not to have a blazingly clear opinion. (We all know his stance on C++, for instance.)

As a pilot program, R4L should have graduated or ended a long time ago. After several years of active development, its status remains unclear. Instead of cracking heads to get everyone on the same page, Linus has instead spent all this time sitting back and watching his subordinates fight amongst themselves, only to then place responsibility for the drama on Martin's shoulders. Poor form.

Arguably his reprimand of Martin is a clear signal that he will never show Rust any favor, but he hasn't said anything explicitly. Maybe he knows he should, but he fears the shitstorm it will cause. Maybe it's time for him to rip off the band-aid, though.

And again, all of this could have been avoided if he'd just put his foot down one way or the other. Imagine how much time and energy (even just Martin's alone) could have been saved if Linus had just said "no, keep it downstream".

> it shows me the source and I can click on the link to verify the source ... (search engine use case)

To me, this is exactly a search engine. I type my query into 2005-2015 Google, I scan the page summaries under the links to see the answer, and click the best-looking result to confirm or read the details. Occasionally you need to re-word your query to get the answer you're looking for. Sometimes I don't bother clicking through because the answer is right there.

I don't really care that I can use plainer English with an "AI"; I'd be happier if I just got 2010 Google back. But sadly, it's gone.

The "what if you don't have the software" argument doesn't hold water for me. What if you don't have git? What if you don't have a text editor? What if you don't have a filesystem?

Most programming language communities are okay with expecting a certain amount of (modern) tooling, and C can't rely on legacy to remain relevant forever...

That's 32.5 megabits/sec, not MB/s. It uses the 802.11ah standard.

https://www.morsemicro.com/products/

https://en.wikipedia.org/wiki/IEEE_802.11ah

I remember vividly how unfun resistive touchscreens were.

Especially on tablet computers, which existed long before the iPad, but never caught on. They also had terrible battery life, ugly TFT screens and backlights, unreliable wireless connectivity, laggy UI (Apple seems to be the only company that cared about a consistent 60Hz response), and I think a lot of them ran Windows CE? I'm not sure about that last one, I don't remember, but I'm sure the software sucked.

(I'm excluding the Palm-Pilot-ish devices with low-powered CPUs and monochrome LCDs here; those started popping up in the 80's, and of course there was the failed Apple Newton. The devices I'm talking about were basically x86 laptops without keyboards.)

> Nobody said they wanted an iPod or iPhone or iPad or a Macbook Air before

What do you mean? There were MP3 players before the iPod, Blackberries and PDAs before the iPhone, and tablet computers and lightweight laptops before Apple popularized them, and people did expect the somewhat clunky early versions of these technologies to improve. For instance, there were a lot of jokes and commentary about the rapid evolution of cellphones in the 1995-2005 era as they went from horrible bricks to trendy gadgets with cameras, software, multimedia, and e-mail -- all before the iPhone had even started development. People were not totally blindsided when Apple offered their streamlined version of already-existing ideas.

Jobs should get credit for the leap in quality, functionality, and mass appeal his products represented, but lately I've noticed the history is getting exaggerated to the point where we were all using rotary phones and beige boxes like cavemen before Steve Jobs singlehandedly invented the laptop, tablet, and smartphone. But the truth is far more nuanced than that.