belthesar

> May want to include a time series database, like InfluxDB

Seems to have native support for Prometheus, so that seems to be the TSDB to use for the project. That said, if you're at the point where your record density takes advantage of the benefits of a time series DB vs a well indexed RDBMS, I'd also imagine that you're beyond the scope of this little service.

That's a clever trick. It's also pretty trivial to set up a SOCKS5 proxy with Shadowsocks if it's desirable to keep that DNS resolution local.

Intel GPUs got quite a bit of penetration in the SE Asian market, and Intel is close to releasing a new generation. In addition, Intel's allowing for GPU virtualization without additional license fees (unlike Nvidia and GRID licenses), allowing hosting operators to carve up these cards. I have a feeling we're going to see a lot more Intel offerings available.

That's kind of the rub here.

> volunteer That's the majority of OSS. Only a handful of the projects we use today as a part of the core set of systems in the OSS world actually have corporate sponsorship by virtue of maintainers/contributors on the payroll. > unknown The actor built up a positive reputation by assisting with maintaining the repo at a time when the lead dev was unable to take an active role. In this sense, although we did not have some kind of full chain of authentication that "Jia Tan" was a real human that existed, that's about as good as it gets, and there's plenty of real world examples of espionage in both the open and closed source software world that can tell us that identity verification may not have prevented anything. > untrusted The actor gained trust. The barrier to gaining trust may have been low due to the mental health of the lead maintainer, but trust was earned and received. The lead maintainer communicated to distros that they should be added.

That's the rub here. It's _really easy_ to say this is a process problem. It's not. This was a social engineering attack first and foremost before anything else. It unlocked the way forward for the threat actor to take many actions unilaterally.

I read recently that systemd does not recommend that you link to libsystemd to participate in systemd-notify message passing. The API for talking to it is quite simple, and vendors are encouraged to implement a compliant interface rather than loading all of libsystemd into your program to manage this. This of course would mean maintaining your own compliant interface as API changes happen, which is likely why it isn't done more frequently. It seems to me that there would be a lot of value in systemd stubbing out libraries for the various functions so that dependent projects could link to the specific parts of systemd it needs. That, or some other way to configure what code gets load when linking libsystemd. Full disclosure, I've not looked at libsystemd to see if this is already possible or if there are other recommendations by the project.

The ceramic resonator described in this post has been a source of much consternation with the tool-assisted speedrun community. One of the goals of that community has been console-verification of TAS movies, to validate that the runs aren't taking advantage of emulator quirks. If you've ever seen TASbot perform at a GamesDoneQuick event, that's exactly what console verification is doing.

The ceramic resonators degrade in accuracy over time (as cited in the article), which leads to non-deterministic performance of the APU, and since the entire console's timings are all linked together, this leads to non-deterministic execution of game code.

As a tool-assisted speedrun is essentially a timeline of inputs, there's no logic to account for system execution, and as such, hardware determinism is a requirement. Since an accurate emulator, barring hiccups in the underlying runtime environment, gives us a deterministic runtime environment, this works great. However, it's lead to some weird and awkward behavior when trying to console verify TAS movies on these >30 year old SNES consoles.

Replacing these ceramic resonators to repair these consoles has had mixed success, but there are folks that are successfully doing it, thus keeping these legendary consoles alive, and bringing their timings back into spec.

This hasn't been my experience. In my experience, the reason why your ops teams divest themselves from the marketing side is because marketing decides to contract some firm to design their site for them, and the firm decides to deploy to Vercel or WP-Engine or whatever. Then, Marketing comes to ops and says "hey, I need you to change this DNS thing" weeks/months into their engagement, with no understanding of the ramifications. Ops/product team pushes back, because the change would fundamentally break the application. Marketing gets defensive, "we've spent all this time and money on this, you just need to make it work", a broken halfway solution is implemented, and ops/product, in protest, divests themselves from the solution. Bingo bango, shadow IT is ratified, the kludgy hackjob lives in production forever, and no one thinks about it until the next time something breaks.

