It's kind of their whole thing, when you think about it. They didn't get to where they are by playing nice with others. If you're supporting anything in the Apple ecosystem, the fix is in.
That's kind of brilliant. I had no idea that kind of thing would actually work. I always assumed that bidirectional connections were needed to allow ETH frames to function, electrically. I further assumed this applied to optical networking too.
For 100BaseFX and 1000BaseSX at least, there’s no auto negotiation for link speed etc. As long as it sees a carrier from what it thinks is the other end of the link, it’s happy.
This is a good point. I wonder how much NES emulator code is in Claude's training set? Not to knock what the author has done here, but I wonder if this is more of a softball challenge than it looks.
For me, the dividing line is how compact the language representation is, specifically if you can get the job done in one file or not.
I have no doubt that there's a lot of Go jobs that will fit in a 500 line script, no problem. But the language is much more geared towards modules of many files that all work together to design user-defined types, multi-threading, and more. None of that's a concern for BASH, with Python shipping enough native types to do most jobs w/o need for custom ones.
If you need a whole directory of code to make your bang-line-equipped Go script work, you may as well compile that down and install it to /usr/local/bin.
Also the lack of bang-line support in native Go suggests that everyone is kinda "doing it wrong". The fact that `go run` just compiles your code to a temporary binary anyway, points in that direction.
Yup. This is some of the stuff that gets missed when understanding Security.
Ultimately, you're just buying time, generating tamper evidence in the moment, and putting a price-tag on what it takes to break in. There's no "perfectly secure", only "good enough" to the tune of "too much trouble to bother for X payout."
FWIW, you can make software that runs on Harvard architecture chips. They feature distinct address spaces for ROM and RAM. It's been a while, but it's how Atmel/Microchip AVR micros work.
That's the mother of all people-space problems in IT, right there.
To solve this, one can be an instrument for change. Network, band people together, evangelize better ways forward, all while not angering management by operating transparently.
Sometimes, that can work... up to a point. To broadcast real change, quickly, you really need anyone managing all the stakeholders to lead the charge and/or delegate a person or people to get it done. So the behavior of directors and VPs counts a lot for both the problem and the solution. It's not impossible to manage up into that state with a lot of talking and lobbying, but it's also not easy.
I'll add that technological transformation of the workplace is so hard to do, Amazon published a guide on how to do this for AWS. As a blueprint for doing this insanely hard task, I think it holds up as a way to implement just about any level of tech change. It also hammers home the idea that you need backing and buy-in from key players in the workforce before everyone else will follow. https://docs.aws.amazon.com/prescriptive-guidance/latest/clo...
> It also hammers home the idea that you need backing and buy-in from key players in the workforce before everyone else will follow.
Yup, this is the key issue and what makes it primarily a people problem. Technical solutions don't work if the main problem is getting buy-in to spec/build/adopt one, unless you're willing to build a lot of things you end up throwing out. So instead the bulk of the high risk work is actually negotiation between people.
Everything about these big moves in the streaming space is basically to re-create the "good old days" of cable subscriptions and pay-per-view.
I think we can expect HBO streaming to continue as a premium subscription for movies and high-production-value shows. That would let everything else to land on Netflix with no conflict.
I must have misunderstood what "Servant Leadership" actually is. I identify as such, but I also do just about all of the "Transparent Leadership" things called out in the article. I may have to re-evaluate my orientation.
There's only one place I disagree and that's when it comes to empowering the team to do every last thing within your charge ("become redundant"). Depending on the organization, there are some actions that only a manager is empowered to do. Someone still needs to be present to weigh in on disputes/arguments, break ties, handle performance, reviews, interviews, PIPs, dismissals, and handle _other_ managers when necessary. It's simply not possible delegate these things and in the case of dealing with other managers, can imperil a person's employment.
Also, I would caution anyone to avoid directly comparing management to parenthood, even as a metaphor. A lot of people have terrible parents, and so model the worst behaviors: they can't nurture a houseplant let alone a human being. I've seen people like this bring the worst possible models for management into the workplace this way, and they do a ton of damage to businesses, psyches, and careers in return. Instead, I urge anyone to look to the carpenter/gardener dichotomy and how good leadership requires a bit of both:
reply