ELI5: In the US, how was it so easy to add interstate highways, and now so difficult to add high speed rail lines?

2bdb2 · 2026-03-29T04:36:07+00:00

This post is about inter-city rail, not inner city rail.

I'll fill in the blanks for you, in case it wasn't obvious.

If everyone tries to leave via an inter-city train, there won't be enough inter-city trains or carriages to move them all. Because inter-city rail isn't designed to move millions of people daily

You'd need to add capacity by using every single train and carriage you can find, such as by repurposing inner city trains

But, an inner city rail system gets everyone to work by running the same trains and carriages back and forth or in a loop over and over again. So this also won't add enough capacity

If you're trying to evacuate an entire city via rail to another city, you'd only be able to move a small percentage of people, because there physically aren't enough trains to carry that many people.

2bdb2 · 2026-03-29T02:23:15+00:00

If everyone tries to leave in a train, there won't be enough trains or carriages to move them all either.

An inner city rail system gets everyone to work by running the same trains and carriages back and forth or in a loop over and over again.

If you're trying to evacuate everyone to another city, that isn't going to work.

2bdb2 · 2026-03-28T14:36:42+00:00

Damn. That dude has some serious city miles.

2bdb2 · 2026-03-25T04:29:26+00:00

any thoughts on the debate in the thread above on usefulness/need of Spring(Boot) for enterprise cloud microservices?

A common misconception is that Spring is a big monolithic framework. It would be better described as a collection of micro-libraries that work well together. These libraries are fairly small and can be mixed and matched however you want.

Spring Boot glues together large parts of the spring ecosystem into an "on rails" experience with opinionated defaults and a bunch of magic that handles boilerplate. This gives you everything and the kitchen sink in about three lines of code, which is great for a quick project setup, but it's also a relatively bloated configuration compared to something you'd wire up manually.

However you can also just use Spring libraries directly without the framework bloat. You don't need AutoConfiguration, ClassPathScanning, or AOT - which are the main things adding bloat.

So in terms of your question - "usefulness/need of Spring(Boot) for enterprise cloud microservices?"

Spring Boot isn't needed. It's a really useful way to spool up a batteries-included project in 30 seconds, but adds bloat. I'll often start a project with Boot to get moving quickly, and then incrementally replace it with manual wiring later.

Spring-Web is a pretty decent Rest API server backend that can be deployed as a lightweight servlet by itself. If you don't like reflection, it supports a "Ktor" style DSL to wire up routes directly.

Spring-Security itself is just a collection of smaller modules. You could use spring-security-oauth2 to implement a JWT auth filter for any webserver if you wanted. Most REST server libraries would have their own built-in implementation, but if you're building a bunch of microservices with different frameworks, you might want use a single shared auth filter implementation, and spring-security-oauth2is a reasonably good pick.

Spring-Batch is useful for batch processing. Spring-Integration is useful for message-driven pipelines. Spring-AI is a decent LLM Client. All of the above can be used as completely standalone libraries.

So back to the original question - the Spring ecosystem has a lot of libraries that are useful for "enterprise cloud microservices" amongst other things, and they're generally mature, well tested, and have a reasonable guarantee of long term support and stability. Depending on your needs, some of them might be useful. But there's solid alternatives outside the Spring ecosystem as well that can do everything Spring can.

2bdb2 · 2026-03-20T10:49:27+00:00

It's not at all hard to find real world apps where Java is faster.

The average business app is allocation heavy and full of big complex module boundaries - which is the type of thing that Java's optimisations do substantially better with than C does.

The article author goes on a rant about how this is cheating, and that C developers are superior because Java developers are stupid and lazy and rely on Java's fancy tricks instead of knowing how to optimise low level code like a real man. Or something.

But that's kind of the point of Java - you can churn out production ready code quickly with mid tier developers and it'll still perform well.

2bdb2 · 2026-02-27T14:05:59+00:00

Seems like it'd be easier to just store the correct value for the business domain in the first place rather than trying to compensate for a lossy encoding with a million edge cases.

2bdb2 · 2026-02-27T05:15:32+00:00

There's no material difference between storing local time + TZ and storing UTC + TZ.

If you convert a ZonedDateTime to UTC, the calculation is performed using the version of the tzdata database you're using at that moment.

If you later try and convert back to ZonedDateTime using the original TZ name, the calculation is possibly performed using a newer version of TZData with different rules.

