I'm a Linux admin/engineer, with some hardware experience in my prior job. Lots of general Linux, Solaris, and UNIX experience; patching, upgrading, replacing OS, hardware, and applications.
Starting in 2014 I've gotten into Golang, building a wiki, Nagios-type monitoring system, and other programs, so I'd love to branch out from the OS engineering and administration side.
I'm a Linux admin/engineer, with some hardware experience in my prior job. Lots of general Linux, Solaris, and UNIX experience; patching, upgrading, replacing OS, hardware, and applications.
Starting in 2014 I've gotten into Golang, building a wiki, Nagios-type monitoring system, and other programs, so I'd love to branch out from the OS engineering and administration side.
That would be the perfect solution, even if the upgrade boards came at some kind of premium for those of us who aren't into yearly TV upgrades.
For what it's worth regarding CBS All Access: If you're an Amazon Prime member, you can subscribe to the CBS All Access 'channel' in Prime Video, and use the Prime Video app to watch those shows.
I'm in the same exact TV situation, had to find this workaround to catch Star Trek Discovery, really lame.
After trying a few of the others after Google Reader shut down, I settled on https://tt-rss.org/. It has an official Android client and quite a few iOS clients as well.
Did I miss the mud-slinging and corporate culture bashing from the original rejection? I can get the AMD dev being a bit sour by the whole situation if they personally spent time working on this rejected patch, but damn.
There were certainly implications that the AMD coders were making technically compromised decisions:
> The reason the toplevel maintainer (me) doesn't work for Intel or AMD or any vendors, is that I can say NO when your maintainers can't or won't say it.
And telling them to sit in a corner and really THINK about what you've done, young man:
> I'd like some serious introspection on your team's part on how you got into this situation and how even if I was feeling like merging this (which I'm not) how you'd actually deal with being part of the Linux
kernel and not hiding in nicely framed orgchart silo behind a HAL. I honestly don't think the code is Linux worthy code
All pretty mild, really, but I'm not the one who got the email telling me my months of work was not Linux-quality and would not be merged.
(I am giggling at the idea of "Linux quality" being held up as an ideal)
> ... but I'm not the one who got the email telling me my months of work ... would not be merged.
See, the thing is that they were told previously -- back in February? March? -- that this wasn't gonna happen. Instead of trying to work out a better way forward, AMD effectively ignored that, went back to work, and just now came back and said "here's 90k LOC, please merge".
Dave replied -- rightfully, in my opinion -- "no".
Ahh, thanks for pointing those out. I completely skipped over those portions...I was expecting some Linus-level chewing out that I'd missed given the tone of the response, haha.
Certainly pretty mild considering the source, though I understand why the second quote would stir things up a bit, especially making it into an "Us vs Them" situation.
While I agree with Dave that the patch should not have been merged, I can understand the tone of the reply, not just from frustration but maybe even some actual panic about job security. Depending on how AMD's management takes this news, some of the people who wrote this patch may not have a job in a little while if the merge doesn't happen. I'm trying to be sympathetic.
Considering AMD is bleeding money, I assume it was pretty hard as well to get someone to sign off on getting headcount/resources to write Linux drivers.
What I think is weird is it seems like just a few years ago, Microsoft was embracing Steam. They released (or rather, allowed some team to port and publish) remasters of Rise of Nations and Age of Empires II on Steam, with some really great Steam integration too.
Guess that was before someone at Microsoft came up with this UWP idea and somehow roped gaming into it.
I've found myself always coming back to VSCode for my (stupid simple, nothing crazy like Docker or anything) Go projects.
They've really done a fine job with the editor and extensions. Bravo Microsoft!
They changed the 2FA to use a microservice, so whatever the vulnerability was before, if the 2FA is now on an isolated server, that vulnerability shouldn't have access to the new 2FA key.
I think it's fairly important to note that they're NOT currently using the microservice for the 2FA, and they're NOT using bcrypt right now.
The blog post states they're "working towards" these changes, they're not currently in place. It's fairly unlikely that they're using the same secret key as the one they found on the server, but it's fair to assume that they are still using salted SHA-2 for your passwords and the same 2FA setup right now.
They likely won't roll out the major changes until they roll out the "new and improved" Linode dashboard they're coming up with.
The article didn't state that. The article stated they are rolling out soon. The new dashboard will be an open source project. So you'll know when that gets released. There is no link to the project yet so assume that part isn't started yet. So the microservices should be released in a timely manner. Let's hope with the new focus on transparency if there are any delays they will keep us posted.
Isn't that exactly what I said? o.O I said they will "likely" get rolled out with the new dashboard, not that the article said they would lol. But, they never stated when it would happen anyways, so "delays" aren't really a thing when there's no deadlines.
But given that they don't know what the vulnerability is, there's no way of knowing that.
When it comes to the security of who's hosting my servers, I want a little more reassurance than they shouldn't have access. I need to know that they don't.
Remote: Yes
Willing to relocate: Yes
Technologies: Linux, Golang, Postgres, AWS, nginx, git, HTML, Ansible, Caddy, metrics and monitoring, service reliability, Docker, Kubernetes, Prometheus, Grafana
Résumé/CV: https://jba.io/resume.pdf
Email: me@jba.io
I'm a Linux admin/engineer, with some hardware experience in my prior job. Lots of general Linux, Solaris, and UNIX experience; patching, upgrading, replacing OS, hardware, and applications.
Starting in 2014 I've gotten into Golang, building a wiki, Nagios-type monitoring system, and other programs, so I'd love to branch out from the OS engineering and administration side.
All my Golang programs can be found at https://github.com/aqtrans