dale_glass

Things I don't like:

* It's not standard. You can't plug in some normal formatting library there and be done with it.

* You'll probably end up having to write conversions back and forth.

* It's fragile -- if anything gets misaligned it'll break

* It's tooling unfriendly. Think things like Nagios, Grafana, etc sending formatted notifications. Everything can do this or <b>this</b>, but practically nothing is set up to accommodate this format.

* It leaks into other subsystems. You can't eg, just search/replace/insert/delete words if you need to for any reason without breaking this.

Is it the worst thing ever? No, but it seems to go with the pattern that nothing in XMPP is normal or comfortable. Everything has this weird particular flavor to it and more complexity than necessary.

If it were up to me, my option would be to support 2 things: Markdown for simple cases, and embedded HTML for when you really have to get fancy. Each of those can be handed out to existing code and you don't ever have to keep adding extensions because what if people want colors or something now.

What part part, sorry?

I don't have that many problems with XML myself, but XMPP is weird even in XML land, because it tries to do XML all the way.

For instance, it works as a constant, uninterrupted stream. You never close the document until the disconnection. Which means you absolutely have to parse it with a stream parser.

It could have been something sensible, like a document per message: "Here's 300 characters of XML document: <xml>....". But nope.

And what's up with this? https://xmpp.org/extensions/xep-0394.html

Other people provided some info:

https://news.ycombinator.com/item?id=9772968

https://news.ycombinator.com/item?id=31133082 (article and discussion)

But TL;DR:

* It's hard to even parse, XMPP uses an uninterrupted XML stream. * The contents are often baroque and complex * Standards are a mess, and stuff that should be in core isn't * Data loss is possible * Protocol wasn't made for mobile devices * Multiple devices are terribly supported * Data loss is possible

From my attempts long ago, and other testimonials, writing an XMPP client is a full time job of solving weird problems that shouldn't exist in something better designed.

Unfortunately XMPP is an absolutely terrible protocol. IRC's not much good either, but at least it has the excuse of being ancient and limited in what it wanted to achieve.

I don't know how it just happens that sending text messages to people can manage to result in specs that are painful to implement.

> A model is not derived work of its training data. This seems to me insane, but a lot of the world seems to hold this view

Why insane? Models don't take the content as-is, they take measurements. I don't owe you royalties just because I used your photo to get the proportions and coloring of a duck right. Go watch artist streams, you'll often see people to go Google Images for references. I've never seen that result in credit or payments.

The alternative is that we hand out lots of money to a few large companies specializing in content archives, and there's really no benefit to anyone else anyway. On the long term I would expect a few fat cats to get fatter, the small guy to get nothing, and AI still work but get there slowly. I don't see the point or the benefit.

How about bmaptool? It can work on sparse images.

In general, I don't see the point in manually specifying block sizes most of the time. What I want nearly always the maximum performance, and that should be possible to derive from the hardware, and/or benchmarking.

What about uses like say, skipping data? seek= and skip= are in block sizes, that may not be ideal for performance.

A smart tool should be able to write in 1 MB blocks and yet still skip 512 bytes.

Why are we still using dd?

Seriously, it's a weird obtuse command. Weird syntax that doesn't match anything else, and the block size shouldn't be needed 99% of the time. A modern tool should figure out a good value on its own, either by interrogating the devices at both ends, or by benchmarking, or both.

Eventually data centers will get sated for one reason or another, or production capacity will increase, or manufacturing will shift toward higher capacities. Or some combination of those.

The my_random_bytes implementation doesn't look good at all at first glance. Let's see:

1. I believe it errors out if the HWRNG returns the same value twice. That's actually a thing that can legitimately happen. "0" is also a legitimate output.

2. "here" is a terrible name for a length

3. It does a memcpy of a minimum of 4 bytes to the destination, even if count is lower. It'll also overflow longer buffers with a length not divisible by 4.

It appears to be real: https://www.blockchain.com/explorer/addresses/btc/bc1pvqd6c5...

Zero transactions so far.

In some ways, sure.

