ezst

Almost like, mercurial had it figured out and got completely ignored because of the dominance of git's monoculture... The unit of work to be captured is the series (of commits), there's no issue having a linear history as long as series' boundaries can be identified. Merges can fit that bill, but doing it right and consistently with git is real work and consequently nobody does it.

Out of curiosity, have you looked into capture checking from Scala? It's proposed as a generalization of the rust borrow checker, to handle capabilities and other side-effectful computations (error handling, asynchrony, ...) in an ergonomic manner. Not sure if/how much cross-pollination there might be :-)

https://docs.scala-lang.org/scala3/reference/experimental/ca...

Strikingly similar story here. Ontologies and knowledge graphs seemingly make a comeback because it is argued (with little evidence, from what I can tell) that it helps LLMs make sense of the dataset. I see no practical difference or benefit vs. providing the date model as DDL or via other means to represent the ER graph. I'd like very much to be convinced otherwise or at least read a rationale about the alleged differences.

you and me are enthusiasts, we love to know about codecs, formats, and we spontaneously seek novelty in this field and engage with it (I have similar stories of amazement about opus, I even went quite deep the rabbit hole of writing a java decoder implementation for it just to study it). But most people won't get nearly that excited, unless a new format magically enables something like twice the compression performance (so people start spreading the word that they can e.g. buy their next smartphone with 128GB storage and not the 256GB version and enjoy the same capabilities). Anything less than that will be a rounding error and barely perceptible, not worthy of the attention, and definitely not of the time to re-process and massively convert prior content.

Only if you believe this to be representative of a road legal car. I find it easier to believe that it's a purpose-built stunt prototype, otherwise they couldn't stop talking about how clever they were solving the seemingly infinite list of engineering challenges and contradictions that make it an actual car that actual people can drive on an actual road.

Having lived through the MP3 era and experienced the many years/decades? that it took for experts across fields to come together and figure out LAME and the bag of parameters that ultimately made it better than most audio formats around it, I would lean towards waiting this one out, and not take any announcement of a "winner" as gospel. We've yet to see the codecs mature and refine for some time.

I also remember the big claims about WebP's superiority, which ended-up in practice, at equivalent file-size, mostly trading away some of the JPEG artifacts that we all know for some unusual new ones.

I don't think there's a large-enough margin in this space that a new format could chew into to make the general public care: image compression seems like a solved problem overall. The second best thing is to come-up with a format that can make the content producers not have to care either, i.e. be the best in class or close-enough in a variety of use-cases (lossy, lossless, fast, animated, hdr, progressive, …). My naive impression was that jxl is mostly interesting in that regard.

Why not both? What makes EVs meaningful is when you get to the point of pushing green electricity to the grid and have the bulk of the utilitarian traffic consume it. Electrifying supercars for the sake of it has no measurable impact in the grand scheme of things.

> My impression also is that the Matrix community really loves their DAGs and the group state management that they built

I mean, if you take that out, what's left of Matrix and its differentiating proposition?

Not OP and loving that the upper part of that linked page comes with a warning message:

> Your account, @gmail.com, doesn’t have a recovery phone number. If you’re locked out of your account, a recovery phone number helps you get back in. [Add recovery phone]

I want to believe this, but I know Google's incompetence too well to doubt something like this is intentional :-)

As someone who came to terms with dying on the mercurial hill, someone who forgot more gitisms than there are to learn in the first place because git cli's inconsistencies and poor taste hurts and neuters my memory, yeah, I relate.

Most people aren't VCS nerds, most are of a generation that only ever knew git. Learning git was a prerequisite they engaged with out of necessity, not by choice, not after exploring the problem space and pondering about different approaches. Learning git was difficult, and the more they learned the more they discovered they had more to learn, including the little things, obscure details and a plethora of paper-cuts. For them (again, I suspect they are a majority), the perspective of learning something else comes with the expectation of a similar daunting effort and steep cognitive reluctance.

That's the paradox of git as I see it: had it been a simple and easy system to pick-up, it would probably have been replaced, and/or the VCS space would be much more competitive.

So it's mercurial all the way down, then?

Isn't that in parts why alcohol and tobacco are taxed at higher rates? That's a thing in many countries at least

What happened there, ... After official support by Google for the 4a stopped, I remember checking LOS out, and found that it wasn't supported there either. Did I hallucinate that, or did LOS resume support afterwards? Or maybe I'm mixing up LOS and graphene

And neither shows the outcome as to illustrate/support their point, which is phenomenally ironic considering the context..

