I’ll take the compliment! My goal was to keep each unit to simple tap and drag play dynamics. If there’s another curiosity, mechanical, electrical, another unit, I can add it to the development plans. It’s fun for our family!
> Apple is actually the opposite of Ubiquiti -- they don't want you to be able to configure anything or have any visibility into anything.
True, however before I was running a UniFi household I did quite enjoy Apple's Airport equipment. Back in the day it felt like they were the first time I had consumer networking equipment that I wasn't forced to reboot regularly to resolve issues.
Not a fan of either but I feel obligated to point out they don't appear to be sponsoring Omarchy, they just posted about it on their social media account(s). Hyprland they actually did do a small sponsorship for.
Omarchy is the passion project of a really wealthy person and is backed by his profitable business. What does ‘sponsoring Omarchy’ mean? Like.. where does that money go?
I think it amounts to providing free premium CDN service, the stuff you'd usually have to pay for. They didn't say anything about cash money changing hands.
That’s really reasonable then (I guess apart from any disagreements with the authors views). Omarchy isn’t just a post installation script, they have the entire thing bundled as an ISO. So I can see why an in-kind sponsorship of a CDN makes sense. Although it’s still unclear to me how Omarchy specifically fits into ‘the future of the open web’ vs Ladybird
Very cool! I think I'll have some opportunity soon to give it a shot, I have just the set of projects that have been needing a tool like this. One thing I think I'm missing after perusing the docs however is, how does one onboard other engineers to the cluster after it has been set up? And similarly, how does deployment from a CI/CD runner work? I don't see anything about how to connect to an existing cluster from a new machine, or at least not that I'm recognizing.
There isn't a cli function for adding a connection (independently of adding a new machine/node) yet, but they are in a simple config file (`~/.config/uncloud/config.yaml`) that you can copy or easily create manually for now. It looks like this:
I almost used this recently to gain more control over the HTTP cache behavior in our app at work, but eventually realized what I wanted could be achieved by combining plain old cache headers with some more intelligent cache busting query strings. I would definitely like to see some more real-life examples where this API provides unique benefits over traditional cache handling.
This API is pretty useful for writing web apps that also work offline/with bad connectivity. It saves you from re-implementing the browser fetching/resource loading logic the browser already does for you.
It's very powerful, which also makes it a footgun: you can end up with fetch() requests going out over the network, with server responses saying one thing, but the frontend receiving something completely differently.
As for examples, I believe Home Assistant uses it to cache pretty much every resource in the frontend pre-emptively so you can use the web UI even if your internet connection is down (but your connection to your home server isn't).
This API is used heavily in service workers to store responses for offline use. I don‘t think you can use HTTP cache headers to robustly achieve the same effect.
I created an SRS based kanji learning app (https://shodoku.app/https://github.com/runarberg/shodoku) hosted on GitHub Pages (meaning the app is a static HTML page) where all the dictionary data is stored as hundreds of thousands of json (and SVG) files. Storing these assets using the Cache API saves tens of thousands of round trips to the server in addition to offering a somewhat robust offline experience.
The issues in question here surface even with an empty city, at higher populations the CPU will almost certainly become the issue but right now most of the complaints are unrelated to sim performance and it even seems like for most people the sim performs quite well even at higher populations.
Seems like this was likely from before the hotfix that was released this morning which has improvements for some of the more egregious issues mentioned like DOF, LOD, and global illumination: https://store.steampowered.com/news/app/949230/view/37093367...
Still far from ideal but glad to see movement so quickly from the dev team and as has been mentioned the game is certainly playable albeit with some setting tweaks.
This is the week before go-live with a large customer. They've been doing lots of testing on their end (refreshing), and in the final stretch they found two glaring issues.
These two issues were glaringly, obviously wrong in core modules, and 100% reproducible.
Both were bad queries (static but parameterized). One resulted in an error from the DB server, and the other was a full join rather than filter by parameter (x=x vs x=:x), so spectacularly wrong results. Both were triggered by doing typical operations in our application.
Both issues had been in our code for many, many months, yet somehow the thousands of users we have across our several hundred customers somehow didn't report or experience these issues.
I fixed both issues in less than 15 minutes.
This isn't the first time. Sometimes I'm amazed how long such glaring issues manages to survive out in the wild amongst our customers.
Not saying they didn't know. Just saying that sometimes these things just happen.
I spent so much time in cities.exe I'm scared to check out the second one. How do you feel about the modding scene for it? I had probably 70GB of assets loading, converting the game into something altogether different.
After seeing this happen time and time again, it's kind of a wild decision to make. So many negative reviews I see these days are about performance issues.
You would think a little more time would be put into reaching at least some reasonable performance level.
> So many negative reviews I see these days are about performance issues.
Unfortunately, negative publicity from bad performance doesn't really stop these games from selling well, as proven by most AAA releases in the past few years.
Skylines isn't an AAA release though. And the first game was only really successful because the prior sim city was full of user hostile changes. The new game similarly banks on the accumulated positive image of the first one. To risk all that with a user hostile, awfully optimized early release is a risky game to play.
The studio already killed a series once with a bad second entry, cities in motion 2...
Exactly, and what the other replies to your comment don't understand is that: a; they'll patch performance over time b; humans forget things very quickly, initial bad reviews don't matter.
Oh yeah, everyone remember the Panama papers? Yeah seems the public have forgotten about them a long time ago. What was done about em? Humans only remember some things.
yep, performance issues are just less important than functionality issues in the lead-up to a release. You can fix performance with a patch. It's hard to walk back "game crashes when I trigger the main menu"
I think they released it without having a discussion about how bad an impression poor default settings could make. With a few adjustments it looks great and is very playable on my 3080 at 4K even before the patch. Really big blunder for sure.
They announced in advance of launch that it would have these issues so not unexpected, guess they knew the issue but no time to add it into the final release yet.
I'm talking about the pointless screen you have to dismiss to get to the login screen. The one that was introduced with windows 10 to make it look more like a smartphone.
[1] https://en.wikipedia.org/wiki/SimRefinery