From their page:

"Additional apps. HomeView supports compatible third-party audio and video apps from your iPhone for a familiar experience across devices"

This implies that Plexamp could be supported, and possibly Messenger and Snapchat calls, but it's too early to tell.

> My house has a bunch of spots on the wall where an old intercom system used to live: it'd obviously be a budget buster to buy a bunch of these to fit in those slots but even if you did, you'd need Apple to provide an intercom solution (a la the Watch's Walkie-Talkie?) or you're...out of luck.

Apple Home already provides this. It's not a full voice chat, but you can tap a thing and say something and it'll broadcast it to the rest of the house; in my case, that's two HomePods Mini, but it's easy to assume it will include this as well.

If you're just looking to say "Hey kids, dinner's ready" or "We have to leave in 15 minutes" to the entire house then that circumstance is handled already; if you want to have a back-and-forth conversation with someone in another room, though, it doesn't do that (yet?).

I actually created a separate golang library with something like this in mind: https://github.com/danudey/ansipants

The original idea I had being that CI environments, or anywhere that shows terminal output, could use a streaming ANSI parsing library to detect when a program sent a 'change window title' OSC event and then start a new collapsable section in its output. This would let programs update the actual terminal window title with its current state when running locally and update the CI interface when running in CI.

Adding in the ability to specify the program's current status and (optionally) progress could be extremely useful in CI environments as well. Imagine, for example, a long-running analysis task which uses OSC 7501 to say that it's currently running and is 75% of the way done. CI could expose that in the UI to provide useful information to the end-user without having to print a progress bar or multiple progress lines to the fake terminal it's being run in.

More importantly, they want to build an ecosystem around their ecosystem around k8s. They want people publishing their software to work on OpenShift (e.g. in the operator catalog), they have certification processes for software compatibility (e.g. CNI certification), and now that they've come as far as they have they're going after VMWare's lunch, madly scooping up every customer they can get their hands on to try to offer them a user-friendly kubevirt implementation to replace VMWare (and NSX).

If OpenShift was close to k8s then there wouldn't be enough differentiation between the two to make it worth the money so they're building out everything they think that execs and overworked infra teams will be willing to pay for to make k8s migration a workable option (rather than an internal migration project that stagnates and drags on for ten years).

OCP is just RHEL but for Kubernetes, and RHEL has done pretty well over the years all in all. RHEL is "just Linux", but it's "just Linux" with a bunch of RHEL-specific stuff in it and on top of it, and RHEL-specific policies around it, such that you can buy something from a software or hardware vendor that works with and is tested on RHEL and you know it'll work with your systems.

The goal is the same; company sells this software/solution, it runs on OpenShift v4.xx and up; you need RH's mesh and virt operators installed and configured, and then you can install our operator for our software and you're done. Now your whatever, database or CMS or whatever it is, just works. You don't have to customize the charts or define your own ingress gateway, it's all handled already if your system is set up properly. Then you get the meta-control panel that lets you see and manage all of your clusters and etc., so you can get a higher-level view, etc. etc.

They want vendor lock-in to an extent, but they've seen that what customers want isn't "Linux", it's a Linux distribution that gives them enterprise reliability (read: never getting new versions of stuff, only security patches) and compatibility guarantees from vendors. They're just trying to do the same thing with kubernetes. Will it work? Seems like it's going okay so far, I guess we'll see.

In reality, the article is about correctly caching a path:policy mapping while working within the limitations of eBPF and Linux filesystem semantics. If you read the article in that context rather than wondering 'what is new and interesting about memoization in eBPF?' it's a lot more interesting.

I probably would have titled this 'Calculating cache keys for filesystem paths in eBPF' or something, since that's the cool and interesting problem that was solved.

btrfs ended up being basically a consumer version of a few of ZFS's most visible features - transparent compression, subvolumes, and copy-on-write - which then farms out the other most useful features - RAID + volume management + encryption - to the existing tooling. Makes sense for a smaller-scale project, no shade, but it definitely misses the mark if you've spent time on ZFS systems taking advantage of what ZFS has to offer (like recursive snapshots or vdevs).

My current vacuum is a V15, and I like it a lot. It was expensive (and a gift), but it's very effective, has a lot of attachments to make it easier to clean upholstery/the carpet/a computer/drawers/hardwood/the window frames/whatever, comes with a wall mount that the cable connects to so you can just put it in the mount and it charges. The one issue I had seems to be a relatively well-understood issue with the electronics, which resulted in me having to spend another $100+ on a new housing - the electronics + motor + LCD screen + etc., basically the whole 'vacuum' part of the vacuum. Given how well it's treated my so far, though, I'm not too miffed.

Our last vacuum (which we still have) was a Miele, and while it was also fantastic it was far more of a pain in the ass since it's a plug-in with a bag vs. a cordless canister. The quality is similar, I think the Dyson is a bit better, but I use it exclusively because it's far easier to go get it, vacuum up a spill, and put it back. I know that's more of a comparison between canister and bag vaccums, but the fact that they're around as effective despite the dyson being a canister is I think a point in its favor.

Whether all of their stuff is as good, or only the more expensive stuff, I can't say.

My feedback:

1. It works great. I had to empty it several times because it was picking up so much more stuff than our existing vacuum did - mostly pet hair and the like.

2. It's the one with the little laser thing, which is a dumb little gimmick until you see it in action and then it's life-changing - if you're like me and find satisfaction in picking up every invisible crumb anywhere.

3. After a year and a bit, maybe less, it started misbehaving. It would suddenly turn off, then you'd have to let go of the trigger and pull it again; then it would work fine. Then it would happen a few times until it worked fine. Then it almost never worked fine. I kind of tolerated it for a while until I got fed up and googled the problem, and it was suggested to buy a new housing - the electronics plus the motor, basically the whole 'vacuum' part of the vacuum, which was only just over a hundred dollars direct from Dyson. Irritating to have to spend an extra hundred bucks to get my five hundred dollar vacuum working as expectred, but expected it to cost far more.

Would I recommend it? Not sure. It's very expensive, it works very well; it has a nice wall mount that charges it and which holds a small subset of the attachments it comes with. I'm glad I have it and I use it often.

Yes, it's plastic, but if it were, for example, steel or aluminium then it would be too heavy to use for any length of time. As it is, it feels very sturdy and has held up physically very well, but I'm obviously also not rough with it so there's no reason it would have any issues unless it were, in fact, cheaply or poorly made.

Having steam depend on those libraries directly means that when you install you get all the libraries you'll need and you won't run into issues later on when you go to run a 32-bit game and it can't load the appropriate 32-bit system libraries for you. It's annoying for sure but it simplifies the user experience dramatically (especially if you're just installing Steam directly on Ubuntu or something).

Does my web browser feel slow because of pointer indirection or virtual function calls? Or is it because I have to download 15 MB of Javascript to load this page, which then goes out to 35 other domains to fetch other Javascript and ads and CSS?

In the insanely tight compute loop that he's looking at all of those things definitely make a difference, but a lot of software is slow not because it's inefficiently written (which it probably is) but because it's inefficiently designed and it's doing too much.

In a game engine, where you have 16ms to do 100% of your simulation work, update all your state, and then send all the data out to be rendered, definitely this sort of thing is an issue. In an Electron app? There are a thousand other things that are wasting far more of your time and responsiveness than the misguided 'cleanliness' of your code.

It's not impossible, but I feel as though if Trump decides that China is friends and Taiwan is enemies (as he seems to have done with North/South Korea lately) then Taiwanese refugees might not be as eager to move to the US as, say, Canada, Australia, or Europe.

Outside was too bright for me to see my laptop screen even at full brightness, but by the time I had it outside and had discovered that my phone had overheated so much it refused to turn on until it cooled down.

At least my drink was still cold.

I understand why, mind you; would VS Code or Slack have as much velocity of improvement if they had to individually manage GUI toolkits for each platform? Would VS Code be as extensible if the UI were built in Swift or Qt?o But the results are still there.

There are projects to try to make this /better/, like Tauri - Electron but using your system's built-in browser engine rather than shipping a new one, so that you don't have to have eight separate copies of Chromium loaded into memory - but they still need to reach feature-completeness and projects need to do a non-trivial migration, and then they need to test across multiple browser engines, etc., so it's still not the same.

Regardless, this is the situation we have right now; everyone figured that RAM capacity would continue to increase at the same rate as RAM usage, "it works on my machine" but it's a 32 GB Macbook, Chromium optimized for performance and not memory usage by assuming that each 'page load' would be short lived (browser behavior) rather than having one 'page load' run for hours or days (Slack, VS Code, Spotify).