> but there are holdouts still on Pandas because it was so complicated to learn with so many little extra rules to learn to avoid paper cuts that they feel like learning another data manipulation tool would be really hard.

Totally unrelated but I love and dread how that describes almost to the perfection the sad state of affairs we're at with git.

I see several problems with this,

- by definition, the AI isn't human, irrespective of its computational abilities, it needs a human to tell it what being human is, and the ways "humanity can be advanced" need to be validated on this basis

- "advancing humanity" isn't a one dimensional problem/single-KPI optimization game, you might optimize certain things (e.g. expected life expectancy) at the detriment of others (e.g. freedom of movement). If you are not understanding the proposition, you are not understanding the target outcome.

- even if the target outcome is perfectly formally specified and commonly understood (which it can't), you want your AI to rationalize that the journey to get there is the most direct and efficient.

- especially so since subsequent runs of the same prompt will provide different plans

- anything less than that is begging to be conned: as a sensible person, you wouldn't give unlimited power and all your faith to a single individual trusted to "advance humanity" if they cannot be understood. On what ground would you give the machine a pass?

In all, such comments really worry me. It's like AI is triggering for some people the kinds of oppressive religious feelings whereby the individual should submit itself to the will and desires of a pretended all-powerful being. Do you really think our ancestors chose to cut off their legs in abandonment when they figured that some animals could outpace them? No, they built traps and throwing weapons to catch them and see how they taste.

Not sure I get that. If AI is not working for humans' benefits (i.e. it is not working towards an optimization problem set-up by humans), whom is it supposed to benefit, then? (i.e. how is that better than an entropy-producing machine)?

Same for 2, there are so many infinite ways to boil the oceans, but so few oceans to boil to begin with. Better make sure that this insane energy (both in the physical, due to natural resources scarcity, as well as intellectual) is spent towards meaningful and useful ends. We can no longer be the judges of that if we can't comprehend what we got in return.

> those changes have flowed through to your distro so you aren’t waiting on kernel updates

Unless you insist on running a server distro that's consistently obsolete by design (and if the notion of GPU comes into picture, that definitely shouldn't be the case), it shouldn't matter in practice. Every reputable desktop distro has a kernel/mesa stack that's up to date.

Why not pick Scala (-native), or OCaml, or…

Thinking of it abstractly, Effects is a more generic version of the "what color is your function"¹ dilemma, and the way to make this kind of abstraction not "color too much" (i.e. not pollute the core language by wrapping everything in a monad that implements its own parallel runtime with exceptions, asynchrony, …) is an active research topic². Scala is advancing in this area by scoping effects in a manner that's not too dissimilar to a generalized version of rust's borrow-checker, and I'm very curious to see how that spans out.

¹: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

²: https://www.scala-lang.org/api/3.5.0/docs/docs/reference/exp...

Not playing devil's advocate or anything, but effect systems go beyond DI: it's not just about passing around a capability, but managing its lifecycle in a referentially transparent manner, i.e. monads all the way down. It's a real pain, but they set themselves up to bear the burden, so, good for the rest of us I guess?

Congrats, you just described XMPP

Yeah, because the obvious solution to the problem of having too much bots is… more bots.

Conversations is a XMPP client, it's essentially the same protocol that delivers reliable notifications to every Android, Nintendo switch, etc. Unless you have an Android distro that kills every background app indiscriminately, you will be fine with Conversations delivering messages and notifications to you.

Interestingly, the link you posted relates to Unified Push, which is a protocol that relies on a "distributor" app which acts as a proxy, receiving reliable notifications on behalf of other applications. And it happens that Conversations can be configured as a UP distributor, because of how good it is at that/how well the XMPP protocol lends itself to it.

Long way to say you should give XMPP a shot, it really works well!

Notebookcheck¹ measured 17.5h of wifi+websurfing battery life and 12.5h at 500+ nits, how long are the days on your planet effectively?

Also, that's on Ryzen AI 7 PRO 450, you might be getting even more out of the Panther Lake alternative.

¹ https://www.notebookcheck.net/Excellent-business-laptop-with...

I feel we've been there before, I clearly remember the compiz/beryl years: they were not just about bling being added to traditional window manager and desktop environments, new window management paradigms were being experimented with (using 3d walls to stick windows and icons on, circular action menus, etc). Whatever stands to supersede the ubiquitous WIMP paradigm has to come up with substantial gains.

But that's not answering my question? What do you expect to get from today's ARM chips that's fundamentally impossible otherwise? And how is that a step forward?

T14 gen7?

And how exactly does that matter? How close do you have your head to x86 assembly for the instructions set to matter?