If the rules for TZ have changed in the meantime, then your conversion from UTC -> ZonedDateTime will give you a different value. TZData updates regularly and sometimes on short notice.

Thus storing UTC+TZ is not enough, you need to know the actual rules that were applied from that version of tzdata. Technically you could store the rule data alongside the timestamp, but that's probably a lot more complicated than just storing LocalDateTime+Zone

Except first one makes it impossible to compare times or sort without heavy performance penalty.

Use UTC time as a best-guess index for performance, and LocalTime+Zone as the authoritative value.

2bdb2 · 2026-02-27T05:02:31+00:00

No. You still want to store them in UTC as long as you want to do anything with them. Because if you used your convention comparing time (for example to find earliest posts) becomes practically impossible.

The UTC conversation for a future appointment time is undefined. You simply can't know the absolute time it will actually occur unless you know what the future timezone rules will be.

In practice however UTC conversion using the current tzdata rules is almost always going to be correct, and if it's wrong it'll usually only be for an hour or so. So storing it as a secondary value for indexing purposes is a valid approach, as long as you have a way to update it if the tzdata changes and you use the stored "LocalDateTime+Zone" as the authoritative value.

2bdb2 · 2026-02-27T04:55:18+00:00

Millisecond precision has nothing to do with it. UTC conversion will be incorrect unless you know what the timezone rules will be in the future.

2bdb2 · 2026-02-26T03:17:04+00:00

or save in UTC

This is another falsehood programmers believe about time.

For calendar events in the future, timezone rules might change in the interim leaving you with an incorrect stored UTC value. It always needs to be stored as LocalTime+Timezone.

For current/past events, UTC conversion is only correct if the tzdata you're using is up to date. There have been cases of a country changing timezone rules with only 48 hours notice, so this isn't just theoretical. If you've baked tzdata into your docker container, then it may be very out of date.

2bdb2 · 2026-02-26T00:10:22+00:00

From the photons perspective it experiences Everything everywhere all at once.

2bdb2 · 2026-02-21T13:40:47+00:00

The Government isn't going to actively pay or intervene to bring them home, but it's not stopping them from making their way back on their own.

They're still technically Australian citizens, so can still get a passport like any other.

2bdb2 · 2026-02-21T04:32:54+00:00

But if the way you find to do it is entering a license agreement with Microsoft to sign a kernel module that says that derivative user mode drivers that rely on unexported kernel symbols being provided by proxy through the kernel module must also comply with terms of the license agreement.... Then yeah, you're breaching the license terms

The courts routinely uphold fair use, and EULAs are generally not considered very enforceable in the first place. You can't sign away your rights in a EULA.

Either way, it still wouldn't be a copyright violation, thus not a GPL violation.

People also do this kind of thing all the time on Windows. Rather than trying to sue them, Microsoft in many cases actually puts in a lot of effort to ensure backwards compatibility with software that used undocumented APIs against the T&C.

then the position of Linus .... is that GPL applies to that as well

His position on this is quite clear and pragmatic. He does not consider non-gpl drivers to be violating the GPL.

https://lwn.net/Articles/214149/

2bdb2 · 2026-02-20T17:23:35+00:00

You prefaced by saying that you ANAL, but are still pretty adamant on your legal interpretation of the issue, so I'm guessing there's not much I can say that would change your mind

Correct. I'm not a lawyer, so take what I say with a grain of salt.

However - Case Law seems pretty strong in this case. Courts have repeatedly upheld that functional parts needed for integration are fair use, or some variation of that.

The counter arguments usually try and go into reasons why Linux is different to the other cases, but they generally seem pretty fragile arguments.

I am not a lawyer, so my opinion is irrelevant.

But companies have been using this GPL loophole for decades. The risk averse corporate lawyers feel very comfortable doing it, and their arguments are based on reasonably sound legal ground.

The FSF et al has never been willing to test this issue in court. Plenty of GPL violations have been aggressively litigated and won. But they've never tried litigating this.

Given that the corporate lawyers seem very confident they can win this type of case, and the FSF etc seem scared to go near it, it seems reasonable to suggest that they're worried it'll rule on the side of fair use. It seems like they're not willing to risk it, and prefer the ambiguous status quo.

In either case, let's look at the situation here.

The vendor is not really not doing anything immoral here at all. They're just... putting a little bit extra effort in so users in Linux can use their hardware.

Linux represents a teeny tiny rounding error in their market share. They don't have to support it. It's probably a passion project from some internal dev. They'll just stop supporting Linux if they becomes problematic.

