HN user
https://github.com/yalue/
I had the same experience, lol. I started with Crime and Punishment expecting thinly veiled philosophy where each character is a mouthpiece for one of the author's thought processes. Granted there's some of that, but I wasn't expecting such an exciting murder drama. Went into Karamazov expecting an exciting murder drama, and got the type of Russian literature I initially expected Crime and Punishment to be! Really it's a question of expectations.
Truly the biggest prize of the IOCCC is getting your name listed next to geniuses like the author of nanochess.
So every time my ISP changes my IP, facebook pitches a fit, makes me solve a dozen captchas and authenticate on an existing login session, but in the meantime Meta' sother website doesn't even require using the registration email for a password reset?
Pathetically hypocritical to use AI to write this blog post when generic copy editors have been hit way harder by AI than programmers.
15 years ago, Enterprise FizzBuzz [1] was supposed to be satire. These days, it's not quite complex enough to capture "modern" web dev.
[1] https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
For a long time, windows had two options:
1. Update and restart and prompt for bitlocker password and update and restart and prompt for bitlocker password and restart
2. Update and restart and prompt for bitlocker password and update and restart and prompt for bitlocker password and shut down (and restart)
Finally, they fixed the last bit of option 2
Microsoft Go? I've used Go on windows for years now and this is the first I've heard of this fork. So it only exists because microsoft wants to have a crypto package that complies with an arbitrary regulation? Is there a reason that a better package requires a fork of the entire runtime rather than just, say, a normal Go package? It sounds like it requires cgo to call into third-party libraries, but that's already a common practice in "normal" Go libraries.
One thing I do appreciate is how the relevant issue in the upstream Go repo says: "A number of companies must comply with them, for example as part of a broader FedRAMP compliance posture. (If that's not you, you can ignore this. Run!)" [1]
Apparently I'm just not the target audience. Sounds like I'm correct in assuming it's security theater at best, and an avenue for new backdoors at worst.
The velocity of a spacecraft in low earth orbit is over 15,000 miles per hour. Smashing into the atmosphere is perhaps the most fuel- and cost-efficient way to slow down to a speed at which landing is possible.
Heh, so it's an 1897 version of what this guy on youtube attempted with a monster truck with mild success: https://www.youtube.com/watch?v=ohxGA7fpfu0 (warning: extremely redneck)
One thing the article doesn't seem to mention is noise. I've found that the "actual" air purifiers seem to be much quieter than box fans. Perhaps if you had greater control over the box fan's speed you could get the noise down to a comparable level, but I doubt the cheap type of fan used in the article is capable of such a thing.
The issue is that the "young" demographic mentioned in the article is ages 18-29, and high school must have changed quite a bit in recent years if students have not actually heard about the holocaust or WWII.
Judging by the project, it's implemented by instrumenting the source code; either manually modifying error returns with a wrapper function, or by running source files through an automated tool that will find and modify the return statements for you.
Even though I hate emojis in general, it still drives me nuts that there's a swan emoji but not a goose emoji
I'm not anyone involved in this thread (so far), but I've written a minimal PDF parser in the past using something between 1500-2000 lines of Go. (Sadly, it was for work so I can't go back and check.) Granted, this was only for the bare-bones parsing of the top-level structures, and notably did not handle postscript, so it wouldn't be nearly enough to render graphics. Despite this, it was tricky because it turns out that "following the spec" is not always clear when it comes to PDFs.
For example, I recall the spec being unclear as to whether a newline character was required after a certain element (though I don't remember which element). I processed a corpus containing thousands of PDFs to try to determine what was done in practice, and I found that about half of them included the newline and half did not---an emblematic issue where an unclear official "spec" meant falling back to the de facto specification: flexbility.
It's honestly a great example of something a GPT-like system could probably handle. Doable in a single source file if necessary, fewer than 5k lines, and can be broken into subtasks if need be.
Having to hold perfectly still (possibly in an uncomfortable pose) in a giant machine that's making loud, uncanny noises for 20+ minutes is indeed a very bizarre, meditative experience. It is interesting, but, in my opinion, you're probably going to be happier not having the health concerns that lead to getting an MRI in the first place!
Jon Bois is a genius, and this is the main example I return to when tempted to think that hypermedia is just a gimmick. It takes a special type of creativity to not just make it feel "tacked on." Perhaps the light jazz and dated look of the google maps visuals just meld well with the nostalgia evoked by the content of the story. The text alone would probably work as a good scifi short, but the additional material makes it so much more dramatic.
Here's an idea for how to maintain Go moving forward: keep making the damn tool however you want. The thing never would have existed in the first place if they had started with an industry survey. It was created to address a perceived need, by the people with the need, for themselves. This model is perfectly fine moving forward. Some industrial user wants a new Go feature or bugfix? Great. If it's enough of a problem, they can fix it and upstream a patch. That's how open source software is always supposed to work. Telemetry does nothing to improve this situation. If the Go team at google no longer has any ideas for what to work on (as must be the case if they're wasting their time on dumb crap like forced google spyware in a compiler) then they should just stop. Maybe focus on accepting PRs from people with ideas and strong enough motivation to work on them. I mean, there are 5000+ issues and 330 open PRs on the go github right now, so that should be plenty to keep them occupied. On top of that, how can literal thousands of issues not be a strong enough source of actionable usage information that they saw fit to try to get more? Do they plan on wrapping up all the open issues before looking at telemetry?
Yes, I was in the first category of people, where I am using GDNative to ultimately call a single function written in Go, not due to speed, but simply in order to leverage a huge amount of code I had already written in that language. Judging by the GDExtension headers, I can probably pull off something similar if I forgo all of the C++ bindings that I don't need. However, I am hesitant to dedicate any time to doing so at the moment.
Don't get me wrong, GDExtension seems awesome, but it's also true that it doesn't seem geared towards the case that I was using GDNative for.
As much as I'm looking forward to 4, has GDExtension been stabilized / documented yet? I know there's the existing C++ example [1], but I really, really don't want to jump through a scons & C++ project simply to call a single native function in a DLL. You can do such a thing with GDNative, and I presume that it is possible in GDExtension as well, though it isn't obvious how to do so. This strikes me as a huge barrier to adoption, since GDNative is one of the big things that will be incompatible with 4.
[1] In the godot-cpp library: https://github.com/godotengine/godot-cpp
Boy, if only you saw how popular Beamer (a LaTeX presentation framework) was in certain academic circles. Spoiler: it leads to exactly the problem you describe, in addition to using some default styling that manages to be both hideous and crushingly bland at the same time. At least, based on the screenshots, this proposed framework doesn't have the second problem.
I guess, the way I view this is as a "better beamer" (which isn't saying much IMO) rather than a better powerpoint. Basically, it's a way for people who were going to make a text-heavy presentation anyway to produce something that looks OK, and to avoid using a heavyweight tool like LaTeX.
One of the most fun (?) parts of academia is the unique blend of frustration and satisfaction that results when a shoddy paper somehow clears peer review only to get eviscerated when it lands on the desk of an actual expert.
"the detailed exploration of irrelevancies" LOL, if that isn't a "time-tested" method for making a paper sound academic, I don't know what is.
I understand that key travel time is included in the latency measurements to facilitate the camera-based measurement, but wouldn't it make more sense to measure latency purely in terms of electrical signals? For example, measuring the time between the first connection of the circuit in the keyswitch to the time at which the USB packet including the keypress is sent across the wire? This seems like it would be equally possible to test with a second logic analyzer, without relying on a high FPS camera. Many people who use "special" mechanical keyboards are well aware of the actuation points on their keyboards, and understand that there are tradeoffs between travel time, physical feedback, and so on.
Put another way, unless you think gently resting your fingerprints on the top of a key should count as a "press", then it doesn't make sense to include the key travel time in latency.
If accurate, it's unfortunate to hear the situation has worsened here. About 7 years ago, I sent what was essentially a single-line bugfix to Go, and it was reviewed and merged within 3 days.
At least in the original paper [1], the key idea is that instead of training a neural network to treat "images" as an array of pixels, you train a network to map a camera location and direction (in 3D space) to a distance and a color.
For example, if you tell a NeRF that you have a camera at location (x, y, z) and pointing in direction (g, h, j), then the network will output the distance at which the ray emitted from the camera is expected to "hit" something and the RGB color of whatever is hit.
Doing things in this way enables rendering images at arbitrary resolutions (though rendering can be slow), and is naturally conducive to producing rotated views of objects or exploring 3D space. Also, at least theoretically, it should allow for more "compact" network architectures, as it does not need to output, say, a 512x512x3 image.
Fun side fact: that's a project from Yusuke Endoh, who also happens to be the most prolific winner of the the obfuscated C contest (ioccc.org).
They figured out how to brick a Lego set.
Nice website and account. This sort of basic ROM manipulation was a huge gateway into low-level programming for me and many others. For an aspiring teenage programmer, it is immensely satisfying to be able to open a ROM in a hex editor and get Marin to greet Link by saying your crass phrases of choice at the start of Link's Awakening.
Surprised the start of the article neglects to mention the biggest hidden feature of the game, though: the fact that it also contains a hidden port of "The Lost Levels" (unlocked after getting a high enough score in the main game, IIRC). Super Mario Bros Deluxe is a stellar example of a great port; it's clear that a huge amount of thought and effort went into making a high quality version for the GBC. Glad to see it getting a bit of attention in this day when ports of old games are used as lazy cash grabs, inferior to the original releases.
Fortunately, they fixed dependency management first, so you can simply stop updating any dependency that adopts generics!
What about the file in the article makes it a "non-ELF binary"? The only thing I can think of is putting junk data in place of bytes the ELF spec designates as "padding" and expects to be 0. Other than that, it seems totally reasonable that putting garbage in place of a section-header offset with no headers, a physical address, and an alignment field wouldn't make it an acceptable ELF.
It's entirely on the Linux kernel to not verify these fields. However, its failure to verify these doesn't make the file not an ELF. It just makes it an ELF with a stupid alignment requirement that Linux happens to ignore.
Better yet, another commenter [1] found that you can clobber the number of section header entries, as long as the size of a section header entry is 0. So, now the smallest size is two bytes shorter: 112 bytes for a full "Hello, world!", with an 8-byte "alignment" field to spare!
I'll need to update this article. The only annoying part will be scribbling over the hexdump output again.