I think VGT is a good QQQ replacement. It is based [1] on the MSCI US Investable Market Information Technology 25/50 Index which is free-float adjusted [2] [3], meaning that SpaceX will have a lower weight due to its lower free float. Also, VGT has a substantially lower expense ratio (9 bps / year [4]) than QQQ (18 bps / year [5]). You can compare VGT and QQQ's holdings on these pages [6] [7].
That's fantastic. Thanks! I actually use QQQM which has lower fees. Seems like Invesco pulled a trick from marketing and segmented the market to have it both ways. I also need to find leveraged ETFs that have float adjusted weights which is a bit trickier. I might just pull out of TQQQ until the dust settles.
No it’s not. When the asset management industry says “information technology” they exclude the technology used for communication. That’s why VGT doesn’t invest in GOOG or META. AMZN is consumer discretionary so it’s also excluded.
This reminds me of Vibe Kanban (https://vibekanban.com/) which I use to manage coding agents on most of my projects.
The Vibe Kanban developers unfortunately decided that they didn't see a path to profitability and have stopped investing in the project. It's open source and so you can run it locally / fork it, but it has stopped improving and there are still annoying bugs that need to be fixed (and I don't have time to maintain it personally). This makes me sad because I would be willing to pay for Vibe Kanban, but I didn't need the features their paid plan offered (in retrospect maybe I should have paid anyway).
I'll give Kanbots a go :) I'd recommend liberally copying features from Vibe Kanban. In particular the remote support and "Open in VS Code" button (which in my case opens a local VSCode client pointing to a remote VSCode server) are critical for me.
Vibe Kanban is indeed a treasure trove in terms of useful features.
I've been working for the last week or two on getting my new tool up to parity with VK with additional improvements. I've been posting some screenshots into the Vibe Kanban discord as well. Hopefully it'll be a great fit for your use case when I finally am ready to launch it.
(My tool aims for better features than VK in both the Kanban board and agent workspaces, while adding extra systems like desktop windowing, plugins, in-browser VSCode integration, and htmx-like server-rendered UI. The remote access also works differently - you host the whole thing like OpenClaw and access the remote desktop UI from the browser, rather than run a webserver on your laptop to access remote coding agents.)
You can also make ZIP files smaller by switching the compression from Deflate to Zstandard. In the one case I tried this, this resulted in a 60% file size decrease [1]. Unfortunately Info-ZIP which provides the unzip command hasn't had a release in 18 years, so it doesn't support this newer compression/decompression method. You have to use 7-Zip instead.
As far as I know, the ISO standard for zip only specifies two compression methods: "store" (no compression) and "deflate". If I follow that, when I create a zip file, I know it's not performant, but at least it's almost universal (except for file ownership, permissions, character encoding and anything modern).
The corporate PKWARE has added other compressions to their original zip software, but those are not in the standard. They will not work for an EPUB, a LibreOffice file, etc. If I want a good compression, I reach for zstd (often through `tar`) or 7z if I want more portability.
Oh thanks - I was waiting for a moment where I could turn up sound to watch the other video, but I didn't realise that that would set me back half an hour. This is the perfect amount of background for now!
> At the time of writing, the fix has not yet reached stable releases.
Why was this disclosed before the hole was patched in the stable release?
It's only been 18 days since the bug was reported to upstream, which is much shorter than typical vulnerability disclosure deadlines. The upstream commit (https://github.com/gnachman/iTerm2/commit/a9e745993c2e2cbb30...) has way less information than this blog post, so I think releasing this blog post now materially increases the chance that this will be exploited in the wild.
Update: The author was able to develop an exploit by prompting an LLM with just the upstream commit, but I still think this blog post raises the visibility of the vulnerability.
There exist some disclosure embargo exceptions when you believe the vulnerability is being used in wild or when the vulnerability fix is already released publicly (such as git commit), which makes it possible to produce exploit quickly. In this case it is preferred by the community to publish vulnerability.
My only caveat would be that in some security fixes, the pure code delta, is not always indicative of the full exploit method. But LLMs could interpolate from there depending on context.
> The author of iTerm2 initially didn’t consider it severe enough to warrant an immediate release, but they now seem to have reconsidered.
It's funny that we still have the same conversation about disclosure timelines. 18 days is plenty of time, the commit log is out there, etc.
The whole "responsible disclosure" thing is in response to people just publishing 0days, which itself was a response to vendors threatening researchers when vulns were directly reported.
It’s a wrong way to look at things. Just because CIA can know your location (if they want to), would you share live location to everyone on the internet?
LLM is a tool, but people still need to know — what where how.
Not sure if that's a great example. If there's a catastrophic vulnerability in a widely used tool, I'd sure like to know about it even if the patch is taking some time!
The problem with this is that the credible information "there's a bug in widely used tool x" will soon (if not already) be enough to trigger massive token expenditure of various others that will then also discover the bug, so this will often effectively amount to disclosure.
I guess the only winning move is to also start using AI to rapidly fix the bugs and have fast release cycles... Which of course has a host of other problems.
I think in the context of these it’s more of “we’ve discovered a bug” which gives you more information than “there is a bug”. The main difference in information being that the former implies not only there is a bug but that LLMs can find it.
If you're a random person on the Internet, I can indeed not do much with that information.
But if you're a security research lab that a competing lab can ballpark the funding of and the amount of projects they're working on (based on industry comparisons, past publications etc.), I think that can be a signal.
Wrong argument, since it's not just available to "the CIA" but every rando under the sun, people should be notified immediately if "tracking" them is possible and mitigation measures should become a common standard practice
There are many attackers that are just going to feed every commit of every project of interest to them into their LLMs and tell it "determine if this is patching an exploit and if so write the exploit". They don't need targeting clues. They're already watching everything coming out of
Do not make the mistake of modeling the attackers as "some guy in a basement with a laptop who decided just today to start attacking things". There are nation-state attackers. There are other attackers less funded than that but who still may not particularly blink at the plan I described above. Putting out the commit was sufficient to tell them even today exactly what the exploit was and the cheaper AI time gets the less targeting info they're going to need as the just grab everything.
I suggest modeling the attackers like a Dark Google. Think of them as well-funded, with lots of resources, and this is their day job, with dedicated teams and specialized positions and a codebase for exploits that they've been working on for years. They're not just some guy who wants to find an exploit maybe and needs huge hints about what commit might be an issue.
>Do not make the mistake of modeling the attackers as "some guy in a basement with a laptop who decided just today to start attacking things". There are nation-state attackers.
The parent's point is that if those capable attackers can exploit it anyway, doesn't mean it should be given on a silver platter to any script kiddie and guy in some basement with a laptop. The first have a much smaller target group than the latter.
> LLM is a tool, but people still need to know — what where how.
And the moment the commit lands upstream, they know what, where, and how.
The usual approach here is to backchannel patched versions to the distros and end users before the commit ever goes into upstream. Although obviously, this runs counter to some folks expectations about how open source releases work
So this bug just proves my thesis about shortening update windows.
You may need Claude Mythos to find a hard-to-discover bug in a 30-year-old open source codebase, but that bug will eventually be patched, and that patch will eventually hit the git repo. This lets smaller models rediscover the bug a lot more easily.
I won't be surprised if the window between a git commit and active port scans shrinks to hours or maybe even minutes in the next year or two.
This is where closed source SaaS has a crucial advantage. You don't get the changelog, and even if you did, it wouldn't be of much use to you after the fix is deployed to production.
"Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting."
Maybe they did get their models to test their pages, but they didn't tell their models to pretend that they're browsing on mobile using a 3G connection.
I think most people can speak faster than 120 WPM. For example this site says I speak at 343 WPM https://www.typingmaster.com/speech-speed-test/, and I self-measure 222 WPM on dense technical text.
I think (without having done extensive research) that some sort of Apple hardware is your best bet right now. Apple hasn’t raised RAM upgrade prices [1] (although to be fair their RAM upgrades were hugely inflated before the crunch) and their high memory bandwidth means they do inference faster than most consumer GPUs.
I have an M4 MacBook Air with 24 GB RAM and it doesn’t feel sufficient to run a substantial coding model (in addition to all my desktop apps). I’m thinking about upgrading to an M5 MacBook Pro with much more RAM, but I think the capabilities of cloud-hosted models will always run ahead of local models and it might never be that useful to do local inference. In the cloud you can run multiple models in parallel (e.g. to work on different problems in parallel) but locally you only have a fixed amount of memory bandwidth so running multiple model instances in parallel is slower.
[1] https://fund-docs.vanguard.com/F0958.pdf
[2] https://www.msci.com/indexes/documents/methodology/2_MSCI_25...
[3] https://www.msci.com/documents/10199/6bafd9e3-0474-f03b-16bd...
[4] https://investor.vanguard.com/investment-products/etfs/profi...
[5] https://www.invesco.com/qqq-etf/en/about.html
[6] https://stockanalysis.com/etf/vgt/holdings/
[7] https://stockanalysis.com/etf/qqq/holdings/
reply