timschmidt

Sometimes specificity matters. Usually when looking directly at some specific piece of code. In this conversation, the intended meaning was clear. Folks just love being the pedant and the brinksmanship which comes with it. There's a propensity to derail otherwise useful conversations into discussions like this rather than dig deeper into what people meant, and were trying to communicate.

No. It's been quite some time since I realized that all language is a pidgin used to translate between individuals' unique lived experiences and points of reference. And find communication much more fluid and less confrontational when the focus is on shared meaning rather than perfect word choice. Especially when working with non-native speakers, but also just people in general. Stephen Fry captures the feeling: https://www.youtube.com/watch?v=Ovi7uQbtKas

When TZubiri made their original comment, I understood they were speaking about some or all of the issues outlined in the paper I linked. If you didn't, that's ok. If you think the referenced paper missed something, it's OK to add that.

> You make it really hard to take you seriously.

Same, bud.

I find that pessimism holds most of it's practitioners back from their full potential.

The surface of mars is roughly the size of Earth's dry landmass. They'd have to spend quite a lot of effort looking for it to find it. And at that point it'd probably look more like a treasure trove of useful thermoplastics, refined metals, magnets, and other useful things otherwise difficult or expensive to source on Mars directly.

There are enough problems for a 44 page paper titled "What Every Computer Scientist Should Know About Floating-Point Arithmetic"[1] I don't quibble on the language because I know what people mean.

Most folks won't encounter most of the issues, generally. But expose your code to a large enough dataset, or be like me and write a CAD/CAM system with motion control and experience most of them.

That's why I wrote hyperreal[2]

1: https://www.cs.tufts.edu/cs/40/docs/WhatEveryComputerScienti...

2: https://github.com/timschmidt/hyperreal

> Floating point is deterministic, what are you talking about?

Order of operations can change a result, for example. I suspect you mean that the algorithm never changes. While op means that mathematical operations which most folks would expect to be reliable are not.

Oh hey, one of my projects is relevant to an article: https://github.com/timschmidt/hyperreal

It's an infinite precision exact constructive real with excellent performance characteristics and approximation only at explicitly named lossy export functions.

Some recent benchmarks: https://github.com/timschmidt/hyperlattice/blob/805d092d1d96...

I'd go even more radically low cost, and kit the first lander out with wifi, and a half dozen each of every commercially available robot dog, humanoid, and wheeled or tracked robot of any interest. Rumble in the Mars Robodome. Bit of publicity for the existing manufacturers who may be willing to pay for the privilege, and who will undoubtedly learn valuable things about how their designs fail and can be improved. And you figure out in one stroke if there's a COTS platform you can buy for $30k that gets you 80% of what you need. If any of them function for any period of time, you use them to prepare the space for future landings. Rinse, repeat. After a few iterations, you have a half dozen manufacturers with commercially produced platforms with a few strategic modifications to which you can bolt your science instruments.

That's another great example. And ridesharing on the mission allowed them to prove it very inexpensively and with much lower risk than a dedicated mission.

I think the question of technical possibility answers differently from the question of organizational feasibility. Starlink is optimizing costs because they have a financial incentive to do so. The less each satellite costs, and costs to maintain, the more income they make. I fear incentives are not so direct in governmental orgs. Outside contractors performing most of the work have outsized influence, and incentive to inflate costs. Budgetary decision makers all want to see investment in their own districts.

I think Starlink and cubesats have definitely proven the approach can reduce costs.

The engineering does not seem as challenging to me as figuring out how to get such a policy approved and pushed through all the administrative and decision making layers without watering down and budgetary inflation.

> Senate Launch System

... checks math ... Starship should have enough cargo capacity for this. One launch. We could put the whole senate up there. The house might take a couple launches unless we really pack 'em in. /s

Not just mass optimization either. Intense effort and cost are expended through verification because a single payload simply must work. But using commodity hardware with reduced verification effort, launching many, and tolerating some amount of attrition has resulted in reduced costs for Starlink.

I'm not BoingBoomTschak who you're replying to, but he's right. My experience comes mostly from decades of reading xiph.org and ffmpeg mailing lists where such things are discussed, rather than implementing them myself. But there is constant discussion of encoder performance / quality trade-offs in software and hardware encoders. Hardware encoders, especially ones attempting to meet strict performance targets, simply cannot take advantage of some of the most complex quality improvements as they depend on information only present in past/future frames. Sometimes as many as 30 frames away.

It seems like you are interpreting this as a slight against the quality of Apple's hardware encoders, which may legitimately be very good. As are Nvidia's, Intel's and AMD's. But all of them will produce larger file sizes and lower quality than equivalently optimized non-realtime software encoders, which simply have more information and more time, memory, and flexibility to compute over it.

We're talking about fundamental properties of compression and computational time/space trade-offs. Even Apple can't design around them.

