Email providers have better spam filtering, some have strict rules about attaching any kind of executable code to an email (as in - you just can't).

Email clients are always getting updated, stricter about validating content before showing it, etc.

So a table is a hashtable. Just about anything can be a key to the hash - a number, a string, a boolean, another table, a userdata. I can't recall if functions and coroutines can be keys but I suspect they could. I definitely know that nil can't be an index.

In Lua - all iterators are implemented as a function + state + current key. When you write "for x in (whatever)", that (whatever) is really a function call like func(state,key). Lua calls it repeatedly to traverse the loop.

Lua will take the first returned value and use it as the new key in the next call to func(). Once the function returns nil as the first value (or just returns no values) - the loop stops.

There are two functions - pairs and ipairs - that really just return the built-in next function with a starting key. pairs returns (lua's next(), the table, nil), and ipairs returns (next(), the table, 0).

(there's a bit more to it than that and some under-the-hood changes between Lua versions but we'll just go with that explanation).

Lua repeatedly calls that next() function with the table and previous key.

Say you had an array like table like { [1] = some_value, [2] = another_value }.

When you write something like "for i,v in ipairs(a_table)" that roughly expands to:

  * pairs() returns next(), the table, 0. 
  * Lua calls next(table, 0) and next returns (1, some_value)
  * Lua calls next(table, 1) and next returns (2, another_value)
  * Lua calls next(table, 2) and next returns nil.

When you can iterate through it with sequential, integer keys.

Note - you don't necessarily need to use ipairs to iterate. Lua also has a numerical "for" loop so you could do that. Or - if you want to start your arrays at 0 instead of one you can write your own ipairs() like function in just a few lines of code. Observe:

  local zpair_it = function(table, key)
    key = key + 1
    if table[key] then
      return key, table[key]
    end
  end

  local zpairs = function(table)
    return zpair_it, table, -1
  end

  local tab = { [0] = 'yay', [1] = 'huzzah' }
  for i,v in zpairs(tab) do
    print(i,v)
  end

As far as using like objects, that's getting into metatables and stuff but - basically lua has a syntactical sugar to make object-orientation nice.

If you write "obj:func()" - that's the same as writing "obj.func(obj)" - assuming "obj" is a table, Lua will fetch the "func" key from the table, then call it as a function with "obj" as the first argument (this can be referred to as self within your function definition).

If Lua tries to fetch "func" from your table and it doesn't exist - it will check to see if your table has a metatable defined with an __index metamethod (or table) and pull func from that. So - your table could just have your object's actual state data on it, and functions are referenced in a separate metatable.

Observe:

  local dog_methods = {
    bark = function(self)
      print("bark bark I'm a",self.breed)
    end
  }

  local dog_metatable = {
    __index = dog_methods
  }

  local huskie = setmetatable({
    breed = 'huskie'
  }, dog_metatable)

  local collie = setmetatable({
    breed = 'collie'
  }, dog_metatable)

  huskie:bark()
  collie:bark()

Anyways wow that was a lot. Highly recommend going through the Lua manual. It's not a long read.

Something I would be 100% OK with is some regulation that at first boot, you have to present information about what parental controls are available on the device and ask if you'd like them enabled.

I haven't set up a phone in a hot minute, I only do it once every few years, is this something they already do?

I'd imagine there's a lot of cases where a parent buys a new phone and hands down the old one to their kid without enabling safety features. I don't know if there's a good way to help with that - maybe something like, whenever you go to set a new password, prompt "hey is this for a kid?" and go through the safety features again?

Just spitballing, that last one may not be a good idea, not really sure.

Currently, websites and apps are supposed to ensure they don't have kids under 13, or if they do - that they have the parents permission. That's federal law in the US.

These laws make the operating system or app store (depends on the particular law) responsible for being the age gate.

This doesn't stop the federal law from being enforced or anything, but the idea is apps/websites don't handle it directly, that's handled by the operating system or app store.

So now - companies like Meta can throw up their hands and say "hey, the operating system told us they were of age, not our fault." It also makes some things murkier. Now if Meta gets sued, can they bring Google/Apple/Microsoft in as some kind of co-defendent?

I think that murkiness is the point. They don't need to create the most bullet-proof set of regulations that 100% absolves them of all responsibility, they just need to create enough to save some money next time they get sued.

I can think of a ton of regulations we could create to better help protect kids. We could mandate that mobile phones, upon first setup, tell the user about parental controls that are available on the device and ask if they'd like to be enabled. Establish a baseline set of parental controls that need to be implemented and available by phone manufacturers, like an approval process that you need to go through to hit store shelves.

We could create educational programs. Remember being in school and having anti-drug shit come through the school? It could be like that but about social media (and also not like that because it wouldn't just be "social media is bad," hopefully).

Again all these laws do is take what should be Meta's burden, and make it everybody else's burden.

I feel like complying really undermines any first amendment arguments. Software is a first amendment protected form of expression, giving in before getting any actual threats from the state makes your participation seem voluntary.

Systemd's participation puts the entire world into compliance with a California law

Like - you don't make it illegal to not do age attestations, but you provide a mechanism to encourage it.

You get a certification you can slap on your website and devices stating you meet the requirements of a California Family-Friendly Operating System or whatever. Maybe that comes with some kind of tax break, maybe it provides absolution in the case of some law being broken while using your OS, maybe it just means you get listed on a website of state-recommended operating systems.

That certification wouldn't necessarily have to deal with age attestation at all. It could just mean the device/OS has features for parents - built-in website filtering, whatever restrictions they need. Parents could see the label and go "great, this label tells me I can set this up in a kid-safe way."

Hell, maybe it is all about age certification/attestation. Part of that certification could be when setting it up, you do have to tell it a birthdate and the OS auto-applies some restrictions. Tells app stores your age, whatever.

The point is an OS doesn't want to participate they don't have to. Linux distros etc would just not be California Family-Friendly Certified™.

I wouldn't have to really care if California Family-Friendly Certified™ operating systems are scanning faces, IDs, birth certificates, collecting DNA, whatever. I'd have the choice to use a different operating system that suits my needs.

I mean listen I understand - I'm not owed anything. If he wants to take posts from elsewhere and share them to his blog with all context and background removed that's his business. And he doesn't have to respond to any comments he doesn't want to.

But if he gets a question he doesn't want to answer... He could just not answer it. Just leave my comment hanging. Hell - he could delete it even. I'd be perplexed but would probably shrug it off.

The whole lying thing is what bothers me. I'd rather somebody just not respond than try to feed me bullshit.

He had a blog post that seemed just weird and out of left field. Like it was clearly a response to something but what? What was the motivation for it?

When asked he said y'know. He just thinks about stuff and writes and that's what he does.

Turns out the blog post was a post he also made on social media. And said post was a response to something. And I guess he thought it was pretty good writing and should go on his blog, too.

Nothing wrong with that on it's own but I feel like most people would preface a post like that with "I saw this thing." And when directly asked like... He just straight up lied?

That whole thing just rubbed me the wrong way.

For full context https://lemire.me/blog/2025/10/17/research-results-are-cultu...

In the comments I turned into kind of a dick. I was pretty upset about being lied to.

Anyways between that and articles like this that are honestly useless and kinda misleading - I'm not really the biggest fan.

The technique is also used in Discord RPC Bridge for Wine - allows Wine apps to communicate with Linux Discord - https://github.com/EnderIce2/rpc-bridge

If I have a passenger that can use the phone - it will be infinitely easier to have them place an order via app. They can look at the map, set up navigation, read through the menu and handle getting the order in, etc.

The driver needs to know where the restaurant is. A lot of time when I'm getting fast food - I'm on the interstate, I don't really know where I am, I just know I saw a sign saying the next exit has a Taco Bell. If anything asks me to confirm the restaurant location as 123 Main Street or in some city - I have no idea if that's right or not.

Maybe if it integrates with Android Auto and Google Maps so I can place an order and get navigated, that could work.

Another big issue is knowing the menu. I definitely wouldn't want to sit and have a robot read me the whole menu. There are some places where I could order without seeing the menu but - if you don't go very often you probably need to see the menu. And if you're not going very often you probably don't have their app on your phone anyway.

The apps don't take how busy the restaurants are into account. If I get to a place and it's slammed, I'll look around a bit for something else less busy, because I want to get back on the road. So I'm not really all that committed to a particular place anyway.

I also tend to not trust the apps. I can't tell you how many times I've placed an order only to find out they're out of something when I get there. If I order at the speaker I get that feedback immediately and can pick something else (or somewhere else).

Basically you need to have all of the following be true:

* Have nobody else in the car that could operate the phone for you * Know the restaurant location * Know the menu * Have the app * Ready to commit to any wait * Trust the app is correct

There used to be a time where the drive-through was a pretty great deal but - for all the reasons you outlined above it's losing a lot of appeal. I think you pretty much hit the nail on the head - businesses prefer drive-through because it requires less staff, less resources. You also eliminate issues with people loitering in lobbies.

There are places where drive-through/walk-up only may be the only way a restaurant will open due to perceived safety concerns. So that I kind of get but ideally, the municipality would find a way to address the actual safety of the area, or at least the perception. Sometimes areas just look dangerous but are actually fine.

But yeah I think the appeal of drive-through is dying out for a variety of reasons. We no longer see cars as convenient, we desire walkability, we value healthier food over faster food, we'd rather work less and have extra time at home to do things like cook, things like that.

I should point out I'm speaking very broadly, as an American who isn't facing poverty. My view is likely limited and skewed, there are very likely to be scenarios I'm not considering.

Like a very common issue is - if you don't have an access control allow headers header for icy-metaint - you can't pull out the embedded Shoutcast metadata client-side. You now have to pull now-playing type data via some other method, like polling the Icecast API - which may not be available. A lot of servers don't send any CORS headers, some only send the allow-origin header.

In theory stream producers can use Ogg to encapsulate the stream and use bitstream chaining to have in-band metadata. That limits the codecs to Vorbis/Opus/FLAC, which are all great codecs - bigger issue tends to be how the browser handles chained bitstreams in audio elements. My understanding is - they just don't handle it at all.

So - if the goal is to play the streams in the browser and ensure you have a consistent experience, it makes sense to proxy them all into some common format like HLS and serve it over HTTPS. You can have timed ID3 metadata, and eliminate CORS and mixed-media issues. This does mess with the stream's ability to accurately measure things like, how many people are listening.

But, I think using the term "fully-owned" to refer to pushing up to GitHub, then deploying to Cloudflare Pages is definitely not "fully-owned"

In my case - I have an internet radio station available in a few different codec/bitrate combinations. I generate a chained Ogg FLAC stream so I have in-band metadata with lossless audio.

The stream gets piped into a process that will encode the lossy versions, update metadata the correct way per-stream (like there's HLS with timed ID3, there's Icecast with chained Ogg Opus, Icecast with AAC + Shoutcast-style metadata).