Logs: freenode/#haskell
| 2020-09-17 19:54:28 | <monochrom> | I think it's easiest if the OS used for compiling is the same OS used for running. |
| 2020-09-17 19:54:31 | → | gestone joins (~gestone@c-73-97-137-216.hsd1.wa.comcast.net) |
| 2020-09-17 19:54:59 | <monochrom> | For example totally don't go "I dev on Windows, deploy on MacOS", that's insanity. |
| 2020-09-17 19:55:51 | <monochrom> | You really don't need one more gratuitous variable in your journey. |
| 2020-09-17 19:56:17 | × | geekosaur quits (42d52102@66.213.33.2) (Remote host closed the connection) |
| 2020-09-17 19:56:33 | → | notzmv`` joins (~user@177.103.86.92) |
| 2020-09-17 19:57:09 | <sm[m]> | frdg has an old working macbook and is a bit over their head already, personally for me installing linux on a mac would be a nightmare |
| 2020-09-17 19:57:46 | <koz_> | monochrom: Yeah, you're right. I'm merely speaking from my own experience here, and I'm Linux through-and-through. |
| 2020-09-17 19:57:52 | <koz_> | (both personally and for work) |
| 2020-09-17 19:58:14 | <sm[m]> | getting offtopic here, but I think the real challenge here will be the connectivity (getting through firewalls, setting up dns or static ip) |
| 2020-09-17 19:58:26 | <nineonine> | so any idea how can I ensure the process is being killed? |
| 2020-09-17 19:58:32 | <davean> | koz_: well its a permissions issue on some OSs (suposibly windows), and others lack the IO hole POSIX systems tend to have (embeded OSs) |
| 2020-09-17 19:58:43 | <nineonine> | can I do something nasty like grep by process name and kill it? |
| 2020-09-17 19:58:48 | <nineonine> | using shell |
| 2020-09-17 19:58:56 | <koz_> | nineonine: That might not necessarily work either. |
| 2020-09-17 19:58:56 | <nineonine> | (just in case) |
| 2020-09-17 19:59:00 | <nineonine> | doh! |
| 2020-09-17 19:59:02 | <frdg> | in the end Ill figure something out. All I want is to avoid pain. |
| 2020-09-17 19:59:08 | <koz_> | As I said - I've managed to get an unkillable process even at the OS level. |
| 2020-09-17 19:59:14 | <koz_> | (due to bad driver) |
| 2020-09-17 19:59:15 | <nineonine> | this is horrible |
| 2020-09-17 19:59:16 | <monochrom> | I think it's useful to first find out why the process is not terminating. |
| 2020-09-17 19:59:22 | × | Jesin quits (~Jesin@pool-72-66-101-18.washdc.fios.verizon.net) (Quit: Leaving) |
| 2020-09-17 19:59:24 | <sm[m]> | nineonine: pgrep & pkill are your friends! |
| 2020-09-17 19:59:30 | <davean> | nineonine: is that the *kernel* can't kill it |
| 2020-09-17 19:59:37 | <davean> | often |
| 2020-09-17 19:59:37 | <sm[m]> | oh sorry.. carry on |
| 2020-09-17 19:59:38 | × | gestone quits (~gestone@c-73-97-137-216.hsd1.wa.comcast.net) (Ping timeout: 272 seconds) |
| 2020-09-17 19:59:44 | × | notzmv` quits (~user@177.103.86.92) (Ping timeout: 258 seconds) |
| 2020-09-17 19:59:53 | <davean> | for example Linux can't kill a process blocked on IO (This is basicly the POSIX OS issue in general) |
| 2020-09-17 19:59:57 | <nineonine> | it is pretty hard to reproduce |
| 2020-09-17 20:00:04 | × | incertia quits (~incertia@d60-65-215-180.col.wideopenwest.com) (Ping timeout: 256 seconds) |
| 2020-09-17 20:00:08 | → | petrus joins (~petrus@unaffiliated/petrus) |
| 2020-09-17 20:00:21 | × | finkata quits (~dpetrov@83.222.188.39) (Remote host closed the connection) |
| 2020-09-17 20:00:33 | <sm[m]> | frdg: what's more painful, $5/mo or 5-50 hours of system administration :) |
| 2020-09-17 20:00:51 | <monochrom> | I don't know if you already know, but if Unix, terminateProcess is just SIGTERM. |
| 2020-09-17 20:00:55 | <davean> | nineonine: if you want to generate an unkillable process on POSIX its generally pretty easy using NFS and just removing the server ;) |
| 2020-09-17 20:00:56 | → | mariatsji joins (~mariatsji@2a01:79d:53aa:c66c:fcb4:8a4:b249:c1d3) |
| 2020-09-17 20:00:59 | → | incertia joins (~incertia@d60-65-215-180.col.wideopenwest.com) |
| 2020-09-17 20:01:47 | notzmv`` | is now known as notzmv |
| 2020-09-17 20:01:53 | × | notzmv quits (~user@177.103.86.92) (Changing host) |
| 2020-09-17 20:01:53 | → | notzmv joins (~user@unaffiliated/zmv) |
| 2020-09-17 20:01:55 | <nineonine> | right, that makes sense. the fact that there is no guarantee about terminating the process is quite surprising to me :D |
| 2020-09-17 20:02:04 | <monochrom> | Haha NFS brings fond memory. |
| 2020-09-17 20:02:12 | <davean> | nineonine: really its the "worse is better" issue |
| 2020-09-17 20:02:32 | <davean> | Infact the only OS family I know that has this issue *is* POSIX |
| 2020-09-17 20:02:40 | <davean> | I don't know of this being able to happen anywhere else. |
| 2020-09-17 20:03:57 | <monochrom> | Old school lab used to be like, every last day of semester, reliably, NFS crashed by overloading, all processes blocked and unkillable, you couldn't even log out. (Because, like, logging out requires checking your home directory for .logout but it's through NFS but NFS is not responding...) |
| 2020-09-17 20:05:11 | × | mariatsji quits (~mariatsji@2a01:79d:53aa:c66c:fcb4:8a4:b249:c1d3) (Ping timeout: 244 seconds) |
| 2020-09-17 20:05:25 | <sm[m]> | there is a way to guarantee termination, and that's to reboot the machine |
| 2020-09-17 20:05:44 | <glguy> | cut power; I've had reboots fail :) |
| 2020-09-17 20:05:46 | <sm[m]> | right ? or is even that impossible, without a hardware switch ? |
| 2020-09-17 20:06:12 | <sm[m]> | ack |
| 2020-09-17 20:07:14 | <monochrom> | We students didn't bother to power cycle for many reasons. In this case, turning off would be OK, but turn on would be pointless. |
| 2020-09-17 20:07:33 | <glguy> | It would be pretty nifty if having a process stalled on an NFS mount make it so that not even cutting power was enough to kill the process. |
| 2020-09-17 20:07:45 | × | ggole quits (~ggole@2001:8003:8119:7200:7c4d:5b32:3cf7:fd63) (Quit: Leaving) |
| 2020-09-17 20:07:45 | <glguy> | you just were left with a permanently on computer! |
| 2020-09-17 20:08:04 | <monochrom> | That's like defy the 2nd law of thermodynamics. |
| 2020-09-17 20:08:14 | <davean> | sm[m]: you can't guarrentee a reboot :( |
| 2020-09-17 20:08:17 | <glguy> | sure, but we're talking about NFS |
| 2020-09-17 20:08:27 | <monochrom> | hahaha OK fine just cause! |
| 2020-09-17 20:08:30 | → | eric joins (~eric@2804:431:c7d4:402a:218c:8374:598c:5968) |
| 2020-09-17 20:08:44 | <monochrom> | "NFS solves the halting problem!" |
| 2020-09-17 20:08:46 | <davean> | You know they use to write persistent OSs? |
| 2020-09-17 20:08:57 | <davean> | you removed power, you plugged it back in, and it would be exactly where you left it |
| 2020-09-17 20:09:02 | <davean> | that was a thing in the 70s |
| 2020-09-17 20:09:12 | <davean> | The entire OS was transactional. |
| 2020-09-17 20:09:30 | <davean> | There were a few of them, I forget which at this point though |
| 2020-09-17 20:09:54 | sm[m] | gets itchy for new OSs |
| 2020-09-17 20:10:26 | <monochrom> | Well yeah, more seriously you could say "turn off" means use a bit of reserve battery to save state and then turn off. |
| 2020-09-17 20:11:04 | <monochrom> | Or even you always have autosave so it's close enough. |
| 2020-09-17 20:11:32 | monochrom | thanks AoE2 DE for having frequent autosave, like only 2 minutes lost in the worst case |
| 2020-09-17 20:11:45 | <davean> | Yah no the processes couldn't tell |
| 2020-09-17 20:11:49 | <davean> | The memory came back the same. |
| 2020-09-17 20:11:58 | hackage | uniqueness-periods-vector-examples 0.4.0.0 - Examples of usage for the uniqueness-periods-vector series of packages https://hackage.haskell.org/package/uniqueness-periods-vector-examples-0.4.0.0 (OleksandrZhabenko) |
| 2020-09-17 20:12:04 | <davean> | well the same as the last consistent state, which you couldn't have observed past |
| 2020-09-17 20:12:48 | × | coot quits (~coot@37.30.53.120.nat.umts.dynamic.t-mobile.pl) (Quit: coot) |
| 2020-09-17 20:12:49 | × | eric_ quits (~eric@2804:431:c7d4:402a:e9bd:254c:fe89:5831) (Ping timeout: 272 seconds) |
| 2020-09-17 20:13:06 | → | frdg` joins (~user@pool-71-184-143-249.bstnma.fios.verizon.net) |
| 2020-09-17 20:13:09 | × | mmohammadi9812 quits (~mmohammad@5.238.164.128) (Quit: I quit (╯°□°）╯︵ ┻━┻) |
| 2020-09-17 20:14:10 | → | acarrico joins (~acarrico@pppoe-209-99-203-201.greenmountainaccess.net) |
| 2020-09-17 20:14:34 | × | justsomeguy quits (~justsomeg@unaffiliated/--/x-3805311) (Ping timeout: 260 seconds) |
| 2020-09-17 20:14:35 | × | frdg quits (~user@pool-71-184-143-249.bstnma.fios.verizon.net) (Ping timeout: 240 seconds) |
| 2020-09-17 20:14:38 | → | notzmv` joins (~user@177.103.86.92) |
| 2020-09-17 20:15:23 | → | gestone joins (~gestone@c-73-97-137-216.hsd1.wa.comcast.net) |
| 2020-09-17 20:16:19 | → | juuandyy joins (~juuandyy@90.166.144.65) |
| 2020-09-17 20:16:27 | × | frdg` quits (~user@pool-71-184-143-249.bstnma.fios.verizon.net) (Client Quit) |
| 2020-09-17 20:16:28 | → | aplainzetakind joins (~johndoe@captainludd.powered.by.lunarbnc.net) |
| 2020-09-17 20:16:41 | × | acarrico quits (~acarrico@pppoe-209-99-203-201.greenmountainaccess.net) (Client Quit) |
| 2020-09-17 20:17:01 | → | acarrico joins (~acarrico@pppoe-209-99-203-201.greenmountainaccess.net) |
| 2020-09-17 20:18:14 | × | notzmv quits (~user@unaffiliated/zmv) (Ping timeout: 260 seconds) |
| 2020-09-17 20:20:06 | × | gestone quits (~gestone@c-73-97-137-216.hsd1.wa.comcast.net) (Ping timeout: 260 seconds) |
| 2020-09-17 20:20:54 | → | machinedgod joins (~machinedg@d67-193-126-196.home3.cgocable.net) |
| 2020-09-17 20:22:28 | × | p-core quits (~Thunderbi@koleje-wifi-0046.koleje.cuni.cz) (Quit: p-core) |
| 2020-09-17 20:22:49 | → | p-core joins (~Thunderbi@koleje-wifi-0046.koleje.cuni.cz) |
| 2020-09-17 20:23:54 | × | aplainzetakind quits (~johndoe@captainludd.powered.by.lunarbnc.net) (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net) |
| 2020-09-17 20:24:33 | → | aplainzetakind joins (~johndoe@captainludd.powered.by.lunarbnc.net) |
| 2020-09-17 20:25:02 | → | eric_ joins (~eric@2804:431:c7d4:402a:5d9b:3471:cb46:d9c6) |
| 2020-09-17 20:27:54 | → | bitmagie joins (~Thunderbi@200116b80679150051a84e8093abf52a.dip.versatel-1u1.de) |
| 2020-09-17 20:28:39 | × | eric quits (~eric@2804:431:c7d4:402a:218c:8374:598c:5968) (Ping timeout: 272 seconds) |
All times are in UTC.