That doesn't mean Apple's hardware encoder is in any way bad or unusable. All lossy compression will be imperfect, yet much of it is useful. And most modern codecs and encoders seem to be capable of high quality results. The implications of the differences under discussion are percentages of a bitrate or tiny nearly imperceptible artifacts or breadth of available resolutions, refresh rates, and color modes or codec choice. Software encoders are always at the bleeding edge of what's possible. Hardware encoders are necessarily a snapshot frozen in silicon with limitations imposed by the implementation. The middle ground is largely already occupied by SIMD and other transform-specific ISA extensions already present in most CPUs.

> I've never enjoyed languages that plant a flag on one mechanism and force users to adapt.

Well, the hardware designers have chosen one (or at most a small number of) mechanism[s] and implemented in silicon. The farther you diverge from their implementations, in terms of abstractions, language features, and the like, the more you will pay in performance. Your choice.

Not op, but that's a very interesting proposition. While the law and legal code are technically property of the people, I'm not aware of any single point of download for it all.

Weather satellites have done more to increase crop yield than anything since the invention of artificial fertilizer and save more lives.

Well, besides the big three auto makers buying up all the public transit and decomissioning it.

> 300 billion output tokens — $22.5 million worth of compute, if charged at current Astra rates.

This makes the 100 billion tokens (total in/out) I've spent on my project on the $200/mo plan seem like a deal. Wow.

> So you dislike

You said dislike. I said suspicious. One's an opinion, the other an invitation for science.

> vinegar, salt, and any fermented foods that suppress microbial agents?

In the gut microbiota broad system sequencing experiments I've consumed reports from, even altering diet from one primary food source to another can result in complete restructuring of the gut ecosystem as quickly as within 24 hours. And switching back to the original food source didn't return to an identical gut ecosystem. Many studies show direct connections between gut microbiota and specific and broad health impacts.

So I think suspicious is right. There is much yet to be learned.

> most supermarket bread is stabilized, which you might not like aesthetically, but it isn't doing anything to your health

That's a large assertion to make without evidence. Personally, I'm suspicious of all antimicrobial agents' effects on gut microbiota and the knock-on effects on health.

I don't know about others, I can only speak for myself. But I do appreciate numbers for bare models, numbers for model + harness, numbers comparing different models in the same harness, and numbers comparing several models across several harnesses.

It's a lot of information to ingest, but it gives me some idea of which part of the system is doing which part of the work, how well different harnesses and models interoperate, and more insight into the part of the equation under my direct control as a software developer.

Harnesses can fairly easily be adapted to other models. Moving capabilities from one model to another is a more involved process requiring distillation, training, etc.

Son, I've been building and installing custom roms since the HTC Dream, was involved in OpenMoko, and have owned nearly every open or Linux-running phone of the last 30 years back to the Sharp Zaurus and iPaqs.

Your custom rom experience sits wholly within a larger category of computer systems experience about which I've been speaking.

The sort of fragmentation you describe is a symptom, not a foregone conclusion.

> Nobody is interested in reinstalling OS-es on their phones because the amount of effort to create an Android ISO that's as usable as what's preinstalled is truly gigantic.

You've restated my thesis.

> Yes, I am on the younger side

I could tell.

> It is a niche, it always was.

Again, only because the platforms are locked down and there is no single standardized target for universally bootable ROMs in the way a Linux ISO can boot on any PC.

Kinda sounds like you might be younger and didn't live through the 8bit micro -> PC transition. Standardization of the platform led to a cambrian explosion.

https://en.wikipedia.org/wiki/Influence_of_the_IBM_PC_on_the...

> 99% of people never installed an OS and never will, what's your point here?

That the 1% who do build visicalc, Linux, the internet, Google, and every application and innovation that happens outside the corporate wall. The entire ecosystem everyone else ends up using.

And that calling that niche is ridiculous, shortsighted, and shooting oneself as a platform owner in the foot.

> As much as it seems beloved here, people that flash custom Android OSs are the very definition of niche users.

Hmm... Let's try reframing this: "as much as it seems beloved here, people that install their own operating systems on PCs are the very definition of niche users"

I'm absolutely certain that's how IBM felt before the clones. But the ability to install what they wanted on a defacto standard platform is what launched the computing revolution. I think we'd still be living in a sterile monopolistic environment with $10k compilers otherwise.

Folks installing their own ROMs on phones are only niche because they've been pushed out at every opportunity using locked bootloaders, embedded security processors, factory installed secret keys, etc.

Despite all that, there's still thriving communities developing and using custom ROMs on their phones. That demonstrates more than niche demand.

4 bits per 16 bytes is ~ 1/4 the cost of ECC, which is possible to implement with just an extra cycle or two of latency in the memory controller. MTE seems similarly lightweight. Costs some transistors and a percent of a percent of power budget, but much like ECC it seems a fair bargain.

And it's not complete until it can send and receive email.

I'm using async on esp32 with embassy, for instance, where there's simply no room and no need for a runtime as complex as tokio.