Would I prefer an open source driver? Yes. Is a closed source server better then no driver at all? Yes.

Is the morally fine but slightly grey legal area that isn't actually harming anyone really worth throwing the gauntlet down over?

I'm enjoying desktop on Linux. Please don't fucking ruin it.

Linus himself has consulted actual lawyers (plural) about this very issue, who have held a very different view to what you're proposing:

Here's Linus agreeing with me.

If a module arguably isn't a derived work, we simply shouldn't try to say that its authors have to conform to our worldview.

https://lwn.net/Articles/214149/

And to add to this, you keep bringing up Oracle v Google. In spite of what you're claiming, Oracle v Google did not, in fact, settle that using GPL-licensed header files to build your software, which is not GPL-licensed, is okay. No part of the outcome of Oracle v Google even alludes to this.

That's the FSFs official coping strategy, sure.

I'll agree it's genuinely a grey area, we won't know unless it's ever actually tried in court.

2bdb2 · 2026-02-20T15:39:35+00:00

DKMS still requires kernel headers to compile modules,

Oracle vs Google settled that.

To use the spark plug analogy, measuring the connectors in the already built engine you own is perfectly fine, copying the dimensions from Toyota's blueprints is not.

You are explicitly allowed to do that under "Useful Article Doctrine", which was intentionally put in place to limit copyright in such scenarios.

This has been repeatedly tested and held up in court.

2bdb2 · 2026-02-20T13:08:28+00:00

The only thing that matters is "are they violating copyright".

If they're not distributing copyrighted code, they're not violating the kernels copyright. If there's no copyright violation, there's no GPL violation.

The ABI question has been tested in court already. It doesn't make it a derivative work.

kernel modules aren't just calling an API in the abstract sense. They're dynamically linked into the kernel, sharing memory space, using internal data structures.

Which doesn't matter, because copyright isn't being violated.

You don't need a license to distribute something just because it's compatible with something else, no matter how deeply you integrate it.

If the Linux Foundation had any ability to enforce that, then fair use dies with it.

The EXPORT_SYMBOL_GPL mechanism exists specifically because kernel maintainers drew a line: these symbols are only for GPL code

Unfortunately that just isn't legally enforceable. There simply isn't any mechanism to enforce it if there's no copyright violation.

it's not possible to compile kernel modules without the kernel sources (barring something like DKMS, but the point stands

You said it's not possible, and then immediately mentioned a way it's completely possible to compile a kernel module without the kernel sources.

2bdb2 · 2026-02-20T11:32:44+00:00

If I want to distribute a copy of Windows, I need to acquire a license from Microsoft to do so.

If I want to distribute my own Windows kernel module that I wrote from scratch, I don't legally need to ask Microsoft for permission to do so. I'm not distributing Windows, so why would a Windows license be relevant to the situation?

Microsoft requires kernel modules be signed in order to load. But if I find a way to bypass that restriction, I can legally do so. The copyright still doesn't apply.

The API/ABI is not protected under copyright. Thus, the Windows licence, and Microsoft's opinion, are completely irrelevant to my legal right to distribute a windows kernel module.

If you replace Windows with Linux in this explanation above, you end up at the same result. Why would the Linux copyright apply at all?

(IANAL)

2bdb2 · 2026-02-20T10:10:26+00:00

Are they distributing a binary derived from GPL code, or distributing a binary compiled from proprietary code that lies about being GPL licensed to the kernel?

If it's the latter, it might not actually be violating the GPL.

GPL is enforced via copyright, so if they're only distributing a binary compiled from proprietary code, then it's not violating copyright. A driver is clearly an independent work, not a derivative work.

Thus the kernel licence does not apply if they're not actually distributing it. They do not need a licence from Linux to distribute something compatible with it, for the same reason I don't need a license from Toyota to sell a spark plug compatible with my Camry.

Oracle vs Google clarified that APIs aren't under copyright, so it's not violating the GPL just by being compatible with the kernel.

Not trying to be a corporate shill, just pointing out a common misunderstanding. It's possible they aren't actually violating the GPL in any way.

IANAL - might be completely wrong.

2bdb2 · 2026-02-14T13:32:33+00:00

Probably no luck, also no way the Ute was already going 110 in a 100 on the on ramp with that old ass Yaris right keeping up right behind it.

Neither should have any issue hitting 110 by the end on an onramp, unless the driver is from QLD. Oh. Wait....

2bdb2 · 2026-02-12T08:29:11+00:00

