| --- Log opened Wed Jan 20 00:00:15 2021 |
| 00:05 | <&ToxicFrog> | It will protect you against the fairly specific problem of "the computer or hard drive was stolen while it was powered off". |
| 00:05 | <&ToxicFrog> | (and makes it harder -- but not impossible -- to get data off of it if stolen while asleep or while on but locked) |
| 00:10 | < Yossarian> | Is there a performance hit? |
| 00:12 | <&ToxicFrog> | I assume so. |
| 00:12 | < catalyst> | I have never measured it but I'd expect so too |
| 00:12 | <~Vornicus> | for SSD I'd say you would probably get noticeable performance hit. spinning rust on the other hand wouldn't have too much significance |
| 00:29 | | ErikMesoy1 [Bruker@Nightstar-h0p1f8.bb.online.no] has joined #code |
| 00:29 | | ErikMesoy [Bruker@Nightstar-h0p1f8.bb.online.no] has quit [Ping timeout: 121 seconds] |
| 00:35 | | macdjord|slep [macdjord@Nightstar-re5.7if.45.45.IP] has joined #code |
| 00:35 | | mode/#code [+o macdjord|slep] by ChanServ |
| 00:39 | | mac [macdjord@Nightstar-re5.7if.45.45.IP] has quit [Ping timeout: 121 seconds] |
| 00:59 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has quit [Connection closed] |
| 01:40 | | Kindamoody is now known as Kindamoody[zZz] |
| 03:20 | | ErikMesoy1 [Bruker@Nightstar-h0p1f8.bb.online.no] has quit [Ping timeout: 121 seconds] |
| 03:49 | | ErikMesoy [Bruker@Nightstar-9npdcr.bb.online.no] has joined #code |
| 04:00 | | Degi [Degi@Nightstar-12l3e7.pool.telefonica.de] has quit [Ping timeout: 121 seconds] |
| 04:02 | | Degi [Degi@Nightstar-36aqj1.pool.telefonica.de] has joined #code |
| 04:03 | | ErikMesoy [Bruker@Nightstar-9npdcr.bb.online.no] has quit [Operation timed out] |
| 04:11 | | ErikMesoy [Bruker@Nightstar-9npdcr.bb.online.no] has joined #code |
| 04:23 | | ErikMesoy [Bruker@Nightstar-9npdcr.bb.online.no] has quit [Ping timeout: 121 seconds] |
| 04:31 | | ErikMesoy [Bruker@Nightstar-4o2q1m.bb.online.no] has joined #code |
| 05:07 | | VirusJTG [VirusJTG@Nightstar-42s.jso.104.208.IP] has quit [Connection closed] |
| 05:07 | | VirusJTG [VirusJTG@Nightstar-42s.jso.104.208.IP] has joined #code |
| 05:07 | | mode/#code [+ao VirusJTG VirusJTG] by ChanServ |
| 06:19 | | Vorntastic [uid293981@Nightstar-h2b233.irccloud.com] has joined #code |
| 06:19 | | mode/#code [+qo Vorntastic Vorntastic] by ChanServ |
| 06:54 | | celticminstrel [celticminst@Nightstar-n1gkap.dsl.bell.ca] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
| 07:18 | | abudhabi [abudhabi@Nightstar-a9ev88.adsl.tpnet.pl] has joined #code |
| 07:32 | | abudhabi [abudhabi@Nightstar-a9ev88.adsl.tpnet.pl] has quit [NickServ (RECOVER command used by abudhabi_)] |
| 07:32 | | abudhabi [abudhabi@Nightstar-l9nm86.adsl.tpnet.pl] has joined #code |
| 11:56 | <@sshine> | sigh, these people I work with are so nice, but their discipline is that of mentally unstable hoarders. |
| 12:18 | | Kindamoody[zZz] is now known as Kindamoody |
| 12:41 | < abudhabi> | Explain. |
| 13:01 | | catalyst [catalyst@Nightstar-ejd4sd.cable.virginm.net] has quit [[NS] Quit: -a- IRC for Android 2.1.59] |
| 14:00 | <@sshine> | abudhabi, I spent some hours today trying to get a particular sub-project running, and every time I encounter a fatal error, there's a not insignificant probability that everyone knows this and ignores it. 31% of unit tests succeed (I found out after cleaning up the output from debug data enough to determine.) |
| 14:02 | <@sshine> | besides the typical reasons related to javascript (the setup script worked 3 months ago, but no longer does for external reasons), some of the dependencies in package.json were too new and didn't actually work, but the other devs didn't know because they had an older version in $PATH that still worked. |
| 14:07 | | celticminstrel [celticminst@Nightstar-n1gkap.dsl.bell.ca] has joined #code |
| 14:07 | | mode/#code [+o celticminstrel] by ChanServ |
| 14:10 | < abudhabi> | Sounds like business as usual. :V |
| 14:10 | | Kindamoody is now known as Kindamoody|afk |
| 14:41 | <@sshine> | heh, yes |
| 14:41 | <@sshine> | "That's front-end work for ya!" is how they say. :) |
| 14:41 | <@sshine> | I'm like... no! |
| 14:41 | <@sshine> | ;) |
| 14:46 | <@sshine> | I've had like ten "Is this fatal error supposed to occur here?" moments today. |
| 14:47 | | catalyst [catalyst@Nightstar-ejd4sd.cable.virginm.net] has joined #code |
| 14:48 | <@gnolam> | Hmm. Storing variable type options in a database (simple string key, value that can be string, bool, integer, float). What's the best option? |
| 14:48 | <@sshine> | whereas I would normally think fatal errors should never occur. |
| 14:48 | <@gnolam> | Separate tables for each type? Separate columns and store NULL in the ones you don't use? String representation? Big chunk o'JSON? |
| 14:49 | <@sshine> | gnolam, are all future types scalars? |
| 14:49 | <@gnolam> | Yes. |
| 14:50 | <@sshine> | I'd probably keep the enum in code and use a varchar for the key, and use a varchar for value and encode it after fetching it. |
| 14:51 | <@sshine> | unless you have good SQL schema integration so that your SQL ENUM is somehow mapped to code. |
| 15:18 | < abudhabi> | I'd just go with string key, string value, enum type and at the DB level whatever the migration framework spits out. |
| 15:19 | <@sshine> | abudhabi, so you'd keep them as strings in the application? |
| 15:20 | < abudhabi> | Sure, why not? |
| 15:21 | <@sshine> | I suppose it depends on whether you want to use domain-specific (logical, arithmetic) operators on them eventually. :-P |
| 15:22 | < abudhabi> | Yeah, a lot hinges on what it's actually used for. |
| 15:23 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 15:23 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 15:24 | < abudhabi> | An alternative would be to skip the type field, and make the value a JSON object to be serialized/deserialized as needed. |
| 15:24 | <@sshine> | gnolam, so basically: ditch type-safety unless your database-mapping layer is really smart (C#'s Entity Framework, Scala's doobie, Haskell's Esqueleto come to mind) |
| 15:27 | <@sshine> | abudhabi, postgres has a JSON field type. |
| 15:27 | < abudhabi> | Cool. |
| 15:29 | | Vorntastic [uid293981@Nightstar-h2b233.irccloud.com] has quit [[NS] Quit: Connection closed for inactivity] |
| 15:29 | <@sshine> | abudhabi, if you used a VARCHAR and it contained a string-serialized JSON value, that could work even though it sounds like a slippery slope (using a default JSON decoder, you'd accidentally get objects and lists and nested combinations if they ever showed up). it does provide a trivial coding format, that's nice. except, big/high-precision numbers in JSON don't necessarily have a nice representation, so it |
| 15:29 | <@sshine> | also hinges on the client library JSON decoder being able to handle those well. |
| 15:30 | <@sshine> | so if your integers were arbitrary-precision, the way you'd typically encode that in JSON is with a string. but then how do you tell apart a string with a big number and a big number? |
| 15:30 | <@sshine> | (there's no requirement to do that, but this is often how people encode big numbers in JSON because many programming languages are still fragile wrt. representing arbitrary-size numbers) |
| 15:30 | < abudhabi> | Mmm. The JSON would have to have two fields, one for value, other for type. The only difference being one less field in the table. |
| 15:31 | <@sshine> | what's the benefit? |
| 15:38 | < abudhabi> | That's it. ;) |
| 15:55 | <@sshine> | ah :) I'd be hesitant about making fields contain structured data. but that does overcome the problem I described. |
| 15:56 | <@sshine> | for example, you can't trivially search for fields that match some value unless the RDBMS has JSON selector support. |
| 16:03 | | bluefoxx [fuzzylombax@Nightstar-gmbj85.vs.shawcable.net] has quit [Ping timeout: 121 seconds] |
| 16:05 | | bluefoxx [fuzzylombax@Nightstar-gmbj85.vs.shawcable.net] has joined #code |
| 16:05 | <@gnolam> | Thanks for weighing in. |
| 16:05 | <@gnolam> | But I think I just found a way to postpone making an actual decision for a few more weeks. >_> |
| 16:24 | <@sshine> | I would've gone with SQL ENUM for the key until my previous job. I learned that if you ever want to remove an option, but preserve legacy data, you need the distinction in code anyway. |
| 16:25 | <@sshine> | so basically there were lots of databased values of all kinds that you couldn't pick any more, but you couldn't easily remove them yet either. |
| 16:52 | | Emmy [Emmy@Nightstar-l49opt.fixed.kpn.net] has joined #code |
| 17:01 | | Kindamoody|afk is now known as Kindamoody |
| 18:39 | | john_cephalopoda [john@Nightstar-2sgivq.dip0.t-ipconnect.de] has joined #code |
| 20:47 | | * gnolam laughs out loud at the national CERT's 2020 CTF challenge. |
| 20:47 | <@gnolam> | Not only was the actual flag hidden in a C64 demo... but an old Fairlight member showed up, solved it, and released a cracked version. :D |
| 20:48 | <&ToxicFrog> | I love it./ |
| 20:49 | <&McMartin> | Hell yeah, Fairlight. |
| 20:50 | <&ToxicFrog> | Yeah, good to know FLT is still kicking. |
| 20:51 | <&McMartin> | Not too hard to get enough people together to Get A Band Back Together, it seems |
| 20:56 | <@gnolam> | https://cert.se/2021/01/CTF-FLT.png |
| 21:15 | | SmithKurosaki [uid215460@Nightstar-ed0oqj.irccloud.com] has joined #code |
| 21:31 | | john_cephalopoda [john@Nightstar-2sgivq.dip0.t-ipconnect.de] has quit [Connection closed] |
| 21:32 | | john_cephalopoda [john@Nightstar-2sgivq.dip0.t-ipconnect.de] has joined #code |
| 21:37 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has quit [Connection closed] |
| 22:30 | | himi [sjjf@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 22:57 | | Emmy [Emmy@Nightstar-l49opt.fixed.kpn.net] has quit [Ping timeout: 121 seconds] |
| 23:24 | | john_cephalopoda [john@Nightstar-2sgivq.dip0.t-ipconnect.de] has quit [Connection reset by peer] |
| 23:24 | | TheCephalopod [john@Nightstar-2sgivq.dip0.t-ipconnect.de] has joined #code |
| 23:40 | | TheCephalopod [john@Nightstar-2sgivq.dip0.t-ipconnect.de] has quit [[NS] Quit: Leaving] |
| 23:44 | | abudhabi [abudhabi@Nightstar-l9nm86.adsl.tpnet.pl] has quit [Operation timed out] |
| 23:46 | | himi [sjjf@Nightstar-1drtbs.anu.edu.au] has joined #code |
| 23:46 | | mode/#code [+o himi] by ChanServ |
| --- Log closed Thu Jan 21 00:00:16 2021 |