7 ms·
10 years ago, someone wrote a test for Servo that included an expiry in 2026
- kristofferR 6mo ago[flagged]
- andai 6mo agoIt was started by people who thought Twitter didn't have enough censorship (back when it had a lot more). I guess that's a matter of personal sensibilities, but it's pretty funny to me. (Note: this is the only fact I know about it, happy to learn more.)
- rirze 6mo agoAny social space will break down upon reaching a critical point in representation of the general populace. I have no idea about the development however.
- tomhow 6mo agoPlease don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- MBCook 6mo agoWorked for me.
- db48x 6mo agoClassic! But before you judge the fix too hashly, I bet it’s just a quick and easy fix that will suffice while a proper fix (to avoid depending on external state) is written.
- pavel_lishin 6mo agoI'll bet you one US Dollar that this is a scenario where the temporary fix becomes the permanent one. (Well, at least, permanent for a hundred years.) Some day, Pham Nuwen is going to be bitching about this test suite between a pair of star systems.
- db48x 6mo agoThat’s one of my favorite books :) I agree that it’s plausible!
- em-bee 6mo agoof course it is just an easy fix. it's the kind of solution that even someone like me could write who has no understanding of the code a all. (i am not trying to imply that the submitter of the PR doesn't understand the code, just that understanding it is unlikely to be necessary, thus the change bears no risk. but, the solution now hides the problem. if i wanted to get someone to solve the problem i'd set the new date in the near future until someone gets annoyed enough to fix it for real. and i have to ask, why is this a hardcoded date at all? why not "now plus one week"?
- db48x 6mo agoThere’s a lot to be said for simplicity. The more logic you put into handling the dates correctly in the tests, the more likely you are to mess up the tests themselves. These tests were easy to write, easy to review, easy to verify, and served perfectly well for 10 years. But doing it right shouldn’t be all that hard.
- bombcar 6mo agoAny time constant will be exceeded someday. An impossibly short period of time after the heat death of the universe on a system that shouldn’t even exist: ERROR TIME_TEST FAILURE
- unkl_ 6mo agoPosted on HN in 2126: 100 years ago, someone wrote a test for servo that included an expiry in 2126
- yetihehe 6mo agoNow I feel bad for using (system foundation timestamp)+100 years as end of "forever" ownership relations in one of my systems. Looking now, it's only 89 years left. I think I should use nulls instead.
- prerok 6mo agoWell, it won't be your problem /j
- bombcar 6mo agohttps://factorio.com/blog/post/fff-388 https://factorio.com/blog/post/fff-388 - they wanted to use a 64 bit int for the tick count, but Lua doesn't have one; so they used the one available and worked out when it would lose precision. "More than 2 million years seems to be enough for us to not be around any more when the bug reports start appearing."
- prerok 6mo agoI once saw a pop-up in a game saying something along the lines of: wow, it's 10 years later and this game is still being played! Made me laugh out loud, nice little easter egg. Sadly, I don't recall which game it was. Maybe SpaceChem?
- jerf 6mo ago
- Alupis 6mo agoJust skimmed the PR, I'm sure the author knows more than I - but why hard code a date at all? Why not do something like `today + 1 year`?
- whynotmaybe 6mo agoBecause it should be `today + 1 year + randomInt(1,42) days`. Always include some randomness in test values.
- andai 6mo agoInteresting, haven't heard this before (I don't know much about testing). Is this kind of like fuzzing?
- whynotmaybe 6mo agoI recently had race condition that made tests randomly fail because one test created "data_1" and another test also created "data_1". - Test 1 -> set data_1 with value 1 - Test 1 -> `do some magic` - Test 1 -> assert value 1 + magic = expected value - Test 2 -> set data_1 with value 2 But this can fail if `do some magic` is slow and Test 2 starts before Test 1 asserts. So I can either stop parallelism, but in real life parallelism exists, or ensure that each test as random id, just like it would happen in real life.
- devin 6mo agoAre you joking? This is the kind of thing that leads to flaky tests. I was always counseled against the use of randomness in my tests, unless we're talking generative testing like quickcheck.
- whynotmaybe 6mo ago`today` is random.
- Eldt 6mo ago
- andai 6mo agoInteresting, from the title I thought it was intentional, as a "forced code review." Apparently not, but now I really like that idea!
- adrianpike 6mo agoWe've done that at a few places I've been at - it's tricky because if the failure is too short its just annoying toil, but if it's too long there's risk of losing context and having to remember what the heck we were thinking. Overall it's still net positive for me in certain cases of enforcing things to be temporary, or at least revisited.
- bombcar 6mo agoWhich is why SSL certs are now 47 days long or whatever it is.
- gnabgib 6mo agoTLS certs are 200 days (as of last month). Or whatever https://www.digicert.com/blog/tls-certificate-lifetimes-will-officially-reduce-to-47-days https://www.digicert.com/blog/tls-certificate-lifetimes-will...
- jakub_g 6mo agoI always wanted to make feature flags system where each FF must declare an expiration date max 1 year in the future and start failing CI beyond that date to force someone to reevaluate and clean up. It's just too easy to keep adding new feature flags and never removing them. Until one day the FF backend goes down and you have 300 FFs all evaluate to false.
- fzeroracer 6mo agoWe had something like this where I last worked. Whenever we were adding new features or adding things that had potential for significant regressions, we were expected to add feature flags around the change/addition and set an expiration date for three months or so in advance. Once that rolled around, we'd either remove the old path or evaluate if it was necessary to have around as a permanent feature. I think it worked out really well even though it increased the administrative overhead. We were always able to quickly revert behavior without needing to push code and it let us gradually shrink a lot of the legacy features we had on the project.
- samlinnfer 6mo agoi had to plant a 10 year time bomb in our SAML SP certificate because AFAIK there is no other way to do it. It’s been 7 years since then. Dreading contacting all the IDPs and getting them to update the SAML config.
- vocx2tx 6mo agoBut still a kludge. Better: use something equivalent to Go's testing/synctest[0] package, which lets you write tests that run in a bubble where time is fixed and deterministic. [0] https://pkg.go.dev/testing/synctest https://pkg.go.dev/testing/synctest
- dathinab 6mo agoin general - generating test data in a realistic way is often better then hard coding it (also makes it easier to add prop testing or similar) - make the current time an input to you functions (i.e. the whole old prefer pure functions discussion). This isn't just making things more testable it also can matter to make sure: 1. one unit of logic sees the same time 2. avoid unneeded calls to `now()` (only rarely matters, but can matter)
- WorldMaker 6mo agoSimilarly, I like .NET's TimeProvider abstraction [1]. You pass a TimeProvider to your functions. At runtime you can provide the default TimeProvider.System. When testing FakeTimeProvider has a lot of handy tools to do deterministic testing. One of the further benefits of .NET's TimeProvider is that it can also be provided to low level async methods like `await Task.Delay(time, timeProvider, cancellationToken)` which also increases the testability of general asynchronous code in a deterministic sandbox once you learn to pass TimeProvider to even low level calls that take an optional one. [1] https://learn.microsoft.com/en-us/dotnet/standard/datetime/timeprovider-overview https://learn.microsoft.com/en-us/dotnet/standard/datetime/t...
- harikb 6mo agoA comment from the PR > Not a serious problem, but the weekdays are wrong. For example, 18-Apr-2127 is a Friday, not Sunday. There is now many magical dates to remember - 2126 ( I think PR was updated after that comment) and 2177. There is also 2028 also somewhere.
- dhosek 6mo agoOne of the comments: > Us, ten years after generating the certificate: "Who could have possibly foreseen that a computer science department would still be here ten years later." This was why there was a Y2K bug. Most of that code was written in the 80s, during the Reagan era. Nobody expected civilization to make it to the year 2000.
- bombcar 6mo agoNo, people thought that storing a year as two digits was fine because computers were advancing so fast that it was unlikely they'd still be used in the year 2000 - or if they were it was someone else's problem. And they were mostly right! Not many 80s machines were still being used in 1999, but lots of software that had roots to then was being used. Data formats and such have a tendency to stick around.
- naikrovek 6mo agoSoftware has incredible inertia compared to hardware. It is effectively trivial to buy millions of dollars of hardware to upgrade your stuff when compared with paying for existing software to be rewritten for a new platform.
- oasisaimlessly 6mo agoThis is a very SWE-centric perspective. The very names of software/hardwsre would imply the exact opposite.
- marcosdumay 6mo agoHas the last industrial hardware you've seen updated to use protected memory like most controllers have been able to for a few decades? Or better, its drivers run in what Windows version?
- jamesfinlayson 6mo agoFunnily enough I worked at a company with a codebase written in the 1980s - no idea what it originally ran on but someone decided in the mid 2000s to update it to run on modern hardware. Unfortunately they chose Itanium... so 20 years later they're paying lots of money for Itanium hardware.
- ianberdin 6mo ago“Someone” please stop write Someone at every possible post, especially on X.
- esafak 6mo agoI fixed one of these test cases too. Attached to it was a comment: // By the time this fails, I should be sipping pina coladas on the beach. Alas, he was still working, albeit at another firm.
- m_aiswaryaa 6mo agowhat a nostalgic test to fix lol
- m_aiswaryaa 6mo agoquite the nostalgic test to fix lol
- 28304283409234 6mo agoHmm. Interesting to call out someone like this. Stuff happens. We're all humans. For now. At least we were back then.
- _jackdk_ 6mo agoThis sort of thing can be a real problem for bootstrappable/reproducible builds, where you want to verify that the tests all pass. For a while, GNU Guix wouldn't bootstrap with tests enabled because it wanted to build openssl-1.1.1l for some reason, and the test suite contained expired certificates. (This was especially bad in a Nix-ish environment, where changing whether or not tests run changes the build command that the derivation uses, which means that you can't turn the tests off without changing the hash of every dependent package.)
- franga2000 6mo agoIsn't it common to set a fake static date and time for reproducible builds?
- _jackdk_ 6mo agoIt's a good idea, I don't know how often it's baked into the build runner by default. And in the Guix openssl-1.1.1l case, it hadn't been done.