Nice - thanks for this

Not my experience. I’ve had my X1C for a year now and have not had to ‘dial in’ a single thing.

Most of my prints are functional items in PETG of various colous. Some PLA for cosmetic parts. And I did some things in TPU earlier in the year. Probably been through like 10kg of filament on it.

Can’t think of a single serios print failure that wasn’t human error - e.g. forgot to clean the bed, didn’t support it properly.

My one gripe is that when changing PETG reels, it doesn’t always manage to wipe the nozzle very well leaving a few rogue stringy bits that usually just pull off.

And obviously I don’t love the closed-wall software situation, but their software is pretty good.

I also wasn’t aware so had a search.

If you don’t mind Reddit, this thread is interesting… https://www.reddit.com/r/rails/comments/133lcyl/can_someone_explain_what_happened_with_the/

Or there’s this… https://www.theverge.com/2021/5/3/22418208/basecamp-all-hands-meeting-employee-resignations-buyouts-implosion

Edit: Actually this is probably the most comprehensive summary: https://schneems.com/2021/05/12/the-room-where-it-happens-how-rails-gets-made/#the-basecamp-incident

I get that, and it was almost certainly Booking.com who leaked it as I have had shady messages through even their own messaging platform before…

I think what baffles me is that this gets so close to convincing (if you’re not internet savvy), and then they throw in something so bizarre like having a username of “Rus Education” 🙄

Unfortunately, I just don’t have the social capital to move people off of Meta messaging services… A good 50% of my friends have ditched FB, but somehow saw WhatsApp as the solution 🤦

I’ve got a relatively new Fedora install and I think I’ve seen this too - not had time to fully investigate, but have found on occasion if I leave it for a day the monitor brightness has wound down.

Based on how you’re observing the loading move from 100% CPU ro 100% GPU, I would suggest that it is “working” to some extent.

I don’t have any experience with that GPU, but here’s few things to keep in mind with this:

1. When you use a GPU for video encoding, it’s not the case that it’s ‘accelerating’ what you were doing without it. What you’re doing is switching from running a software implementation of an HEVC encoder on your CPU to running a hardware implementation of an HEVC encoder on your GPU. Hardware and Software encoders are very different to one another and they won’t combine forces; it’s one or the other.

2. Video encoders have literally hundreds of configuration options. How you configure the encoder will have a massive impact on the encoding time. To get results that I’m happy with for archiving usually means encoding at slower than real-time for me on a 5800X CPU; if you’re getting over 100fps on your CPU I would guess that you have it setup on some very fast settings - I wouldn’t recommend this for anything other than real-time transcoding. Conversely, it’s possible you have slower settings configured for your GPU.

3. Video encoding is very difficult to do “well” in hardware. Generally speaking software is better suited to the sort of algorithms that are needed. GPUs can be beneficial in speeding up an encode, but the result won’t be as good in terms of quality vs file size - for the same quality a GPU encode will be bigger, or for the same file size a GPU encode will be lower quality.

I guess this is a roundabout way of suggesting that if you’re happy with the quality of your 100fps CPU encodes, stick with it!

3x 3 day pre-season tests for the new regs

Single GPU with scripts that run before and after the VM is active to unload the GPU driver modules from the kernel.

I think this was my starting point and I had to do just a few small tweaks to get it right for my setup - i.e. unload and reload the precise set of kernel modules that block GPU passthrough on my machine.

https://gitlab.com/Karuri/vfio

At this point from a user experience p.o.v it’s not much different to dual booting, just with a different boot sequence. The main advantage though is that I can have the Windows OS on a small virtual harddrive for ease of backup/clone/restore and have game installs on a dedicated NVME that doesn’t need backing up

I’ve been 100% linux for my daily home computing for over a year now… With one exception… To be honest I didn’t even try particularly hard to make gaming work under Linux.

Instead I have a Windows VM - setup with full passthrough access to my GPU and it’s own NVME - just for Windows gaming. To my mind now it’s in the same category as running console emulation.

As soon as I click shutdown in windows, it pops me straight back into my Linux desktop.

I had some hard to track down intermittent network issues when I upgraded from LMDE5 to LMDE6 - the solution was to get a newer kernel from backports - its fairly painless…

https://forums.linuxmint.com/viewtopic.php?t=413995#:~:text=You get the kernel updates,using with command uname -v.

Yep, especially surface mount lithium batteries - they’re very sensitive to the solder reflow profile being juuuust right

Just to add in case you’re not aware, the EF-RF adapters are literally just spacers that shift the lens mount to where it would have been if there was a mirror in there - optically it’s just 24mm of air, so no quality impact at all.

The only thing to keep in mind is that there is a slight autofocus slow-down with the much older lenses, but not enough to bother me.

I literally just faced this same dilemma! I went online looking to upgrade the kit lens I’ve had on my Canon EOS 70D for nine years and got sucked into the mirrorless hype.

In the end I sortof ended up upgrading both… I got a great deal on a second hand Canon mirrorless body, and because it has in-body image stabilisation I could then spend a lot less money to get a 25 year old ‘L’ series EF lens rather than a newer one with IS in the lens.

I’m extremely pleased with this set-up so far, and even more pleased that I can add to my lens collection in future for much less money than if I needed IS hardware in every lens.