stanmancan

Sure, but vibe coding a whole telecom platform that’s considered flawless by experts in the language is a pretty mythical feat if you ask me.

Possibly, but I’m a senior software engineer that’s been writing Elixir for the last 5 years and has been experimenting with and using AI for the last 12-18 months.

Congrats on being one of the mythical developers that manages to get AI to write perfect code consistently!

If you vibe coded an entire telecom infrastructure and an external audit found no issues then it sounds like you might need to find better auditors.

Such as?

Yes exactly! Good for you for keeping at it.

If you haven’t ran before and are carrying some extra weight then yeah it’s probably a good place to start for your first couple of short runs. Even running slowly puts additional stress on your achilles so it’s a bit of a wake up call to your body. Running slowly for 10 minutes a few times when you’re just getting started isn’t going to hurt anyone and if everything checks out then you can start to up the pace.

10km/h is very fast for a beginner and likely unsustainable for more than a couple of minutes, I would expect most people to be starting around 5-6km/h if they’re a healthy weight.

I think the best piece of advice is START SLOW. way slower than you think. And run for way shorter than you think. Even if your lungs and muscles are fine, if you haven’t ran for a while then your tendons certainly aren’t. You won’t know until it’s too late and then you’ll be out of the game for weeks or months. If you can run on grass or a softer surface your body will thank you, running on concrete is brutal until you’re used to it.

There’s probably programs than you can follow that introduce you to running, I’d follow one of those.

The issue with not having a single source of truth is not the fact that you have to update code in 2-3 places, it’s that you have to know to update code in 2-3 places.

Accidental divergence is the problem, not intentional.

The ones most likely to be “exposed to market forces” right now are the junior developers who never got to “have it good for so long”.

It's likely nearly impossible to evaluate that in the short term; I think we're looking at generational damage, much of which won't be apparent for years to come.

Yes the same applies to junior and inexperienced developers.

You can scaffold out a simple app pretty easily. Anything large or complex things break down. If you don’t know what you’re doing you end up leaking secrets like the dozens of examples we’ve seen so far.

A large portion of the content on the internet is now generated by AI.

You can and do have full conversations with bots and not know. I want to interact with humans not LLMs.

There’s no way to combat it. An army of bots can post a specific rhetoric and it can and does sway people’s opinions.

The new version of Digg was shut down because they couldn’t find a way to combat AI. They were at least trying to, other platforms are just eating it up because “user activity” is a win for them.

I’m pretty sure they’re smart enough to remember to put “make no mistakes” in their prompt.

This lands for me. I’m pushing 40 and over the last few years I’ve definitely been eliminating distractions. Anything with scrolling or algorithms meant to suck you in is gone. Deleting apps and blocking websites on my phone to prevent distractions. Phones getting much less use. Just yesterday replaced my Apple Watch with a regular watch.

Sorry if I worded poorly but you’re definitely less likely to run into a collision with v7, but it’s not impossible, which is what I was trying to point out.

Thanks for a more articulate answer!

Plenty of systems end up generating multiple UUID's in a single millisecond.

The issue with UUIDv7 is that you also have significantly less entropy since you only have a 62 bits (sometimes less, depending on implementation) of "random" data. So while the time aspect of format lowers the chances of collisions, generating two UUIDv7's in the same millisecond (depending on implementation) have a significantly higher chance of collision than two UUIDv4's.

It's still incredibly unlikely, but it's also incredibly unlikely you generate two matching UUIDv4's, but it does happen.

TLDR; It's possible to generate matching UUIDv7's, don't assume otherwise.

The scenario being the collision itself, the time period isn’t particularly relevant aside from it occurring much quicker than expected.

I left a more detailed comment on the parent, but it's definitely not impossible!

It's still possible in most implementations of UUIDv7.

UUIDv7 assigns the first 48 bits for the timestamp in milliseconds. You can generate a lot of UUID's in a millisecond though!

Then you have another 12 bits that you can use as you wish; "rand_a". The spec has a few methods they suggest on how to use these bits including 12 bits of random data, using it for sub-millisecond timestamps, or creating a monotonic counter, but each have their downsides:

- Purely random data means you can still run into collisions and anything within the same millisecond is unordered

- Sub millisecond you can run into collisions; there's nothing stopping you from generating two UUID's with the same 62 bits of rand_b data in the same sub-millisecond timestamp.

- Monotonic counters can overflow before the next tick, then what? Rollover? Once you roll over it's no longer monotonic and you can generate the same random data within the same monotonic cycle. Also; it's only monotonic to the system that's generating the UUID. If you have a distributed system and they each have their own monotonic cycles then you'll be generating UUID's with the same timestamp + monotonic counter, and again, are relying on not generating the same random data.

You can steal some of the 62 bits in rand_b if you want as well; you can use rand_a for sub-millisecond accuracy, and then use a few bits of rand_b for a monotonic counter. There's still a chance of collision here, but it's exceedingly low at the expense of less truly random data at the end.

If you want truly collision free, you'd also need to assign a couple of bits to identify the subsystem generating the UUID so that the monotonic counter is unique to that subsystem. You lose the ordering part of the monotonic counter this way though, but I guess you could argue that in nearly 100% of cases the accuracy of sub-millisecond order in a distributed system is a lie anyways.

Unfortunately people are inherently lazy. Curious and driven indivdiuals will excel with the availability of LLM's, but the majority will atrophy.

Obligatory https://xkcd.com/221/

I'm going to give Apple the benefit of the doubt here until proven otherwise. I can't see them releasing something with a terrible user experience as it would cause a lot of reputational harm.

It's cheap for what you get.

If you just need "a small box to make API calls and do minimal local processing" you an also just buy a RPI for a fraction of the price of the GMKtec G10.

All 3 serve a different purpose; just because you can buy a slower machine for less doesn't mean the price:performance of the M1 Mac Mini changes.

Because the taxpayers bail them out. I could define anything as not being risky if I knew taxpayers would bail it out.

I feel like I must be misunderstanding something here because it sounds like you're saying depositing funds in a bank is considered risky behaviour?

The vast majority of products with paying customers need better availability than “database went down on Friday and I was AFK until Monday, sorry for the 3 day downtime everyone”

To be honest I thought OP said they lived in an apartment; a house is a different story.

Occams razor

Did the sisters know where you lived? Curious if the police provided them with an area and the sisters were able to give a proper address?

Yes that’s how jobs work; you go to work, do your job, try not to get fired, and get paid for the work you do.

Is that supposed to be a bad thing?