iknownothow

I mentioned elsewhere that time taken for setting is also a major factor for why Portland cement is preferred.

Maintenance is probably less of a factor but it also depends on the use case. Take what I have to say with a grain of salt. Lime is a living material that slowly converts lime to limestone. For some use cases, the lime needs to be replenished often through applying lime wash on the plaster of external walls or wet interior walls.

As for load bearing walls or regular interior plaster walls I'm not sure there is much maintenance you can do and they are fairly durable.

As far as I know Portland cement sets faster and is a stronger but has a life span of decades and does not lend itself to be repaired or replenished.

I'd like to also convey some vibes I have about this topic as follows. Imagine having a 2 storey family home made of concrete that you want passed on for many generations. In 50-75 years, repairs/upgrades would require a lot of demolition as concrete with rebar is very strong. Much of the old material is trashed and hard to recycle. A similar house made of lime based products and some stone and wood would lend itself more easily for similar repairs and seamless upgrades and can maintain the same aesthetic look for longer. It feels like lime based products are appropriately strong and suitable for the smaller scale. The old material can be treated like any old dirt or rubble and is less polluting.

Sure but lime plaster can be used in bathrooms on the non shower walls as there's no running water but lots of moisture/humidity which leads to mold growth. As far as using it in the grout behind tiles, you may have a point.

I'm considering applying lime wash between the tiles regularly but not sure what the results will be.

It is not lime as in the fruit, it is lime as in the material (CaOH2). Lime the material is the binding agent in lime plasters. It is not likely to get washed away.

I'm not sure as I'm not a builder or plasterer and it does depend on the use case.

However I do know that some grout and some paints that say they are anti-mold contain Lime or calcium hydroxide as their primary anti-mold ingredient. I think pure Lime putty can be used as pointing material between bricks in humid basements. Lime plaster (lime mixed with sand) can also be used in bathrooms (with some considerations I am not familiar with). So, my best guess is that some mix of Lime can be used as grout. But I can't say for sure.

Something I plan on doing before this winter is to use Lime Wash. Take Lime (CaOH2 in powder form) and mix with water until it has milk like consistency and brush it on grout or on (white) bathroom walls. If it works, I expect it to be a yearly or quarterly ritual and not a one time solution.

EDIT: A fascinating historical material I recently learned about used in bathrooms is called Tadelakt [1] which uses Lime as one of its ingredients.

[1] https://en.wikipedia.org/wiki/Tadelakt

You are correct.

I'm not sure why I remember cement to be water proof. Its possible I infered from how its been used around me. I have seen cement very often used where water contact is expected (bathrooms etc). I have also seen brick walls plastered with an extra layer of cement as putty considered to be rain proof and any leaks were thought of as poor workmanship rather than poor material choice.

P.S. I'm not a builder. I've taken an interest in the topic a few months ago.

I forgot another important reason why Portland cement is preferred over lime these days. Lime takes a while to set (a few days?), cement sets faster.

For those not familiar, the secret ingredients are to do with the Lime Cycle [1]:

1) Quicklime/Slakedlime (Calcium Oxide, CaO)

2) Lime (Calcium Hydroxide, CaOH2)

3) Limestone (Calcium Carbonate, CaCO3)

To keep it simple, typically you start with Quicklime (CaO) and after construction you end up with some mix of all three and after hundreds of years, the masonry transitions to mostly Limestone with microscopic traces of the other two. The slow transition of the lime cycle upon exposure of the masonry to both air and water (rain) ends up making the structure "self healing" and "stronger over time".

Fun fact! Lime putty is anti-mold even in humid conditions because upon exposure to moisture, CaOH2 + H20 becomes too basic for mold to grow on.

Cement/Concrete (based on Portland cement) is water proof but Lime by itself is not. But Roman Concrete, made from Lime and mixing with ash or broken pottery or ceramics makes it water proof [2]. I beleive Roman concrete was used whenever contact with water was expected. Both concrete and Roman concrete have the same underlying chemistry (Pozzolanic reaction) to make them water proof [3].

The fascinating thing is that Lime is everywhere in ancient masonry. Lime is more breathable, workable and sustainable. The only thing is, it requires maintainance, which is why Portland cement has taken over the world.

Modern cement/concrete is amazing for large structures. I hope Lime makes a comeback soon at least partly as putty and for building smaller homes.

[1] https://en.wikipedia.org/wiki/Lime_(material)

[2] https://en.wikipedia.org/wiki/Roman_concrete

[3] https://en.wikipedia.org/wiki/Pozzolanic_activity#Reaction

