I think the article kind of tramples on its own point by showing a very long history of the changes to the Finder’s icon over the years, but I think what it’s trying to say is that it has been mostly unchanged for many years so it shouldn’t change now. It now has a gray box all the way around instead of two blue faces that go all the way to the edge. However, it simultaneously showed that it has been redesigned several times to match the aesthetic of the OS and while this is a larger change than most is still within the same design space.
The actual problem as explained in the first two paragraphs of TFA and shown in the first picture, is that the light and dark blue sides of the Finder icon have swapped sides. For the first time in its existence of many decades, the dark side is now on the right instead of the left. This is the problem.
I used to do aeropress or pour over coffee every morning but now I brew a large batch of hot coffee in a jar and then leave it on the counter overnight. The next day I remove the grinds and put the coffee in the fridge. Then on weekdays I just pour some over ice. It’s barely more work than making one pour over and I get 7 days of coffee with no prep work in the morning: delayed instant gratification all in one.
> There are amazing books out there but they are textbooks. 1000 pages long on a single subject, and people don't want that.
I would recommend to you, the author of the OP and others in this thread read “Amusing Ourselves to Death” by Neil Postman. It is old but it has had amazing sticking powe in my idea of what is entertainment and what is informational. He argues that many things are made to be entertainment (even some books that are thousands of pages) and challenges readers to consider this when deciding what to invest into. We can’t all be experts on everything so we make decisions, consciously and unconsciously about when and where to draw the line based on what information is available, how it’s presented and how much the value/work tradeoff is to study/consume it in that format.
I think the sting comes when we see people ignore low hanging fruit especially willfully but we would be less critical of someone saying that the task at hand is beyond their current capacity that someone else might be better suited to a particular task or topic.
I do enjoy dual-PK-certificate authentication in my homelab: one by equipment, and one by user/group.
Only misgiving is that the key management issues have worsen only for the key administrator(s). But it is a viable and sustainable AA model because there is the most important security component: instant denial of a user and/or a equupment.
Did I miss where an actual oval is explained in this method? I assume it is just drawing the same arc upside down but wanted to be sure there isn’t a follow up post or something.
Yeah, they're symmetrical. You use the three-center method doing isometric drawings by hand all the time. The second side is a mirror image of the first.
> Using smallpond and 3FS depends largely on your data size and infrastructure:
> Under 10TB: smallpond is likely unnecessary unless you have very specific distributed computing needs. A single-node DuckDB instance or simpler storage solutions will be simpler and possibly more performant.
> 10TB to 1PB: smallpond begins to shine. You'd set up a cluster with several nodes, leveraging 3FS or another fast storage backend to achieve rapid parallel processing.
> Over 1PB (Petabyte-Scale): smallpond and 3FS were explicitly designed to handle massive datasets. At this scale, you'd need to deploy a larger cluster with substantial infrastructure investments.
Makes it very easy to determine if this would be useful for me and how much work I would expect to do to use it.
IMO means “in my opinion.” I used that phrase to express how the following statement is my opinion and not a universal truth. My “audience” in this case is myself.
I do that because otherwise there’s always a comment saying how things like “obvious” can be subjective.
I also used the word “pretty” to, again, soften the word “obvious” so that readers don’t think that it’s a universal truth.
with some "no s, sherlock" on the ">1PB will require additional infra."
go on...
like people talking about 1gbit iSCSI, and no one thought to say that 120MB/s, which is technically slower than ATA/133 which came out twenty years ago, might be the bottleneck. Obviously 10gbit will be "as fast as a local drive"!
Yes, exactly right! This means you need to buy additional hardware, like network cards[0], and possibly gbic and fiber optics.
I had a Chinese co-worker and something like this was actually his style of writing, no use of AI, because I was sitting next to him few times when he was writing documents.
some was AI generated, but I made sure everything was accurate. I'd normally rewrite everything, but I wrote this quickly before I had to leave the house. Didn't think it'd be on the front page!
Yeah I reeeaaally want to see benchmarks! Single node duckdb is absolutely insane (as in fast) performance wise, especially compared to something like Spark. There's been a lot of speed focussed work in the project and I don't know of any faster data processing (I'm not counting traditional SQL since a lot of the speed benefits there come from indexing etc and essentially doing additional work ahead of time).
I guess it comes down to how well written the distributed workflows are, there's a lot to get wrong, but in theory it should be able to achieve very impressive numbers.
My reasoning behind this is Dask, which uses Pandas under the hood being capable of better benchmarks than Spark, I think this is partly some good optimisations, but also simply that pandas is faster than spark's row based model. Duckdb is on some benchmarks more than 10x faster than pandas, you can see where this is going. . .
Can you share more details about the conditions under which it is slow in recent versions? We moved from 3.x to 7 for our main database and after adding a few indexes we were missing we have seen at least an order of magnitude speed up.
As someone that has ran every version from 3.2 to 8 on small nodes and large clusters (~100+ nodes)...
8 is waaay faster in the real world. It's not really comparable. Your micro benchmark is comparing the few nanoseconds of the heavier query planner, but in the real world that query planner gives real benefits. Not to mention aggregations, memory management improvements, and improvements when your working set size is very large/larger than memory.
Thanks for the data! I think I may have different use cases than are covered by your benchmarks.
Do you often do that many independent $incs (or any query) in a single second? I have gotten much better performance by using `BulkWrite` to do a bunch of small updates in a batch.
To go to a specific example from the "Driver Benchmark" on the link from your first reply:
I notice in this specific example that there's no separation of the hashing from the query timing. so I might try to do the hashing first then time just the inserts. I would also a batch of `insertOne`s and then do a bulk write so I'm making much fewer queries. I will often pick some random size like 1,000 queries or so and do the `bulkWrite ` when I have accumulated that many queries, have surpassed some time (like if it has been more than 0.5s since the last update) or if there's no more items to process. Additionally if the order of the inserts doesn't matter using `ordered: false` can provide additional speedup.
For me the limiting factor is mostly around the performance of BulkWrite. I haven't hit any performance bottlenecks there that would merit benchmarking different ways to use it, but I would mostly be trying to fine tune things like how to group the items in a BulkWrite for optimal performance if I did.
Even in the case of one-off queries it almost always feels faster on 7+ than earlier versions. As I mentioned the one bottleneck we hit with migration was that we had some queries where we were querying on fields that were not properly indexed and in those cases performance tanked horribly to the point where some queries actually stopped working. However, once we added an index the queries were always faster than on the old version. When we did hit problems, it took only a few minutes to figure out what to index then everything was fine. We didn't have to make changes to our application or the queries themselves to fix any issues we had.
Again this microbenchark is useless. Don't pick databases this way. This is not the kind of operation you should be worrying about optimizing, it's not usually the bottleneck or what is slow.
Setup a clone of prod and build a tool to replay your traffic to it.
I have lots of data from datadog and ops manager but not going to take the time to publish ATM.
I just moved a 4tb deployment from 3.2 to 7. It cut max query time by about half. I actually went to instances with half the cpus, too (although I switched from ebs to ssds).
> Again this microbenchark is useless. Don't pick databases this way. This is not the kind of operation you should be worrying about optimizing, it's not usually the bottleneck or what is slow
It was for us. API calls that need to aggregate stats on same ID. We found a way around, but it would not have been an issue if MongoDB 8 was like 2x faster.
> I just moved a 4tb deployment from 3.2 to 7. It cut max query time by about half. I actually went to instances with half the cpus, too (although I switched from ebs to ssds).
Just single-core performance improvement in the last 10-year might explain your outperformance.
> Just single-core performance improvement in the last 10-year might explain your outperformance.
Nope, after migration max query time was still over a minute in some cases. What makes the biggest difference is performance tuning. After a week or so of index tuning, I got max index time below 6s. If Mongo makes each query take 2ms instead of 1ms, it literally doesn't matter to that customer or their customers, since it's just noise at that point. The old instances were M5s, so not that old.
The point is that the few nanoseconds difference you're measuring is not what you spend the most time on, usually.
Also you mentioned write performance. If you set journal commit interval to 500ms or something, then you can easily beat the old 3.2 write speeds, since if you're using 3.2 you probably don't care that much about journal commit intervals anyway ^_^
