If the SystemD team want to manage network startup, system logging, firewalls and whatever else takes their fancy, then fine, go right ahead; just do it in a way that makes it easier for system admins to disable it and plug in a more fully featured and/or stable alternative, and do it as a child of PID1 so if/when it does crash it doesn't bring the whole system down with it.
Oddly enough, every one of the things you mention are: 1. able to be performed by things other than systemd when systemd is PID 1. 2. not performed by PID 1 when the systemd implementation is used.
3c) In general, while they minimally accommodate server-side daemon software, most of the development focus of systemd is for the desktop user's use-case.
I don't see how this is the case. Most of the newer features in systemd are server-oriented. Who runs nspawn/docker/etc on the desktop? Or stateless services? Who cares about unalterable logs on the desktop?
It seems like most of the features in systemd are actually more server-oriented.
I have to admit, I've never understood this fetishism for boot times. Boot times stopped being unreasonably long years ago. Why do people still care about modest improvements in speed to something that doesn't happen that often?
Anybody who runs thousands of servers on dozens of boxes, spawning and removing servers dynamically. That is, anybody using modern system administration practices. Booting a container under systemd takes milliseconds. Most of the alternatives don't grok containers at all, and they aren't adding 30s to a 1 minute boot cycle, but 30s to a boot cycle that otherwise might take a millisecond to run.
Obviously you don't use coreos. Configuration management is a big problem in the linux world, precisely because every daemon insists on storing its configuration in random files in random formats in/etc. The usual solution is to, gasp, start sticking all this stuff in a database. Then you either fix the daemons to use the database, or build a bunch of glue that parses the database and dumps a ton of files to/etc for compatibility.
How will anybody maintain all that junk, you ask? Simple, anytime you make a change you wipe the server and re-install it.
I suspect that it will take Slackware longer to move to OpenRC than it takes Gentoo to move to SystemD at the current pace.:)
I've used OpenRC for ages now, but systemd has a lot of clear advantages. I doubt I'll ever use it again. Gentoo is about choice so I'm sure it won't go away any more than twm will, but I suspect that it is only a matter of time before it isn't on the stage3s and you pick your init just like you pick your kernel/syslog/etc. You might start finding more and more Gentoo packages that lack openrc support as well, or where the openrc support is maintained by somebody other than the package maintainer.
Sure, but all those tools you need to mount/usr are all present in your initramfs. / is just a crude initramfs which pollutes your path once it is finished doing its job.:)
From every experience I've had with systemd, I'd say that it is NOT progress. I don't want every little thing integrated in the manner systemd does.
Integrated in what way? Sure, they have a bundled suite of applications, but you can swap out journald for syslog just as you can swap out koffice for libreoffice if you run KDE. It has some dependencies like udev and dbus, but that's just a design choice.
And frankly, OpenRC is a lot better.
How do you figure? I've been using OpenRC for more than a decade and there are a LOT of things it doesn't accomplish like: 1. Having upstream-provided service scripts for most packages. Most OpenRC scripts are custom-built by Gentoo maintainers. If a Gentoo maintainer doesn't maintain a script, you will have to write your own. 2. Actually stopping services thoroughly. If a service doesn't clean up children properly. OpenRC doesn't care. 3. Optional auto-restart. 4. Sane network configuration. The networkd configuration is much simpler than oldnet/newnet/whatever. 5. Drop-ins. I like a Gentoo-provided openrc script, but I want to set ionice. That means hacking up the script, and then merging in changes every time it is upgraded. With systemd I just stick a drop-in file into/etc that sets that one setting and systemd merges it in every time. 6. Booting in milliseconds in a container. I'm not sure how well it boots in a container at all, though I know this is being worked on. 7. Clean shutdowns when you're using stuff like lvm/raid/etc. Systemd can drop to dracut and allow the initramfs to do a full clean unmount. Sure, the read-only approach works reasonably well, but it always bothered me seeing OpenRC shut down with in-use messages.
OpenRC is about as good as it gets for a traditional bash-based service management system. I've always been happy to use it. However, unless I'm stuck on BSD or something I doubt I'll be using it much in the future.
That part, systemd is good at. I have no objections to systemd advantages as an init system. The large complexity of doing more than it should encompasses the non-init-system parts of systemd. For example, last I heard they just added DNS caching. Into the init system. Since when does the init system need to handle DNS caching?
I haven't heard anything about that (cite?). It does do DNS setup (systemd-resolved), but that is NOT part of the init system. It is a completely separate binary which can be interchanged with something like dhcpcd if you prefer. That seems like the unix way to me...
I'd also argue (controversially) that journald is outside the scope of an init system. It has some compelling arguments for its existence, but surely it should be a separate project rather than an integral part of systemd.
Journald is not part of the init system either, and there is no requirement to use it at all to use systemd. It simply integrates well with systemd.
I think your objection is that they maintain all this stuff and distribute it as part of the same source tarball. If I maintained by sysvinit, openrc, and bind and distributed a tarball containing all three without changing their current functionality, would that make any of them less "unixy?"
Emphasis on maybe... I'm sure a few devs still use openrc on Gentoo, but it seems like systemd has quite a bit of momentum. It seems just a matter of time before it becomes at least an equal default and you start finding more packages that have systemd support only than packages that have openrc support only.
A complex startup system that logs to a database rather than a text log, is just poor engineering.
Unless you are logging direct to a printer, I've yet to see a modern operating system that outputs a log that is human-readable. Most of them encode the log data in ASCII or UTF8 and store them in a series of sectors that likely fragmented all over the disk, requiring a complex set of tools to read a database that indicates where the data may be found on the disk, and communicate with the drive controller to retrieve the data. Oh, and outputting the log to the screen requires a bunch of console/display drivers.
I don't get the practical difference between the systemd journal and a log file in text format. Either way you need a bunch of tools to read them. At least with the journal you can be assured that it wasn't tampered with without detection.
At the moment, just about every major distribution except Slackware and Gentoo not only supports systemd, but ships with it on by default.
Uh, Gentoo supports SystemD just fine. It hasn't become the default yet, but it seems pretty close. I suspect a good percentage of the developer community runs it now.
The majority of systems I deal with are servers. They mostly have plenty of CPU and memory available and typically run very few services..... they boot plenty fast without systemd.
Are you sure about that? Before doing some updates to a server I'm running I shut it down, created a snapshot of the disk, and booted it back up. The complete operation took about 200ms I'm estimating (it didn't execute instantly, but I barely could have blinked in the time it took).
There is no way that would have worked if it wasn't running systemd. And no, this wasn't running on bare metal. Who runs servers on bare metal these days?
Ah, that hadn't occurred to me. I guess you could add a rotation axis to the thing. I figured the bigger issue would be jitter/quantization/etc. With an equatorial mount you just have a single continuous motor that just turns at the right rate and is continuous - so it would be very smooth. With a computerized alt-az even with rotation you'd end up with the computer firing off steps on all three motors at various intervals, but ultimately the movement of the thing would be a series of individual steps. With enough gear reduction I imagine that could be very fine and seem continuous, but if you cheap out the thing isn't going to be smooth, which would kill an exposure.
I'd have assumed that by now a motor-driven Alt-Az mount would be good enough to eliminate the need for an actual physical Eq mount. Just tell the thing where/when it is and maybe point it at a guide star and it should be able to simulate an Eq mount, assuming the steppers have sufficient resolution that you don't notice the steps in an exposure (but what kid is going to be taking photos anyway?). Then you can switch modes at will when panning around.
Heck, stick GPS and a compass in the thing and it could find a star for you and just ask you to tweak it to correct for compass/tilt error. That is $10 worth of extra parts these days.
I think History jumped the shark for me when I watched that WW1/2 miniseries a few months ago. The Mass Effect soundtrack was amusing, but the real winners were the Japanese Arleigh Burke destroyers. Ancient Aliens didn't really bother too much since I couldn't be bothered to watch it.
Honestly, those Battle-360-type shows never really impressed me much. They could use all that 3D/etc to do something to help me understand how the battles took place. Instead it involves a lot of pictures of a few soliders behind sandbags with the camera weaving around bullets suspended in mid-air, which has little to do with the actual battle.
It seems like authentication is important to modern society. I think the only real solution is a government-issued ID, capable of challenge-response. Even a PIN for the ID is useless if every company expects you to hand it over to them.
As it stands right now, it is SOP for an admin to block all exit nodes at the incoming router, the IP stack on the machine, the web server, and the application, because of abuse.
If only. It seems to be SOP to block relay nodes as well. I run one, which does not allow exits, and I run into lots of sites that block me. Must be fun for whoever gets my dynamic IP next.
People don't like to admit it but the existence of Nuclear weapons has prevented a major conflagration between the `big powers', at least since the Korean War (MacArthur wanted to use them there, his boss didn't).
Yup. It is certainly a big factor preventing war over the Ukraine. If the Ukraine had nuclear weapons, it would probably remain intact.
Would the US nuke China over an invasion of Japan? Probably not.
Would the US nuke Russia over an invasion of Germany, France, or the UK? Probably not.
In the end, when you're talking about doomsday the stakes are pretty high. Just letting the other guy invade your ally tends to look like a very good option. If you don't want to get invaded, having your own nukes is better than relying on somebody else's.
The fundamental issue is that credit cards are based on the premise that you can authenticate somebody using a shared secret that you share with everybody you do business with.
I can post my ssh public key in this post if I wish, and about the only thing anybody could do with it is give me access to their systems. There is no reason that credit cards can't be made secure in this day and age. Nobody wants to bother, so we deal with messes like this.
If all UPS had were credentials that authorized only UPS to make charges to specific accounts (not even knowing what the account number is) below a certain spending limit, then stealing them would have little benefit to anybody (only UPS could use them), and they could easily be revoked by the banks or UPS itself without much trouble (so that even somebody who had the ability to charge somebody, deposit the money into a UPS-controlled account, and then move the money into their own account wouldn't be able to do so).
So, I don't get why pair-instability supernovae happen in the first place, and the Wikipedia article certainly isn't helping.
The argument is that at some point a star gets hot enough that its photons start creating electron/positron pairs, and this causes a collapse. Then that collapse leads to a runaway nuclear reaction.
What I don't get is how the star would ever become supercritical from a nuclear reaction perspective. I get that there might be some kind of transition in pair creation as the whole star gradually increases in temperature and perhaps a large portion of the star crosses some threshold temperature at the same time. I get that this could reduce pressure in the star and allow it to start collapsing.
However, while the transition in pair-creation behavior might happen quickly (this is an event at the quantum level), the collapse of the star involves huge masses of gas falling inwards at macroscopic speeds. I don't see how the migration of a few dozen sun's worth of H/He towards the core is going to happen at a rate anywhere near the rate at which individual H/He atoms are colliding throughout the core. So, if the density started to rise such that you got an increase in nuclear reactions, wouldn't that create additional pressure that stops the collapse?
For there to be an explosion you need to build up potential energy of some kind and then release it all at once. If you light C4 with a match it just burns from the surface which doesn't lead to a dramatic release of energy. If you send a shockwave through it that travels faster than the speed of sound in the medium then the initiation of combustion of the C4 propagates faster than the shock wave produced by the combustion, and as a result the energy of the entire explosive is released seemingly at once. Likewise if you ignite a cloud of pure hydrogen surrounded by normal air it will just burn at the surface hotly, but if you premix hydrogen and air to a stoichiometric mix and light a match, it will detonate, because in that case the ignition will naturally propagate faster than the speed of sound (and is not limited by the diffusion of oxygen/hydrogen to allow mixture).
Nuclear reactors don't explode, because they aren't significantly supercritical - they stay near equilibrium. A nuclear bomb reaches supercriticality because for a very short moment in time the inertial of the collapsing fissile mass allows it to continue to collapse before the energy produced by the initiating chain reaction can blow it apart.
Is that the case for these supernovae? Does it take long enough for the nuclear reactions to start that the mass of the falling gas has enough inertia to allow it to continue to compress even after passing the critical point?
If they dont offer and you only use it as its a convenience to make your life easier, then again, you are on your own.
There is no such thing as "optional" work. If you don't "voluntarily" use your phone to get more work done, then you'll be replaced by somebody who does. You won't be fired for not using your cell phone - you'll be fired for being the slowest person in the department.
If this were blue-collar work then we'd be talking about people "voluntarily" not using provided safety equipment because it slows them down. The only way to regulate this sort of thing is that if an employee gets injured due to deliberate disobedience of corporate policy that says they had to use safety gear, you have to fine the company millions of dollars anyway. Then the employer will actually ENFORCE the policy, and not just let 99% of their employees ignore it, and fire the 1% who follow it.
If the company doesn't want employees using their personal cell phones, then they should forbid their use to do work, and take steps to ensure access is blocked (not actively facilitate their use).
So every time I do a load of laundry and put bleach into it to make my undies sparking white I'm adding carbon tetrachloride to the atmosphere unintentionally.
That, and introducing a suspected carcinogen into your underwear.
When I open up the tap in my kitchen sink, am I "blowing off water straight to atmosphere" ??? Of course not, showing us all that you didnt know that Carbon tetrachloride was a liquid while making your first post blaming a bunch of people that you clearly have other different issues with.
Saying that something is a liquid/solid/gas/etc is a bit of a simplification. The reality is that substances exist in equilibrium between various phases, and this shifts based on temperature/pressure.
If you spill some water on a sidewalk in the summer and come back an hour later, you won't see any water, because it will evaporate - probably fairly quickly depending on the humidity.
Carbon tetrachloride is much more volatile than water in practice. The boiling point isn't all that much lower, but unlike water there is almost none of it present in the atmosphere to start out. That greatly facilitates evaporation per Le Chatelier's principle.
Oh, and I don't think anybody uses carbon tetrachloride in air conditioners. Old ones certainly use CFCs though, and most of those boil at a lower temperature. Carbon tetrachloride has been a known carcinogen for ages, so industrial uses have been shifting away from it for a while.
Slashdot Mirror
If the SystemD team want to manage network startup, system logging, firewalls and whatever else takes their fancy, then fine, go right ahead; just do it in a way that makes it easier for system admins to disable it and plug in a more fully featured and/or stable alternative, and do it as a child of PID1 so if/when it does crash it doesn't bring the whole system down with it.
Oddly enough, every one of the things you mention are:
1. able to be performed by things other than systemd when systemd is PID 1.
2. not performed by PID 1 when the systemd implementation is used.
3c) In general, while they minimally accommodate server-side daemon software, most of the development focus of systemd is for the desktop user's use-case.
I don't see how this is the case. Most of the newer features in systemd are server-oriented. Who runs nspawn/docker/etc on the desktop? Or stateless services? Who cares about unalterable logs on the desktop?
It seems like most of the features in systemd are actually more server-oriented.
I have to admit, I've never understood this fetishism for boot times. Boot times stopped being unreasonably long years ago. Why do people still care about modest improvements in speed to something that doesn't happen that often?
Anybody who runs thousands of servers on dozens of boxes, spawning and removing servers dynamically. That is, anybody using modern system administration practices. Booting a container under systemd takes milliseconds. Most of the alternatives don't grok containers at all, and they aren't adding 30s to a 1 minute boot cycle, but 30s to a boot cycle that otherwise might take a millisecond to run.
replacing /etc with a mysql database
Wow, I just puked a bit.
Obviously you don't use coreos. Configuration management is a big problem in the linux world, precisely because every daemon insists on storing its configuration in random files in random formats in /etc. The usual solution is to, gasp, start sticking all this stuff in a database. Then you either fix the daemons to use the database, or build a bunch of glue that parses the database and dumps a ton of files to /etc for compatibility.
How will anybody maintain all that junk, you ask? Simple, anytime you make a change you wipe the server and re-install it.
I suspect that it will take Slackware longer to move to OpenRC than it takes Gentoo to move to SystemD at the current pace. :)
I've used OpenRC for ages now, but systemd has a lot of clear advantages. I doubt I'll ever use it again. Gentoo is about choice so I'm sure it won't go away any more than twm will, but I suspect that it is only a matter of time before it isn't on the stage3s and you pick your init just like you pick your kernel/syslog/etc. You might start finding more and more Gentoo packages that lack openrc support as well, or where the openrc support is maintained by somebody other than the package maintainer.
Sure, but all those tools you need to mount /usr are all present in your initramfs. / is just a crude initramfs which pollutes your path once it is finished doing its job. :)
Of course, nothing prevents you from mounting /usr over NFS in usr-move distros. You just mount it from the initramfs.
The initramfs is the new /. However, unlike / it goes away once it has done its job.
From every experience I've had with systemd, I'd say that it is NOT progress. I don't want every little thing integrated in the manner systemd does.
Integrated in what way? Sure, they have a bundled suite of applications, but you can swap out journald for syslog just as you can swap out koffice for libreoffice if you run KDE. It has some dependencies like udev and dbus, but that's just a design choice.
And frankly, OpenRC is a lot better.
How do you figure? I've been using OpenRC for more than a decade and there are a LOT of things it doesn't accomplish like: /etc that sets that one setting and systemd merges it in every time.
1. Having upstream-provided service scripts for most packages. Most OpenRC scripts are custom-built by Gentoo maintainers. If a Gentoo maintainer doesn't maintain a script, you will have to write your own.
2. Actually stopping services thoroughly. If a service doesn't clean up children properly. OpenRC doesn't care.
3. Optional auto-restart.
4. Sane network configuration. The networkd configuration is much simpler than oldnet/newnet/whatever.
5. Drop-ins. I like a Gentoo-provided openrc script, but I want to set ionice. That means hacking up the script, and then merging in changes every time it is upgraded. With systemd I just stick a drop-in file into
6. Booting in milliseconds in a container. I'm not sure how well it boots in a container at all, though I know this is being worked on.
7. Clean shutdowns when you're using stuff like lvm/raid/etc. Systemd can drop to dracut and allow the initramfs to do a full clean unmount. Sure, the read-only approach works reasonably well, but it always bothered me seeing OpenRC shut down with in-use messages.
OpenRC is about as good as it gets for a traditional bash-based service management system. I've always been happy to use it. However, unless I'm stuck on BSD or something I doubt I'll be using it much in the future.
That part, systemd is good at. I have no objections to systemd advantages as an init system. The large complexity of doing more than it should encompasses the non-init-system parts of systemd. For example, last I heard they just added DNS caching. Into the init system. Since when does the init system need to handle DNS caching?
I haven't heard anything about that (cite?). It does do DNS setup (systemd-resolved), but that is NOT part of the init system. It is a completely separate binary which can be interchanged with something like dhcpcd if you prefer. That seems like the unix way to me...
I'd also argue (controversially) that journald is outside the scope of an init system. It has some compelling arguments for its existence, but surely it should be a separate project rather than an integral part of systemd.
Journald is not part of the init system either, and there is no requirement to use it at all to use systemd. It simply integrates well with systemd.
I think your objection is that they maintain all this stuff and distribute it as part of the same source tarball. If I maintained by sysvinit, openrc, and bind and distributed a tarball containing all three without changing their current functionality, would that make any of them less "unixy?"
Gentoo, maybe?
Emphasis on maybe... I'm sure a few devs still use openrc on Gentoo, but it seems like systemd has quite a bit of momentum. It seems just a matter of time before it becomes at least an equal default and you start finding more packages that have systemd support only than packages that have openrc support only.
A complex startup system that logs to a database rather than a text log, is just poor engineering.
Unless you are logging direct to a printer, I've yet to see a modern operating system that outputs a log that is human-readable. Most of them encode the log data in ASCII or UTF8 and store them in a series of sectors that likely fragmented all over the disk, requiring a complex set of tools to read a database that indicates where the data may be found on the disk, and communicate with the drive controller to retrieve the data. Oh, and outputting the log to the screen requires a bunch of console/display drivers.
I don't get the practical difference between the systemd journal and a log file in text format. Either way you need a bunch of tools to read them. At least with the journal you can be assured that it wasn't tampered with without detection.
It boils down to the old adage: "If it ain't broke, don't fix it."
I have a perfectly working abacus that you're more than welcome to take off my hands. :)
Sure, you can live without Chef, Puppet, SystemD, Docker, KVM, etc. Why you would want to is a mystery to me.
At the moment, just about every major distribution except Slackware and Gentoo not only supports systemd, but ships with it on by default.
Uh, Gentoo supports SystemD just fine. It hasn't become the default yet, but it seems pretty close. I suspect a good percentage of the developer community runs it now.
The majority of systems I deal with are servers. They mostly have plenty of CPU and memory available and typically run very few services..... they boot plenty fast without systemd.
Are you sure about that? Before doing some updates to a server I'm running I shut it down, created a snapshot of the disk, and booted it back up. The complete operation took about 200ms I'm estimating (it didn't execute instantly, but I barely could have blinked in the time it took).
There is no way that would have worked if it wasn't running systemd. And no, this wasn't running on bare metal. Who runs servers on bare metal these days?
Ah, that hadn't occurred to me. I guess you could add a rotation axis to the thing. I figured the bigger issue would be jitter/quantization/etc. With an equatorial mount you just have a single continuous motor that just turns at the right rate and is continuous - so it would be very smooth. With a computerized alt-az even with rotation you'd end up with the computer firing off steps on all three motors at various intervals, but ultimately the movement of the thing would be a series of individual steps. With enough gear reduction I imagine that could be very fine and seem continuous, but if you cheap out the thing isn't going to be smooth, which would kill an exposure.
I'd have assumed that by now a motor-driven Alt-Az mount would be good enough to eliminate the need for an actual physical Eq mount. Just tell the thing where/when it is and maybe point it at a guide star and it should be able to simulate an Eq mount, assuming the steppers have sufficient resolution that you don't notice the steps in an exposure (but what kid is going to be taking photos anyway?). Then you can switch modes at will when panning around.
Heck, stick GPS and a compass in the thing and it could find a star for you and just ask you to tweak it to correct for compass/tilt error. That is $10 worth of extra parts these days.
I think History jumped the shark for me when I watched that WW1/2 miniseries a few months ago. The Mass Effect soundtrack was amusing, but the real winners were the Japanese Arleigh Burke destroyers. Ancient Aliens didn't really bother too much since I couldn't be bothered to watch it.
Honestly, those Battle-360-type shows never really impressed me much. They could use all that 3D/etc to do something to help me understand how the battles took place. Instead it involves a lot of pictures of a few soliders behind sandbags with the camera weaving around bullets suspended in mid-air, which has little to do with the actual battle.
It seems like authentication is important to modern society. I think the only real solution is a government-issued ID, capable of challenge-response. Even a PIN for the ID is useless if every company expects you to hand it over to them.
As it stands right now, it is SOP for an admin to block all exit nodes at the incoming router, the IP stack on the machine, the web server, and the application, because of abuse.
If only. It seems to be SOP to block relay nodes as well. I run one, which does not allow exits, and I run into lots of sites that block me. Must be fun for whoever gets my dynamic IP next.
People don't like to admit it but the existence of Nuclear weapons has prevented a major conflagration between the `big powers', at least since the Korean War (MacArthur wanted to use them there, his boss didn't).
Yup. It is certainly a big factor preventing war over the Ukraine. If the Ukraine had nuclear weapons, it would probably remain intact.
Would the US nuke China over an invasion of Japan? Probably not.
Would the US nuke Russia over an invasion of Germany, France, or the UK? Probably not.
In the end, when you're talking about doomsday the stakes are pretty high. Just letting the other guy invade your ally tends to look like a very good option. If you don't want to get invaded, having your own nukes is better than relying on somebody else's.
The fundamental issue is that credit cards are based on the premise that you can authenticate somebody using a shared secret that you share with everybody you do business with.
I can post my ssh public key in this post if I wish, and about the only thing anybody could do with it is give me access to their systems. There is no reason that credit cards can't be made secure in this day and age. Nobody wants to bother, so we deal with messes like this.
If all UPS had were credentials that authorized only UPS to make charges to specific accounts (not even knowing what the account number is) below a certain spending limit, then stealing them would have little benefit to anybody (only UPS could use them), and they could easily be revoked by the banks or UPS itself without much trouble (so that even somebody who had the ability to charge somebody, deposit the money into a UPS-controlled account, and then move the money into their own account wouldn't be able to do so).
So, I don't get why pair-instability supernovae happen in the first place, and the Wikipedia article certainly isn't helping.
The argument is that at some point a star gets hot enough that its photons start creating electron/positron pairs, and this causes a collapse. Then that collapse leads to a runaway nuclear reaction.
What I don't get is how the star would ever become supercritical from a nuclear reaction perspective. I get that there might be some kind of transition in pair creation as the whole star gradually increases in temperature and perhaps a large portion of the star crosses some threshold temperature at the same time. I get that this could reduce pressure in the star and allow it to start collapsing.
However, while the transition in pair-creation behavior might happen quickly (this is an event at the quantum level), the collapse of the star involves huge masses of gas falling inwards at macroscopic speeds. I don't see how the migration of a few dozen sun's worth of H/He towards the core is going to happen at a rate anywhere near the rate at which individual H/He atoms are colliding throughout the core. So, if the density started to rise such that you got an increase in nuclear reactions, wouldn't that create additional pressure that stops the collapse?
For there to be an explosion you need to build up potential energy of some kind and then release it all at once. If you light C4 with a match it just burns from the surface which doesn't lead to a dramatic release of energy. If you send a shockwave through it that travels faster than the speed of sound in the medium then the initiation of combustion of the C4 propagates faster than the shock wave produced by the combustion, and as a result the energy of the entire explosive is released seemingly at once. Likewise if you ignite a cloud of pure hydrogen surrounded by normal air it will just burn at the surface hotly, but if you premix hydrogen and air to a stoichiometric mix and light a match, it will detonate, because in that case the ignition will naturally propagate faster than the speed of sound (and is not limited by the diffusion of oxygen/hydrogen to allow mixture).
Nuclear reactors don't explode, because they aren't significantly supercritical - they stay near equilibrium. A nuclear bomb reaches supercriticality because for a very short moment in time the inertial of the collapsing fissile mass allows it to continue to collapse before the energy produced by the initiating chain reaction can blow it apart.
Is that the case for these supernovae? Does it take long enough for the nuclear reactions to start that the mass of the falling gas has enough inertia to allow it to continue to compress even after passing the critical point?
If they dont offer and you only use it as its a convenience to make your life easier, then again, you are on your own.
There is no such thing as "optional" work. If you don't "voluntarily" use your phone to get more work done, then you'll be replaced by somebody who does. You won't be fired for not using your cell phone - you'll be fired for being the slowest person in the department.
If this were blue-collar work then we'd be talking about people "voluntarily" not using provided safety equipment because it slows them down. The only way to regulate this sort of thing is that if an employee gets injured due to deliberate disobedience of corporate policy that says they had to use safety gear, you have to fine the company millions of dollars anyway. Then the employer will actually ENFORCE the policy, and not just let 99% of their employees ignore it, and fire the 1% who follow it.
If the company doesn't want employees using their personal cell phones, then they should forbid their use to do work, and take steps to ensure access is blocked (not actively facilitate their use).
So every time I do a load of laundry and put bleach into it to make my undies sparking white I'm adding carbon tetrachloride to the atmosphere unintentionally.
That, and introducing a suspected carcinogen into your underwear.
When I open up the tap in my kitchen sink, am I "blowing off water straight to atmosphere" ??? Of course not, showing us all that you didnt know that Carbon tetrachloride was a liquid while making your first post blaming a bunch of people that you clearly have other different issues with.
Saying that something is a liquid/solid/gas/etc is a bit of a simplification. The reality is that substances exist in equilibrium between various phases, and this shifts based on temperature/pressure.
If you spill some water on a sidewalk in the summer and come back an hour later, you won't see any water, because it will evaporate - probably fairly quickly depending on the humidity.
Carbon tetrachloride is much more volatile than water in practice. The boiling point isn't all that much lower, but unlike water there is almost none of it present in the atmosphere to start out. That greatly facilitates evaporation per Le Chatelier's principle.
Oh, and I don't think anybody uses carbon tetrachloride in air conditioners. Old ones certainly use CFCs though, and most of those boil at a lower temperature. Carbon tetrachloride has been a known carcinogen for ages, so industrial uses have been shifting away from it for a while.