I find that I rarely do one search. It’s usually a search, followed by looking at the first few links and probably opening them in tabs, then refining the search terms to get better results. It’s an iterative process. So the 10 per day on average would be exceeded quite quickly.
I too feel the yearly price of $108 for one person, $155 for two people and $216 for a family is expensive. Ok, maybe the family plan is cheaper if you can find five others to share it with.
Is Julia any good for general purpose (non-scientific) use? I guess it probably may not have as many libraries as Python. So what do the library and third party package coverage look like in comparison to languages like Python, Go, etc.?
Can you give an example of general purpose use? It's not great if you want to make a standalone program and distribute it to other users. It's awesome if you are doing exploratory stuff, quickly exploring different ideas or algorithms. The ecosystem has a lot of high quality stuff but where it lacks you can of course call out to python or R or other languages.
Lul. No. Everytime one of these "look how amazing Julia pots comes up", myself and many others do what we can to protect other people from wasting their time or their money from using it due to our personal experiences with it professionally or as hobbyists.
A bit weird writing style, and I don’t know if this is Substack or the lack of proofreading.
It quotes a problematic statement and then after one or two paragraphs, it says this:
> But here is an important thing that many people forget:
> There is no better productivity hack than a great culture. No AI tools will provide bigger productivity gains.
> I’ve unfortunately seen and heard this sentence quite a few times, either directly or from an engineer or engineering leader who has reported that to me.
So the problematic sentence is the one that talks about a great culture being the biggest productivity hack? I had to scroll up again and see what it was referring to.
I like the graphical interface and the movement of the blocks. Brings back memories of defragmenting hard drives once a month and seeing noticeable performance improvements sometimes.
> Fragmentation and extent allocation were adding measurable variance, even on NVMe,
Why exactly would there be a measurable variance on NVMe? I understand there could be some impact on magnetic hard drives. This sounds like some sort of coincidence due to other factors and that this defragmentation won’t achieve much (except for wearing out your SSD even faster in certain cases).
Yes: I discovered that tested performance on copper-rs a high performance OS for robotics when I run it on ext4 and what is annoying in robotics is the max latency & jitter. Especially that we allocate large slabs so this is not helping at all.
(fragmented relative to baseline)
bandwidth: 100.65 -> 94.74 MiB/s (-5.86%)
elapsed time: 339.550 -> 360.699 s (+6.23%)
mean latency: 9935.7 -> 10554.6 us (+6.23%)
p50 latency: 6715.2 -> 6838.9 us (+1.84%)
p95 latency: 19394.4 -> 20599.9 us (+6.22%)
p99 latency: 131498.2 -> 131988.3 us (+0.37%)
max latency: 183713.2 -> 624392.9 us (+239.87%)
jitter stddev: 17823.1 -> 19806.0 us (+11.13%)
jitter CV: 179.38 -> 187.65% (+4.61%)
Also check your nvme granularity with fstrim -D if you are on 4KB your nvme is so fine grain that it doesn't matter much but if it is 64KB like my main one. Ouch, those small files in the middle of the 64KB won't magically go away.
SSD still have slower reads when the data isn't sequential. Not slow enough to matter, especially with extents meaning the data is probably in a handful of locations, not 10000, but it's absolutely measurable if your blocks are small enough (<1MB typically, though disk benchmarks usually use 64KB random reads and sometimes 4KB).
It's more complex than that... Sequential reads are faster than random reads across most mediums (including system ram), but if there's enough prefetching, you might get better throughput on an SSD with the data fragmented than contiguous because SSDs can often read from multiple regions in parallel and contiguous data might not allow for that.
If you're at the point where you're optimizing for this, you've got some really high performance requirements though. And you'll have to do your own testing, because rules of thumb won't do.
Except most SSD also don't store pages sequentially internally (hidden flash wear leveling is even in microsd cards now), and the dram/SLC buffer areas are finite especially on low end budget hardware. Don't defrag your SSD dude. =3
Indeed, most Linux setups supporting trim, already defer these operations to a weekly schedule to reduce wear, and most fs will optimize in 10MB or 25MB chunks given unlike HDD... the SSD seeks are nearly constant time. Logging fs like f2fs, are content aware so will auto re-locate hot and cold (rarely modified) file types, and despite the log-structure... on an SSD performance losses are often surprisingly negligible.
Most modern NVMe with dram cache and SLC buffer areas also defer committing pages to low-endurance flash areas. And most kernel tweakers will set swapiness to 1 on SSD/NVMe machines to try to keep stuff buffered in dram as long as reasonably possible. It is a space-time tradeoff that can boost a desktop machine performance especially with preload daemon active.
If people want ludicrous speed... than just run ext4 with a separate 128GB journal NVMe drive on a split PCIe x4 bus.
Defrag on most modern drives usually just fills these buffer areas full, and things grind to the slowest i/o choke point. =3
My guess is that OpenAI now has a full blown Cursor equivalent in development (an expansion of Codex?) and will announce it in September. Otherwise it stands to lose those who are used to working with Cursor.
Yeah, the "go above and beyond for our users" implies they have a "better" version of Cursor coming. Probably integrating their new chip/microphone based product.
I have a lurking account and follow some other accounts, but I’m not interested in “liking” or “reposting” any posts. I want to keep my usage and engagement as low as possible. The “For You” feed doesn’t work for this need because it relies on signals like liking content.
I agree that the Discover feed sucks (why does it show posts from people I’m following when there’s a dedicated tab for that?). But I’d rather have a better Discover feed than me having to do more work on the “For You” feed.
'show more/less like this' should work[0] with cowboy's for you feed. 'more/less' was proprietary for discover but they've rolled it out to other feeds now[1].
I think it's part of an interactions object passed to the feed operator. You can see what's potentially passed here[2].
> Any call the agent makes to an external connector is reviewed by an LLM judge to prevent dangerous operations.
A few basic questions: how reliable is this judge since it’s based on an LLM? What additional measures can an admin or someone with more technical knowledge take to tighten this further if needed? Are the rules in or used by this judge visible to the users or an admin?
Maybe that's a hot take, but it's probably still safer than how things are often done in reality when employees want to "get something done" and sign up for random services, download their own software or other variants of shadow IT.
This posture is applicable while we ease out of what I'm calling the "golden era" (loose restrictions on access with limited consequence) but one of the reasons I am pedantic and bearish about solutions like this is that they too have a short lifespan that we can already estimate the expiration date of.
We assume LLMs can always be fooled, so the judge is just one step of the verification process. The deterministic layers, per-tool db roles, read-only-by-default integrations, query timeouts, are the ones an admin can configure. The judge's rules aren't exposed to admins today. I like your idea of letting admins add their own rules or knowledge to the judge, we should add that.
One of the core issue here is LLMs are probabilistic not deterministic, even with set of rules or context , llms are inherently built to make best guess, so my question is how you are ensuring that LLMs are following rules?
You're right, and we don't. The judge is best-effort screening not enforcement. Enforcement is deterministic with per-tool Postgres roles, proxy-injected creds, host allow-list, human approval on destructive writes. Those hold whether the judge is right or wrong.
It's not safe or reliable, no matter how hard you try. Fundamentally, agents will try whatever they can to achieve the goal, as we've seen in many recent security incidents.
If determinism is important, as it is in many business use cases, use agents to build the tool, but don't let them run it.
I built a similar product around this exact idea: AI builds the workflow. Fixed rules run it.
I too feel the yearly price of $108 for one person, $155 for two people and $216 for a family is expensive. Ok, maybe the family plan is cheaper if you can find five others to share it with.
reply