InternetOfStuff

I'd love to, but IME it's unstable with more than a handful of participants and doesn't offer stuff I need, such as breakout rooms.

Unfortunately, Jitsi isn't a viable solution at this point except for 1 on 1.

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.

Website: https://ingianni.eu/

Linkedin: https://www.linkedin.com/in/luca-ingianni/

ECC is not officially supported on Ryzen. If it works on your particular board/BIOS, great, but it's not officially validated or tested

The Asus Pro X570 ACE (or similar name) explicitly offers ECC support though, not just unofficially.

Breakout rooms, for instance?

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).

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.

Chromium silently moved to a snap package some weeks ago.

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.

This quote is the best part of the article:

> "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.

Heh, interesting, didn't know that.

I was just trying to pick a random example.

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.

This is a remarkably clueless article.

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).

So they do :-D

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.

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)

Last I tried it, it didn't work on Firefox, and was somewhat unstable.

Too bad, really. Loom seemed nice.

Now I find that I rely more and more on brands to decide which things I buy, because I simply cannot trust user reviews in most of the cases.

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).

ISTR my Dell USB-C dock can do that (but check for yourself, I might misremember). No idea how well it works with Macs though.

Except recouping the CO2-expenditure of the concrete piston will take a long time.

When the idea was described to me it was proposed to carve the piston out of sheer rock (obviously requiring fitting geology).

I don't think I subvocalise, I read way faster than I can speak. There's certainly ideas flowing through my mind as I read, but not sounds. It feels like a mixture between words, thoughts and emotions, not a stream of (silently) spoken words.

I bought a book on speed reading because I was dissatisfied with my "slow" reading, only to discover that according to their tests I was way up there in both speed and comprehension :-D

I was shocked to learn from that book that many people subvocalise - it felt so foreign (and utterly cumbersome) to me. I hadn't even considered people did that.

Most of the book was about not subvocalising - which I don't think I do anyway, so I never read it to the end.

Indeed if I read to my kids I'm often simultaneously reading one sentence aloud, and reading 1...2 sentences ahead for myself so I get the voices right. So in effect I'm reading the entire text twice while speaking it once.

Anecdata: I have an Asus ACE mainboard and use ECC RAM with it.

Works as advertised.

You can opt out of recaptcha by just boycotting the website which uses it.

Ah, I was waiting for somebody to make this argument, which I find somewhat disingenuous given how widespread reCaptcha's use is.

With sites I don't care about leaving them is exactly what I do - but there are sites I pay a lot of money to use, and can't really avoid using for business reasons, yet they still subject me to reCaptcha.

The path I've taken instead is to address this with the site owners. Most weren't really aware of how overreaching reCaptcha feels to some, and I've had good discussions. Of course nobody changed their site based on my complaint, but I like to think I raised awareness.

But of course by "opt out" you mean to remain a user of a service but not the parts you don't like.

Specifically, a part of user verification. I'm still not sure why they feel they need to verify my humanity - they've got my credit card details and everything.

Whether you are entitled to do this or not is still up for debate.

Let me ask the opposite question: is the owner of a website entitled to sell my privacy for their own (debatable) convenience?

Tbh reCaptcha irks me more than ads.

False comparison. Google users are voluntary.

Not entirely. I can choose not to use Gmail or similar services.

I can opt out of Google ads+tracking only because I'm technically adept enough. I can't (realistically) opt out of reCaptcha.

I don't think a single compile cycle per half day

Hm... I read this quite differently than you do. Not compile cycles, but actual test-driven product iterations.

Do you have more solid sources than I do?

https://intenseminimalism.com/2012/a-brief-history-of-agile-...

https://brettwgreen.com/2014/01/25/rockets-before-rovers/

Speaking as an aeronautical engineer, I disagree.

Engineering systems requires an engineering process and discipline, and agile is just not up to the rigor.

Agile just means closing as many feedback feedback loops as you can as early as you can, and to preserve opportunities to course-correct for as long as you can. All this to keep the destructive effects of surprises (which are sure to catch you) as low as possible.