Gotcha and thank you! So the encryption is happening on the OpenAI backend and the agent's clear-text output designated to the sub-agent never reaches local.

Which is a real problem since you can't intercept/monkey patch the ciphertext to decrypt it locally to be able see the clear-text since we don't have the encryption key/algo/salt. No hacking :(

Could someone explain to me where exactly the encryption is happening?

I assumed that the main agent makes calls to sub-agents locally. Does Codex work in such a way where the main agent makes calls to sub-agents in the backend (openai server) before reaching local?

Out of curiosity, can there not be something like a two party or N party veto? i.e. requiring a minimum of two or N parties to work together to veto?

The choice between just a single party having a veto power vs no party with veto powers seems a little black and white to me. Happy to be enlightened on the matter.

I just checked again. 16GB DDR5 (291 Euro) to 32GB (519 Euro). Seems right to me and does not match what you reported. Maybe they updated the website by the time I checked.

I checked the prices for 64GB DDR5. There's some variance based on brand/model but the average and trend seems more or less right. Did you happen to notice that it is about prices in the EU?

Thank you author Ian Mckay! This is one of those good hygiene conventions that save time by not having to think/worry each time buckets are named. As pointed out in the article, AWS seems to have made this part of their official naming conventions [1].

I'm excited for IaC code libraries like Terraform to incorporate this as their default behavior soon! The default behavior of Terraform and co is already to add a random hash suffix to the end of the bucket name to prevent such errors. This becoming standard practice in itself has saved me days in not having to convince others to use such strategies prior to automation.

[1] https://aws.amazon.com/blogs/aws/introducing-account-regiona...

Potential reasons I can think of for why they don't disallow name reuse:

a) AWS will need to maintain a database of all historical bucket names to know what to disallow. This is hard per region and even harder globally. Its easier to know what is currently in use rather know what has been used historically.

b) Even if they maintained a database of all historically used bucket names, then the latency to query if something exists in it may be large enough to be annoying during bucket creation process. Knowing AWS, they'll charge you for every 1000 requests for "checking if bucket name exists" :p

c) AWS builds many of its own services on S3 (as indicated in the article) and I can imagine there may be many of their internal services that just rely on existing behaviour i.e. allowing for re-creating the same bucket name.

I'd ask politely to refrain from such comments :)

This is not me criticising you. I totally understand the urge to say it. We're all thinking the thing you're thinking of. It takes effort not to give into it ;)

The reason I personally would refrain from making such comments is that they have the potential to end up as highest ranked comment. That would be a shame. Topic of S3 bucketsquatting is rather important and very interesting.

Please appreciate that this might well be the assasination of Franz Ferdinand of our generation, the event that set the wheels in motion for World War 1.

I urge everyone to lower the temperature. Not just in the comment section, but in real life and in your minds.

If you're on HN reading this, then you have above average influence. If you're working at Google, Meta, Tiktok, X, etc, today's the day you for you to act in service of humanity. Lower the temperature.

I agree, Databricks is one of many in the space. If S3 makes Databricks redundant, then they also make others like Databricks redundant too.

S3 has much bigger fish in its sight than the measely vector db space. If you see the subtle improvements in features of S3 in recent years, it is clear as day, at least to me, that they're going after the whale that is Databricks. And they're doing it the best way possible - slowly and silently eating away at their moat.

AWS Athena hasn't received as much love for some reason. In the next two years I expect major updates and/or improvements. They should kill off Redshift.

I just did a wget of the site and noticed the following line at the end.

> <script async src="https://www.googletagmanager.com/gtag/js?xxxxxxx"></script>

I am going to use this for sure, but it is a little ironic.

I'd say that's where we're headed. A big model that's trained from the start to use tools and know when to use certain tools and how to use tools. Like us :)

I wouldn't be surprised if someone's building a dataset for tool use examples.

The newer gen reasoning models are especially good at knowing when to do web search. I imagine they'll slowly get better at other tools.

At current levels of performance, LLMs having the ability to get well curated information by themselves would increase their scores by a lot.

To be fair, I'd put finding literal string diffs in the category of asking LLMs to do rote arithmetic.

The attention mechanism does far too much complex thinking for such a dumb task. This is precisely where you need to dumb down and focus and be disciplined rather than do high level next token prediction.

You'd benefit from actually asking the LLM to list the full document and compare, kind of like reasoning, and similar to how LLMs perform better when they break down arithmetic or algebra tasks into smaller steps.