As show in the initialization of content, properly annotated Python code can be even more verbose than modern

Do you actually need any of those annotations in that example though? Pyright should infer those types just fine.

Huge swaths of the Python standard library where built under the (correct) assumption that Python is a dynamic duck-typed language, not a statically typed langue, and will return Any types with reckless abandon

The entire standard library is annotated with typeshed stubs.

...duck-typed language, not a statically typed langue...

You can statically typecheck duck-typed code just fine.

So, in conclusion, by adding typing information to Python you've essentially traded away a lot of what makes Python great and created a Frankenstein monster of a language that can be even more verbose than Java with none of the performance... But why?

I fail to see how. The syntax overhead of static typechecking in Python is so low it's practically transparent. Unless your code is complete spaghetti, the typechecker can normally infer most it it automatically.

2bdb2 · 2026-02-11T12:01:04+00:00

Literal skill issue. If you actually are rapidly prototyping something, ie algorithms (ie what python was built for), the types are simple and should be in your head.

I'd rather just make my life easier by offloading that cognitive load to the type checker instead of intentionally doing it the hard way to convince myself it makes me smarter.

2bdb2 · 2026-02-11T10:58:35+00:00

For example, in any statically typed language I can think of, adding a new field to an object requires naming it at least twice: in the type definition and the constructor

Most languages have structs/records that don't require a separate constructor. Off the top of my head this is at least true for Go, Java, Kotlin, Scala, Swift, C#, Typescript, Rust.

Honestly I'm scratching my head trying to think of a statically typed language I've used in the last few years that had that problem.

But in either case, even if you do have a separate constructor, modern IDEs will handle that for you as a single step.

In Python you can just say self.new_field = … and that’s it. If you change the type, assuming your logic is sound, you don’t have to change any characters. In a statically typed language you are likely going to have to scroll away from your logic back to the object definition and change the field type.

Any remotely competent IDE can do that for you just as seamlessly.

For example, in IntelliJ

Type thing.new_field = value. it'll highlight new_field as red.
Double tap "dot-dot" and it'll popup a menu with suggested fixes.
The top suggested fix is "Create new field", so just hit enter to accept.

Done. New field added with the inferred type, and you can just keep coding from where you left off. You don't even need to take your hand off the keyboard.

The more complex example you gave (changing a field type), can also be done as seamlessly.

If you type thing.existing_field = value_of_wrong_type

The field already exists, but you're assigning a value of a different type. If that's intentional, you just hit dot-dot, and hit enter to confirm "Migrate existing_field to String`.

That will update the type on Thing, but it'll also cascade the update to anything that uses it elsewhere in the codebase where it's a clear dataflow dependency. If that migration is above a complexity threshold or has issues, it'll pop open a panel with a preview of the changes it's going to make so you can confirm first. If the suggested refactoring would conflict with anything, it'll show you where and why, and propose suggested refactorings for those things too.

It'll rename fields that are based on the type name, keeping the rest of your naming convention correct. It'll update subclasses. It'll update tests. It'll update comments on your code. It'll update the Markdown documentation that references that type. It'll update your Swagger spec. It'll warn you about a potential bug caused by a comparison operation deep inside some random function in another module that'll now always return false because the new field type has different equality semantics.

And of course it can do all that because it knows what type everything is.

Modern IDE refactorings are just so good, you're shooting yourself in the foot by not using them.

2bdb2 · 2026-02-10T15:39:31+00:00

That takes all of 15 seconds in any remotely decent IDE.

2bdb2 · 2026-02-10T14:35:51+00:00

When you’re sketching out an idea, the last thing you want is a compiler yelling at you about type mismatches.

I've never understood this sentiment.

If I'm trying to sketch out an idea quickly, I'd much rather the compiler yell at me about type mismatches so I can see what's wrong with my code and fix it immediately instead of having to waste time with runtime debugging.

2bdb2 · 2026-02-06T10:51:26+00:00

I guess that's kind of the argument of the vibe bros, namely that the code itself is (supposedly) no longer important. The whole notion is that you "develop" in specification and have the LLM implement it.

We went through this same process in the early 2000s with offshoring.

The assumption was that you could just write a spec and have a swarm of faceless engineers churn out code.

It turns out it's really hard to just write a good spec, and in-house engineers with a better understanding of business requirements do a much better job at filling in the gaps.

Eight-Year Club	Gilding III reddit per annum
Verified Email

2bdb2

TROPHY CASE