0-100˚F lines up well with weather ranges, and 1˚F is about the smallest diff someone can feel. Many digital thermostats use integer ˚F and introduce 0.5 steps if you switch to ˚C, even in countries where ˚C is default, so they kinda admit it.
Pounds vs kg, similar story as F vs C. Pound is pretty much the human-discernible granularity. Otherwise doesn't matter.
0-100 MPH lines up well with car speeds, which is usually the thing you're measuring with that. KPH is excessively granular for that. Probably not by design, but yeah.
The feet/inches vs meters/cm thing matters less. It's base-12 vs base-10. You can do decimal feet or fractional meters of course, but it's less common, so apparently both ways are fine.
As a Canadian I have no idea what 72˚F means or feels like: is it warm or cold? I do know what 22˚C feels like and how to dress for it. How "intuitive" a temperature number is completely learned behaviour and cultural acclimation.
Pounds vs kg: see above. All the non-American people seem to have "intuitive" grasp of metric measurements.
> 0-100 MPH lines up well with car speeds, which is usually the thing you're measuring with that. KPH is excessively granular for that. Probably not by design, but yeah.
So 'more granularity' is good for temperature but not for speed. Got it.
> The feet/inches vs meters/cm thing matters less. It's base-12 vs base-10. You can do decimal feet or fractional meters of course, but it's less common, so apparently both ways are fine.
By "foot" do you mean 'regular' foot or survey foot:
Because there are two different units in the US customary system, used for basically the same purpose, that use the same name. And the "foot" isn't the only unit like that:
Here's another one: which weighs more, a pound of feathers or a pound of gold? A pound of feathers. Because feathers use one 'pound-system' [1] and is 453g, while gold uses another pound-system [2] and is 373g. But of course an "ounce" of gold (31g) is more than an "ounce" of feathers (28g), because Troy is 1/12 of pound but Avoirdupois is 1/16. In addition to the above "ounces" there is also "fluid ounces".
I didn't say it's about being used to one. It can be "in the 20s" C for multiple months, kinda silly. 22.0˚C also feels different from 22.5˚C. There's a right amount of granularity for temperature and for speed.
Foot and pound have unambiguous meanings in the US. There's a reason the whole survey foot and gold-pound thing is trivia that nobody knows, they're niche or abandoned systems that you only use if you're being clear that it's not regular feet or pounds. I also know that the US system is technically not "imperial," but nobody cares.
I'm not the person you were replying to, but I can answer this one. And yeah, I can see all the metric fanboys (a very small subset of metric users, mind you) hovering over that downvote button, but I don't get paid in Internet points so here goes:
The nice thing about imperial (as well as the customary system used in the US) is that it's based on measurements that people have found useful over thousands of years. They're human units, adapted to what people need to do with them, not the other way around.
It's difficult to explain to metric folks because it's really something you have to experience. But here's an example:
Reservoir volume in the US is measured in acre-inches. An acre is a unit of area used for measuring property, usually farmland. It's a bit less than half of a hectare. And of course an inch is 2.4cm. Acre-inches sounds totally bizarre when you first hear about it. But for the people that need to work with this value, it's an extremely useful way to measure reservoirs and gives you an intuition that you just don't get from cubic meters.
It's true that you can't just convert that to other units of volume without doing some math or looking up the conversion rate, but that rarely matters. If you're trying to figure out how fast the lake will rise or fall with a given inflow and outflow, you're going to have to have some way to account for the fact that the lake is a) an irregular shape and b) takes up more area the higher the water gets. You already need to know the area of the lake at any particular height to work out the evaporation rate anyway, so that's a number you're going to have. The units are designed to make that calculation easier, which was really important back in the days when slide rules were the state of the art.
All the customary units are like this in one way or another. They're units designed for a particular domain, and when used in their domain they work very well and calculations can be done in your head. They use fractions because that's what people have historically used (seriously - my grandfather could work fractions in his head faster than I could type them into a calculator, and he made asphalt for a living. Imagine what a carpenter could do.).
Think about it. Imagine you were never taught a measurement system. You find yourself needing to come up with a unit to make measurements for wooden planks you're going to use to build a house. Would you choose a unit as long as a meter? Or one as short as a centimeter or even a decimeter?
Bonus challenge to the fine folks clicking that downvote button: give me a real practical reason to prefer Celsius to Fahrenheit, besides the fact that Celsius is part of the metric system. No, the freezing and boiling points of water don't cut it - I work with hydrocarbon fuels, I salt my driveway and patio, I don't live at sea level, and quite honestly every American 8-year-old can spout off 32° and 212°. There's a Fahrenheit equivalent to Kelvin (Rankine) so the Kelvin to Celsius equivalence doesn't count either. My claim is that both scales are completely arbitrary, and only advantage one has over the other is that you're used to one of them. Go ahead, prove me wrong!
> Reservoir volume in the US is measured in acre-inches.
Never heard of an acre-inch before, and I'd have to get out a calculator to work out how much water that actually is in pints or gallons, or how much it weighs.
The metric equivalent would be a hectare-meter or a hectare-mm. I know a hectare is 100 m x 100 m, so 10,000 m². So I instantly know that a hectare-meter is 10,000 m³ (10 ML, or 10,000 tonnes of fresh water). A hectare-mm is 10 m³ (10 kL). If my 1 ha block gets 1 mm of rain, then that's 10 kL or 10 tonnes of water. So easy i can do it in my head.
I only know of it because it's a unit used by the US Army Corps of Engineers, who maintain the local reservoir. A buddy of mine's dad worked for them when I was a kid so that lake was my stomping ground.
A couple more to add to your list: an inch is about as long as your thumb joint (with some variation between individuals obviously). It's an easy way to gauge the size of everyday objects without needing to carry around a tape measure.
The recommendation for emergency supplies is about a gallon of water per person per day - or 3.7 liters if you're using metric.
I've also heard it claimed that the 0-100 Fahrenheit scale is more functionally useful because the endpoints of 0 and 100 represent the tipping point of serious danger for humans from hot or cold weather. The closer you get to 100 degrees the more care you need to take about heat stroke and keeping hydrated, and similarly the closer you get to 0 degrees the more care you need to take about retaining heat and staying out of the elements - the freezing and boiling point of water isn't a necessary marker for survival. And people like nice round numbers to serve as markers for such things, divisibility be damned.
Metric is sterile and functional for calculation and consistency, which is fine and necessary for many things, but that's not a reason to completely ditch Imperial.
> The nice thing about imperial (as well as the customary system used in the US) is that it's based on measurements that people have found useful over thousands of years. They're human units, adapted to what people need to do with them, not the other way around.
US customary is not "thousands" of years; temperature (Fahrenheit) only came out in 1724 for example, and many other units were only standardize much more recently:
Second, even with-in the system itself there was also sorts of inconsistencies. Until just a few years ago there were two "foot" units; one was recently retired:
Here's another one: which weighs more, a pound of feathers or a pound of gold? A pound of feathers. Because feathers use one 'pound-system' [1] and is 453g, while gold uses another pound-system [2] and is 373g. But of course an "ounce" of gold (31g) is more than an "ounce" of feathers (28g), because Troy is 1/12 of pound but Avoirdupois is 1/16. In addition to the above "ounces" there is also "fluid ounces". And let's not forget about the third system [3], which got replaced by… the metric system in 1971.[4]
> Think about it. Imagine you were never taught a measurement system. You find yourself needing to come up with a unit to make measurements for wooden planks you're going to use to build a house. Would you choose a unit as long as a meter? Or one as short as a centimeter or even a decimeter?
Millimeters. That single unit gets you down to very small scales (finer than 1/16") and to large lengths: four significant digits (9999mm) gets you to the equivalent of >32' (~11yd).
You misunderstood me. It's based on measurements that people have been using for thousands of years. The Romans had feet and miles, for example - not exactly the same lengths, but for the same purposes. The Japanese shaku is almost exactly the same as a US foot. A Japanese Shō is about half a gallon. A Chinese jīn is just slightly larger than a pound. There's a reason for this.
> there was also sorts of inconsistencies
I never claimed otherwise. But do notice that the survey foot and standard foot weren't used for the same purposes, and the difference between them wasn't likely to confuse anyone except maybe people new to the field.
> Here's another one: which weighs more, a pound of feathers or a pound of gold?
Yep, Troy weights. And no one's sure where the Troy system came from. The main reason for its use is because of international trade. Also not something regular people (i.e. people that didn't work directly with precious metals) would have had contact with.
> Millimeters
Hah! Yeah right. Look at all the various non-metric systems that have existed throughout history. Did any of them use something like millimeters to measure wooden planks? Why not?
> As evidence for this Australia/NZ/EU do everything in millimetres in construction.
They do it because the metric system is mandated there and it doesn't give you reasonably sized unit for that scale of work.
Try this: go to a home center (or whatever it's called there - the place you buy building supplies) and measure some drywall. Do the measurements you made agree to the advertised ones within half a millimeter? Compare the dimensions of drywall sheets from different pallets and manufacturers. Do their dimensions agree to within half a millimeter? If not, that's a sure sign you're using units poorly adapted for purpose.
The issue might be Root CA vs intermediates. The root CA that eMudhra rolls upto may be used for other intermediates which were not compromised or revoked. Removing the root CA will mean that these valid certificates no longer work.
This is technically a problem in the CLI - it needs to support revocations properly, not rely on root CA verification only. I’m not sure though whether there’s a standardised mechanism (that Apple supports) for CLIs.
> These steps affect every tool that uses /etc/ssl/cert.pem. Afterward, tools that use only this file might not be able to verify some websites whose certificates chain to these root CA certificates through intermediate CAs that weren't affected.
In pracitce, those root CAs have already been removed in major browsers. If your server uses them, you would likely have needed to migrate to another root already.
Apple’s own security framework is supported by curl with OpenSSL or GnuTLS (build with ./configure --with-apple-sectrust). That blocks the intermediate certificates via the same mechanism Safari uses for example.
Not sure why macOS doesn’t ship such a build of curl.
I think it’s possible to add intermediate certificates with distrust marker attributes to bundles with OpenSSL. But other libraries consuming the bundle would not understand it, so the problem remains.
Being pedantic, the risk/benefit of remote perspectives are theoretical and dependent on the destination network also having multiple independent links. Otherwise any “uplink” ISPs are all SPoF regardless of anything Let’s Encrypt does because the traffic must traverse them to get to the destination.
But remote perspectives are still worth doing, Let’s Encrypt should not be the “less diverse” than the infrastructure of their typical certificate requestor.
Sure, if you can MitM the connection to a single-homed destination network, you can get Let's Encrypt to sign you certificates for things in that network, regardless of how many perspectives Let's Encrypt uses.
However, if you can MitM the uplinks at all of Let's Encrypt's perspectives, you can basically break the entire CA for everyone. Adding more perspectives reduces the risk of that.
> Domain Validated (DV) certificates are the least-identity-validated SSL certificates and can be obtained quickly and easily—even by a malicious bot. These certificates are low-cost certificates that only require validation that a company or person can demonstrate control over a web domain for which they want to secure a certificate.
This is arguably a flaw in allowing DV certs at all, but given that it's there, LE doing this raises the bar for spoofing about as far as it can be raised.
That's a bit of an exaggeration. Domain-validated certificates already existed, and were fairly commonplace, before Let's Encrypt. What was different about LE was that their certificates were free.
Let's not forget that it was mostly a manual process for most of us. Someone would obtain a cert, and email it to you, along with the private key. I'm sure old JIRA tickets would have so many "encrypted" zip files containing RSA 2048 keys and leaf certificates valid from 2008 to 2011.
Most independent site owners couldn't obtain an EV certificate even if they wanted to - the process effectively requires that the applicant be a business.
Without major cross-national legal changes, OV/EV certificates on the open web are pointless at best and misleading to the point of being dangerous at worst. They remain quite useful in specific scenarios outside of normal web browsing, but that's not the issue at hand.
dealing with this at work now, can you explain the situations in which you _should_ use OV/EV certificates? from my perspective they seem quite useless, even the NSA uses DV, but I don't know enough to actually say that. It seems like there are regulations which might make it required, but I also cannot find any link to anyone talking about what regulations those might be. Just that... "there are regulations"
Outside of regulatory requirements, they're useful for code signing (the extra hoops frustrate malicious actors, the legal identity behind the cert can be targeted for banning/suing/prosecuting), apps connecting to their own home services, and document signing, off the top of my head.
not trying to mess with you, the code signing one makes sense to me, but what do you mean by 'apps connecting to their own home services'? and document signing? like DocuSign? how would an OV cert help there?
Most apps don't need access to all web sites, they just need access to specific services. If the developer of the app controls some or all of those services, then the app can be coded to require the use of OV/EV certificates. With that rule in place, the app can then also inspect the subject DNs and check for the presence of its own organization details. The end result would be kind of like certificate pinning, except a little more flexible.
For documents, yes this includes things like DocuSign, but also signed PDFs, signed XML, etc. Any situation where a business, nonprofit, government agency, etc., is corporately attesting to something, like the signing of a contract or the public release of a statement, can use an OV/EV certificate.
I liked the idea conceptually of CAA record only allowing DNS validation. Then use DNSSEC.
I say “conceptually” since I know: 1. Actual attacks found with CT have used compromised TLDs, which kills the whole thing anyway, and 2. I haven’t really seen where the hosting company’s infrastructure (BGP ads and internal routing) is what’s compromised. Well certainly in the latter case they can probably also get in to the hosting machines directly.
> For DV, if you can successfully MitM every connection to a destination, then you _do_ own the domain.
That's a policy, not an inherent consequence of DV certs.
If every verification method other than DNS was shut off, it would still be DV, but with care it could be immune to MitM. I'm not advocating for that, but it's an option.
Don't focus too hard on the current method. Just work with me and imagine a value that comes direct from the registry and there's some kind of secure link, maybe DNSSEC maybe not.
The problem with this is risk management. In reality, MITM attacks on DV issuance are vanishingly rare --- and close to infeasible in many important cases. But misissuance of DV certs is less rare; it just doesn't happen with MITM attacks. Rather, the usual cause is registrar account takeover.
DNSSEC isn't going to happen, among other things, because it doesn't address a meaningful threat to the WebPKI.
On the contrary I have personally seen the attacks and the impact. My understanding was that CAs are required to do that by spec and Let's Encrypt already does that.
The Use case - Lot of SAAS based products allow/require the administrators to prove the ownership of a domain via ACME methods. The administrators then are allowed to manage the profiles for users that have email address with same domains in the SAAS product.
Ironically the testing setup itself used the network hack for the successful ACME challenge
I don’t think looseness is always more comfortable. You need looseness in the right areas which is what tailoring provides.
Maybe it’s cold and the extra airiness is working against you.
Maybe the clothes rustle and rub more when you move.
How do (non-elastic) pants stay up, without some minimal measurement for the waist?
I own some more baggy T-shirts and layering with a sweater feels more uncomfortable because the clothes will fold in places you don’t want them to with a sweater on, which is not a problem for more trim fit clothes.
I didn’t like the article because all of the missing defense-in-depth necessary to prevent the intrusion is firmly in the category of traditional cyber security. I could sympathise with an argument about organisational pressures and lack of time/people leading to an insecure sandbox, but that doesn’t seem to be the argument they are making. People have been securing systems that can run untrusted code for a very long time, and whilst mistakes happen, there are not really many novel ones.
The problem of “how to stop the model from attempting to be a hacker” is probably a more interesting and novel one, but it does not need to be solved to prevent the incident.
I think (for now), it is still relevant. A language is an abstraction, and a good abstraction, like a good LLM harness, can be quite valuable.
Let’s say I’m writing some concurrent code with an LLM. I’d probably feel much safer having it write Rust, rather than C. So even in a post-LLM world, languages will continue to evolve as long as abstractions can be improved.
But do you still have enthusiasm for finding out about new language features or concepts? I'll do what it takes to get the job done, but the passion for it is totally gone.
Yes, as an example structured concurrency in Java (final release in Java 28 perhaps). I think that could totally change how we write concurrent code in that language.
I just upgraded a less important service to Java 27, a few days after its release (several nice features). It's cool how easy it is to upgrade nowadays.
That an agent writes most of the code doesn't mean anything to me here.
My examples are Java because that is the main language where I work.
You're welcome. I now feel inspired to try to change your mind, if you don't mind.
I would argue that "concepts" actually are more important than ever. Let's take my structured concurrency example. It doesn't matter here exactly what is, but if it ends up being as important as I think it will be, I likely want to write most concurrent code that way going forward.
However, it will likely be years until agents go to it unless deliberately steered in that direction. And if I want to make agents write it, I need to review it, and if I'm going to review, I need to understand it.
I think this is why I'm not pessimistic about the profession, it still feels like what I'm doing and learning matters.
just chiming in to say that i agree with you. i initially felt demotivated and passionless but the more i use llms to generate code the more i feel like knowledge of the concepts are crucial to generating useful code.
eg. you dont need to memorise sorting algorithms or be able to write them, but you do need to understand the concept of sorting, and the concept of time complexity, etc etc. knowing what data structures to use and when to use them. knowing how to structure concurrency for your problem space. many many concepts.
system design is becoming the most important thing, and to me it's also the most interesting part of creating software. and there will always be more to know.
There's a couple of languages I follow their roadmap and I find exciting, including Java and C#. I don't feel there's proper justification of writing backend services in something like python or ruby anymore, for example.
Yeah, I also try to follow what's new. But it's more like "Ok, that's good I guess." Rather than "Cool! Looking forward to applying this in my next project!"
I found C# exciting when it was new and adding features that were important to me, but now it feels like it has become bogged down with chunks just abandoned on the alter of backwards compatibility (Expression, anyone?) and adding features I couldn’t care less about (null safe code, pattern matching, etc).
I worked with C# for a decade around the transition from .net to .net core to .net. I've come to really dislike it as a language because of it's implicity and abstractions but I'm surprised that you're not finding the new features intereting. All the work on immutability seems pretty awesome to me at least. Sure it's still this bastard version where you build "readonly" objects and put them into immutable collections, but I assume they'll work on this going forward.
I'm never going back to it, but I do think it's the best it's ever been.
Meaningfulness comes from what you care about. I wonder why you were interested in programming-language concepts before but now (apparently) stopped caring about the code. The code still remains the language that communicates the actual program logic.
I guess a large part of my motivation was that it makes me a more effective and skilled programmer. There are countless of interesting things out there, and the motivation to focus on one comes from what you do with it later on.
Yeah, I don’t think it assumes zero knowledge, which is what I’d expect from a “first programming language” book.
But it does say it’s targeted more for an “algorithms” course in the introduction.
As a side note, I think a REPL is the best environment for learning to program for absolute beginners. You get instant feedback and can focus entirely on just short snippets of real code, without having to worry about compilers, build systems, and “the OS” as a whole. Especially if it comes with a GUI wrapper, you can skip the terminal entirely.
I think it’s more of a time vs code tradeoff, if done properly.
For example in the Vec case, you could theoretically build an alternative which encodes the “three sections” property internally, and ensures correctness at construction time for the pointers. Not as completely safe as a Vec, but you can still get similar benefits for the “business logic”.
But I agree, just having a custom structure that does not provide a safe wrapper around this would be sacrificing standard guarantees.
The existing, human standards are based on human capabilities. Humans may not have read all the papers that could be cited. However, all these papers are almost certainly in the AI’s training set and it potentially has the ability to retrieve them over the internet into its context. Why shouldn’t we expect the AI to cite more comprehensively?
It seems more like a goal-setting problem, than an actually novel one. But a paper with lots of citations is not as “cutting edge”, so maybe doesn’t make sense for marketing reasons.
reply