I believe it's valuable to think of this question in terms of how our physical reality really can't answer it. It's a tacit acknowledgement that the rules of the physical world we exist in are not universal; We live with causality, but for existence to begin it must not be a universal requirement.
Eastern philosophy understood it quite early, you can only go so far with cause and effect.
Brahman, Prime mover, are great explanations as to why there must be a causeless entity, something that is not ruled by material nature in order to be the causeless source of it. The cause of all causes that is causeless itself.
Seems harsh to blame somebody for simply paying to do something they enjoy when the alternative is just not doing it. Blame the monopoly, not the consumer.
High prices and high profit margin are not in and of themselves anti-consumer, otherwise every luxury brand would be considered anti-consumer. If people will buy the tickets at the prices marked, why should they lower them? If they push prices high enough that the demand curve starts to dip, they will rationally correct for that.
The only anti-consumer force at play is the monopoly power Live Nation is granted to dictate the price of tickets. There's very little that can be done via boycott when it comes to monopolies.
It’s not like there’s another option, which is why the DOJ probably has a case. If you want to attend certain games it’s a) be a season ticket holder or b) pony up to a monopoly.
It takes two to tango. You're conflating this with victim blaming. This is a willing party willing to continue the cycle of the problem. For those making the decisions on "is it too expensive", then by definition it is not has stadiums continue to be filled by people participating in the fleecing.
Someone with money can spend their money however they want. They can gamble it, they can snort it up their nose, they can invest it, they can do WTF they want. If what they do with the money contributes to the problem, then they are still part of the problem.
What is the actual problem here? If someone is willing to pay more for a ticket than you are, by what principle should the venue or performer be obligated to instead sell it to you at a lower price?
It might be "retro" in the sense that it isn't the primary way most businesses host their services, but I still don't think there is any better way to actually learn the ins and outs of networking and server management early on than to have non-obfuscated control and responsibility for everything you're doing.
I think it's a useful exercise in simple port forwarding, proxying (via nginx, for example), and certificate management. So long as you're not serving port 80 beyond redirecting to 443 and those are the only two ports being forwarded to the pi, it's really not that risky.
I bought an HTC vive 7+ years ago and have middling opinions on its viability long-term as a major game platform. VR is fun and novel, but once the novelty wears off it can be tedious.
It's worth doing a vision pro demo in an Apple store if you can. I'm not planning to buy one in its current state, but it was immediately obvious that this was entirely new territory. It moved a piece of technology from fiction to reality in my mind. The eye tracking is hard to believe without having experienced it.
I'm not ready to say that this device will be responsible for such a large technology shift as the previous person, but I think it will play an large, perhaps pivotal role on our way to the next thing.
Disclaimer: I know a lot of people compare this to a device that I can surmise was meant to do a lot of similar things made by Meta; I have not tried this and may be attributing first-mover credit to Apple for things that Meta may have done similarly well. My comment is made from the perspective of somebody who has never experienced eye tracking in any capacity before.
Nothing Nintendo likes more than selling a sub-optimal way to experience their games.
You'd be talking about suddenly adding support for every game they've ever made running on a million unique hardware configurations. There is literally only downside for Nintendo's brand in doing such a thing.
It's also worth remembering that "sub-optimal" is completely up to opinion. If Nintendo decided to chase the optimal, we'd have a new Nintendo Switch every year like an iPhone. This would, of course, be a bad idea.
"I want 120 FPS. Or it's suboptimal!"
"I want an AMOLED, not just OLED. Or it's suboptimal!"
"I want keyboard input. Or it's suboptimal!"
And on and on.
A console generation is 8 years, on average. Nintendo's approaching the end. If we're making fun of Nintendo because a smartphone is more powerful, that's a testament to how fast phones have become, not a testament to Nintendo's sluggishness (as the Tegra X1, at the time, was the fastest mobile graphics chip available. What are they going to do? Call the generation after four years?)
Well, wait, we can define "optimal" as the "current best way to play game X".
I haven't used Nintendo Switch's Online emulation service, but my understanding was that the N64 emulator for it was initially very bad (though I've heard they fixed it?). On emulators for Windows, playing the same game, they would boost the resolution to 1080p [1] and bump the frame rate up to 60fps for a lot of games, while not giving any real negatives. For example, I think Conker's Bad Fur Day plays much better on Project64 than the original cartridge, so I'd define that as "optimal", and probably better than it would be if it were on the Nintendo Switch service.
EDIT:
[1] Actually I could be off on that number. I thought it was 1080p, but I think that doesn't jive with aspect ratios. Still, it's a higher resolution than what the original hardware gave us.
"Optimal" in my comment was specifically meant to mean "consistent". Nintendo is never on the forefront of hardware (aside from their creativity in that area), but their product is absolute consistency. Games work very well and always the same for everyone.
Emulators are the antithesis of performance consistency. I love them, but there's zero way Nintendo (in its current form) ever officially supports an emulator you run on a typical PC.
Oh, in that case, no kidding. Even Yuzu has several hundred games it doesn't support.
Yuzu also has things that just don't work well for most players. Super Mario Odyssey depends quite a bit on HD Rumble; which a Yuzu player almost certainly won't get unless they use a Switch controller. But why would an emulator user buy one and not use the Xbox controller they have lying around?
Yuzu also tends to fuzz the timing for complicated games in weird ways. I saw an emulated copy of Super Mario Bros Wonder someone was playing, and I tried a very hard level (5-out-of-5 difficulty) called Fluff-Puff Peaks Special Climb to the Beat. Super tricky (https://youtu.be/4PcBDeCKa0Q).
On my Switch, I could beat it on a few tries, consistently. On his emulated version though... I could not beat it. I tried over and over - with a Pro Controller - and could not beat it for over an hour. I pulled out my Switch version, again, a few tries, beat it. I swear Yuzu was subtly, imperceptibly screwing up the timing and physics. It wasn't a slow computer either - 13th Gen i5, RTX 3050. Not the latest thing around, but should be fine for Yuzu.
I really wish Ansible would have chosen to use python instead of YAML (since that's what it ends up being anyways). Shoehorning actual programming logic into YAML files is just awful; Working with Ansible as a software engineer is without a doubt the worst work I've done in my professional career. Every otherwise simple logic structure in any programming language like loops, variable declaration, or conditional statements take 5x as much space and are very difficult to understand immediately.
My first love in this space was Chef, and honestly it remains my favorite in config management because you can write things in it that look very non-programmy, but you're still just writing in pure ruby. Obviously Ansible has the advantage being agentless, but I just cannot stand how popular it is.
As a counter anecdote I can tell you that all of the ops-people I worked with, they gladly switched from Puppet and Chef to Ansible, specifically because it was less programming and more shell-like.
Not that this is good or bad, but I think that's why Ansible took off with the traditional operations-teams.
More shell like, and more normative. There's a given form & shape in Ansible; playbooks resemble each other.
You don't get that with programming languages. People do all kinds of shit with programming languages. There's tons of good ways to tackle a problem. And exponentially many more bad ways to tackle a problem.
Having a given repeated form makes interpreting & understanding Ansible far easier than the alternatives.
When I was first using chef -- and didn't quite get the paradigm -- it was really easy to fallback to a lot of native ruby. i.e. "I dont want to run these resources in certain contexts, let me just wrap them in an if statement." Which ended up creating a bit of a mess over time, and broke some of chef's functionality.
By using yaml ansible basically forces you to be purely declarative, which I found to be a boon, especially once other engineers who similarly didn't initially get the declarative paradigm started on working in the codebase.
Ansible is a nice tradeoff to allow sysadmins with no programming experience to work with it, and someday hopefully graduate to something else. For that, I think it's a net-positive.
But yes, trying to work with even mildly complex data structures in Ansible is a nightmare compared to raw Python.
Kidding aside, it is somewhat amusing to see the same discussion as when chef happened repeat itself.
Ansible clearly had to take a lot of liberties with the yaml format to make it work in practice. The amount of yaml in yaml you have to write is surprising. I cannot wait for the cycle to repeat itself.
> Ansible clearly had to take a lot of liberties with the yaml format to make it work in practice
and yet, completely facepalmed by invoking Jinja2 with its default begin and end characters that are meaningful to yaml, thus ensuring billions of person-years of SO questions due to having to quote, sometimes multiple ways, every jinja2 invocation
Contrast that to GitHub Actions which uses ${{ }} for its parameterization and thus no quoting required, in contrast to
- debug:
msg: '{{ "what kind of lack of forethought was this nonsense" }}'
I think this is more a personal preference rather than something practical. As a counter-example, I've implemented Ansible-like syntax as a configuration for a couple of unrelated projects, and people like it because it is similar to Ansible, which is used for infrastructure management. I doubt I'd do that by writing a parser for Python-like configuration language.
Also, don't forget that yaml is way easier to pick up by non-python developers and people unfamiliar with programming.
I once took a job that involved managing Ansible playbooks for an absolutely massive number of servers that would run them semi-regularly for things like bootstrapping and patching. I had used Chef before for a similar task, and I loved it because it's just ruby and I could easily define any logic I wanted while using loops and proper variables.
I understand that Ansible was designed for non-programmers, but there is no worse hell for someone who is actually familiar with basic programming than being confined to the hyper-verbose nonsense that is Jinja templating of Ansible playbooks when you need to have a lot of conditional tasks and loops.
Chef vs Ansible was the first example that popped into my mind. I had a very love/hate relationship with Chef when I used it, but writing cookbooks was definitely one of the good parts.
So why is there this massive ecosystem around not writing modules then? RedHat invented automation controller just so they didn't have to implement proper error handling with Ansible.
The 'not writing modules' approach is for people that aren't comfortable writing code. I think most capable users for non-trivial things should write custom modules a lot of the time.