This is good engineering practice, plain and simple.

Maybe I am wrong in my understanding

No, not at all. Just maybe a little... narrow?

observations from testing or using is fed back quite quickly so that fixes can be included in the next sprint.

Quite quickly, yes.

The next sprint...maybe? Not necessarily.

Sure, you'll stick it in the backlog. But whether you'll start working on this improvement immediately is a separate matter. If that's the best course of action, sure, do it. But maybe you have more pressing matters, and the present implementation will do for now. Or... it's not possible to attack it in the next sprint, because a new board needs to be spun, and that takes preparation. Then it'll be slated for the appropriate time, by necessity. That doesn't mean you forego an agile approach -- it just looks different, because the landscape is different.

Especially true when the project gets closer to start of mass production.

Sure. Which is why being able to make, and find, and correct your mistakes early, when it's not so dramatic yet, is the goal of that whole Agile song and dance.

As you're intimately familiar of course, surprises in engineering are usually the bad kind, and the later they come, the worse they catch you. So, have as much feedback as you can, as early as you can (and with as much fidelity as you can).

All that can be changed as well but at some point it gets complicated!

Not everything has to be changed, that's just a strawman.

But not every detail has to be nailed down at the beginning either.

The idea behind Agile is to reduce risk. If there is no risk of the bus system changing on you, there's no harm in fixing it right at the beginning.

But if there is a chance it might, you'd do well to have systems in place which enable you to react to changes with a minimum (though non-zero, of course) amount of pain.

However, I still think waterfall is the only approach when trying to design a hardware product. Electronics require pretty specific requirements up front before you design and order boards, obviously mechanical tooling can be even more expensive.

I disagree, having taken part in agile embedded development.

Sure, it looked a bit different from pure-software, but the same underlying principle of short iterations applied. Our definition of "short" was a bit different, but still...

And yes, you may have some "very specific" requirements, but you may also have some "pretty loose" ones -- just like software.

But... I think there are lots of ways to do quick experiments and tighten up the feedback look even with robotics or electronics. Breadboards and development kits can be used as initial electronics prototypes. 3d prints help test a mechanical concept

See, there you go.

The core idea behind Agile isn't to have sacrosanct two week sprints (or even to have sprints in the first place), it is to close as many feedback loops as you can as quickly as you can. Whatever that means in practice.

This has been good engineering practice for longer than software exists.

I read that the Mercury space project created their software in half-day "sprints". Back in the '60s, on punch-card machines (I guess).

And Pulse Audio was started by Pottering but he quickly moved on

Which is pretty much what I blame him for.

He has a history of starting ambitious (maybe overly so) projects, doing all the fun stuff until it kinda sorta works, and then riding off into the sunset.

Thank you for making me aware.

I wish the idea that DevOps was a role or activity would die.

If like buttons will be disallowed for privacy reasons, shouldn't the same also apply to Google captcha?

That would be a relief.

SEEKING WORK: Embedded/IoT development, development process consulting, product quality consulting

Location: Munich, Germany

Remote: preferred

I'm an experienced (>10 years) software engineer with management experience. I have a master's in mechanical engineering.

I've worked on all stages of embedded products, from product management, to specification, to coding, testing, and qualification. A lot of my career was spent working on safety-critical systems up to ASIL D / SIL4.

How I could help you:

  * advise in improving the quality of your product
  * close gaps in your team's embedded development expertise
  * organise and manage your development efforts
  * provide training
  * bring automated tests and continuous integration to your embedded projects (DevOps for embedded!)
  * close gaps in your team's embedded development expertise
  * help you comply with safety regulations
 

  * training and advising several German Fortune 500 companies on DevOps
  * managing a small, experienced team in the development of an industrial robot
  * advising a multinational company in the development of a highly safety-critical (ASIL D)
    automotive electronics component
  * advising a startup in the IoT development tooling space
  * coaching a startup team on improving their development workflow