Skip Navigation

Posts
1
Comments
315
Joined
3 yr. ago

  • It's worth bearing in mind that those bar charts on the Nevermore repo are showing the ratio of VOCs rather than the quantity, so make particularly nasty materials like ABS appear comparable to much safer ones like PLA. It's not going to do you any good if you melt several kilos of PLA in a pan then take the lid off and huff the fumes, but running a single 3D printer with PLA in a large room is going to be pretty safe. The main VOCs emitted by PLA aren't that harmful - some like acetone and acetaldehyde are produced by the human body and found in food (athough turning alcohol to acetaldehyde is what causes hangovers), methyl methacrylate is used to glue in hip replacements, and isobutanol is often a fermentation byproduct that ends up in alcoholic drinks. That doesn't mean that PLA fumes are completely harmless, but means that it's not worth worrying about the level of harm as running a printer in a room with the door open for a whole day is probably somewhere around the level of harm as eating cooked food or having a small beer.

  • Exhaust/intake fans generally aren't too important - materials like PLA that tolerate the air in the printer being replaced have very low emissions of potentially harmful VOCs and particles, and materials like ABS that emit lots of nasty stuff want the chamber air to stay hot, so having a fan replace the hot air with cold air isn't great.

    If you do have nasty stuff in the printer chamber that you want to send out a window, then the exhaust fan is the more important one. Unless your chamber is totally sealed, an intake fan is going to increase the chamber pressure and encourage contaminated air to go out any gaps, whereas an exhaust fan makes the pressure lower inside the chamber, so encourages clean air to come in through the gaps, stopping contamination escaping. Obviously, this is only relevant if you've got a vent tube or filter on the extractor, as if it's just extracting into the room, there's no difference between it extracting the air and it leaking.

    I guess maybe the use case for an intake fan is either if you've got a material that wants the coldest air possible, so want to swap the chamber air for outside air as quickly as you can, or if you've got the exhaust fan venting into a chamber where you're filtering the air without letting it cool down much, and the intake draws from that chamber. I don't think either of these are particularly common situations, though.

    I've got a non-max SV08, and I just don't have an extractor or intake fan on my enclosure, and feed the extractor fan wire to my air filter.

  • If you're the kind of person who wants a particular person banned, you probably want to be on the kind of instance that would ban them, and then from your perspective, they'd be banned, so you'd never have to see their posts. It still being possible to interact with them from other instances isn't any more of a big deal than it being possible to interact with them on an entirely different website after they're banned from regular social media - no one can ban someone from the whole Internet.

  • I know people who say exactly this kind of thing entirely seriously (potentially because they first saw it as an unlabelled joke that they took too seriously). Sometimes people are just incorrect pedants smugly picking fault with things that aren't even wrong.

  • It depends on the sense of wet that you're using. Most of the time, the relevant kind of wet is how much water something contains, and water achieves peak theoretical wetness by that definition. It's only in specific circumstances that the surface is coated evenly by a wetting agent definition is relevant, like painting or firefighting.

  • There aren't currently any RISC-V hardware implementations that support big endian (although I guess someone must have tried it on a simulator), so supporting it in the Linux kernel is about as useful as supporting any other hypothetical CPU that only exists on paper. The mainline kernel is meant for computers that exist in the real world, so supporting BE RISC-V should only happen after such CPUs have actually been made. As things stand, there's nothing to suggest that anyone will bother making them, so the Linux maintainers shouldn't bother supporting them.

  • Technically Temu doesn't import anything. They're allowed to sell toxic or otherwise dangerous goods because the customer's the one importing them, and there are plenty of things you're allowed to import for personal use that you wouldn't be allowed to import for retail. The EU's working on closing this loophole, but the UK isn't in the EU anymore.

  • They got lots of consultants in from MindGeek who own Pornhub etc. and several age-verification services. They told the government that the consultants who were raising issues were overreacting, and the government believed them because obviously the world's largest porn company wouldn't encourage them to enact a law that would do bad things to the porn industry. They didn't stop to think that the law as written means there's now a requirement for smaller compliant porn sites to either spend more than their total revenue implementing an age-verification system or buy in one of the ones MindGeek own.

  • The law was announced a long time before it came into effect, so companies that didn't do anything to become compliant in advance were playing chicken in the hope that it'd be repealed before they ever had to obey it.

  • It's not shifting goalposts, you've just been arguing against Star Trek missing different goalposts to the ones everyone else understood it to be aiming for for several posts.

    The Fedaration core worlds are ones like Earth, Vulkan, Andoria and Tellar that have been member worlds for a very long time and are physically closer to the center of Federation territory. By the time of TOS, it's obviously not just the founding four worlds, but as TOS is a series about a multi-year deep space exploration mission, nearly every planet the Enterprise visits is going to be either outside the Fedaration or a frontier world. If a planet only gets a throw-away line rather than a load of exposition about how they've been a member for decades and several of the crew are from there, then that's enough to say it's a frontier world.

  • You've just listed a bunch of incidents on frontier worlds and said that proves they haven't solved any problems on core worlds. SIgning some paperwork to join the Federation doesn't instantly solve all your problems, and colonies aren't founded with prescience that means they avoid ever running into problems. Also, you've ignored the key point that it's meant to be relative to what's possible for modern humans, so things like being seriously disabled after exposure to high levels of fictional kinds of radiation like Pike was instead of being a very dead puddle of goo is a huge victory.

  • I think you've got lost in the weeds a bit. They've solved all those problems on Earth. They've spread those solutions around the core worlds of the Federation. They're still working on spreading the solutions to other worlds and bringing those worlds into the Federation. The fact that it's still a work in progress ending war or disease on a galactic scale doesn't mean that they can't have already succeeded on the scale that's relevant to humans contemporary to when the show was made.

  • Oh Boy!

    Jump
  • We're in a thread that was started by someone complaining that their Windows machine kept waking up seemingly on its own when they put it to sleep, so how wake on LAN behaves for a computer that's completely shut down was never particularly relevant, and certainly not something to be taken as the only situation we're discussing. When a computer is asleep, wake on LAN can wake it, and because the OS is still loaded, it doesn't need to do a full boot before running any wake on LAN handling it has. If wake on LAN is disabled in the motherboard settings, then a computer in a deep sleep like S3 can't respond to network activity at all.

    Also, I'm not sure where you've got the idea that wake on LAN is mainly for fully powered off machines. There's a reason it's usually called wake on LAN, not power on by LAN. The ability for a network event to power on a machine from S5 power off is usually a separate setting and isn't even possible on all hardware that supports wake on LAN.

    I'm also not sure where you got the idea that only the hardware aspect counts as wake on LAN and the OS-side handling for being woken on LAN doesn't count. Like with many things related to computers, it requires a hardware aspect and a software aspect working together to form a whole system, and in this case, it's the whole system that's called wake on LAN.

  • Oh Boy!

    Jump
  • It's not any packet that's waking up machines configured to wake on LAN without restricting it to magic packets, it's any packet addressed to the machine's MAC. Just like a regular packet when the machine's fully awake, it's specific to the network adapter with that MAC, and gets handled by that network adapter. Once it wakes the machine (either to fully on or a sleeping-but-still-doing-things state like S0), the OS starts/resumes and is told why it was started and can choose to access the packet and respond to it. From the perspective of the device on the other end of the wire, it sent a packet to a machine and got the response it expected. It doesn't have to know whether the machine was fully powered on or whether it woke up to deal with the request before going back to sleep again.

    By default, for most network traffic that partially wakes Windows when the machine has wake on LAN enabled in the UEFI settings, Windows sees it's been woken by LAN activity, checks the packet, decides it doesn't care, and goes back to sleep before anyone notices (or remains in S0 sleep if it was in S0 sleep as it wouldn't need to wake up to deal with the packet). For a few other kinds of LAN activity, it opts to respond to the packet. If you've got your UEFI settings set to only wake on magic packets, these won't make it that far, though. There's also a Windows setting to force it not to respond to regular non-magic packets and immediately go back to sleep if it's woken by them.

  • Oh Boy!

    Jump
  • The MAC-specific magic packet is an optional mode for wake on LAN, not a mandatory one. Plenty of network adapters forward packets to the OS if wake on LAN is enabled and let the OS decide whether it only wants to respond to magic packets, and by default when wake on LAN is enabled, there are other kinds of packet Windows responds to, e.g. Address Resolution Protocol, which lots of routers use to check whether devices are still connected. It's not supposed to wake the machine, especially if S0 sleep is enabled, but it can, especially if it's done excessively.

  • Oh Boy!

    Jump
  • When Windows wakes itself up to do things like that, it wakes itself to a different sleep level where it can still do things but the machine isn't visibly on. That's the whole point of S0 sleep. If it's fully waking itself up to do things, then either S0 sleep is disabled or there's a firmware bug affecting the motherboard that means certain actions during S0 sleep will exit sleep (which is more common than it should be).

  • Oh Boy!

    Jump
  • That's almost certainly because you've got wake on LAN enabled in your BIOS settings and something else on your network wants to have a late-night chat with your computer.

  • Webp

    Jump
  • Oops. I'd somehow missed that there was now a third kind of JPEG.

  • Then they're an instance admin, not a mod, and you probably didn't want to be on their instance anyway. Unlike an admin ban on Reddit, it doesn't stop you using Lemmy/mbin/Piefed as there are other instances.