AnyOldName3

I've definitely noticed less shininess than the same filament was getting at the same temperatures on my previous printer, except for the first layer. As the first layer prints without part cooling, my guess is that the extra part cooling versus the other printer means it's setting before it's had time to self-level. If that's right, then turning down the part cooling (and then also the speed so you can get away with the reduced part cooling) would make things shiny again. I've not bothered investigating that, as most of what I print is either functional, where I wouldn't care about shininess, or gets painted, where any shininess would come from paint or clearcoat.

As someone who's just spent half an hour reading Wikipedia thanks to this thread, I can now dispense a summary of what I read to make it feel like I didn't just waste a chunk of time I should have spent in bed by wasting another chunk of time I should be spending in bed.

Fats are made out of fatty acids, which are carboxylic acids with a longish carbon chain. A saturated fatty acid only has single bonds between carbon atoms, a monounsaturated fatty acid has a single double bond somewhere in the chain (and these are sometimes things that turn into buzzwords, e.g. omega three oils are ones where there's a single double bond three along from the end of the chain), and a polyunsaturated fatty acid has more than one double bond.

Single bonds in a carbon chain can only be one way around, so you don't get isomers of saturated fatty acids, but double bonds in a carbon chain can be in either of two orientations. If the hydrogens are on the same side for both sides of the bond, that's the cis orientation, and if they're on opposite sides, that's the trans orientation. Most natural unsaturated fats are cis, so they generally don't get explicitly labelled as cis fats, and just the trans ones get the extra label. Notably, though, vaccenic acid, which is about 4% of the fat in butter, is trans by default, so it's cis-vaccenic acid that gets the extra label.

Unsaturated fats tend to be more liquid at room temperature, but can be made by growing cheap vegetables. They also go off faster as free radicals can attack the double bonds. Saturated fats tend to be solid at room temperature, but mostly need to come from animals or more expensive plants (palm fat is an exception - it's cheap and mostly saturated). It's therefore desirable to use industrial processes to artificially saturate fats, and we can do that by heating them up and exposing them to hydrogen in the presence of a catalyst like Nickel. You don't necessarily want to fully saturate your fat, though, so might stop part way, and if you do, unless you intentionally tweak the process to avoid it because it's the 21st century and you're legally obliged to, you get some of the partially hydrogenated fat switching from cis to trans.

Over the course of the last century, we realised that (except for a few like vaccenic acid) trans fats are harmful in lots of exciting ways, e.g. messing up cholesterol, blocking your arteries, and building up in your brain. They've therefore been banned or restricted to certain percentages in a lot of the world. You can get a similar effect by fully hydrogenating things to get safe (or at least safer) saturated fat and mixing it with the unmodified fat, or by switching everything that used to use hydrogenated vegetable oil to using palm oil, which is one of the driving forces behind turning rainforests into palm plantations.

Apparently, this was twenty five minutes of writing, so I'm nearly up to an hour of thinking about fats.

I ran the printer's pre-sliced 12-minute benchy with cheap Geeetech PLA filament, and it didn't come out great, but then realised that when I'd removed the nozzle clog that was there from the factory (apparently they test some nozzles during QA, so mine had some dregs of filament with a lump that needed a cold pull to shift it) I'd accidentally plugged one of the part cooling fans into the wrong header and it wasn't running. After fixing that, it came out much better than what you've got here, despite a pause part way through due to trying to do it with the tail end of a roll.

I've read that the throat cooling isn't great for PETG as the fan as it draws warm air from inside the toolhead shroud, and there's an alternative one on printables that avoids this problem (although a duct to isolate the fan and its cutout in the shroud from the rest of the shroud interior might be simpler), so that could be related as you're running PETG.

Conspiracy theory: they realised this news was about to break, and removed the comment section because they expected a shitshow where every one of their customers saw comments pointing out their crimes.

As a dub watcher, the comment section was important. The dub comments were the only place to see what an unsubtitled background sign said or which scene had been cut from the manga that explained why something weird happened without there being comments from sub watchers full of spoilers for a couple of episodes later, which they don't consider spoilers as the subtitled version of that episode was a week old.

I said he more-or-less killed him, not that he actually killed him. Care was not taken to ensure he'd be revived or revivable. He was left forgotten in a pocket. The likely outcome was that he remained forgotten and didn't get wet until he'd been dropped under some furniture, crushed like a stock cube or gone mouldy. Maybe he had dependents, like a young child who'd have died without their parent. It being theoretically possible to revive someone later doesn't make turning them into a dehydrated cube meaningfully better than making them dead if you don't have a strong plan with a failsafe to make sure they stop being a cube. Even with guaranteed revival, if they're a cube for long enough that they notice the lost time, it's just like roofying someone and holding them hostage for a while. Do not turn museum guys into dehydrated cubes.

If not for an accident where he ended up in a washing machine, he'd have been left as a cube indefinitely. From a cube's perspective, there's no difference between being a cube and being dead.

Upstream Firefox doesn't comply with FDroid's rules (thanks to the 'proprietary bits and telemetry' Handles mentioned), so is only available from the Play Store or as a loose APK that won't auto-update.

He did more-or-less kill, and then steal the identity of, the museum guy. He's not a paragon of virtue, either.

A big part of the reason was that Facebook offered game studios a big upfront sum if they made their games work on whatever headset they were selling at the time in standalone mode with no major caveats. The headset only had an anemic mobile GPU, so was only capable of as much as mobile games were doing at the time. A bunch of studios took them up on this offer, and cut back their projects' scope to be viable under the hardware constraints, so nearly everything that got made was gimmicky mobile-style minigames, and obviously that's not what makes people want to drop hundreds of dollars on hardware, as they can get their fill by borrowing someone else's headset for an hour.

Mobile GPUs have improved, so standalone headsets aren't as terrible now, but we missed the expensive toy for enthusiasts and arcades phase and soured most people's opinions by making their first VR experience shovelware.

It's not realistic to demand to own games in the same way as a spoon any time soon. It is, however, pretty reasonable to demand you own games like you'd own a book. You can chop up a book and use it to make a paper maché dog, but you can't chop up the words within to make a new derivative book (or just copy them as its to get another copy of the same book except for a single backup that you're not allowed to transfer to someone else unless you also give them the original). The important things you can do with a book but not a game under the current system, even with Gog, are things like selling it on or giving it away when you're done with it and lending it out like a library.

About a hundred years ago, book publishers tried using licence agreements in books to restrict them in similar ways to how games and other software are restricted today, but courts decided that was completely unreasonable, and put a stop to it. In the US, that's called the First Sale Doctrine, but it has other names elsewhere or didn't even need naming. All the arguments that applied to books apply equally well to software, so consumers should demand the same rights.

The vfs of MO2 isn't the thing that's hard to port. FUSE would make it fairly straightforward and the main reason USVFS is complicated in the first place is that there's not a way to make a fast VFS under Windows due to the higher overhead of going back and forth between kernel and user mode, so it has to resort to hooking most of the multitude of functions in the Win32 and NT filesystem APIs instead of just providing about twenty callbacks like you'd do with FUSE.

A mod manager looks much simpler than it is as it looks like you're just keeping track of lists of files, but mods come in the most insane packaging formats ever devised (e.g. with mad compression schemes and custom scripting languages) and mod managers need to selectively pretend to have all the bugs of every other mod manager as mods get made that rely on a particular bug in the mod manager their author used.

MO2 has a particular extra complexity when thinking about porting it to Linux in that it uses Win32 APIs in lots of places it doesn't really need to, and also does so in a few places where it's genuinely much more convenient that it does. It also uses a custom build system generator generator because its CMake and dependencies are too complicated for a human to practically deal with, so it would take loads of work to even build a completely unusable binary on Linux. We have people volunteer to do the work a few times a year and read a warning I write that looks like this comment and claim to have the willpower to do it anyway, but none of them have ever submitted a single commit.

As a counterpoint, I've had Ubuntu's installer and grub's updater overwrite and break Windows' boot files several times, but never had the opposite happen (I've had both destroy themselves, though). Thankfully, I know how to rebuild the necessary parts of a Windows install, so it's never been a catastrophe, but it's irritating to see what's always been the source of the problems I've had be held up as infallible. Possibly this is a problem unique to Ubuntu - I'm happy to blame Canonical - so maybe it could be entirely sidestepped with other distros.