JSON: No comments, no datatypes, no good system for validation.

YAML: Arcane nonsense like sexagesimal number literals, footguns with anchors, Norway problem, non-string keys, accidental conversion to a number, CODE INJECTION!

I don't know why, but XML's verbosity seems to cause such a visceral aversion in a lot of people that they'd rather write a bunch of boring code to make sure a JSON parses to something sensible, or spend a day scratching their head about why a minor change in YAML caused everything to explode.

Actually my own problem with XML was annoyance that back when I had the thought of doing a complex config format in XML, the idea of modifying it programmatically while retaining comments turned out to be absolutely non-trivial. In comparison with the mess one can make with YAML that's just a trivial thing.

As an old school Perl coder, not true. Lots of people had a taste for Perl. TIMTOWTDI was sold as an actual advantage.

Perl caters to things almost nobody else does, like the way you have a negative "if" in "unless" and placing conditions after the code. So you can do things like:

    frobnicate() unless ($skip_frobnicating);

     if (!$skip_frobnicating) frobnicate();

The bigger problem with Perl IMO is that it started as a great idea and didn't evolve far enough -- a bunch of things had to be tacked on, and everyone tacked on them slightly differently for no real benefit, resulting in codebases that can be terribly fragile for no good reason and no benefit.

And I believe made by some of the people that formerly worked on Descent.

Think for instance the Debian package configuration dialogs -- they're far more comfortable than the same questions without a TUI, and still work over a serial console if you have to use one.

For tools like various kinds of "top", there's many potential tools you can use to the same end and intentionally using one that draws CPU graphs over one that just displays a number. Graphs are much easier to interpret than a column of numbers.

In many cases they're the optimal choice given some constraint -- like the desire to have minimal dependencies, working over SSH, and being usable without breaking the flow. Yeah, you could make a tunnel to a tool that runs a local webserver and delivers graphs by HTTP, but the ergonomics of that are terrible.

So we've applied to run a Gaming and VR track this year and it actually happened! I think we got some amazing talks and excellent attendance.

The videos were just all released on the FOSDEM site.

I think for a first time everything went great, and we hope that we can do this again. Please use the Submit Feedback link at the bottom of the talk pages to make the next time even better.

Comments URL: https://news.ycombinator.com/item?id=46883568

Points: 1

# Comments: 1

Like what if I want to graft on TTS to an existing text chat system and give each person an unique, randomly generated voice? Or want to try to get something that's not quite human, like some sort of alien or monster?

Whatever's possible, local on Linux. If it's not, one of my servers has a GPU that I pass through to a Windows VM, and run the games there and displayed by streaming. Also works for VR.

Not a setup for everyone and a tad technically complex to set up, but it works well enough for my needs.

It does run into some trouble with games that don't like virtual machines, but since I'm a very casual gamer I just play things that don't complain about that.

> Can someone be the Steam for Excel, please? :)

You can actually add anything you want to Steam, so you can use Steam Link to run Excel remotely.

I believe the reasoning was partly that suspend to RAM had serious reliability issues due to the complexity of saving the state, partly that people starting expecting cell phone-like performance where eg, mail is always received.

Compare a physical shop with Spotify. A physical shop has limited space, so old stuff has to be pruned out to leave room for the new releases. So sales for old stuff gradually stop, and there's a small selection of current releases you can buy.

Spotify and the like aren't like that. It's an infinitely growing amount of music you can play. New releases may be completely unnoticed by users who follow recommendation algorithms. You can trivially follow impulses like "So what else did the the band that made Video Killed the Radio Star make?".

Since digital is infinitely reproducible and not perishable this will keep getting worse and worse. Any new artist competes against all of the music that was released before them.

> Also, why are people moving mountains to make huge, power obliterating datacenters if actually "its fine, its not that much"?

I presume that's mostly training, not inference. But in general anything that serves millions of requests in a small footprint is going to look pretty big.

I can generate images or get LLM answers in below 15 seconds on mundane hardware. The image generator draws many times faster than any normal person, and the LLM even on my consumer hardware still produces output faster than I can type (and I'm quite good at that), let alone think what to type.

The EU makes travel between EU countries as easy as travel between US states. You can just get on a train from Germany to Spain without any prior planning.

For my uses, my rule is "long to research, but easy to verify". I only ask for things I can quickly determine if they're right or not, I just don't want to spend half an hour googling and sorting though the data.

For most of my queries there's an acceptable margin of error, which is generally unavoidable AI or not. Google isn't guaranteed to return everything you might want either.

The way I see it, when LLMs work, they're almost magical. When they don't, oh well, it didn't take that long anyway, and I didn't have them until recently, so I can just do things the old boring way if the magic fails.

I vaguely recall the PGP manuals talking about scenarios like a woman secretly communicating with her lover, or Bob introducing Carol to Alice, and people reading fingerprints over the phone. I don't think long trust chains and the use case of finding a trust path to some random software maintainer on the other side of the planet were part of the intended design.

I think to the extent the Web of Trust was supposed to work, it was assumed you'd have some familiarity with everyone along the chain, and work through it step by step. Alice would known Bob, who'd introduce his friend Carol, who'd introduce her friend Dave.