That voltage spike only applies to flyback converter. Your typical buck/boost converter doesn't do that - the current waveform is a sawtooth, and voltage ripple is designed to be in the mV range.
The nature of surges is not simple like that - a lightning strike can easily blow MOVs and inrush limiting resistors in multiple devices. I come from a rural area and coming to someone's house with a bag of fresh MOVs and resistors is not an uncommon thing after a big storm.
I believe that it highly depends on the type of the surge protector, their ratings and the cable network involved. I do not think that it would cause issues in two surge protectors from power outlets connected in series, and depending on their rating and switching characteristics maybe both could trigger, I agree.
I believe the question is if it's safe at all to do so rather than whether the protection works or not, though I'd have to be all ears about interactions between multiple parallel surge arrestors.
It's not very different from daisy chaining normal extension cords - safe if you know what you're doing (not exceeding the current rating on any of them). Most surge protectors are fused, making them safer to daisy-chain than normal extension cords.
> It's not very different from daisy chaining normal extension cords - safe if you know what you're doing
It’s not safe, and it’s expressly forbidden by the NEC, see 11.1.5 below:
> 11.1.5 Extension Cords
> 11.1.5.1
> Extension cords shall be plugged directly into an approved receptacle, power tap, or multiplug adapter and shall, except for approved multiplug extension cords, serve only one portable appliance.
Daisy chaining extension cords is unsafe and not recommended. Only use extension cords that you’ve inspected and are properly rated for the environment (don’t use indoor cords outside, don’t use an outdoor extension cord outdoors unless it’s GFCI protected) and power usage of the device you are powering.
Any time electricity has to flow through a splice or mechanical connection, the possibility of a loose connection causing an arc and subsequent fire exists.
It’s unlikely to happen to you specifically, but it does happen and avoiding electrical fires is a good thing if it can be avoided.
Daisy chaining power strips is also forbidden by the NEC:
> 11.1.4.2
> The relocatable power taps shall be directly connected to a permanently installed receptacle.
Yes, there is a risk of failure involved with anything electrical, but I don't see why anyone would consider chaining extension cords inherently dangerous enough to ban. It increases the number of connections, but that's a miniscule risk compared to the 5+ connections an extension cord might have on its own. The only significant risk I know is people disregarding the max amperage rating of everything in that chain.
For anecdotal experience, I've had both extension cords and wall plugs fail (nothing serious thankfully, but they did get a bit melted), but in those cases it had nothing to do with my extension cord chains, but rather an internal connection failure.
AFAIk, the rationale for extension chords is that they are sized to cause a controlled amount of voltage drop within their lenght. If you keep adding them, you will increase the drop, and many devices will react by increasing the current.
This is correct. For a 120v 12FLA load at a distance of 50’, you’re fine using a #14 cord. If you double that to 100’, you need to use #10 cord to account for the voltage drop. As voltage drop increases, the amount of current flowing through the cord increases, which can potentially heat up the insulation beyond its rated temperature.
It is probably one of those little process changes to minimize chance of catastrophic failure. Sure, the risk of the daisy chained system going poof is low, but not zero. Instead, you should try to re-work your plans so you do not need to daisy chain.
As an aside, increasing the length of extension cords can cause premature failure of some devices (mostly motorized tools, especially cheaply-made ones) if the wire gauge is inadequate, due to voltage drop.
As a general rule, I wouldn’t run tools past 50 feet on anything smaller than 12 AWG (and really, 14 AWG is the smallest I’d go for any length; anything smaller isn’t safe for most loads).
Note that bstats only tracks Bukkit-compatible servers. It doesn't track Vanilla/Fabric/Forge/etc. installations, so take these numbers with a grain of salt.
There are several primary ways to run a Java Edition server:
1. Pure vanilla server.jar. Has horrible performance, little flexibility, but in the end, it Just Works. This is the server that Realms (Mojang's paid hosting service) uses. In recent versions, some modding is possible via datapacks.
2. Fabric Loader and some vanilla-compatible mods like Carpet etc. Here, "vanilla-compatible" means that a vanilla client can still connect. This is the preferred way of playing for the TMC (Technical Minecraft) community since the underlying server stays mostly vanilla, down to the smallest details and bugs, and no behaviors are changed. The TMC community becomes very agitated when someone tries to "fix" some bugs - they rely on those bugs.
3. Forge/Fabric with mods that change the gameplay, and require the mods to be present on both client and server. This is the traditional "modded" experience, as seen on TV.
4. Bukkit/Spigot/Paper/Purpur, various generations of server software that heavily patches the vanilla server, fixing bugs, adding new functionalities, and presenting a very comprehensive Plugin API, while still allowing vanilla clients to connect. This is the software used by servers that implement custom gamemodes, public servers that need griefing/duping/exploit protection. Many high tech farms don't work on Paper because of how many things it "fixes".
5. Folia - a fork of Paper that has multithreading support. It comes with its own can of worms.
Performance-wise, Fabric+Lithium is probably the most performant in the default configuration, though if you're willing to remove functionality, you can probably get better performance out of Paper (at the cost of losing gameplay features).
As for Bugrock Edition: well... there is Geyser that lets you connect to a Java Edition server with a Bedrock client. ;)
Adding on to yours, since right now you have the most complete background answer.
There's some history in the "Bukkit" family that might make their chaos make more sense.
In the beginning, there was Bukkit, which was a plugin API. And there was its reference implementation, CraftBukkit. It was very popular, Bukkit was the de facto API for server-side modding, and I made 50 bucks off of advertising revenue share for downloads of my plugin, which was a lot for me as a high schooler with one (1) year of java experience. Times were good. Where was I? Oh yeah.
So, for a long good while, times were swell. Then iirc Microsoft announced they were acquiring Mojang (I think this was the precipitating event? Someone correct me if not). And the main Craft/Bukkit guy threw in the towel and pulled a very clever poison pill: he DMCA'd his own repos. You see, Mojang essentially didn't care about server.jar distribution because they were a cool indie company. So CraftBukkit just included it. Which meant it was always in violation of Bukkit's GPL license since that code wasn't open source.
So anyway, CraftBukkit explodes in a supernova and the resulting stellar nursery produces Spigot which pioneered the distribution strategy that all successors would then use - they distribute a decompilation map and their source, then you run a jar that downloads server.jar and performs the unholy mixing of licenses on your machine.
This is where I left the scene so I only have a summary from here on out. Spigot is the main go-to for a while, but the stellar nursery is still hot, and so various creative differences produce Paper, which seems to have mostly caught on to replace spigot though it seems like spigot is still a nontrivial player as well. And these all still implement the same ole GPL licensed Bukkit API.
So Bukkit wasn’t the first. It was hMod in 2010. Everyone came over from hMod because hey0 disappeared for a hot minute in late 2010. Everyone from Bukkit came from hMod, although there were also holdbacks who didn’t like someone stealing the hMod community, but a gathering of major plugin developers and devs from hMod forced everyone’s hand (but also, hey0 disappeared for a relatively long time with no explanation).
hMod also had a problem: it didn’t attempt to reverse any of the code obfuscation from Mojang, so working with it was extremely difficult. When hMod came about, it predated the MCP project as well by like 3 months, which started as a major community effort to deobfuscate the codebase. Bukkit came after MCP and could take from it inspiration.
We are still in year 2010.
Fast forward many years later… Microsoft had nothing to do with what happened actually. Bukkit was secretly owned by Curse, and much later Mojang secretly bought Bukkit.
This secret sale pissed off a lot of the community and one of the core but non-OG contributors (Wolverness — he joined Bukkit much later) issued a DMCA against the codebase as a form of protest. This was obviously controversial but he also had a lot of support.
Mojang actually never substantially interfered with the wholesale illegal distribution of its source code.
Anyway, because Mojang was officially hiring the Bukkit team, but only limited to some members from the OG 2010 team, and with the other core contributors not being included at all, and with the DMCA taking down the repos, Bukkit became dirty and there wasn’t a future for Bukkit anymore. Spigot, which was then a performance fork of Bukkit, became the de facto successor (not to say that there weren’t many other options and competing choices in play too).
Spigot didn’t create their distribution strategy though. MCP did things this way.
I switched from Paper to Fabric +/- 3 years ago. It allows me to create better server-side mods than what I was able to make with the Bukkit/Spigot/Paper API.
Not that that API isn't impressive. I was also surprised to learn MCC uses it.
Windows also loves installing garbage drivers by default. I remember it was obsessed with installing an AMD GPU driver update )that only ever showed a black screen on boot) since it was newer than the working version I was using. I disabled the driver updates (this option in buried in a sub-dialog of a classic control panel option at the time) but since it had previously sniffed out that the driver existed it obsessively continued to download and install it in the background, re-bricking the install. None of the guides on clearing the download cache seemed to be able to convince it to give up, I eventually just reinstalled the OS without and internet connection and disabled the option before running updates.
reply