Hacker News Reader

Comment by bravetraveler | Hacker News Reader

Where can I drop a file to always return 1969

I was thinking 1984, or if I can return a float, NaN.

Sure, not picky. A symlink to /dev/null for "I'm a grown-up/own this device" would be acceptable. Assumed one would put whatever value they wanted in the INI file :)

It’s admin settable. So just sudo homectl it. You are presumably admin.

That's beside my 'point', but fine. I'm deliberately conflating things for humor, sorry it missed. I'll get serious/stop joking around. I have no interest in administrating this. Especially on a per-user basis (despite that being the only way this 'works', I'm generally opposed). I'd prefer a file to drop in /etc... like one would express preferences over, say, /usr.

It's entirely optional, I get that. I could 'just' not set anything. Spare your fingers. I want to poison it [or loudly opt out] without a lot of effort. This includes running N commands when a file to could effectively disable the signal.

Said differently: I don't want to configure the portal, I want to ~~break~~ mask it.

> Said differently: I don't want to configure the portal, I want to ~~break~~ mask it.

Since this is sd-userdbd we are talking about unless the used backend provides the value it is unset by default. And if you manage your home directory using sd-homed unless you explicitly set it it is also unset by default.

I am aware, I kind of want a louder signal than doing nothing [which is a great option, I admit]. I quote myself:

> It's entirely optional, I get that. I could 'just' not set anything.

Why? Telemetry, mainly. I'd rather attestation [or whatever intends to use this] fail and make it apparently deliberate.

Well, to get something to fail you need an implementation that can fail. And since nothing is using this so far there is nothing you can get to fail. In the end something that implements the actual communication would end up probably defaulting to "under 13" or whatever if it somehow fails to retrieve any value (or maybe not, who knows), so I wouldn't realistically see even without this, getting the attestation to "break" would end up unlikely.

Hypotheticals are truly exhausting! I had a wall of text and chopped most of it off. This started out as a joke and now it's dead, thanks.

The failure/assumption of under-13 or whatever, as a result of manipulation, is fine. I'm not actually trying to solution something though, jeez.

I find it more compelling to say, for instance, "x% of our users have chosen not to share their information"... rather than "y% have not set it". This category would almost surely be about as 'useful' (useless) as the 'do not track' header... and a concern for something other than systemd or even the portal (to a degree).

I think the loudest way you can protest is to use and support distros that do not have systemd. There are lots to choose from in 2026.

Stick a service unit in `/etc/systemd/system/` that is a oneshot type with `WantedBy=multi-user.target`, and which runs the appropriate homectl command for each user listed in /etc/passwd (likely just in a shell script).

Today it is.

A few years down the road it might not be.

In late 90s we would have laughed if somebody proposed this was going to be a thing, let alone that linux community will just go with it. Heck, I would not have believed systemd was going to happen.

And yet, here we are.

It’s open source. You can always just keep the field.

> Where can I drop a file to always return 1969

I am out of the loop: what is so special about 1969 concerning age verification?

I doubt I can do the observation justice, my mind went there thinking 'a moment before the Unix Epoch' and the more... well-traveled meme: 'haha funny number [dropping the leading 19]'. Any number would've worked just as well, it's not significant. I really just wanted to express my participation in this, if at all, likely won't be in good faith.

That said... an option for 'I could have declared an age/birth date but chose not to' seems preferable. I was talking about poisoning but this could be more productive. Any attestation would reasonably fail, sure, but it sends a potentially-meaningful signal [to someone].

> 'a moment before the Unix Epoch'

OK, "I am so old that already lived before the UNIX epoch even started" (or a year which breaks systems that cannot handle times before the UNIX epoch) sounds plausible. :-)

Fairly context dependent, however :) This attestation/verification topic (and 1969, presumably) keeps appearing in places where I doubt The Epoch is relevant!

hello,

i'm always a fan of 1-JAN-1970

[eg. the "birth" of UNIX-like OSes unix-timestamp eg. "0" ;]

date -d @0

cheers a..z

Reply on news.ycombinator.com