Also my guess would be that the models that perform well are MoE models where there may be an Expert or two that does well on tasks that needs focus rather than intuition. So without knowing anything about Gemini Flash, my guess would be that it's an MoE model.

As far as I can tell, the paper covers text documents only. Therefore your example doesn't quite apply.

It is well known that LLMs have a ways to go when it comes to processing images like they process text or audio.

I don't think there's any good performing multimodal model that accepts image pixels directly. Most vision capabilities are hacks or engineered in. An image undergoes several processing steps and each processor's outputs are fed to the transformer as tokens. This may happen in one network but there's non-transformer networks involved. Examples of preprocessing:

* OCR * CNNs (2D pattern recognizers) with different zooms, angles, slices etc * Others maybe too?

> Log-linear attention replaces the fixed-size hidden state with a logarithmically growing set of hidden states

Does this mean the models can be smaller too (on top of the primary benefit of being faster)?

That's fair. I care about the end result.

The problem is about taking information in 2D/3D space and solving the problem. Humans solve these things through vision. LLMs or AI can do it using another algorithm and internal representation that's way better.

I spent a long time thinking about how to solve the ARC AGI 2 puzzles "if I were an LLM" and I just couldn't think of a non-hacky way.

People who're blind use braille or touch to extract 2D/3D information. I don't know how blind people represent 2D/3D info once it's in their brain.

Don't take this the wrong way, your opinion is also vibes.

Let's ground that a bit.

Have a look at ARC AGI 1 challenge/benchmark. Solve a problem or two yourself. Know that ARC AGI 1 is practically solved by a few LLMs as of Q1 2025.

Then have a look at the ARC AGI 2 challenge. Solve a problem or two yourself. Note that as of today, it is unsolved by LLMs.

Then observe that the "difficulty" of ARC AGI 1 and 2 for a human are relatively the same but challenge 2 is much harder for LLMs than 1.

ARC AGI 2 is going to be solved *within* 12 months (my bet is on 6 months). If it's not, I'll never post about AI on HN again.

There's only one problem to solve, i.e. "how to make LLMs truly see like humans do". Right now, any vision based features that the models exhibit comes from maximizing the use of engineering (i.e. applying CNNs on image slices, chunks, maybe zooming and applying ocr, vector search etc), it isn't vision like ours and isn't a native feature for these models.

Once that's solved, then LLMs or new Algo will be able to use a computer perfectly by feeding it screen capture. End of white collar jobs 2-5 years after (as we know it).

Edit - added "(as we know it)". And fixed missing word.

Thanks for the reply and apologies for the general cynicism. It's not lost on me that it's people like you that build tools that make the work tick. I'm just a loud potential customer and I'm just forwarding the frustration that I have with my own customers onto you :)

Your customers are software devs like me. When we're in control of generating timestamps, we know we must use standard ISO formatting.

However, what do I do when my customers give me access to an S3 bucket with 1 billion timestamps in an arbitrary (yet decipherable) format?

In the GitHub issue you seem to have undergone an evolution from purity to pragmatism. I support this 100%.

What I've also noticed is that you seem to try to find grounding or motivation for "where to draw the line" from what's already been done in Temporal or Python stdlib etc. This is where I'd like to challenge your intuitions and ask you instead to open the flood gates and accept any format that is theoretically sensible under ISO format.

Why? The damage has already been done. Any format you can think of, already exists out there. You just haven't realized it yet.