Reminds me of the time marketing decided to change the logo on the marketing site for the product team I was on without being aware that the site was scraped and redeployed on a different domain (by hand). When the logo changed, the CSS for the image element wasn't updated, truncating part of the logo, proudly displaying the word "ass" as a part of the logo in an unfortunate cropping incident.

These are kind of two different things though. The challenges of encapsulating a wire protocol to display video like HDMI and using a protocol like ATSC 1.0, which has support for subchannels that send effectively arbitrary bitstreams that in the case you linked, happens to be fragmented h.264/h.265 that the TV already has codec support for. 80 mbit for sub-ms latency, lossless encoded HDMI is a non-starter. 80 mbit for sub-200ms lossy encoded video streams? Yeah, let do 100.

I really and truly do wish this wasn't true, but it is. Part of this is because we've built an expectation that the only thing one needs to pay for to use services connected on the Internet is access, and once access is paid for, the problem is solved.

But that's not the case. Products cost money, and we've established a pattern of free to play to freemium for much of the most popular services. This could change, but it would take the major players to flip the script, and they've invested so much into ad systems that they'd be hard pressed to abandon it.

I bet the ArchiveTeam might be able to help you out with this. They were quite helpful when I wanted to make sure a site was preserved, and might be able to help you as well, or at least point you in the right direction. https://wiki.archiveteam.org/

I'm hard opposed to storing my second factor codes alongside my first factors. Part of the reason why I use 2FA is because if my password store is compromised, the accounts in it that are compromised do not contain all of the credentials necessary to log into the accounts protected by 2FA. I also do not store my emergency removal codes in the same secret store as my passwords for this reason.

Oh cool, so not only is it third party code, I can't even inspect it!

Great question! I haven't gotten that far yet. I have Proxmox running on a 12th gen i5 currently, and my other two compute nodes, a 3rd gen i7 laptop and a 7th gen i5, are currently still serving production workloads, so I haven't had a chance to set up a cluster yet. That said, I don't mind limiting features to lowest common denominator for the k3s control plane node, as I don't need gobs of power for it or advanced CPU features, and I imagine that's the pain you might be facing (though I'm new to Proxmox, so who can say?)

That said, I do have a NAS that I can provide both NFS and iSCSI storage to, so I imagine if I run NFS as the backing storage, I shouldn't have to worry about clustered file systems. Each compute does have local storage, but the plan is to provide that via a CSI for workloads that don't need to be highly available or where fault tolerance isn't a concern.

Perhaps I'm being a bit doom and gloom about this, because I think it's probably pretty reasonable that Discord is searching for any sort of additional revenue stream they can get. Based on the numerous attempts at increasing monetization on the platform, I imagine because they need it.

That said, the last thing I want in a chat platform is a metric ton of additional untrusted code in an application that has more access and permissions than I think a chat app needs. If there's no way for me to opt out of having this code execute on my machine, I'm probably going to switch to a PWA if I can, because then I believe I have more control over what permissions third party code has access to.

Depending on the use case, this is definitely an option. I personally prefer using Proxmox under my Container Orchestration hardware because, as it seems to always eventually do, my home lab has become production, and being able to do software patches of the underlying system without service outages is really desirable. I've been agonizing and going back and forth between various potential solutions for this for a couple months now, with the most recent attempt being "Deploy k3s, with a fully separate control plane from the worker nodes, and run all of those atop a Proxmox cluster because being able to migrate VMs across nodes and also stand up isolated workloads to test out other solutions makes changing things in the future far less risky".

That said, I was running the Homelab on effectively a single Unraid hyperconverged NAS/compute layer before then, and that worked wonders for quite a long time. I wouldn't consider Unraid my first choice now, given the advancements in TrueNAS SCALE in the time since I chose it as the solution, but the concept of NAS + Container Orchestrator as hyperconverged homelab today is quite attractive.

I can appreciate folks coming to the defense of the demo, but the lede on what makes this special is pretty well buried to folks that aren't in this space.

If there was a blurb on the page stating that the cool bit we should be excited about isn't whether the image classification is accurate, but that there's realtime image classification running against WebGPU. That's definitely neat. However, with no context for folks clicking a random link, I don't think it's really all that off base for folks to comment on the model's functionality being comically inaccurate. At the time of writing, I had to read the bottom comment to get the understanding necessary for why this is neat.

