Logs: liberachat/#haskell
| 2021-06-10 08:50:45 | <dminuoso> | Apparently the legal department of the customer seems to think so |
| 2021-06-10 08:50:56 | <Maxdamantus> | dminuoso: if you're not interacting with another computer, I imagine you theoretically don't need to worry about this, as long the computer you're running on isn't having its clock set backwards. |
| 2021-06-10 08:52:00 | <Maxdamantus> | If you are dealing with another computer, one proper way to guarantee that time doesn't seem to move backwards after the message is handled by the other system would be to include a timestamp in all of your messages. |
| 2021-06-10 08:52:10 | <Maxdamantus> | and the other computer should not handle the messages until that time has passed. |
| 2021-06-10 08:52:56 | → | yd502 joins (~yd502@180.168.212.6) |
| 2021-06-10 08:54:07 | × | dragestil quits (~quassel@user/dragestil) (Remote host closed the connection) |
| 2021-06-10 08:54:49 | <kritzefitz> | Maxdamantus, but then you have to trust that your clock actually isn't set back. NTP and negative leap seconds might cause unexpected behavior here. It has been mentioned that those *shouldn't* set the clock backwards, but I personally wouldn't bet on it. |
| 2021-06-10 08:55:26 | → | dragestil joins (~quassel@user/dragestil) |
| 2021-06-10 08:55:57 | <earthy> | dminuoso: 'what midnight' 'should it start or finish close to midnight' |
| 2021-06-10 08:56:40 | <Maxdamantus> | kritzefitz: then I guess you'd have to just apply my principle to within the same system. |
| 2021-06-10 08:56:45 | <dminuoso> | earthy: I was just waiting for that question. :-) |
| 2021-06-10 08:56:49 | × | spoonm quits (~spoonm@tokyo.spoonm.org) (Quit: Don't look behind you!) |
| 2021-06-10 08:57:55 | <dminuoso> | Luckily this is just a small project, and the customer wasn't being too serious about what their legal department thinks. As long as it's "roughly" around midnight, all is good. |
| 2021-06-10 08:57:55 | → | ubert joins (~Thunderbi@2a02:8109:9880:303c:ca5b:76ff:fe29:f233) |
| 2021-06-10 08:57:55 | <earthy> | but, given that you talked about account activation 'at midnight', the obvious answer is to have the account active already, but have the login system check against the timestamp of the request coming in. |
| 2021-06-10 08:58:09 | <Maxdamantus> | So if you're updating a database at midnight, include a timestamp in the database entry, and when you read database entries, wait until that time has passed. |
| 2021-06-10 08:59:02 | <earthy> | and have an account with validity time ranges. |
| 2021-06-10 08:59:04 | <dminuoso> | earthy: If only things were that simple. To activate an account, I need to register resources with an external API. |
| 2021-06-10 08:59:13 | <dminuoso> | Which itself has no validity range |
| 2021-06-10 08:59:56 | <earthy> | as long as all interaction is through your frontend... I don't particularly see the problem. |
| 2021-06-10 09:00:13 | <dminuoso> | I dont have a frontend, its behind that external thing. |
| 2021-06-10 09:00:15 | <dminuoso> | That's the problem |
| 2021-06-10 09:00:29 | <earthy> | *ah*... |
| 2021-06-10 09:00:35 | <Maxdamantus> | (and also, avoid reading the time multiple times; read it once after reading from the database, unless you have to wait due to the clock skew) |
| 2021-06-10 09:01:49 | <earthy> | that makes the 'should it definitely be active as of midnight or should it be not active at least until midnight' question that much more important. :) |
| 2021-06-10 09:02:08 | × | whiteline quits (~whiteline@c-64c6e253.54725-0-757473696b74.bbcust.telenor.se) (Ping timeout: 264 seconds) |
| 2021-06-10 09:04:01 | <dminuoso> | earthy: So the account gives access to some physical resource. If your account expires today, and someone elses starts tomorrow, and both of you are linked to the same resource, that would lead to overlapping access to that shared resource |
| 2021-06-10 09:04:03 | × | kiweun quits (~sheepduck@2607:fea8:2a61:4800::e92f) (Remote host closed the connection) |
| 2021-06-10 09:05:42 | <dminuoso> | Meaning I cant just "activate accounts 5 minutes before, and deactivate 5 minutes after midnight" |
| 2021-06-10 09:06:00 | <dminuoso> | Time is a bizarre thing |
| 2021-06-10 09:06:24 | → | whiteline joins (~whiteline@c-cda8d954.54725-0-757473696b74.bbcust.telenor.se) |
| 2021-06-10 09:06:34 | <kritzefitz> | Do the activations and deactivations actually run in different processes? If they happened in the same process, you could just always deactivate first and only activate access after you're done with that. |
| 2021-06-10 09:06:42 | <dminuoso> | Einstein knew too, the problem of time synchronization is what started a life works of a new branch of physics.. |
| 2021-06-10 09:06:57 | <dminuoso> | kritzefitz: thats precisely what I do. :) |
| 2021-06-10 09:08:14 | <kritzefitz> | Ok, I'm not sure anymore what the exact problem is. Do you “just” want to make sure that you run close to midnight or do you also need to reliably determine what the day after that midnight is? |
| 2021-06-10 09:09:40 | <dminuoso> | kritzefitz: Maybe I miscommunicated. There is no real problem, just things I wondered about when I wrote a naive solution, thinking there were subtle bugs. |
| 2021-06-10 09:09:54 | × | jneira quits (~jneira@166.red-81-39-172.dynamicip.rima-tde.net) (Ping timeout: 264 seconds) |
| 2021-06-10 09:11:21 | <earthy> | access to physical resources. that poses the obvious next question: *must* it necessarily be mutually exclusive... |
| 2021-06-10 09:11:55 | <earthy> | (e.g.: a room can hold multiple people, even if that room is an office that should be assigned to just one person at any one time) |
| 2021-06-10 09:12:44 | <earthy> | and the follow-on question is: can you actively *revoke* access at the cut-over time? (e.g. by boucing the person from the room) |
| 2021-06-10 09:13:32 | <dminuoso> | So to avoid further confusion, this is just talking out of curiosity, not out of a need of a problem, right? |
| 2021-06-10 09:14:04 | <earthy> | the thing is: you can create monotonic logical time for your system. you can anchor that logical time to some physical time, but then the *real* problems start. :) |
| 2021-06-10 09:14:36 | <earthy> | yeah, just curious. plus, many of these things we've run into (and tried to solve). :) |
| 2021-06-10 09:14:49 | <earthy> | slightly different context though. |
| 2021-06-10 09:14:50 | <dminuoso> | earthy: There's actually some subtle legal impliciations. There's no reason we couldn't give shared access, just that it would make liability problematic., |
| 2021-06-10 09:15:37 | <dminuoso> | I cant talk details about this project, but imagine the resource was a car. If the car is damaged, who is liable? |
| 2021-06-10 09:15:48 | <earthy> | the driver. |
| 2021-06-10 09:15:57 | <dminuoso> | damaged doesnt mean someone was driving it. |
| 2021-06-10 09:16:24 | <dminuoso> | could just be a paint scratch |
| 2021-06-10 09:16:26 | <earthy> | oh, wait. *drops assumption*. |
| 2021-06-10 09:16:33 | → | fizbin joins (~fizbin@c-73-33-197-160.hsd1.nj.comcast.net) |
| 2021-06-10 09:16:49 | <earthy> | who is liable is not necessarily knowable. |
| 2021-06-10 09:17:04 | <dminuoso> | (lets just pretend we know *when* the damage occured) |
| 2021-06-10 09:17:31 | × | hnOsmium0001 quits (uid453710@id-453710.stonehaven.irccloud.com) (Quit: Connection closed for inactivity) |
| 2021-06-10 09:17:32 | <earthy> | yeah, but the legal framework for the liability may change around the damage... |
| 2021-06-10 09:17:40 | <dminuoso> | highly stateful operations within strict time requirement with legal implications - fun things. |
| 2021-06-10 09:18:12 | <maerwald> | what's the correct way to install llvm on Mac? |
| 2021-06-10 09:18:27 | <dminuoso> | maerwald: angerman would know :p |
| 2021-06-10 09:18:28 | × | vgtw quits (~vgtw@c-9164205c.07-348-756d651.bbcust.telenor.se) (Quit: ZNC - https://znc.in) |
| 2021-06-10 09:18:45 | <merijn> | maerwald: homebrew and/or macports |
| 2021-06-10 09:18:50 | <xerox> | is brew correct enough? |
| 2021-06-10 09:18:59 | <maerwald> | homebrew messes up linking from my experience |
| 2021-06-10 09:19:17 | <angerman> | brew should be good enough; building llvm from source is a bit of a pain. |
| 2021-06-10 09:19:17 | <xerox> | their linking of formulas or linking as in compiler linking |
| 2021-06-10 09:19:28 | <merijn> | maerwald: I mean, my homebrew llvm works, but homebrew is really about "support only the latest bleeding edge" |
| 2021-06-10 09:19:36 | <earthy> | dminuoso: I was assuming damager and affected party are known. even then, if the damage happens at an exact change in law, the liability is complex (think starting the scratch before midnight and taking a few seconds) |
| 2021-06-10 09:19:42 | <merijn> | maerwald: macports is slightly better in that sense |
| 2021-06-10 09:20:05 | <merijn> | Building LLVM yourself is always the wrong solution >.> |
| 2021-06-10 09:20:08 | <merijn> | So damn painful... |
| 2021-06-10 09:20:11 | <dminuoso> | earthy: perhaps a fire is a better example than a scratch. |
| 2021-06-10 09:20:34 | <dminuoso> | If the car was lit on fire, and it created surrounding damage to external property before midnight and after. |
| 2021-06-10 09:21:45 | → | eggplantade joins (~Eggplanta@2600:1700:bef1:5e10:2121:a570:d35e:ba7a) |
| 2021-06-10 09:22:37 | skewerr | is now known as spoonm |
| 2021-06-10 09:23:03 | × | spoonm quits (~spoonm@inaba.spoonm.org) (Quit: ZNC - https://znc.in) |
| 2021-06-10 09:23:18 | × | tromp quits (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2021-06-10 09:23:44 | → | spoonm joins (~spoonm@inaba.spoonm.org) |
| 2021-06-10 09:24:22 | <tdammers> | when it comes to these things, it may be helpful to introduce the concept of "bureaucratic reality" |
| 2021-06-10 09:24:31 | <angerman> | merijn: if only they'd provide binary dists for llvm on both darwin platforms, but they don't. |
| 2021-06-10 09:24:55 | × | spoonm quits (~spoonm@inaba.spoonm.org) (Client Quit) |
| 2021-06-10 09:25:10 | <dminuoso> | tdammers: Guess that's why one has legal departments in the first place. Not because one can avoid bureaucratic reality, but to deal with it in these situations. :p |
| 2021-06-10 09:25:33 | → | spoonm joins (~spoonm@inaba.spoonm.org) |
| 2021-06-10 09:25:48 | <tdammers> | yes, that too |
| 2021-06-10 09:25:50 | × | eggplantade quits (~Eggplanta@2600:1700:bef1:5e10:2121:a570:d35e:ba7a) (Ping timeout: 244 seconds) |
| 2021-06-10 09:26:01 | → | bitonic joins (~bitonicma@2001:470:69fc:105::1812) |
| 2021-06-10 09:26:07 | <tdammers> | but my point is that there is a difference between "bureaucratic reality" and "actual reality" |
| 2021-06-10 09:26:17 | → | vgtw joins (~vgtw@c-9164205c.07-348-756d651.bbcust.telenor.se) |
| 2021-06-10 09:26:27 | × | spoonm quits (~spoonm@inaba.spoonm.org) (Client Quit) |
| 2021-06-10 09:26:43 | <tdammers> | if I scratched your car 5 minutes past midnight, but the police report and eyewitnesses say I did it at 23:55, and my own statement matches that too, then that becomes the bureaucratic reality |
| 2021-06-10 09:27:50 | → | spoonm joins (spoonm@inaba.spoonm.org) |
| 2021-06-10 09:28:44 | → | yd502_ joins (~yd502@180.168.212.6) |
| 2021-06-10 09:31:02 | × | yd502 quits (~yd502@180.168.212.6) (Ping timeout: 272 seconds) |
| 2021-06-10 09:32:02 | <maerwald> | I was expecting xcode --install to install llvm |
| 2021-06-10 09:32:51 | <merijn> | maerwald: That's some high level optimism :p |
| 2021-06-10 09:34:09 | × | dhil quits (~dhil@195.213.192.47) (Quit: Leaving) |
| 2021-06-10 09:34:12 | × | xkuru quits (~xkuru@user/xkuru) (Ping timeout: 272 seconds) |
| 2021-06-10 09:34:24 | <maerwald> | merijn: I spent the last days writing powershell, so I have a lot of optimism |
| 2021-06-10 09:37:23 | → | dhil joins (~dhil@195.213.192.47) |
| 2021-06-10 09:37:29 | <maerwald> | so, after installing llvm with macports, cabal still can't find it |
| 2021-06-10 09:37:48 | <merijn> | maerwald: macports doesn't install it into any of the default search paths |
| 2021-06-10 09:37:59 | <merijn> | maerwald: Because they don't wanna conflict with system tools |
All times are in UTC.