danudey
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).
(I'm not sure if that's true, but I hope so)
It might raise the cost for some scrapers, to some degree, but it raises the cost to, effectively, infinity for anyone who needs to use a screen reader, a browser's 'reader' view, or any other assistive technology.
Things like this just remind me of EA's Spore; it released with DRM so draconian that legitimate players were getting locked out of the game during the first week, while people who pirated the game had no problem whatsoever and were playing the game without issue even before its release. The legitimate users of the thing were the only ones punished by the technology designed to stop everyone but them.
This is going to be the same thing; a website which AI will be able to read in short order but which assistive technologies will not be able to read ever.
Part of the problem that people don't really realize is that it's not practical to just 'link against old glibc'.
In order to ensure compatibility with RHEL7 we need to link against RHEL7 libraries, which means we need to build on RHEL7. That means old, unpatched versions of glibc, libpcap, libcurl, openssl, or who knows what else, in case there's some backwards-incompatible change in newer RHEL versions.
Alternately, we can build/patch the libraries we use and compile them statically into the binary, which is vastly more maintenance work for us for very little benefit.
Meanwhile, compiling against older versions of libraries like glibc means we don't get the benefit of updates; not just new features in glibc, but things like more/better SIMD support in glibc algorithms, more/better optimizations in GCC, and so on.
Alternately, we can stop supporting RHEL7, like Redhat did, and build against RHEL8... Or we can build a separate version against each version of RHEL we want to support.
Funnily enough, we've been shipping RHEL7 RPMs of our product for years, and only recently realized that they won't actually run on RHEL7 because at some point the toolchain updated and now we're compiling against too new of a glibc version and then packaging it into a RHEL7 RPM. It wouldn't have worked on RHEL <8 for the past... few years? But no one uses RHEL7 so it went completely untested for ages and we didn't get any customer complaints.
Now we're re-labelling our RPMs as EL8, but it's just a cosmetic change so that we're claiming the version that we actually require.
IOW China almost definitely sees their own open-weight models as a pressure release valve to ensure the US AI companies, and by extension the US economy, doesn't get too big, and to ensure that these companies don't become the dominant global force (the way that e.g. US cloud companies did originally).
One small example is an extension for the `gh` cli where I give it a PR number and multiple branches and it cherry-picks that PR to those branches, or lets me know if some of the branches don't work. For managing multiple release branches it's very handy, but not so handy that I would have spent a lot of time and energy doing a good job of it.
This seems like a similar sort of thing - a user friendly way to do something that most people don't need, and most people who need it probably don't need it very badly.
I haven't used claude to replace my actual skills - researching, solving problems, etc. - but I do use it to replace all the stuff which is essentially 'spend a few hours reading API docs and writing boilerplate code'.
A fresh boot of my Windows 98 install at the time, once everything was loaded and settled, used up 27 MB of RAM, meaning that after 5 MB of allocations someone was getting paged out somewhere. That extra 16 MB made a world of difference.
Do bear in mind, though, that we're dealing with a lot more than we were back then. Our hardware is more complex, with more and more complex drivers needed to manage more things. Accessibility is different, screens are larger (my monitor now has 27 times the pixels as my monitor then) meaning more memory required for larger textures which are now composited in hardware rather than re-rendered every frame.
I agree with others that things are ridiculous these days, but it's also easy to see that our expectations also need to adjust somewhat. Still, using a webview for displaying the weather... I get why they do it, but it's a scourge. It's emblematic of their care for the customer, which is nonexistent.