That's the thing though, Yuzu doesn't ship with the common keys. Yuzu's quick start guide provides clear instructions for how to root a physical switch and dump the keys from the device, but it doesn't ship with the keys itself. What Nintendo is alleging is that providing the instructions to dump the keys is equivalent to providing them itself.

I definitely think this is a generational thing. Like you, I come from the land of "everything costs something" and treat free with suspicion, but also, we have been conditioning people to expect things to be free, and to bury and distract people from the real cost of those things for quite some time.

Two of the largest video content distribution platforms on the Internet, YouTube and Twitch. Free!* (just watch these ads). Store your data on the cloud with Dropbox, Google Drive, or OneDrive! Free!* (just let us harvest data about what you put in there) Hell, 25 years ago, you want to get on the internet? Use NetZero! Free!* (just look at these popups) And this pattern continues to be pervasive. And the real killer here is that we keep getting things for free*, so people that weren't around during the introduction of these tactics have grown accustom to it as if it's how things should be.

So, I agree, we really have a problem here in messaging and in using misleading psychology to bury dark patterns like the true cost of Free in services we use. We probably should be teaching more folks to beware of the true cost of things, that if it's free, you're the product, not the user, so on and so forth.

Sure, but now you're talking about sites with completely different service level objectives, and conversely, different budgets for their hosting. The problem here, to play off of your analogy, is that Netlify is treating every customer, many with SLOs likely less strict than HN as if they are the Super Bowl. This is an assumption that, according to the most recent policy discoverable by looking through their forum posts, is a constraint of their platform, and something they tout as a feature, not a bug.

When users expressed concerns for a similar scenario that the OP experienced on their community forum, Netlify's staff responded with "how likely is this, really?" Only has to happen once to put someone in significant financial harm.

Any bank where this is the standard operating procedure for interacting with loan applications is not a bank that I'd want to do business with. Perhaps this was just one loan officer's way of doing things, and not the way of the business, but that's just not okay to me.

Any time anyone asks me for any part of my social over the phone, I ask for some other method of verification. Most folks have other ways of doing stuff. It's ridiculous that what should purely be an ID number is so powerful, but I can't change that fact, just how I interact with folks with regards to it.

I looked at using the Ory stack when they were much younger, and had some chats with their team. Ory builds everything with the expectation that you're a large enterprise, where service classes and systems are expected to be scaled. They're also pretty big k8s adopters, so they all but expect that you want to run your workloads in a large environment. Great for folks that are bringing Auth* home from Auth0/Okta, etc, as scaling for each app class is right there, but also a much more complex stack to begin with.

That said, where are you seeing 7 containers? I haven't grabbed the repo to run it, but their quickstart instructions use config overlays to manage specific configs, and none of the examples looked like more than 5 containers, 4+ your database, with 1 of them being a dev mail endpoint. Separating tasks out to 3 different services, frontend, backend, and DB migration, doesn't seem super big to me.

CrossOver is a WINE implementation for people that want a really nice and simple interface. I used to beta test apps for them ages ago, which was nice, as that got me a free copy of the pro product. They recently just cleaned house on that program, and I lost my access, which, you know, fair, but also it happened right as I was wanting to check them out again after having managed WINE with other tools on my workstation.

By default, it makes brand new prefixes, has profiles for well known apps to configure the prefixes accordingly, including managing downloading the installers.

Their fixes and changes to their version of WINE are almost always upstreamed, so eventually you do get those features in OSS WINE, but that's honestly never been the reason to get it. It's the much more friendly UX, and for those using WINE in business environments, a channel to get support for the framework.

For those that want better prefix management for their home projects, there are plenty of OSS projects doing that now. Whisky for macOS, and Bottles for Linux are two fine alternatives to help keep WINE prefix hygiene without it, but neither come with the "we can install this business app for you with no hassle" concierge features.

These folks do know WINE well though. There's a reason they're working with Valve on Proton, and why so many of the commits to WINE come from them.

