depends whether you consider rootless Docker "cheap". I tried running ZeroClaw in a Nix-derived Docker (spoiler - it was a bad idea to use ZeroClaw at all since the harness is very buggy) and there is still a potential for container escape zero-days, but that's the best I've found. also, Nix's own containerization is not as hermetic as Docker; they warn about that in docs
we have a solution for that: GPL + commercial dual-licensing. the problem is that a) there is an entire anti-GPL crowd; although I'd just not give a shit about them, it's worth mentioning, b) who's gonna enforce the license?, c) how are you going to monetize internal use? what if your tech (e.g. a build system) is only really useful internally?
their landing page stops short of saying that Doublespeed would be "a good fit for your political campaign." I'd prefer fighting an AI-powered drone over becoming a victim of "Dead Internet-aaS" startup. at least, flying lawnmowers are honest
I have one of those 'flying lawnmowers' here and I'm not sure you would like to get up close and personal with them. They are super dangerous even when they are nominally under your control. But I agree with you that on the larger canvas the astroturfing will in spite of being more bloodless will do far more damage.
People are just not ready for being skeptical against this, they've barely gotten used to phone scams and now they have astroturfing and deepfakes to contend with.
Ugh, that sucks, I hope it was not a combat situation.
I've got a couple of them here mostly smaller ones (3", 5") and one large one (9") and I'm super respectful of those props and the ones here obviously don't have any kind of payload. Even so I'd hate to see one come at me, I've seen what they can do to pieces of hardwood.
no, it was not, I'm too young to get drafted :) although I'd argue that nowadays, the line between a civilian and a combatant is blurred more than ever. at least in Ukraine it's like that
it's a distinct piece of hardware based on AMD XDNA architecture, which, coincidentally, much like CPUs, can tap into your RAM pool. there are XDNA drivers (`amdxdna`) for Linux.
1. macOS and Windows require installation of Xcode and Visual Studio respectively, and if in Apple's case you kinda can install these tools headlessly and choose to install only the "build tools" package, Microsoft's creature is gonna daze and confuse you with a crap-ton of checkboxes and no easy "just install whatever is minimally needed to compile my code" button, and I don't recall if there is way to install build tools on Windows through terminal.
2. what is going to be distributed? source code itself or actual binaries? and what will the security model of Glaze store be? same as extensions, "everything is open-source and undergoes Raycast's and community review"?
3. Glaze is going to come to Windows and Linux, if we trust the Q&A section at the end. what will Glaze build upon? separate frameworks and languages for each platform or something multi-platform [1] like Tauri or Kotlin Multiplatform? or are you going to copy the Raycast extension model - just run Node, expose some platform integration, and parse React render trees through "Glaze Runtime"? I've been working on a bug in Vicinae [2][3], and I've seen this model in action. it's very hard to make it perform well, but all it takes to achieve native look and feel is to just map React render trees to whatever system component OS offers. (in Vicinae's case, it's Qt. bet that it's done with SwiftUI on macOS and WinUI 3 on Windows.)
[1]: there is a difference between "cross-platform" and "multi-platform". "cross-platform" means "I behave equally across platforms and have no awareness of native look and feel" (e.g. Electron, Unity, Flutter), while "multi-platform" means "I can adapt across platforms to the degree you need" (e.g. C/C++, Rust, KMP)
I think we can make assumptions for all of these. Raycast extensions aren't compiled code, and run within the Raycast runtime/engine. I'd bet that this is exactly the same.
In many ways that's the same as Chrome apps, they have no code, they're just the Chrome binary, so there aren't any code signing issues.
I am not that familiar with audio codecs, yet I think it's exciting if it means "music files will get smaller while keeping as much information". I keep ~50GB of FLAC music on desktop, but mostly I use MP3 320Kbps "mirror" of the music library, which is easier to sync to phone with Syncthing. the quality loss is... noticeable at best.
MP3 is a pretty bad codec compared to newer ones, no surprise that you noticed a quality drop. It should only be used for reasons of maximum compatibility.
I was using Ogg Vorbis 20 years ago, and that was a massive step up from MP3. Now, I have FLAC, and convert to 96k Opus for mobile and browser playback. Combined with listening in the car or through subpar headphones, I don't sweat about leaving a lot of quality behind, and the space savings are worth it.
so, this idea looks like follows: expose programmatic access to your program, which potentially operates in destructive manner (no Undo button) on potentially sensitive data; give a sloppy LLM (sloppy - due to its sheer unpredictability and ability to fuck up things a sober human with common sense never ever would) a Python interpreter; then let it run away with it and hope that your boundaries are enough to stop it at the edges YET don't limit the user too much?
reply