SEEKING WORK | Germany or remote | DevOps strategy and (as a hobby) implememtation
I'm a senior DevOps person. My mission is to enable teams to work together better, faster, more enjoyably.
I firmly believe that engineering is what happens when engineers talk to one another. I
enable teams by making them understand what they can do and what they feel they should be doing.
It's not enough to work on one aspect of your practice; instead you'll need to address improvements at all levels.
To that end I offer everything you need to level up your development efforts:
* training on cultural aspects of DevOps
* training on methods used in DevOps
* training on technology to support DevOps
* ongoing consulting and coaching
* potentially, some hands-on work to get your tech stack off the ground
I'm also pretty active in the community, and am happy to speak at events or on podcasts.
Some boards list in the specs, but that's not a guarantee that it's actually working. Previous BIOS revisions can and have silently broken the ECC part of the memory functionality, and nobody at the board companies was testing it so it went out without anybody noticing until a user started a forum thread about it. That was Asrock iirc.
In the case of MSI, those boards reportedly also don't support the ECC reporting function. They will try to correct them but they don't actually report them to the OS. MSI's answer: "wow, sucks to be you". AMD’s answer: “wow, sucks to be you”. That's what you get from "unofficial support", just a halfhearted level of effort all around.
(there are really multiple levels of functionality here, "boots with ECC in non-ECC mode", "corrects ECC silently", and "behaves like a server and reports ECC to the OS or lets you reboot the system". You'll note that nobody ever commits to a particular level of support on AM4 based products...)
Furthermore, AMD doesn't support it at a processor level, so they apply no pressure to the mobo companies to actually test the features they claim they support, nor will they fix it if there is ever a critical functionality bug. An AGESA update could break or remove ECC and welp, sucks to be you, they never advertised that as an actual feature.
That is why I think it is a little ridiculous that people phrase that as "supported". Nobody is validating that it actually works, nobody at AMD will stand behind the feature, and will in fact tell you that they don't support it.
It works, probably, on certain combinations of hardware and BIOS. It is not supported by anyone other than yourself and your own time.
> Some boards list in the specs, but that's not a guarantee that it's actually working.
You do realize that false advertising is illegal? Of course realistically that would be a very uphill battle to pursue but that doesn't make it legal.
For example my motherboard has built in audio. The board manufacturer makes some fairly vague claims about what precisely that means but it is clear that there are ports on the board and that they will provide some base level of functionality in conjunction with a supported OS. To the best of my knowledge the CPU manufacturer makes absolutely no claims about that feature. Nonetheless, it is reasonable to expect it to work.
Of course it would be nice if AMD required ECC support as part of the platform. Then all the boards would be required to support it and I wouldn't have to bother reading their spec sheets.
> there are really multiple levels of functionality here
This is the real issue. At least historically, some boards "supported" ECC memory to the extent that they could operate with it inserted; they didn't actually do any error correcting though. Of course in the case I'm aware of (MSI) they specifically stated that. If you as a consumer glossed over their claims and missed that, legally that was on you.
Other vendors specifically stated that their boards officially supported actual ECC functionality. It's not safe to assume precisely what that means though (silent vs reported) unless the manufacturer makes an official claim.
Let me point out: to me, auto-updating isn't even the crucial issue (I use unattended-upgrades as well, so whatever).
Yes, functionality and workflows around installation and updates are still insufficient for many use cases, but that could have been ironed out given enough time.
But what you messed up badly, IMO, was to force-migrate packages to Snap in an LTS release before it was ready.
Had you waited until Ubuntu 20.10, I'd have been more forgiving. But you (collectively) were so eager to get this in before the window closed for another two years.
If you had made Snap a compelling product, even LTS users might have voluntarily migrated to snaps once they saw how good it was. Now you've kind of pulled off the opposite.
Sadly the ship has sailed: Both in general, since you've pushed so heavily for Snap in a LTS release when it simply wasn't ready yet. And for me personally, where the forced installation of Snaps by some debs (notably Chromium) broke my trust significantly enough that I turned my back on Ubuntu after over a decade.
Not only is the Chromium Snap dog slow, it also can't see my NFS shares. So the snap version is objectively worse, at least for now.
But if I install a deb, I expect to get a deb. You don't want to offer it anymore, fine, take it out of the repo. But sneakily migrating me to a snap, and not even notifying me, is just trust-breaking.
>But if I install a deb, I expect to get a deb. You don't want to offer it anymore, fine, take it out of the repo. But sneakily migrating me to a snap, and not even notifying me, is just trust-breaking
Indeed.
We need to modify the age old saying:
"Computers do what you tell them to do, not what you want them to"
By applying the following patch:
"Computers do what you tell them to do, not what you want them to do - except Ubuntu 20.04 LTS"
> > "You’d never hear anyone say, 'We help mechanical engineers be agile. That would be silly. And I mean that in the worst possible sense of the word".
This quote is silly.
To me, agile is just good engineering practice, applied to software. Of course mechanical engineers apply its principles, and have for decades before the term Agile was coined.
And as such, this practice is far older than software.
The Apollo space programme is my favourite example: the ultimate goal remained fixed (man/moon/before end of decade), but all steps of the way were discovered and redefined over the programme's course.
Mission objectives were changed depending on what was learned, often even in flight.
This was a very nice and agile (and sensible) approach, regardless of what it was called.
You're just offering your own special definition of "agile", that of course doesn't fit anyone else's definition, and especially any agile consultant's.
Of course, even more ironically, it doesn't fit the original agile manifesto:
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
> You're just offering your own special definition of "agile",
I'm not so sure.
What's the official definition? Don't give me the manifesto, that's just an implementation of common sense in development, as applied to software.
As a trained mechanical engineer (maybe that's why the quote about mechanical engineers irked me especially), the agile manifesto just reads like good engineering practice to me.
And indeed the signatories of the manifesto expected to start a huge discussion on what agility meant for any particular team or product, and how to best live up to its principles.
> of course [it doesn't fit]
That was uncalled for.
> and especially any agile consultant's.
I'm (something akin to) an agile consultant though :-)
Also, just to point out: maybe my definition of Agile diverges from canon. That's OK. I don't care to follow the canon, I care to do right by those who I've been asked to support.
> Of course, even more ironically, it doesn't fit the original agile manifesto:
> > Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
I'm not sure how you came to that conclusion.
How is "welcome changing requirements" a bad fit for "changed the mission objectives (as new information emerged)". Clearly the [competitive advantage/likelihood of success] was increased? In fact the entire programme was shaped such that change was explicit part of the plan.
I've stared at this quote for a while now, and I still can't see the contradiction.
> meaning that they are not updated with security fixes in any systematic manner.
Interestingly, that exact thing was always my worry about Snap (or Flatpack) as well.
Sure, big-name software such as Spotify will keep their Snap package well in order; they've got both the incentive and manpower to do so. (Incidentally, they could also use this manpower to build distro-specific packages).
But what about all the little open-source hobby projects? They'll be packaged with whatever library version happens to be latest at the time. And then, be updated whenever the hobbyist dev finds the time and inclination.
So on my system I might have a huge zoo of different versions of the same library, with various bugs or vulnerabilities.
If they all used the same system-wide library, at least they would all be fixed at the same time (when the library maintainers publish an updated .deb).
To me, Snap and the like feel like they're essentially the same as static linking, except more opaque.
Spotify aren't doing a great job with their Snap, it's been a few versions behind Mac and Windows for a while now. They could do with more dev manpower.
> Facetime has the best audio/video quality of any conferencing software I've used by a mile.
Out of curiosity: can you compare it to Google Duo? Because it has the best quality and stability of any 1:1 product I've ever tried (never tried Facetime)
It's getting long in the tooth by Google standards I suppose. Who knows when they'll axe it.
I think it's strictly 1:1 (which, I gather, Facetime isn't?).
It has good video quality, but what I like most about it is that it's nicely resilient on dodgy connections.
I've often used it wandering around my garden, at the fringe of Wifi range, and it does the right thing: tries to stay on Wifi, but switches over to 4G if the connection becomes too dodgy, then back to Wifi once that's stable again.
All of that with pretty minimal artefacts.
Unfortunately, Jitsi isn't a viable solution at this point except for 1 on 1.