Conversation
|
I'll recount my sad story of how I'm stuck with 32-bit Windows for you. I have this tablet, which I like and works well for me, circa 2015/2016. Due to some confluence of events between Microsoft and Intel, when this generation of devices was launched only 32-bit was ready for "Connected Standby" certification, so manufacturers asked for, and Intel provided, UEFI firmware compiled as 32-bit, which does not include legacy BIOS compatibility (another requirement for "Connected Standby" certification from Microsoft). After some time and effort, Linux eventually added support for a 64-bit kernel to be booted from 32-bit UEFI firmware, but apparently Microsoft never took that same effort for Windows. |
|
@jeremyd2019 thanks for the context <3 we've never really worried about 32bit before -- it's something we did reflexively because Go made it easy. I personally don't think we need to drop support for 32bit (and don't want to) -- I more asked the question to make sure that we go from "implicitly supporting it because it was easy" to "explicitly supporting it moving forward". |
mislav
left a comment
There was a problem hiding this comment.
The fix looks good to me!
Regarding the long term: I do not believe that we should have a 32-bit CI runner just to keep testing this. The CI runner would tell us what we already know: that int is int32 on 32-bit systems. Instead, we could perhaps institute a linter that verifies that any *ID struct field is represented as int64. That would catch future additions of int for fields that represent auto-incrementing database columns.
|
I'm into the linter idea! opened an issue for that |
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
A user reported in #3431 that they were unable to use new Actions features on a
32bit OS. The most immediate fix was to just change from the default
inttoexplicit
int64for run, workflow, and checkrun IDs.Question:
I'll adapt this PR based on the discussion.