If you have a web API that returns a 200 OK with a JSON object with a missing entry when an item is not found, instead of a 404 error, then you have a bug in your API.
But you cannot allow it to change because your users are relying on the existing behavior.
And this is the case for, what, maybe 0.1% of unit tests?
And you're using that... to justify that the "only" thing unit tests achieve is maintain bugs? Although in any case, this is no longer a bug, it's part of your spec now.
But regardless, what about the other 99%+ of unit tests that are enforcing correct behavior...?
Your argument is like saying that food is bad because people occasionally get food poisoning.
The people who matter, who write init scripts, in other words the distro maintainers, were happy to switch.
Why else do you think so many distributions switched?
Yes, the resistance is noisy and stubborn Unix neckbeards. Not even Unix, since every other Unix had something similar to systemd already. LINUX neckbeards.
The journalctl binary format seems to handle corruption pretty well. That was a design criteria.
Everyone forgets or tries to ignore that text files ARE A BINARY FORMAT. It is encoded in 7-bit ASCII with records delimited by 0x0a bytes.
Corruption tends to be missing data, and so the reader has to jump ahead to find the next synchronization byte, aka 0x0a. This also leads to log parsers producing complete trash as they try to parse a line that has a new timestamp right in the middle of it.
Or there's a 4K block containing some text and then padded to the end with 0x00 bytes. And then the log continues adding more after reboot. Again, that's fixed by ignoring data until the next non-zero byte and/or 0x0a byte. This problem makes it really obvious that text logs are binary files.
And here, this isn't perfect but if you had to hack out the text with no journalctl available you could try this:
grep -a -z 'SYSLOG_TIMESTAMP=\|MESSAGE=' /var/log/journal/69d27b356a94476da859461d3a3bc6fd/system@4fd7dfdde574402786d1a1ab2575f8fb-0000000001fc01f1-0005c59a802abcff.journal | sed -e 's/SYSLOG_TIMESTAMP=\|MESSAGE=/\n&/g'
The journalctl binary format seems to handle corruption pretty well. That was a design criteria.
Thanks for pointing that out. I guess thats why they came up with their own format instead of just using sqlite, or something else that is already a standard.
Everyone forgets or tries to ignore that text files ARE A BINARY FORMAT
That's a bit pedantic, even for HN standards :-)
But yes, I know all about fragile log parsers and race conditions of multiple processes writing to the same file. I was just thinking about a scenario where you end up having to read raw logs when things go haywire.
I have a Windows virtual machine that was doing this to me a lot, and making Ubuntu reboots take a long time, and then requiring a disk check after the unclean shutdown.
I found a registry key that tells Windows to force stop apps that block shutdown. I may lose an unsaved document once in a while but I would have lost it anyway, and I am pretty good about saving things when necessary.
Not counting BIOS time it is about 5 seconds to Windows login on my Windows with NVMe systems. It does take about 20 seconds after login for it to finish loading all of the tiny startup notification icons, but that's actually intentional by Windows so it does not overload and prevent you from launching the apps you want. After login I can click on the web browser or email and it will launch instantly for me.
If you are doing a lot of waiting look into getting an SSD for your boot drive.
Or you're running some kind of corporate security product that is going to a remote server for "Mother, may I launch this?" on every EXE and DLL.
LOL! No, the HDD never was reasonably fast. Our expectations changed.
I booted up an old Windows XP box about two years ago before recycling it. It took almost TWO MINUTES to finish booting to the desktop. Some kind of fairly standard 500 GB Western Digital Blue drive. No, I don't know if it had ever been defragmented or had its TEMP files cleared or had old driver modules removed... It was just slow.
I just don't buy it. Sure, SSDs have always been faster—I remember how exciting they were when they were new—but HDDs were always "fine". Not fast, maybe, but nothing ever felt broken. I never waited multiple seconds to open a search box, for example.
And more broadly... have you ever tried running Windows XP in a VM, on modern hardware? Even virtualized, if you feed it anything approaching the resources of a typical 2021 machine, it absolutely flies compared to Windows 10.
I have an SSD for a boot drive on my personal and work computers. Both go out for lunch for long periods of time.
It might be me.
I know my reaction time is 35% faster than my teenage son. I am much more bothered by latency than other people, I'm starting to think that I experience more time than other people.
I can't stand playing single-player games on a Samsung TV that isn't in game mode. The sloppy response drains out all my fun.
When I was playing League of Legends on a "gaming" laptop I found I couldn't ever win (not feel like I was floundering, attacks hitting me and i couldn't do anything about, people avoiding my attacks 100% of the time) until I attached an external monitor. I took movies and could show the timer was 30 ms late on the internal monitor compared to the internal monitor.
Most people seem indifferent to this sort of thing, but not me.
> Most people seem indifferent to this sort of thing, but not me.
The average person who walks into a museum will be able to tell you which paintings they like, and which they do not. An art historian, however, will be able to tell you why they like certain paintings, and discuss specific details in the composition.
You are like the art historian. When you play a game on a laggy TV, you can tell that the TV's latency is making the game worse. A layperson just finds the game less engaging, and doesn't know that it could be better, much less why.
Arguably, the issue is when the HDD isn't the only computer you use. If you switch to using an SSD on, say, a laptop, boot times are super fast, you get used to that, etc.
Then you go use an HDD, and suddenly everything feels slow. The thing is, it's not actually slower than it was before, it's just slower than your most recent comparison point.
If only use an HDD, though, those boot time are just the way it is. I never actually found it to be a large difference between Windows and Linux. The difference that really bit me was startup apps on Windows, but fresh installs were plenty quick.
I think in a lot of ways it's like getting off a freeway after a while. On a regular in-city drive, the road speeds feel normal and reasonably quick (assuming no traffic). When you've just gotten off the freeway, though, you're at half the speed of what you've been driving at for the last hour or two, and it feels very slow.
HDD have been slow since before Windows 10 was announced. I was converting friends to SSDs during the Windows 7 era. At least on HN I would expect technical-minded people to have some perspective on the speed of storage mediums and how _fast_ and _cheap_ solid state drives are. Yes, I said cheap.
A crappy SSD from a good brand is £70/TB (Samsung 860 QVO), and it is ORDERS (plural) of magnitude faster an a hard disk drive.
You can run whatever you want on antiquated hardware, but please people, stop complaining about it and get on with the times already.
I believe the benefits of cryptocurrency outweigh problems.
I like having options that can be anonymous, don't require banks, immune to government influence, and even completely outside any law. Because laws are not always moral and should be ignored and evaded.
That's freedom. Having it is worth the significant amount of problems that come along with it.
> don't require banks, immune to government influence, and even completely outside any law
If any of those things were actually true we wouldn’t be having this conversation.
Also, since you apparently do think that they are true, why are you at all concerned about what banks or governments or laws might mean for cryptocurrency? I thought cryptocurrencies were immune?
> Wouldn’t all sequence points executed before undefined behavior is encountered be required to occur as if the undefined behavior wasn’t there? It would seem so:
No. Code optimization is a series of logic proofs. It is like playing Minesweeper. If a revealed square has 1 neighboring mine and a count of 1, then you know that all 7 other squares are safe. In other Minesweeper situations you make a proof that is much more complex and allows you to clear squares many steps away from a revealed mine. If you make a false assumption of where a mine is, via a faulty proof, then you explode.
The compiler is exactly like that. "If there is only one possible code path through this function, then I can assume the range of inputs to this function, then I can assume which function generated those inputs..."
You can see how the compiler's optimization proof goes "back in time" proving further facts about the program's valid behavior.
If the only valid array indexes are 0 and 1 then the only valid values used to compute those indexes are those values that produce 0 and 1.
This isn't even program execution. In many cases the code is collapsed into precomputed results which is why code benchmarking is complicated and not for beginners. Many naive benchmark programs collapse 500 lines of code and loops into "xor eax,eax; ret;" A series of putchar, printf and puts calls can be reduced to a single fwrite and a malloc/free pair can be replaced with an implicit stack alloca because all Standard Library functions are known and defined and there is no need to actually call them as written.
Depends on when. If we are talking about modern day JVM, than even the non-latency optimized default GC would have <10ms stop-the-world pauses for up to gigantic allocation rates, much less for the presumably minor one of a simple game. And then there are two latency optimized ones, Shenandoah and ZGC, with the latter having <1ms, meaning that your OS introduces more latency with thread switches.
So I think writing a game while profiling allocation rates and paying a bit of attention to not spam new everywhere, one should get decent performance without any framedrops. At most, optimize the hot loops with primitives, arrays.
You'd have to do something like allocate a single byte[] for everything you'll ever need, and reading & writing data would just be a constant tax since you can't just in-place cast that to an int or whatever. It wouldn't be very fun.
But you cannot allow it to change because your users are relying on the existing behavior.