artair

joined 2 years ago
[–] artair@pawb.social 1 points 9 months ago

The print job didn’t fail, so I’m going to write this off as a kernel bug until/unless it happens again. I’m just glad I can run long jobs again!

[–] artair@pawb.social 1 points 9 months ago

The print job didn’t fail, so I’m going to write this off as a kernel bug until/unless it happens again. I’m just glad I can run long jobs again!

[–] artair@pawb.social 2 points 9 months ago (1 children)

That, or this may have been a kernel bug issue. 🤣

The problem started around the time I updated both my kernel and OctoPrint to the latest version. However, there was a new kernel version available and I took the update yesterday. I connected the printer, and it stayed online overnight without any issues. Stress-testing stuff now with a long print job that should run past midnight.

We’ll see if the Dark Lord of Bugs has been exorcised when it finishes!

[–] artair@pawb.social 1 points 9 months ago (1 children)

Checked that and the systemd timers. No dice. However, this problem started right around the time I updated my kernel package, and there was another update that I applied yesterday. I connected the printer and let it sit overnight. No midnight disconnections.

I’m running a print job now that should run past midnight. Fingers crossed that this was just some kind of transient kernel bug!

 

A new and bizarre issue has emerged on my Linux Mint server that seems specific to my Ender 3 and OctoPrint. Every night at midnight, regardless of whether a print is running or not, the USB connection to the Ender fails and restarts. (See screenshot from my Telegram OctoPrint plugin.) I’ve tried setting usb.autosuspend to -1 in GRUB, but that doesn’t seem to help.

I’m completely stumped and could use some advice. The failures are far too scheduled and predictable to be a random hardware failure. A relevant chunk of /var/log/syslog is included below for reference.

May 5 00:00:03 borgcube systemd[1]: logrotate.service: Succeeded. May 5 00:00:03 borgcube systemd[1]: Finished Rotate log files. May 5 00:00:03 borgcube kernel: [93921.837884] usb 1-5.4: new full-speed USB device number 9 us ing xhci_hcd May 5 00:00:03 borgcube systemd[1]: man-db.service: Succeeded. May 5 00:00:03 borgcube systemd[1]: Finished Daily man-db regeneration. May 5 00:00:03 borgcube kernel: [93922.059024] usb 1-5.4: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.63 May 5 00:00:03 borgcube kernel: [93922.059026] usb 1-5.4: New USB device strings: Mfr=0, Produc t=2, SerialNumber=0 May 5 00:00:03 borgcube kernel: [93922.059027] usb 1-5.4: Product: USB2.0-Serial May 5 00:00:03 borgcube kernel: [93922.066323] ch341 1-5.4:1.0: ch341-uart converter detected May 5 00:00:03 borgcube kernel: [93922.066896] usb 1-5.4: ch341-uart converter now attached to ttyUSB0 May 5 00:00:03 borgcube mtp-probe: checking bus 1, device 9: "/sys/devices/pci0000:00/0000:00:1 4.0/usb1/1-5/1-5.4" May 5 00:00:03 borgcube mtp-probe: bus: 1, device: 9 was not an MTP device May 5 00:00:03 borgcube snapd[1104]: hotplug.go:200: hotplug device add event ignored, enable e xperimental.hotplug May 5 00:00:03 borgcube mtp-probe: checking bus 1, device 9: "/sys/devices/pci0000:00/0000:00:1 4.0/usb1/1-5/1-5.4" May 5 00:00:04 borgcube mtp-probe: bus: 1, device: 9 was not an MTP device

 

A new and bizarre issue has emerged on my Linux Mint server that seems specific to my Ender 3 and OctoPrint. Every night at midnight, regardless of whether a print is running or not, the USB connection to the Ender fails and restarts. (See screenshot from my Telegram OctoPrint plugin.) I’ve tried setting usb.autosuspend to -1 in GRUB, but that doesn’t seem to help.

I’m completely stumped and could use some advice. The failures are far too scheduled and predictable to be a random hardware failure. A relevant chunk of /var/log/syslog is included below for reference.

