>none of the characters in her books are self sufficient.
I think they were in the sense that they, within the fiction of the books, had irreplaceable economic skills that made them fortunes. They were (again just in the logic of the books), more than pulling their weight.
Doesn't mean I agree with it as a system but I can see the internal consistency in this respect at least.
Aside from Galt's Gulch, there's also Dagny's brief stint on her own, during which she more or less magically automates everything that needs to be done.
Love it or hate it, her novels, over and over again could set generations of young minds on fire, which her essays could never do. I think it's fair to say the non-fiction was a lot worse.
Always a good time to remember this fantastic quote:
“There are two novels that can change a bookish fourteen-year old’s life: The Lord of the Rings and Atlas Shrugged. One is a childish fantasy that often engenders a lifelong obsession with its unbelievable heroes, leading to an emotionally stunted, socially crippled adulthood, unable to deal with the real world. The other, of course, involves orcs."
I fail to see the irony of "inheriting" an empire from Rand, when the protagonist of atlas shrugged and other main characters were heirs to a fortune. Inheritance is thoroughly explored in her work.
To me- this article is about the social dangers of taking a philosophy to the extreme, and about how easy it is to take advantage of the elderly when estranged.
> like many tragedies, this one is marked by a dark irony: A man devoted to the principle of individualism has ended up living a life defined by a reliance on others.
The irony is that Peikoff believed himself an advocate of individualism, while simultaneously subjugating himself, saying stuff like “I would let her step on my face if she wanted.”
The thing that I felt came through in this article (or maybe it's just my biases) was the hollowness of engaging in relationships purely for one's own selfish ends. Sooner or later (as happened to these people), the selfish desires don't line up any more, and the relationships get torn apart. Contrary to Rand, I don't think that love is inherently selfish (quite the opposite in fact), and it seems to me that love based on altruism is much more stable (and more praiseworthy) than love based on what the other person can do for me.
But then again I would say that, so it's hard to tell if that actually is something I took away from the article or if it's just confirmation bias at play.
IMO: In the end, everything we do is out of inner motivation, and love is no exception, so: all selfish. But that is not to be taken too literally - being unselfish can feel good, too, and is therefore "selfish". Rand's recognizing moral character or whatever as the base of love seems completely random, not how any of that works. We're smart animals! Biological creatures. We need to reproduce. It gets messy.
One thing I didn’t notice- what impact to the bottom line does kubernetes or docker bring?
I love shiny tools and containers as much as anybody, but “this thing is shiny and new age” isn’t a great pitch. Your team needs to have problems that kubernetes can solve.
If you don’t spend that much time on deployments, if outages don’t cost you much money- it is probably not worth it.
When I hear 200/k a year as revenue generating- I hear that this is something that should be limped along as cheap as possible, not that this is something that should be invested into and modernized.
I had the same reaction. I would look more favorably on a company that doesn't use Docker or Kubernetes. These tools, by default make things complicated and slower, so there needs to be a positive benefit for their use case that balances this.
It makes me wonder whether OP's desired for testing and CI is for a specific reason, (e.g. targeted test on certain algorithms, CI/CD to replace manual QC steps etc), or if it's for less-practical reasons.
I would rather run software directly than wrap it in something, (and in this case, the wrapper isn't thin!) unless there are complex system dependencies. And that may be a smell of its own. Depends on the application.
But that's a personal preference. I was asking how Docker makes things slower by default? Like, the act of using Docker means software delivery will necessarily slow down.
Adding an additional layer also means that layer needs to be managed at all times, and additional setup is required to use it. This starts at installing docker related tooling, having to do extra work to access logs inside containers, additional infrastructure management/maintenance (eg private repository), Docker compatibility between versions (it's not very good at maintaining that) etc.
The build/deployment time difference is maybe the least relevant, but also there most of the time, because Docker performs more work than simple zip+scp and an scp copy of the version to archive somewhere. Docker needs to copy far more than just the application files. Avoiding an extra copy of 100MB data (OS + required env) during deployment, if application files are only ~1-2MB tends to add quite a few seconds to the process, although how much it matters depends on network speed of course. For example on my modest connection it'd be ~8-10 seconds vs <1 second.
There are of course great reasons to use Docker such as a larger team that needs a common environment setup or when using languages that don't have great dependency management system (eg they have non-transferrable builds between systems), but it is something "extra" to maintain.
Sure, in the grand scheme of things, though, I wouldn't argue that seconds is a legitimate slow down. I just really struggle to buy into the argument that "non-Docker" is superior and that introducing Docker is a problem. It's _another_ way to do deployments, and it's not strictly worse. There are tradeoffs on both sides, although I would argue Docker has far fewer than just using systemctl and SSH.
> Adding an additional layer also means that layer needs to be managed at all times, and additional setup is required to use it. This starts at installing docker related tooling, having to do extra work to access logs inside containers, additional infrastructure management/maintenance (eg private repository), Docker compatibility between versions (it's not very good at maintaining that) etc
Docker is available on every major distribution. Installing it once takes seconds. Accessing logs (docker logs mycontainer) takes just as long as systemctl (journalctl -u myservice). Maintaining a registry is optional, there are dozens of one-click SaaS services you can use you instantly get a registry, many of them free. Besides, I would consider the registry to have significantly more time-savings benefits due to being able to properly track builds.
> Docker needs to copy far more than just the application files. Avoiding an extra copy of 100MB data (OS + required env) during deployment
This is only partially true. Images are layered, and if the last thing you do is copy your binary to the image (default Docker practice), than it's possible for it to be exactly the same time as it's only downloading one new layer (the size of the application). Only on brand new machines (an irrelevant category to consider) is it fully true.
I think the point is that not using Docker is easier, simpler, cheaper and better than using Docker.
Unless it is not, then you should use Docker.
But many (all?) of us have had the experience of a manager insisting on some "new thing" (LLMs are the current fad of the day) and if we are not using it we are falling behind. That is not true, as we all know.
It is very hard for the money people to manage the tech stack, but they need to, it is literally their job (at the highest level). We desperately need more engineers, who are suited (I am not!) to go into management
But this assumes that Docker provides _no_ advantages in time-savings, which is simply false. The person who recently responded to me noted that themselves. There are several scenarios where Docker is superior, especially in cases with external dependencies.
My point is that the universal argument that Docker is inferior to manually copying binaries is flawed. It's usually put forward by people who fit in the narrow scenario where that happens to be true. If we can agree that both options have trade-offs, and that a team should pick the option that best fits their constraints, then I think that's pretty much where most of the world sits in thinking. There are extremists on both sides, but their views are just that, extreme.
The number one reason to ban it is that golf is a spectator sport and nobody likes watching aimpoint. It is also slow, and poor pace of play can make golf less fun to watch as well.
Pro Golf is under some pressure to become more exciting to watch and faster paced. PGA Tour isn’t the only game in town- there is LIV, TGL, and YouTube golf competing.
I think we are going to see some measures in pro golf taken purely for the sake of the viewer. The pitch clock in baseball was a successful move with similar motivation
How much can aimpoint improve sub-pro level golfers? If it's just a little there's a risk that the pro stuff may seem dull, just people playing under even more arbitrary constraints than you do.
But if they're still leaps and bounds ahead it can still be fun watching people of a skill you understand enough to be amazed.
I'm a 20 handicap who bought AimPoint five or six years ago and it improved my green reading immensely. And I certainly do not waste playing partner's time on the green. It's just a quick feel, stick up the fingers and then putt.
The biggest issue with pro golf is how it’s produced. As for slow play that’s not AimPoint specific. You can play at a reasonable pace and use it. The Tour just needs to enforce pace.
Teens (and tweens) used to do the bulk of the lawn care that homeowners didn't do themselves. I don't think we'll ever get back to that even if all of the immigrants were to be deported. They're just not interested in doing this kind of work anymore.
Picking strawberries in Oregon was my first job, and I progressed through the usual things kids did for money then, so I know where you're coming from. However, there is a major economic change we also need to consider. It used to be you could earn enough over the summer to buy a usable car or pay college tuition. Can a kid even come close to that now? If those jobs can no longer benefit kids to the same degree, avoiding them might actually be the most rational choice. I say this even though I appreciate the diligence I see in young people who had some early experience of working.
Moneywise, the jobs could make sense for workers if we didn't import so much from other countries (fruits, veggies, and products). The same applies to construction and lawn work. Is it better for these kids to be driving for Doordash or working at McDonalds or something than working outside? For young people especially, I think the answer is no. But we all know that most people prefer to work inside an air-conditioned building if possible, even if the job actually pays less than picking strawberries or whatever.
I was a self taught programmer who at one point dropped out of college to try and get into the industry earlier. I spent about a year sending out applications and got absolutely zero response.
I go back to school for the remaining 2 years, and when I graduated I had 5 competing offers with salaries starting at double what I would have accepted when I had not finished school. This huge reversal in outcomes was purely the college degree as far as I can tell- I had less time to send out applications, no internships, and no new personal projects of any substance.
My experience is that there are too many college grads and boot campers with github profiles to get into the industry off of some basic home tinkering.
If you're going to do it, I imagine you've got to go one step up and stand out.
It's less effective at the OS wide level because the context is incredibly important. Notepad is used very differently from word processing and other applications. Even in the context of notepad- you're using that app very differently when working in python vs a readme.
AI is best integrated at the application level because the application developers are best suited to tune the algorithm and determine which pieces of context are most relevant.
If georgism was implemented here, then the value of the lot would have increased very significantly with a house was on it. With the significant additional value, it's likely that the two parties would have been able to come to an arrangement that didn't result in destroying the house.
The root of the problem here is that the house is worth peanuts compared to the land, so the homeowner has nothing to gain from bargaining with the developer. We end up destroying something of value (housing) in the name of speculative land investment, which is a shame
In today's world, the value of the lot increased significantly when the house was built.
The owner certainly could have sold that property with the house on it, and bought a much nicer empty lot.
That is not however what the existing owner wanted to build on the property, and as a result the building is damage to the property
And why should the landowner here bargain with the developer? The developer did not perform basic due diligence on easily a 200k+ investment
---
That being said, georgism plays right into this issue without the developers negligence. With LVT any land with improvements that is not determined to be it's highest and best use will be bulldozed and replaced, which is also a shame.
One of the primary issues noted in the article is that not enough cardholders were floating their monthly rent, and instead they were immediately paying it off just to collect rewards.
I don't think that participation in society as it exists should prevent anybody from holding their philosophy of choice.