You know who has accepted this? Pandas devs (I assume, I don't them). The following are legitimate timestamps under Pandas (22.2.x):

* 2025-03-30T (nope, not a typo)

* 2025-03-30T01 (HH)

* 2025-03-30 01 (same as above)

* 2025-03-30 01 (two or more spaces is also acceptable)

In my opinion Pandas doesn't go far enough. Here's an example from real customer data I've seen in the past that Pandas doesn't parse.

* 2025-03-30+00:00 (this is very sensible in my opinion. Unless there's a deeper theoretical regex pattern conflicts with other parts of the ISO format)

Here's an example that isn't decipherable under a flexible ISO interpretation and shouldn't be supported.

* 2025-30-03 (theoretically you can infer that 30 is a day, and 03 is month. BUT you shouldn't accept this. Pandas used to allow such things. I believe they no longer do)

I understand writing these flexible regexes or if-else statements will hurt your benchmarks and will be painful to maintain. Maybe release them under an new call like `parse_best_effort` (or even `youre_welcome`) and document pitfalls and performance degradation. Trust me, I'd rather use a reliable generic but slow parser than spend hours writing a write a god awful regex that I will only use once (I've spent literal weeks writing regexes and fixes in the last decade).

Pandas has been around since 2012 dealing with customer data. They have seen it all and you can learn a lot from them. ISOs and RFCs when it comes to timestamps don't mean squat. If possible try to make Whenever useful rather than fast or pure. I'd rather use a slimmer faster alternative to pandas for parsing Timestamps if one is available but there aren't any at the moment.

If time permits I'll try to compile a non exhaustive list of real world timestamp formats and post in the issue.

Thank you for your work!

P.S. seeing BurntSushi in the GitHub issue gives me imposter syndrome :)

I've read the link and the GitHub readme page.

I'm sure I'm in the top 1% of software devs for the most number of timestamps parsed. [1]

DST is not a problem in Python. It's parsing string timestamps. All libraries are bad, including this one, except Pandas. Pandas does great at DST too btw.

And I'm not shilling for Pandas either. I'm a Polars user who helicopters Pandas in whenever there's a timestamp that needs to be parsed.

Pandas has great defaults. Here's string timestamps I expect to be paesed by default. I'm willing to pass timezone in case of naive timestamps:

* All ISO 8601 formats and all its weird mutant children that differ by a tiny bit.

* 2025-05-01 (parsed not as date, but as timestamp)

* 2025-05-01 00:00:00 (or 00.0 or 00.000 or 0.000000 etc)

* 2025-05-01 00:00:00z (or uppercase Z or 00.0z or 00.000z or 0.000000z)

* 2025-05-01 00:00:00+02:00 (I don't need this converted to some time zone. Store offset if you must or convert to UTC. It should be comparable to other non naive timestamps).

* 2025-03-30 02:30:00+02:00 (This is a non existent timestamp wrt European DST but a legitimate timestamp in timestamp representation, therefore it should be allowed unless I specify CET or Europe/Berlin whatever)

* There's other timestamps formats that are non standard but are obvious. Allow for a Boolean parameter called accept_sensible_string_parsing and then parse the following:

  \* 2025-05-01 00:00 (HH:mm format)

  \* 2025-05-01 00:00+01:00 (HH:mm format)

[1] It's not a real statistic, it's just that I work with a lot of time series and customer data.

Disclaimer: I'm on the phone and on the couch so I wasn't able to test the lib for its string parsing before posting this comment.

Is there a terminology battle happening in some circles? And if so, what are the consequences of being wrong and using the wrong terminology?

I follow the rnd and progress in this space and I haven't heard anyone make a fuss about it. They are all LLMs or transformers or neural nets but they can be trained or optimized to do different things. For sure, there's terms like Reasoning models or Chat models or Instruct models and yes they're all LLMs.

But you can now start combining them to have hybrid models too. Are Omni models that handle audio and visual data still "language" models? This question is interesting in its own right for many reasons, but not to justify or bemoan the use of term LLM.

LLM is a good term, it's a cultural term too. If you start getting pedantic, you'll miss the bigger picture and possibly even the singularity ;)

How does it compare with s5cmd [1]? s5cmd is my goto tool for fast s3 sync and they have the following at the top of their Github page:

> For uploads, s5cmd is 32x faster than s3cmd and 12x faster than aws-cli. For downloads, s5cmd can saturate a 40Gbps link (~4.3 GB/s), whereas s3cmd and aws-cli can only reach 85 MB/s and 375 MB/s respectively.

[1] https://github.com/peak/s5cmd

I've been inadvertently working on this topic and I'd like to share some findings.

* Do not confuse bots with DDoS. While bot traffic may end up overwhelming your server, your DDoS SaaS will not stop that traffic unless you have some kind of bot protection enabled, for example the product described in post.

* A lot of bots announce themselves via user agents, some don't.

* If you're running an ecom shop with a lot of product pages, expect a large portion of traffic to be bots and scrapers. In our case it was upto 50%, which was surprising.

* Some bots accept cookies and these skew your product analytics.

* We enabled automatic bot protection and a of lot our third party integrations ended up being marked as bots and their traffic was blocked. We eventually turned that off.

* (EDIT) Any sophisticated self implemented bot protection isn't worth the effort for most companies out there. But I have to admit, it's very exciting to think about all the ways to block bots.

What's our current status? We've enabled monitoring to keep a look out for DDoS attempts but we're taking the hit on bot traffic. The data on our the website isn't really private info, except maybe pricing, and we're really unsure how to think about the new AI bots scraping this information. ChatGPT already gives a summary of what our company does. We don't know if that's a good thing or not. Would be happy to hear anyone's thoughts on how to think about this topic.