The LACK (https://www.ikea.com/us/en/p/lack-side-table-white-30449908/) is probably one of the most optimized pieces of furniture you can buy. There's no hand crafted desk that can be this cheap. A wood worker won't even get out of bed for $17.

Now is it an amazingly beautiful, rock solid, heirloom quality piece of furniture? No, but it's not trying to be that.

I meant CD quality audio, as in 44.1 KHz/16 bit digital files, not specifically the CD physical medium. It's an old invention and still fulfills every playback need possible, let alone for old audiophiles who long stopped being able to hear the highest frequencies anyway.

It is bad by modern standards. Low capacity, high noise, imperfect stereo separation, pretty bad frequency response. CD quality audio solves every problem perfectly and it's old and dirt cheap at this point. To even approach that with vinyl you have to fuss over needles, weight, turntable mechanics and so on and and spend a lot of money and still won't get there.

Personally I see far more magic in digital electronics. Storing vibrations physically is neat and clever, but none of that looks particularly magic to me. Just a straightforward, logical solution to a problem. More elegant simplicity than magic really.

You need to carve the master to have something to press from.

How does it buffer audio?

One thing I didn't realize for a long time is that it turns out that a lot of these machines have a digital stage. To cut a disk you need to pack the grooves as close as possible. But the spiral isn't fixed, it's adjusted dynamically. Quiet sections can be packed close together. That means that before cutting, the machine needs to know how much physical space it needs for the audio it's about to put on the disk. And that requires a buffer, and that's very often digital. So it turns out there's precious little vinyl out there without a digital step being involved out there.

Not that it matters anyway, since vinyl is a pretty terrible technology, but still, it's kind of funny.

Apparently it's sort of sensible, but weird.

msoTriStateMixed applies to aggregates. Eg, text.isBold() can be true, false, or a mix. Partly bold, partly not bold.

msoTriStateToggle isn't a real value but only used as a sort of flag. So eg, text.setBold(tristate), where "Mixed" would be invalid, and "Toggle" would flip the bold-ness of the text.

The msoCTrue one is where it gets really weird, no clue what's that for. I suppose an ill-conceived attempt to support the other way to express True.

True being -1 was a thing in Visual Basic and I suppose by some other Windows stuff. Logic being all the bits are 1.

I'm generally friends with good, sane, smart people. If they're all jumping from the bridge, there's almost certainly something to jump from, so yes I would.

https://xkcd.com/1170/

I'm referring to actual people I argued with in the past. People convinced that AI in a self-driving car would involve the car calculating whether to kill a pedestrian or the driver, rather than trying to figure out whether this thing half obscured by foliage is a speed limit sign or not.

Obviously that's not what everyone argues, my point is that there's a lot of chaff in such arguments and not much wheat. People make a lot of noise about dramatic but completely unrealistic scenarios, while ignoring the far more boring reality.

The PauseAI people are for instance talking about human extinction, somehow. And not crappy GitHub PRs.

The critics didn't do themselves any favors. Part think the Terminator has something useful to say on the subject, part invent contrived scenarios like self-driving cars having to resolve trolley problems. Reality turned out to be much more boring.

But yes, what you said but unironically. Like it or not it's here, it's not going away, so all the remaining options have to assume that.

That's not shutting anything down, that's just being selective with what you accept, and everyone did that already to some extent.

Even pre-AI it was obvious that contributions have to be vetted for a bunch of reasons.

> The solution is exactly what the linked article says: shut it down.

At this point it's impossible, so I concur with the parent: forget about the shutting it down and think of something actually realistic.

My most blood boiling error message (long time ago, maybe they fixed it):

"No headset audio" -- displayed by the Oculus desktop app, in regards to not having audio on the headset. There's a "learn more" link, which would send you to the general troubleshooting FAQ.

So, the program knows something is wrong with the audio, but completely refuses to say what. Is it a headset problem, a driver problem, a restart needed!?

Then to make it more fun, when I complained about this stuff originally I got the advice to upload a debug log. Ok, good. That failed every time with "The upload took too long, connection was lost". I pulled out the dev tools and then I saw that what the API actually returns is:

    [{"error":"Attachment is too large. Limit 20 megabytes."}]

Bloody infuriating. They built a system that translates sensible errors into completely useless ones.

I'd fall somewhere in the middle.

I like coding, I just don't particularly enjoy figuring out the framework du jour. The task at hand is interesting, but the part where I need to figure out what are the incantations to have a Qt list with images in it is not. I need a working UI to get the thing done, but the framework stands in my way, requiring me to step away from my task intended task and spend a few hours on understanding QTreeView.

That's where I really enjoy AI currently, because I can get the GUI stuff out of the way much faster and get back to the thing the GUI is for.

Now within the specific problem I'm trying to solve, sure, I enjoy thinking about the abstractions, maintainability and extensibility. That's the part that actually matters. But the Qt UI on top, that's just a visual layer with a structure that was already set in stone, there's no big decisions of interest to make there. Just to figure out how to make it do the thing.

So get yourself a solder fume extractor? There's plenty cheap ones to pick from.

Buy a Framework Desktop with 128 GB instead. It's half the price, and though I bought it for even less before RAM prices went crazy.

I wonder why this is not more common. LVM is easy to set up, and it's already common to allocate volumes for things like disk images for VMs, so why not databases?

> This take is always bizarre to me. You're not talking about the internet, you're talking about the websites you choose to use. There are alternatives for every single website/service that you don't like.

Yeah, the problem is that a lot of those are effectively dead, subsumed by Reddit and Facebook.

I've sometimes dug up still existing sites from the 2000s I used to visit, and the results are typically depressing. Such as:

* Site still exists, but is terribly broken. Doesn't render, uses now incompatible SSL, or something. It's a forgotten server in somebody's closet, still chugging, but not being maintained, so whatever remains will probably vanish whenever the disk/PSU/etc fails.

* Last posts from 2015, mostly with "gee, it's kind of dead in here, anyone still around?" comments at the end of threads.

* Discussion is down to 5 people that post once a month, and there's also a thread with obituaries for past well known members.

I believe transactions are quite optional though? A miner could choose to mine empty blocks if they truly wanted, which transactions to include if any is up to them.

A transaction fee of what? To take a fee from a transaction there has to be a transaction to take a fee from, which needs some sort of "coin" that came from somewhere. Somebody has to create a money supply and distribute it somehow. When the network first comes into existence, nobody has any money, so where does it come into being from?

Mining is what generates the coins. And you need mining because otherwise you need some other issuing organism. Without decentralized mining you get a central issuer, and that's untrustworthy and possible to shut down.