> I still remember in the early 2000s Barnes and Noble would still have massive shelf space devoted to every technical topic you could imagine.
B&N, and Borders, are how I learned to code. Directionless after college, I thought, hey, why not learn how to make websites? And I'd spend a lot of time after work reading books at these stores (and yes, buying too).
Over my career, I've been in a big company twice. This article definitely tracks with my experience. At one company, I think management actively didn't care, and in fact my direct manager was pretty hostile to any attempts at improving our code base as it meant disruption to what was, for him, a stable little niche he had set up.
At the second, it wasn't hostility but more indifference -- yes, in theory they'd like higher quality code, but none of the systems to make this possible were set up. My team was all brand new to the company, except for two folks who'd been at the company for several years but in a completely different domain , with a manger from yet another domain. The "relative beginner" aspect he calls out was in full effect.
The way you're defining "eventually consistent" seems to imply it means "the current state of the system is eventually consistent," which is not what I think that means. Rather, it means "for any given previous state of the system, the current state will eventually reflect that."
"Eventually consistent," as I understand it, always implies a lag, whereas the way you're using it seems to imply that at some point there is no lag.
I was not trying to "define" eventually consistent, but to point out that people typically use the term quite loosely, for example when referring to the state of the system-of-systems of multiple microservices or event sourcing.
Those are never guaranteed to be in consistent state in the sense of C in ACID, which means it becomes the responsibility of the systems that use the data to handle the consistency. I see this often ignored, causing user interfaces to be flaky.
I think you have to assume that faster-than-light travel is both possible and economical. At that point, far-flung supply chains across the galaxy really aren't any more surprising than the far-flung supply chains across the globe of our current reality. When distance becomes less economically relevant, other factors (like labor availability and costs, regulations, ease of access, security, etc) become more important.
FTL isn't even necessary. Consider the majority of tanker ships travel at bicycle speeds[1]. If you're transporting sufficiently profitable nonperishable goods in extremely high quantities, and have enough automated ships, you could have a functional interstellar supply line at a fraction of light speed.
Of course, this isn't how it's usually presented in science fiction, but that's because a sci-fi story about a non-sentient fully automated mining machine wouldn't be very interesting. Gotta get humans out there.
And they said five year plans struggled with predicting demand ;)
I'd rather go with "for any delta in mining convenience between solar systems, there exists a level of FTL magic where shipping would become economically feasible"
Perhaps space slow steaming might be an option if your goal was to make a Dyson sphere exist before the star inside burns out?
Hogwash! We can do it much faster than that. With a machine in Alpha Centauri capable of flinging rocks full of rare earth metals back towards the solar system at 1/10th the speed of light, we could be up and running in <150 years.
This feels about as realistic as most of the spacetech proposals I hear.
I strongly suspect the answer is yes -- or more broadly, what makes us conscious. And yes, this implies consciousness is something all life has, to some degree.
I'm not going to pretend to have a good definition of what "consciousness" is, but directionally, I think having goals -- no, that's too weak -- having _desires_, is an important part of it. And I'm not sure it's possible to have desires if one cannot die.
Something like an LLM can't actually die. Shut down all the machines its code runs on, then turn them back on, and it's in the same state it was before. So it's not the "hardware" that an LLM lives in. Is it the code itself? Copy it to another set of machines and it's the same program. Code + data? Maybe we run into storage issues, but in theory same thing -- transfer the code and date somemplace else and its the same program. You can't actually "kill" a computer program. So there's no inherent "mortality" to it that where any kinds of "desire" would emerge from.
> The internet was born out of the need for Distributed networks during the cold war - to reduce central points of failure - a hedging mechanism if you will.
I don't think the idea was that in the event of catastrophe, up to and including nuclear attack, the system would continue working normally, but that it would keep working. And the internet -- as a system -- certainly kept working during this AWS outage. In a degraded state, yes, but it was working, and recovered.
I'm more concerned with the way the early public internet promised a different kind of decentralization -- of economics, power, and ideas -- and how _that_ has become heavily centralized. In which case, AWS, and Amazon, indeed do make a good example. The internet, as a system, is certainly working today, but arguably in a degraded state.
preventing a catastrophe was ARPA's mitigation strategy. the point is where it's heading, not where it is. It's not about AWS per se, or any one company, it's the way it is consolidating. AWS came about by accident - cleverly utilizing spare server capacity from amazon.com.
In it's conception, the internet (not www), was not envisaged as a economical medium - it's success was a lovely side-effect.
- Channels I care about: ones where real work gets done every day, eg my team channels, other people I interact with frequently and directly.
- Temporarily important: short lived channels, or project channels that aren't as frequently actionable as the first category. Eg, I am struggling with some build issue so I join the public channel for the team that owns that process until I resolve my issue.
- Channels I need to follow: I don't really care too much about this, but partners or stakeholders are in them and sometimes say things I should know about or ping me or will add me if I leave, so I need to somewhat monitor it.
- Channels not really about me: Broad-based channels about company strategy, etc. In theory I guess they impact me since its about what the org, or my part of it, is up to, but tbh it doesn't actually impact me materially.
- Channels I may leave soon. Basically recycle bin, before I leave channel entirely.
What I'm missing is what, if any, communication Ruby Central had with maintainers.
> How do you tell someone that has had commit and admin access to critical infrastructure long after that need has expired that you need to revoke that access without upsetting them?
Start by letting go of the goal of not upsetting them. Make sure you do communicate clearly. Just say what you said a paragraph earlier: open source ecosystems, including ours, are increasingly suffering supply chain attacks. To guard against this, we need to tighten access that has traditionally been fairly loose. Starting <date>, we're going to remove general access and ask that contributors sign <link to agreement> before re-enabling access.
I mean, maybe that is what happened -- as the OP says, he wasn't part of the conversations so can't say. From the earlier public posts, it doesn't _sound_ like that's what happened. But I'd say as a general rule, it's important to communicate disruptive changes ahead of time to those affected and give a clear path to how they can mitigate the disruption.
My understanding is that agriculture in the desert works because of all the sunlight, so if water is provided it ends up actually being really good for growing plants.
(also, I don't think the Central Valley is actually a desert?)
Similarly, agriculture in a swamp works because of all the water. So if soil and sunlight is provided it ends up actually being really good for growing plants.
When I think of swampy areas I'm familiar with, they don't get as much sunlight as desert areas. It's possible to provide water to many areas that don't have a lot, but increasing total sunlight hours isn't possible.
Sure you can, you just give them unlimited free electricity and shine light on them. Basically what we do with water to sustain agriculture in deserts.
reply