May 5 00:00:03 borgcube systemd[1]: logrotate.service: Succeeded. May 5 00:00:03 borgcube systemd[1]: Finished Rotate log files. May 5 00:00:03 borgcube kernel: [93921.837884] usb 1-5.4: new full-speed USB device number 9 us ing xhci_hcd May 5 00:00:03 borgcube systemd[1]: man-db.service: Succeeded. May 5 00:00:03 borgcube systemd[1]: Finished Daily man-db regeneration. May 5 00:00:03 borgcube kernel: [93922.059024] usb 1-5.4: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.63 May 5 00:00:03 borgcube kernel: [93922.059026] usb 1-5.4: New USB device strings: Mfr=0, Produc t=2, SerialNumber=0 May 5 00:00:03 borgcube kernel: [93922.059027] usb 1-5.4: Product: USB2.0-Serial May 5 00:00:03 borgcube kernel: [93922.066323] ch341 1-5.4:1.0: ch341-uart converter detected May 5 00:00:03 borgcube kernel: [93922.066896] usb 1-5.4: ch341-uart converter now attached to ttyUSB0 May 5 00:00:03 borgcube mtp-probe: checking bus 1, device 9: "/sys/devices/pci0000:00/0000:00:1 4.0/usb1/1-5/1-5.4" May 5 00:00:03 borgcube mtp-probe: bus: 1, device: 9 was not an MTP device May 5 00:00:03 borgcube snapd[1104]: hotplug.go:200: hotplug device add event ignored, enable e xperimental.hotplug May 5 00:00:03 borgcube mtp-probe: checking bus 1, device 9: "/sys/devices/pci0000:00/0000:00:1 4.0/usb1/1-5/1-5.4" May 5 00:00:04 borgcube mtp-probe: bus: 1, device: 9 was not an MTP device

[–] artair@pawb.social 1 points 1 year ago

Those are HUGE increases on the Seneschal abilities. It really validates all the criticisms about them being underpowered when the season started.

[–] artair@pawb.social 9 points 1 year ago

Henhouse is fine, secure says local fox.

[–] artair@pawb.social 4 points 1 year ago

Having tried it, I’m hoping I can forget Bluesky.

[–] artair@pawb.social 40 points 1 year ago (2 children)

Not only do they still exist, but they also have a Mastodon presence.

Example: @topintech@flipboard.social

[–] artair@pawb.social 1 points 1 year ago

You’re not the hero we deserve, but you’re the hero we need.

[Salutes in English Major.]

[–] artair@pawb.social 10 points 1 year ago

I was able to bypass the paywall using Google Search’s “cached” view of the page.

https://webcache.googleusercontent.com/search?q=cache:_Uum_1PMdaoJ:https://www.ft.com/content/f9455749-3597-481e-9812-f1c6c6116ebf&cd=9&hl=en&ct=clnk&gl=us&client=safari

As for the content, although I agree with some of the tentpoles to this article, the rest seems a bit saggy. It’s more of an op-ed piece without much more than subjective opinions. If the Financial Times wants to paywall this kind of stuff, they’d better make it worth the price. (This definitely wasn’t.)

[–] artair@pawb.social 1 points 1 year ago

If this is the quality of “independent journalism” we can expect on Twitter/X/TwiX, then let it burn to the ground. Clickbait isn’t journalism.

[–] artair@pawb.social 40 points 2 years ago (3 children)

Speaking from years of experience in IT (nearly thirty of them), I can give my own unscientific opinion: because people put too much faith in certifications, and refuse to do any on-the-job training. You can have five of the six skills listed in a job ad, but if you don't have that all-important sixth one, your application will get round-filed. It doesn't matter if it would be a simple matter to train a tech on that one thing. Businesses want phoenixes for chicken scratch.

Certifications are a boondoggle, and have been for years. The tests have been rigged in such a way that candidates need to take them again and again to pass, and they get charged a fee for each attempt. The test itself is a revenue source for companies. The "prestige" those certifications bring for the companies that front them is based on their difficulty, not on their relevance or fairness.

I once attended a Microsoft certification "boot camp." We all worked our asses off, studied the material, and most of us passed at least one test. Nobody passed all three exams except for one person. I had noticed that person using test prep software with a logo that didn't match the stuff we'd been given. It looked like an orange DNA helix.

After the last test, a bunch of us milled around outside the building, and I asked the guy who passed how he made it through. He ran for his truck so fast that there was practically a dust cloud behind him. That's when I decided to look up that logo on Google.

He'd been using a "brain dump" service. For those unaware of what a "brain dump" is, it's when a third-party company sends a bunch of people to intentionally fail the exams over and over. During each attempt, those people memorize the test questions. Then the company has their plants aggregate all the possible questions in an exam pool and the correct answers to them. In effect, it's a copy of the whole test.

Brain dumps are extremely common in IT. When I worked at VMware, many of our own employees used them to pass certification exams that were mandatory for continued employment. Those people had been doing their jobs for years. They just needed a bogus piece of virtual paper to prove it to our executive leadership. It was all about appearances.

Why is tech struggling for qualified workers?

Because it refuses to acknowledge them.

view more: next ›