lantastic
lantastic on Hacker News
On topic of fear of nuclear war:
After reading Daniel Ellsberg's The Doomsday Machine, I'm surprised we as a species are still around.
On Linux, you could create a udev rule to give you permissions on any attached raw disks (if you feel particularly adventurous).
What's the license for ffs?
Stunts was the greatest! You could make your own tracks, save replays and (IIRC) even resume gameplay from any point in the replay. My very favorite game of all time.
.. and have been for a long time. I don't remember the last time I reached for a hand-written SDK for a HTTP API. It's always some codegen affair. But out-of-the-box experience for many codegen tools is that the generated API ends up being very far in usability from what you'd write by yourself.
The API consumer should be able to adapt the binding to their needs and idioms instead of relying on behavior encoded in a pre-built SDK. The ability to do that with specific codegen tools (e.g. swagger-codegen, go-swagger) is pretty high-barrier. Oagen-emitters looks like something that addresses that gap.
Mine too! Another Lightwave-produced show I loved was Space: Above & Beyond.
> if i remember it correctly: they used a software called "lightroom"
Afaict, it was Lightwave3d, that I just learned still lives to this day. Last release June 11 2025. Also used to make SeaQuest :) Oh, the memories...
Sounds interesting. What's the title?
It is subject to legislation and certification, but it's harder to lobby when you can't privatize the direct costs. Still, scams are common (e.g. inflated medical equipment costs). I guess hustlers gonna hustle in any system.
Others pointed plenty of arguments, but the ones I find most compelling (not necessarily useful in this context) are:
- you can serve any number of disjoint websocket services via same port via HTTP routing
- this also means you can do TLS termination in one place, so downstream websocket service doesn't have to deal with the nitty-gritty of certificates.
Sure, it adds a hop compared to socket passing, and there are ways to get similar fanout with TCP with a custom protocol. But you need to add this to every stack that interacting components use, while websockets libraries exist for most languages that are likely to be used in such an endeavor.
Sure, socketpairs on Linux.
My cynical take is this is regulatory capture on part of the most lucrative tech sector in the next few years, in return for campaign contributions.
Wow, that's massive. I guess it's inevitable that a popular piece of open-source software for end-users will be compelled to accrue dependencies due to popular demand for features that require them.
I feel Telegraf made a good compromise: out of the box, it comes with a _ton_ of stuff[1] to monitor everything, but they make it possible to build only with pieces that you need via build tags, and even provide a tool to extract said tags from your telegraf config[2]. But lots of supply-chain security stuff assume everything in go.mod is used, so that can results in a lot of noise.
[1] https://github.com/influxdata/telegraf/blob/master/go.mod
[2] https://github.com/influxdata/telegraf/tree/master/tools/cus...
In every program that uses a particular feature from the stdlib. Given the same feature, I tend to trust stdlib more than some rando project. And if you don't trust the stdlib, why would you trust the compiler?
comatose sentry
necessary motto
Clearly you didn't read my socrates note.
FIPS and "be secure" aren't necessarily a full overlap: there's plenty of ways to be secure that isn't even allowed in FIPS, so you need to actively disable that set if you run FIPS mode (depending on libraries used, this may e.g. disqualify hardware intrinsics because it was not covered by CMVP, creating potentially material performance consequences).
If you're already compliant (implying you are using FIPS compliant crypto in all situations), the matter is tautological.
Does this mean FIPS-enabled software never runs as such in production (or at all) in environments where it is supposedly mandated?
I like the "go generate" approach to integrate such tools. I used a different (but identically named) go-enum tool [0], which accepts the go type and generates implementations for a bunch of interfaces. The neat thing is that the starting point is the "idiomatic" go enum definition, rather than description via a separate DSL:
//go:generate go-enum -type=State
type State int
const (
Unknown State = 0
Disconnected = 1
Connected = 2
)
which then generates a separate file with implementations such as:
func (i State) MarshalJSON() ([]byte, error) { ...
[0]
https://pkg.go.dev/github.com/searKing/golang/tools/go-enum#...
If you want to relive some the joy of X-Wing, X-Wing Alliance Update (XWAU) modernizes the XWA game (including VR support). For TIE Fighter afficionados, there is even a TIE Fighter Total Conversion project that rebuilds entire TIE Fighter campaign in XWA, including a reimagined campaign that takes advantage of the engine improvements in the mods to build larger engagements. Definitely took me back to that summer spent at the computer with my trusty Wingman Extreme.
Interesting. Can you expand a bit on the kinds of problems that websockets would encounter with such middleware? I've seen a fair share of surprises on just TCP from DPI/MitM and high bandwidth-delay products, so I'm curious about ws analogues.
I heartily agree. Don't treat yourself like a 3rd party.
Thanks for the blog post. Ep383 of the Linux Unplugged podcast [1] also went into detail with CentOS members.
What CentOS gave you until Stream was (with some delay) the "same" set of packages that RedHat released in RHEL, which was (hopefully exhaustively) tested by RedHat QA, including making sure that packages interact in a sane way. That's what earned RHEL (and by extension CentOS) that designation of stability. By virtue of being upstream, CentOS Stream could have a lot more updates (the kind that would previously be internal to RedHat). I doubt same level of QA can/will be invested for each update state (if it could be, RHEL would probably be a rolling distro). If you don't have a QA safety net of your own, the risk is higher with Stream vs 8.
You could hack point releases into Stream: wait for RHEL release, then dnf versionlock Stream packages to the same release versions as RHEL (assuming you can map versions of modular packages).
[1] https://linuxunplugged.com/383
I once used make to jury-rig a fairly complex set of backup jobs for a customer on a very short notice. Jobs were grouped and each group was allowed to run a certain number of jobs in parallel, and some jobs had a non-overlap constraint. The problem was well beyond regular time-based scheduling, so I made a script to generate recursive makefiles for each group that started backups via a command-line utility, and a master makefile to invoke them with group-specific parallelism via -j.
File outputs were progress logs of the backups that got renamed after the backup, so if any jobs failed in the backup window, you could easily inspect them and rerun the failed jobs just by rerunning the make command.
Fun times. Handling filenames with spaces was an absolute pain, though.
> Programmers seem to fall into two camps. Those that need to know details to understand a method and those that need to know the contract to understand a method.
This is an interesting observation. I seem to fall into the former category, but I'm not sure if that's a side effect of working with proprietary codebases that have less than stellar interfaces.
When stuff ultimately goes sideways, I value being able to relatively quickly reason about the flow without firing up a debugger. Information hiding cuts both ways.
Nice, I will definitely try it out!
Interesting, thanks for the link!