You don't need an always on GPS network if the local devices have a backup Stratum 1 clock. You can get clocks that have around 1 microsecond of skew per day. Using one of these, you can lose GPS signal for at least a few days before it becomes an issue.
If you were using FreeBSD, you could have snapshotted the system and ran it in a jail to make sure it rebooted correctly. Even PC-BSD's upgrade system snapshots your file system, spins it up in a jail, upgrades the snapshot, then points your next host reboot to load from the new snapshot. Man, get a modern OS.
What SystemD is doing is a good idea, it's how they're doing it and their attitude. They seem to have the mindset of Devs and not sysadmins. Windows is an example of an OS by Devs. It's death by a thousand cuts. You can't quite pout you finger on exactly what is wrong, but there's a whole lot of small issues that amass into some real annoying rare cases that don't affect most users, but should never happen in the first place.
LaunchD has existed for a long time and is fully opensource and well tested. It has gotten the run-through with iOS which needs to be easy to use and work reliably in some very complicated environments, like cell phones. Of course there is the very strong "not invented here" mindset that a lot of GPL people have. Comparing SystemD to LaunchD is like comparing btrfs to ZFS. The most annoying mind-set that I've seen from the SystemD people is the whole "if everything is working as expected, this situation should never happen, so we may as well not handle this situation". How I hate that. If you know about a failure case, handle it! I hate that "limp along and some time later, fail in some unrelated way that gives the wrong impression". Works great when it works, but the failure cases are a mess.
Did you know that both LaunchD and ZFS had numerous old-school Unix people working on them in all stages of development? These are people who grew up using and managing mainframes and many now make a living managing datacenters. Who would you rather having designing the critical infrastructure of your OS. A sysadmin dev hybrid programmer who grew up learning exactly why things are designed the way they are, or some wide-eyed dev who likes flashy things and assumes the wisdom of a sysadmin is just the rantings of some old person?
Mind you, I'm a fairly young person that loves flashy things, plays AAA video games, and watches anime, not some neck-beard.
I may be miss-understanding something, but if a service crashes, SystemD is responsible to restart the service. In this case the service may just crash again, but that's besides the point. Why wasn't SystemD bringing a crashed service back online?
Another question is why wasn't the service registered with the event for when the network came back up? Then it could crash and stay down until the network was functioning again, instead of attempting to restart every 10 seconds.
It looks to me that both aiccu and Redhat were derping.
By some usage of "rarely". They seem pathological to me. They tend to happen in bursts or start once a threshold is met, in my experience. 80% of my job is dealing with these "rare" corner cases that other people never thought or cared about.
For a given frame of reference under a specific time dilation, time is roughly linear for our current purposes. Space-time may turn out to be foamy, but it should average out at the macro level of nanoseconds.
Logically, time is linear. A certain atom at the right settings will vibrate at a very specific frequency. The problem is trying to keep many difference frames of reference in sync. Time can still be linear, you just need to make sure you're careful how to sync the differences between a one frame of time and another reference frame of time.
The bigger issue is for a given frame of reference, you can only have so much useful precision. Two high precision atomic clocks next to each other can get out of sync because they're so precise that they pick up some very small variations in time dilation. You can compensate for these variations, with in reason.
How old are the time systems on earth, hu? Do you really think if your proposal would simllify anything we had it not established thousands of years ago?
Even 20 years ago, yet alone a thousand years ago, very few people needed to care about what was happening on the other side of the Earth. Knowing you "eat at noon" is only useful for the timezone you're in.
There are situations where you want to sync events faster than light. If you want two servers on different sides of the Earth to "do an event at the same time", light is too slow. At some point we need to stop caring because time dilation is different in different places, but I don't think 10ns is quite there.
I can't wait to see what happens when we need to start syncing time among different planetary bodies. Constantly changing time because one arbitrary planet likes to keep time in sync with the sky is a horrible reason.
I've noticed some common issues myself.
1) Reinventing the wheel when there is a better solution already, and many times free.
2) Thinking everything is a black box and will magically fix their situation. Everyone else is using it, so it must be good.
3) Not making a new wheel because they think their problem is the same as one that has been solved. Many modern solutions have minor differences that become major differences when pushed to the extremes.
I have limited experience working with projects for customers, but it seems like the customer doesn't know what they want, but they know what they didn't want once they see it.
My biggest complaint about other programmers is they don't account for the possible ranges of their parameters. Many just want to get the program "working" and nothing more. I don't like undefined behavior. I try my best to design my programs to have all behaviors well defined. When something goes wrong, I can almost always tell you exactly why it went wrong or exactly where to look. I hate the whole, get 20 people involved because no one knows what code is causing the issue and lets spend hours guessing why a program is failing because we don't know how our programs work.
It was almost as bad as a "if(true == true)" "bug". They should have unit tested this to make sure it failed as expected. Always test your edge cases, and also try to test corner cases. But really. Who doesn't test their edge cases? They're the simplest tests to identify.
You may not realize it, but the Earth is not uniformly inhabited by humans. If you limit yourself to metro areas, the USA has some of the highest densities in the world, surpassing even Japan and South Korea in many cases.
Implied in this. You assume it's impactful. It's only impactful for ISPs that are wasteful and slow. Slow networks are expensive because they go out of their way to do things inefficiently. Fast networks are cheap because they reduce the number of expensive slow layers. If you had to choose between a single chassis that is $2k per customer and supports 5k customers at 1Gb/s with 4Tb/s of uplinks, or a copper node that is $10k per customer and supports 200 customers with a shared uplink of 10Gb. Which one would you choose?
1/6 of the downstream traffic and 1/3 of the upstream traffic is impactful on an ISP network because it consumes resources that would otherwise be available for other uses, and/or requires the ISP to invest in additional infrastructure to prevent that traffic impacting other uses.
The first time I saw a computer was when I was 6 at an electronics convention. My dad wanted to get some cheap speakers or something. I saw a screen saver running on a computer and realized the screen was being "generated". I asked my dad how it worked and he told me the computer was doing math really really fast, and could represent the numbers as the colors and their positions. I instantly knew I wanted to program. I started reading on how CPUs worked and started reading on C and ASM. I tried Basic, but it was too confusing. I stuck with C and ASM. I can't work with something when I don't understand how it works. Regardless of understanding the syntax, not knowing how Basic worked behind the scenes meant I could not use it. That's just how my mind works. C and ASM were easy to understand because they're so close to the CPU.
I cannot fathom the concept of programming being "mysterious" or "impenetrable". It has seemed blindly simple since I was a young child. I didn't do much programming as a child, just enough to verify I understood the concepts. What I was more interested in understanding was how to design complex systems. I loved reading about how kernels work, how the kernel interacts with the hardware, how data moves around in the computer, caching, all of that fun stuff.
For any non-trivial table, if you have a column called ID that holds an int, is your PK, and is the clustered index, you're doing it wrong.
I'm kind of curious about this. One of the issues with not using an int/bigint as a clustered PK is changes to the clustered index changes all other indexes and a simple insert that could have been added at the end of the clustered index is now added in the middle, forcing all other indexes to increase fragmentation, regardless if the newly added row is even in those indexes.
it would be sorted
This only works if your data is sorted in the way you want it sorted. I do a lot of analytics, groups and sorts are done in many different ways, and many times on computed fields.
Slashdot Mirror
You don't need an always on GPS network if the local devices have a backup Stratum 1 clock. You can get clocks that have around 1 microsecond of skew per day. Using one of these, you can lose GPS signal for at least a few days before it becomes an issue.
You don't want to open the circuit, you want to shunt to ground/Earth.
If you were using FreeBSD, you could have snapshotted the system and ran it in a jail to make sure it rebooted correctly. Even PC-BSD's upgrade system snapshots your file system, spins it up in a jail, upgrades the snapshot, then points your next host reboot to load from the new snapshot. Man, get a modern OS.
What SystemD is doing is a good idea, it's how they're doing it and their attitude. They seem to have the mindset of Devs and not sysadmins. Windows is an example of an OS by Devs. It's death by a thousand cuts. You can't quite pout you finger on exactly what is wrong, but there's a whole lot of small issues that amass into some real annoying rare cases that don't affect most users, but should never happen in the first place.
LaunchD has existed for a long time and is fully opensource and well tested. It has gotten the run-through with iOS which needs to be easy to use and work reliably in some very complicated environments, like cell phones. Of course there is the very strong "not invented here" mindset that a lot of GPL people have. Comparing SystemD to LaunchD is like comparing btrfs to ZFS. The most annoying mind-set that I've seen from the SystemD people is the whole "if everything is working as expected, this situation should never happen, so we may as well not handle this situation". How I hate that. If you know about a failure case, handle it! I hate that "limp along and some time later, fail in some unrelated way that gives the wrong impression". Works great when it works, but the failure cases are a mess.
Did you know that both LaunchD and ZFS had numerous old-school Unix people working on them in all stages of development? These are people who grew up using and managing mainframes and many now make a living managing datacenters. Who would you rather having designing the critical infrastructure of your OS. A sysadmin dev hybrid programmer who grew up learning exactly why things are designed the way they are, or some wide-eyed dev who likes flashy things and assumes the wisdom of a sysadmin is just the rantings of some old person?
Mind you, I'm a fairly young person that loves flashy things, plays AAA video games, and watches anime, not some neck-beard.
aiccu then crashes and it never starts again.
I may be miss-understanding something, but if a service crashes, SystemD is responsible to restart the service. In this case the service may just crash again, but that's besides the point. Why wasn't SystemD bringing a crashed service back online?
Another question is why wasn't the service registered with the event for when the network came back up? Then it could crash and stay down until the network was functioning again, instead of attempting to restart every 10 seconds.
It looks to me that both aiccu and Redhat were derping.
People who program for a paycheck just make work harder for me. Lets just give them free money.
If the Empire is making a tractor beam, now they only need a Death Star to go with it.
Darned kids. In my day, sound didn't travel through space
By some usage of "rarely". They seem pathological to me. They tend to happen in bursts or start once a threshold is met, in my experience. 80% of my job is dealing with these "rare" corner cases that other people never thought or cared about.
For a given frame of reference under a specific time dilation, time is roughly linear for our current purposes. Space-time may turn out to be foamy, but it should average out at the macro level of nanoseconds.
Logically, time is linear. A certain atom at the right settings will vibrate at a very specific frequency. The problem is trying to keep many difference frames of reference in sync. Time can still be linear, you just need to make sure you're careful how to sync the differences between a one frame of time and another reference frame of time.
The bigger issue is for a given frame of reference, you can only have so much useful precision. Two high precision atomic clocks next to each other can get out of sync because they're so precise that they pick up some very small variations in time dilation. You can compensate for these variations, with in reason.
We need an absolute reference time, like UTC, but doesn't change for anything. UTC can be based on this time.
How old are the time systems on earth, hu? Do you really think if your proposal would simllify anything we had it not established thousands of years ago?
Even 20 years ago, yet alone a thousand years ago, very few people needed to care about what was happening on the other side of the Earth. Knowing you "eat at noon" is only useful for the timezone you're in.
There are situations where you want to sync events faster than light. If you want two servers on different sides of the Earth to "do an event at the same time", light is too slow. At some point we need to stop caring because time dilation is different in different places, but I don't think 10ns is quite there.
I can't wait to see what happens when we need to start syncing time among different planetary bodies. Constantly changing time because one arbitrary planet likes to keep time in sync with the sky is a horrible reason.
I've noticed some common issues myself.
1) Reinventing the wheel when there is a better solution already, and many times free.
2) Thinking everything is a black box and will magically fix their situation. Everyone else is using it, so it must be good.
3) Not making a new wheel because they think their problem is the same as one that has been solved. Many modern solutions have minor differences that become major differences when pushed to the extremes.
I have limited experience working with projects for customers, but it seems like the customer doesn't know what they want, but they know what they didn't want once they see it.
My biggest complaint about other programmers is they don't account for the possible ranges of their parameters. Many just want to get the program "working" and nothing more. I don't like undefined behavior. I try my best to design my programs to have all behaviors well defined. When something goes wrong, I can almost always tell you exactly why it went wrong or exactly where to look. I hate the whole, get 20 people involved because no one knows what code is causing the issue and lets spend hours guessing why a program is failing because we don't know how our programs work.
Modern implementations of rm reject that.
An edge case is a problem or situation that occurs only at an extreme (maximum or minimum) operating parameter.
A corner case (or pathological case) is a problem or situation that occurs only outside of normal operating parameters
It was almost as bad as a "if(true == true)" "bug". They should have unit tested this to make sure it failed as expected. Always test your edge cases, and also try to test corner cases. But really. Who doesn't test their edge cases? They're the simplest tests to identify.
You may not realize it, but the Earth is not uniformly inhabited by humans. If you limit yourself to metro areas, the USA has some of the highest densities in the world, surpassing even Japan and South Korea in many cases.
Regardless of the local server's firewall, the network firewall should be blocking everything by default, especially for the servers.
1/6 of the downstream traffic and 1/3 of the upstream traffic is impactful on an ISP network because it consumes resources that would otherwise be available for other uses, and/or requires the ISP to invest in additional infrastructure to prevent that traffic impacting other uses.
The first time I saw a computer was when I was 6 at an electronics convention. My dad wanted to get some cheap speakers or something. I saw a screen saver running on a computer and realized the screen was being "generated". I asked my dad how it worked and he told me the computer was doing math really really fast, and could represent the numbers as the colors and their positions. I instantly knew I wanted to program. I started reading on how CPUs worked and started reading on C and ASM. I tried Basic, but it was too confusing. I stuck with C and ASM. I can't work with something when I don't understand how it works. Regardless of understanding the syntax, not knowing how Basic worked behind the scenes meant I could not use it. That's just how my mind works. C and ASM were easy to understand because they're so close to the CPU.
I cannot fathom the concept of programming being "mysterious" or "impenetrable". It has seemed blindly simple since I was a young child. I didn't do much programming as a child, just enough to verify I understood the concepts. What I was more interested in understanding was how to design complex systems. I loved reading about how kernels work, how the kernel interacts with the hardware, how data moves around in the computer, caching, all of that fun stuff.
For any non-trivial table, if you have a column called ID that holds an int, is your PK, and is the clustered index, you're doing it wrong.
I'm kind of curious about this. One of the issues with not using an int/bigint as a clustered PK is changes to the clustered index changes all other indexes and a simple insert that could have been added at the end of the clustered index is now added in the middle, forcing all other indexes to increase fragmentation, regardless if the newly added row is even in those indexes.
it would be sorted
This only works if your data is sorted in the way you want it sorted. I do a lot of analytics, groups and sorts are done in many different ways, and many times on computed fields.