Something of note though is that things are shot for the aspect ratio they're shooting for. I'm guessing The Shield was intentionally shot with both Widescreen and 4:3 in mind if that happened, because it's pretty common to look through your viewfinder as a cinematographer, see that there's a boom in the shot, but it's outside of the matte and proceed with filming.

If we were to trust AI to do this, we'd need to build models specifically for this, with a way to give context to the rest of the set for the scene in question. From a technical perspective, I find the concept interesting, but from a practical sense, the amount of energy and time required to do this is almost a non-starter, and in doing this, we'd be going beyond the director's intent for the work at hand, which makes a transformative interpretation a degree or two removed from the intent of the director and production team.

The interesting thing is that even on highly dense workloads, the benchmarks and real world tests are showing that these hybrid core architectures are doing surprisingly great things.

I have more reading to do on the AMD side, so if you have more info than I take this with a grain of salt, but at least on the Intel side of the camp, the performance of a fully saturated E core is only slightly worse than its P core buddy, with 2x E cores meeting or exceeding the work output of a single P core + its hyperthread.

Even if the only purpose for the E cores is to run OS and other background workloads while your big processing job is getting unfettered access to the P core array, I imagine you'd see pretty great gains here.

For us technology slinging types, homebrew is indeed great. Sparkle updates are indeed fantastic for the average user however. I think I'd be interested in learning how many average users install software outside of the Mac App Store these days.

While I'm a strong supporter of your position that the MiSTer (and any FPGA console implementation) is still emulation, it's worthwhile to keep in mind that this will indeed be _a_ future for preservation (unsure about it being the only, and warmer to, but not sold on it being the best way).

Original hardware is great, but it's getting older, and failing. The Super Nintendo / Super Famicom, for instance, uses a ceramic oscillator as a clock source for its sound processing unit, and as the console is designed, the sound clock is essential for keeping the entire system in sync. Members of the Tool Assisted Speedrunning community have been experimenting with parts replacements to resuscitate this clock source with only mixed successes. This is one of many pieces of silicon on these old platforms that will continue to fail as time goes on.

We can't make brand new classic consoles because the parts are just unavailable, and the industry has a well trodden path of reimplementing discrete electronics in FPGA for decades now with great success. If your goal is to keep playing games for a while longer on your OG console, then heck yeah, go for it. It does indeed do the thing. But if we want to be able to preserve this history in as close to the original form factor and play environment as possible, then we have to explore other options, and FPGA system cloning is a grand way to do this.

The comments of that article cite a couple things:

* The version of Caddy used for the test was missing several recent updates that significantly improve its performance. * Performance improvements for QUIC have always been about removing/recovering from dynamic network connections, and are about running connections at scale. Simple HTTP 1 requests in environments where there are far less shenanigans going on will always be fast. (lib)curl powered requests being single threaded requesting across the local network stack are not representative of the types of performance gains to expect in an HTTP/3 world.

Hyperscalers in the cloud and low latency finance will drive the innovation to make HW offload a thing sooner. For the rest of us normal folk, we can likely live with CPU managed packets until that happens, and then take advantage of the optimization benefits when they make it to us.

I think it's fair to call this out, but my initial read, and the reason why I'm responding, is because it seems like you're saying that it's non-viable.

Unsure if your thoughts come from recent experience, legacy experience, or a need to run CUDA-accelerated workloads, but if you're citing the old wisdom that AMD GPUs on Linux are a pain to deal with, I'm happy to tell you that your knowledge is a bit out of date. AMD's OSS drivers (with closed source firmware blobs, yes) are mainlined in pretty much every modern distro's package manager, and work surprisingly well. Mind you, I tend to not run Linux on laptops, so if there's some nuance you're aware of wrt sleep or something that I'm not, please feel free to share.

I will say "Here There Be Dragons" wrt CUDA/OpenCL workloads however. You have to switch from Mesa to the AMD closed source drivers, and I did have some wonky issues, with, for example using things like Davinci Resolve with those drivers.

This type of "buyer beware" position describes the exact problem US auto dealerships already take advantage of, and advocating for more uses of this methodology doesn't address any of the actual problems, and makes the problems the industry are currently facing actively worse.