InternetOfStuff
Joined 9 years ago
Joined 9 years ago
Unfortunately, Jitsi isn't a viable solution at this point except for 1 on 1.
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.
Website: https://ingianni.eu/
The Asus Pro X570 ACE (or similar name) explicitly offers ECC support though, not just unofficially.
Better video quality?
Dual-screen mode?
Or simply the superior video and audio quality compared to Meet.
I wish I could move away from Zoom, but I've yet to find something similarly useable for my use case (remote trainings).
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.
Annoying but harmless: it's start time has multiplied.
Workflow-breaking: Chromium now can't see my NFS mounts anymore.
It's not just about having a pretty home directory.
> > "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.
I was just trying to pick a random example.
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.
It's clearly written by someone not familiar with the demands of embedded systems.
Also, Pis have a not-so-stellar track record as far as reliability, which is why I wouldn't want to use them in safety-critical systems.
I suspect systems using them will have a hard time passing official reviews (which have been accelerated, but very much still exist).
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.
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)
Too bad, really. Loom seemed nice.
The other day I came across something interesting: two comments, for two different but related products (dynamos). One comment was in German, the other in Italian, but they both had the same non-sequitur in them.
Apparently scammers reuse comments across products (not surprising) and languages (more surprising).
I'm keenly interested in product quality, and have broad experience in product definition, development and QA.
I'm a big proponent of DevOps, and have successfully applied it to less obvious fields such as embedded software.
My speciality is in embedded systems / IoT; I have a MEng in mechanical engineering.
I offer development process consulting, engineering support, and training on a variety of subjects.
find me at https://ingianni.eu
Kismet: 63a85e6b3b4c71066c36e8debc9a916fc2990dacbd6f3a590e3e94e86f6af8eb