Actually, try #3. That's the only term that is generic enough to encompass both the individual recording artists (regardless of the degree of artistry) and the record companies that represent them. I'm talking collectively about everyone involved in the process of bringing that content to market who might plausibly be involved in the decision-making process.
You have k(a) Android devices and k(i) failed devices. k(i) divided by n(i) gives you 58%.
No, that's what failure rate is supposed to mean. However, what the numbers actually said are:
iPhone 6 had the highest failure rate of 29%
iOS devices as a whole had a failure rate of 58%
These two statements cannot both be true simultaneously by any proper definition of "failure rate". The iPhone 6 is a subset of all iOS devices. The claim is made that its failure rate was 29%. For the failure rate of all iOS devices to be 58%, that would mean that at least one iOS device must have a failure rate greater than 58% to pull the average up from 29% to 58%, which contradicts the statement that the iPhone 6 had the highest failure rate at 29%.
Q.E.D.
The only way you could even halfway make those numbers plausible would be if you erroneously divided the iPhone numbers by either the total number of iOS devices or worse, the total number of devices. Either of those approaches makes the numbers meaningless because you don't know the relationship between... to use your terminology... k(i) and n(i) at that point.
In your ramblings, you fail to consider that the vast majority of people who want to avoid expensive shipping charges will often bring their unit into a store... which eliminates many of the simpler problems.
The vast majority of people who want to avoid expensive shipping charges will Google the problem and find an answer themselves. People go to a store when that fails.
I don't really understand how this benefits Spotify as it doesn't improve the service in any way that I can see, and such a move likely makes it worse for users for petty business reasons that have nothing to do with the users.
In the short term, the only negative impact would be if the songs they're demoting are extremely popular and if the public perceives their absence as a loss in quality. Given the size of the musical corpus these days, that seems unlikely.
In the long term, this serves notice to content creators that there's no such thing as a free lunch. Normally, those content creators would have to balance the cost of exclusivity (fewer plays on those exclusive songs) against the benefits (presumably dramatically improved promotion and possibly higher royalty per click. With this policy in place, those content creators have to factor in the loss of the vast majority of their income from the other providers—not just on new content, but also on old content. That significantly changes the balance in a way that discourages these exclusive deals.
And that's a good thing. Vendor exclusivity is inherently anti-consumer.
Under 32 hours and the law would say no benefits are required.
That's not true. You're required to pay for health insurance for anyone working 30 hours or more. Similarly, you're not allowed to restrict 401k for any employer working more than 1,000 hours per year (a little over 19 hours per week).
They could cut the number of sick days or vacation days offered, but that's probably roughly the maximum extent to which they could reduce benefits other than salary.
No, it doesn't. 30 hours per week is considered full time for ACA purposes. It is, in fact, the bottom threshold below which you don't have to, so if they hired someone to work 29 hours, you'd be right.
The percentages are percentages of the 58% of failing devices. Of the devices that failed, 29% were iPhone 6, 23% were the 6s, and 14% were the 6s Plus. Add those together and we're missing the final 33% of failed devices but it's safe to assume that a random collection of 6 Plus, 5SE, 5s, 5c, etc. make up that final 33% of the 58%.
So let me see if I understand this epic math fail correctly. Given n devices, there were k devices that were brought in for repair. Of those k devices, 58% were iOS devices, and of those 58%, 29% were iPhone 6 devices.
Which tells us absolutely nothing about the actual failure rate without knowing how the makeup of those n devices relates to the makeup of those k devices. It tells us nothing about the actual failure rate without knowing what percentage of each model within k were junked and replaced without notifying the service center in question. It tells us nothing about whether the Android and iOS users have similar levels of self-sufficiency in terms of figuring out how to solve their own problems. And there are probably at least three or four other fairly fundamental errors that make this data essentially pure noise.
Arguments over minor methodology points, such as whether to count specific types of failures in the reliability numbers, are basically moot, because the "data" is purely anecdotal and is not mathematically related to the actual rate of failure to begin with. This isn't statistically any better than saying, "Of my friends, more people have had problems with Android phones than iOS phones" or vice versa. If you know nothing about whether the sample population has similar distribution to the general population and you know nothing about whether the data is even an accurate measurement of the sample population itself, then these numbers are quite literally no better than a random number generator with a Gaussian distribution. You might as well arrive at the results by throwing darts at a dartboard. It will be approximately as meaningful.
Am I missing something?
Trust me, if even 1% of iPhone hardware failed during its warranty period, heads would roll, much less 58%.
As a 6D user, in my experience, the Wi-Fi is really nice if you're part of a group trip. You can have your cell phone out, and once in a while when there's a pause, you can snag a photo off your real camera and upload it to Facebook so that the folks back home can see what you're all doing. It's much easier than trying to take photos with two devices at once, because the extra time spent fiddling with your phone is while you're on a bus riding somewhere or whatever instead of while you're out sightseeing on a schedule.
It is also occasionally useful if you don't have (or forgot to bring) a remote controlled trigger release. You can use it to see what the camera sees (in live view/EVF mode) and tell it to take photos, albeit with a lot of shutter lag. With the dual-pixel AF in the 5D Mark IV, it should be even better because you'll have actual phase-detection autofocus with continuous focusing in live view mode instead of contrast-detection AF.
With that said, it might be worth clarifying that at high MP counts, a hybrid system might be preferable, using sensor-based stabilization for fine correction after your finger hits the button.
Canon puts the stabilization in the lens for a good reason. Sensor-based stabilization is only useful on point-and-shoot cameras or mirrorless cameras with electronic viewfinders. As soon as you have an optical path to your eye, sensor-based stabilization is worthless, because it won't help you frame the shot. By contrast, lens-based stabilization locks the image in place so that you can actually see what you're taking a picture of.
This makes a huge difference even at 300mm. By 600mm, you'd be hard pressed to ever get a shot of anything without lens-based optical stabilization.
Except that it doesn't, because it doesn't. The 5D Mark IV sensor uses a gapless microlens array. There are no boundaries between the pixels, period. All light that hits the sensor's surface goes into the sensor except for any that gets reflected when it hits the surface.
True but the image will always suffer from less thermal noise on an equivalent sensor with larger photosites.
Realistically, thermal noise is almost irrelevant except for long-exposure photography (e.g. astrophotography). For normal photographic purposes, it's the shot noise that kills you in low light. When the difference between one and zero photons makes a visually noticeable difference in the resulting value, individual pixels are going to have noticeably different values than the pixels next to them even when they're getting approximately the same amount of light, because a pixel either gets the photon or it doesn't.
But that shot noise basically goes away when you downsample. If you double the number of pixels, a "pixel crop" (one pixel on the individual photo to one pixel on your screen) will give you more noise on the one with smaller sites, but it will also be looking at a much smaller area. If you crop them to cover the same area and average the signals, you'll find that the same number of photons hit both sensors and were detected, so the result is approximately the same, with the exception of the small amount of loss caused by the wiring around the pixels. And by the time that starts to become significant, you're roughly at cell phone pixel densities, and you're either doing back-side illumination, microlens arrays, or both to get rid of that problem.
I was just looking at this article which points out that Apple's R&D has gone up many times over since Job's passed on...
The thing is, that's usually a bad sign. It means that your development teams are growing very quickly, which has two effects:
The median age/experience level drops precipitously, resulting in poorer output quality.
The amount of effort required to maintain the products designed by more people grows by the square of the number of people involved.
Eventually you reach a point where every additional person makes the product worse or more delayed, rather than better or faster. These days, I keep getting the feeling that Apple passed that point a while back, and they just haven't noticed yet. This is one reason why innovative ideas almost invariably come from small companies, not big ones.
The other reason is that the larger Apple grows, the harder it will be to innovate, because the breakage caused by doing so will become an ever bigger problem as the code base increases in size. At some point, it will be necessary for Apple to start over from scratch—probably by buying a company that creates some innovative alternative. At that point, it will have fully become Microsoft or IBM. And that's okay. Eventually, somebody else will come along and become the next Apple. It's the circle of life.
In our solar system only moons are tidally locked to planets, but no planets to stars.
Mercury comes pretty close with its 3:2 spin-orbit resonance. It spins 3 times for every 2 orbits. That's close enough to being tidally locked that the difference is mostly moot from a "cooked on one side" perspective.
If the new phone doesn't have a headphone jack, it'll be all over the Internet. There will be almost no way to avoid knowing that the iPhone 7 doesn't have a headphone jack.
That's not where the user impact comes in. Most people don't use headphones constantly. They use them occasionally. And they will think to themselves, "That's not a big deal." Then, at some point in the distant future:
They're at a friend's house and want to play some song. Their friend has an Android phone, and a stereo with only an 1/8" plug.
They're out somewhere and think, "I'd like to listen to some music while I walk from A to B" and then realize that their Bluetooth earbuds aren't charged.
The stewardess tells them that they can't use wireless headsets (that's a per-airline policy decision) and offers to sell them a headset for $3, but oops, no adapter.
And so on. And suddenly, what seemed like it didn't matter suddenly matters, and you have a pissed off customer.
Apple will do no fixes of anything until it learns its lesson with very bad iPhone 7 sales because of the removal of the 3.5mm audio jack.
What would be worse for Apple would be if they don't lose sales, because there's definitely a non-negligible percentage of their customers who will be negatively impacted significantly by removal of the headphone jack, and if those folks buy the phone anyway, then they're going to end up with a bad impression of Apple products, and Apple will lose them as customers. In the long run, Apple should hope that they lose those sales, because at least they'll have a chance to make up those sales by releasing a future generation that isn't missing critical features.
The ultimate destruction of Apple as a brand of amazing hardware will come if they ship a device without a headphone jack and 30% of their users don't realize how much they'll miss the headphone jack, buy the phone anyway, and then start trash-talking their new iPhone on social media before switching (permanently) to Android. If Apple ships this product, I may start doing covered calls on my Apple stock to limit my losses. As a user, this is just a big annoyance, and I'm hopeful that they'll pull their heads out of their a**es before I'm due for a new phone. But as an investor, this is absolutely terrifying, oddly reminiscent of the period where a certain Pepsi exec was running the show.
Plus, when your headphone cord breaks off in the Lightning port, you'll still be able to charge the phone... until you break a second headphone cord, anyway.
Not the thin ones they use in phones. But still, it's a solvable problem. It has been solved many times by many companies. Basically, waterproofing is nothing more than an excuse.
You could always get a keyboard case. For sure, there's a landscape-mode keyboard case for various iPhones. Not sure about the Android world, but I would assume that they exist there, too.
Question 1: Who the hell reuses passwords, and why? Anyone left not using password managers?
Statistically, almost everyone:
Anyone who created at least one account more than a few years ago and has continued using it without changing his/her password
Anyone who is using a site that doesn't support the browser's build-in password manager (usually by not showing a username field)
There are probably others, but most users have at least a few sites that use shared passwords, and most of them are the fault of the people who designed the websites.
The thing is, lack of upgrades usually indicates a design problem. For services like this, the software should be distributed using git so that local changes can be merged sanely. Instead, most of these bulletin boards involve moving aside the existing installation, extracting a tarball, and running some sort of installer script that does who-knows-what. So upgrading can be nightmarish for sites that involve any sort of customization.
Also, this sort of software should be designed in such a way that it never makes backwards-incompatible changes to data structures, at least for a reasonable period of time (say a year or two). It should be possible to clone your installation to a new directory, apply the patches to the new version, start it up, and let it add additional database fields, etc. as needed, but the new version should be tolerant of partial data created by the old version (and should upgrade it on the fly), and should create data in such a way that the old version can still read it. This ensures that you can test the migration to a new version without having to set up a full clone of your entire infrastructure, with the ability to roll back if it breaks something.
And ideally, a built-in upgrade scheme should be designed into the software. For example, it could have a script that clones itself into a directory beside the original and does a "git pull" in that subdirectory. After you fix any conflicts, it should let you access the new version by symlinking the new version into a subdirectory in the original version's tree. When you're satisfied, it should provide a one-button command that atomically deploys the new version by swapping out the symlink that currently points to the old version with a symlink that points to the new version.
Oh, and it should check for updates automatically and email the admin every time there's an update. And it should allow you to auto-upgrade (with automatic email notification if the upgrade fails because of git conflicts) if you configure it to do so. And it should also have an intermediate mode that always keeps the latest version ready to preview but doesn't enable the upgrade, for folks who want to verify the updates manually, but still want to be ready to quickly install security updates when they find out about an exploit.
With such a design, these systems would stay up-to-date much more consistently.
I understand the point of core hours perfectly. I don't understand the point of them being dictated from the top of the organization down. Realistically, until you have five people in the meeting, there's no chance of not being able to find a day when everyone can be there, and you shouldn't typically have that many people in a meeting unless it is either a team meeting or a broad cross-functional group meeting. Both of these should be repeating events. Decisions about which day to pick for team meetings should be determined by the team based on what works best for everyone, and everyone should agree upon a particular day each week when they all agree to be there. Broad cross-functional meetings don't require a specific person from any given team, so the team or the team's manager should decide who is responsible for representing their team in those meetings based on who will be there on that day of the week.
Workers should be willing to occasionally take brief phone calls on their days off if they need to answer an urgent question about something. More significantly, there should very rarely be anything so urgent that it can't wait a day if it happens to be that employee's day off. If you are finding that such urgent blockers come up frequently, either:
The work of certain employees is too tightly coupled (which means it should have been done by one employee over a longer period of time, and schedules are likely unrealistic).
There isn't enough intra-team communication so that other folks understand what each other are doing at a high level.
There aren't enough people working on an important piece of the puzzle, resulting in things that only one person understands.
Any of these things indicates a failure of management that should be corrected ASAP, and not just because it makes flex-time easier. It is also the only real way to protect against the "hit by a bus" problem, the "won the lottery" problem, etc.
Singletons are a good default design pattern to use if you need something that should typically be shared across lots of pieces of code (e.g. a cache). With that said, my general policy is that you generally shouldn't design classes that are limited to use as a singleton. You should always provide the ability to allocate additional instances unless it is impossible to safely have more than one instance for some reason (and you must justify why this is the case).
Then they'll quietly drop this perk for new hires...
Legally, they can't do that. For ACA purposes, for example, if someone works 30 hours or more, they're considered full-time employees legally, and you have to pay for their health insurance. And you cannot legally limit 401(k) matching unless the employee works fewer than 1,000 hours per year (19.23 hours per week).
At 30 hours per week, about the only thing they have any flexibility on is the number of vacation days. And nobody is going to join a company that makes them work 3/4 time with no vacations, so if they attempted that, it would quickly become a self-correcting problem.
Slashdot Mirror
Actually, try #3. That's the only term that is generic enough to encompass both the individual recording artists (regardless of the degree of artistry) and the record companies that represent them. I'm talking collectively about everyone involved in the process of bringing that content to market who might plausibly be involved in the decision-making process.
No, that's what failure rate is supposed to mean. However, what the numbers actually said are:
These two statements cannot both be true simultaneously by any proper definition of "failure rate". The iPhone 6 is a subset of all iOS devices. The claim is made that its failure rate was 29%. For the failure rate of all iOS devices to be 58%, that would mean that at least one iOS device must have a failure rate greater than 58% to pull the average up from 29% to 58%, which contradicts the statement that the iPhone 6 had the highest failure rate at 29%.
Q.E.D.
The only way you could even halfway make those numbers plausible would be if you erroneously divided the iPhone numbers by either the total number of iOS devices or worse, the total number of devices. Either of those approaches makes the numbers meaningless because you don't know the relationship between... to use your terminology... k(i) and n(i) at that point.
The vast majority of people who want to avoid expensive shipping charges will Google the problem and find an answer themselves. People go to a store when that fails.
In the short term, the only negative impact would be if the songs they're demoting are extremely popular and if the public perceives their absence as a loss in quality. Given the size of the musical corpus these days, that seems unlikely.
In the long term, this serves notice to content creators that there's no such thing as a free lunch. Normally, those content creators would have to balance the cost of exclusivity (fewer plays on those exclusive songs) against the benefits (presumably dramatically improved promotion and possibly higher royalty per click. With this policy in place, those content creators have to factor in the loss of the vast majority of their income from the other providers—not just on new content, but also on old content. That significantly changes the balance in a way that discourages these exclusive deals.
And that's a good thing. Vendor exclusivity is inherently anti-consumer.
That's not true. You're required to pay for health insurance for anyone working 30 hours or more. Similarly, you're not allowed to restrict 401k for any employer working more than 1,000 hours per year (a little over 19 hours per week).
They could cut the number of sick days or vacation days offered, but that's probably roughly the maximum extent to which they could reduce benefits other than salary.
No, it doesn't. 30 hours per week is considered full time for ACA purposes. It is, in fact, the bottom threshold below which you don't have to, so if they hired someone to work 29 hours, you'd be right.
So let me see if I understand this epic math fail correctly. Given n devices, there were k devices that were brought in for repair. Of those k devices, 58% were iOS devices, and of those 58%, 29% were iPhone 6 devices.
Which tells us absolutely nothing about the actual failure rate without knowing how the makeup of those n devices relates to the makeup of those k devices. It tells us nothing about the actual failure rate without knowing what percentage of each model within k were junked and replaced without notifying the service center in question. It tells us nothing about whether the Android and iOS users have similar levels of self-sufficiency in terms of figuring out how to solve their own problems. And there are probably at least three or four other fairly fundamental errors that make this data essentially pure noise.
Arguments over minor methodology points, such as whether to count specific types of failures in the reliability numbers, are basically moot, because the "data" is purely anecdotal and is not mathematically related to the actual rate of failure to begin with. This isn't statistically any better than saying, "Of my friends, more people have had problems with Android phones than iOS phones" or vice versa. If you know nothing about whether the sample population has similar distribution to the general population and you know nothing about whether the data is even an accurate measurement of the sample population itself, then these numbers are quite literally no better than a random number generator with a Gaussian distribution. You might as well arrive at the results by throwing darts at a dartboard. It will be approximately as meaningful.
Am I missing something?
Trust me, if even 1% of iPhone hardware failed during its warranty period, heads would roll, much less 58%.
As a 6D user, in my experience, the Wi-Fi is really nice if you're part of a group trip. You can have your cell phone out, and once in a while when there's a pause, you can snag a photo off your real camera and upload it to Facebook so that the folks back home can see what you're all doing. It's much easier than trying to take photos with two devices at once, because the extra time spent fiddling with your phone is while you're on a bus riding somewhere or whatever instead of while you're out sightseeing on a schedule.
It is also occasionally useful if you don't have (or forgot to bring) a remote controlled trigger release. You can use it to see what the camera sees (in live view/EVF mode) and tell it to take photos, albeit with a lot of shutter lag. With the dual-pixel AF in the 5D Mark IV, it should be even better because you'll have actual phase-detection autofocus with continuous focusing in live view mode instead of contrast-detection AF.
With that said, it might be worth clarifying that at high MP counts, a hybrid system might be preferable, using sensor-based stabilization for fine correction after your finger hits the button.
Canon puts the stabilization in the lens for a good reason. Sensor-based stabilization is only useful on point-and-shoot cameras or mirrorless cameras with electronic viewfinders. As soon as you have an optical path to your eye, sensor-based stabilization is worthless, because it won't help you frame the shot. By contrast, lens-based stabilization locks the image in place so that you can actually see what you're taking a picture of.
This makes a huge difference even at 300mm. By 600mm, you'd be hard pressed to ever get a shot of anything without lens-based optical stabilization.
Except that it doesn't, because it doesn't. The 5D Mark IV sensor uses a gapless microlens array. There are no boundaries between the pixels, period. All light that hits the sensor's surface goes into the sensor except for any that gets reflected when it hits the surface.
Realistically, thermal noise is almost irrelevant except for long-exposure photography (e.g. astrophotography). For normal photographic purposes, it's the shot noise that kills you in low light. When the difference between one and zero photons makes a visually noticeable difference in the resulting value, individual pixels are going to have noticeably different values than the pixels next to them even when they're getting approximately the same amount of light, because a pixel either gets the photon or it doesn't.
But that shot noise basically goes away when you downsample. If you double the number of pixels, a "pixel crop" (one pixel on the individual photo to one pixel on your screen) will give you more noise on the one with smaller sites, but it will also be looking at a much smaller area. If you crop them to cover the same area and average the signals, you'll find that the same number of photons hit both sensors and were detected, so the result is approximately the same, with the exception of the small amount of loss caused by the wiring around the pixels. And by the time that starts to become significant, you're roughly at cell phone pixel densities, and you're either doing back-side illumination, microlens arrays, or both to get rid of that problem.
The thing is, that's usually a bad sign. It means that your development teams are growing very quickly, which has two effects:
Eventually you reach a point where every additional person makes the product worse or more delayed, rather than better or faster. These days, I keep getting the feeling that Apple passed that point a while back, and they just haven't noticed yet. This is one reason why innovative ideas almost invariably come from small companies, not big ones.
The other reason is that the larger Apple grows, the harder it will be to innovate, because the breakage caused by doing so will become an ever bigger problem as the code base increases in size. At some point, it will be necessary for Apple to start over from scratch—probably by buying a company that creates some innovative alternative. At that point, it will have fully become Microsoft or IBM. And that's okay. Eventually, somebody else will come along and become the next Apple. It's the circle of life.
Mercury comes pretty close with its 3:2 spin-orbit resonance. It spins 3 times for every 2 orbits. That's close enough to being tidally locked that the difference is mostly moot from a "cooked on one side" perspective.
Ooh. I've seen this one. They send a probe, and it turns out that it's just a giant, curved mirror with a red filter.
That's not where the user impact comes in. Most people don't use headphones constantly. They use them occasionally. And they will think to themselves, "That's not a big deal." Then, at some point in the distant future:
And so on. And suddenly, what seemed like it didn't matter suddenly matters, and you have a pissed off customer.
What would be worse for Apple would be if they don't lose sales, because there's definitely a non-negligible percentage of their customers who will be negatively impacted significantly by removal of the headphone jack, and if those folks buy the phone anyway, then they're going to end up with a bad impression of Apple products, and Apple will lose them as customers. In the long run, Apple should hope that they lose those sales, because at least they'll have a chance to make up those sales by releasing a future generation that isn't missing critical features.
The ultimate destruction of Apple as a brand of amazing hardware will come if they ship a device without a headphone jack and 30% of their users don't realize how much they'll miss the headphone jack, buy the phone anyway, and then start trash-talking their new iPhone on social media before switching (permanently) to Android. If Apple ships this product, I may start doing covered calls on my Apple stock to limit my losses. As a user, this is just a big annoyance, and I'm hopeful that they'll pull their heads out of their a**es before I'm due for a new phone. But as an investor, this is absolutely terrifying, oddly reminiscent of the period where a certain Pepsi exec was running the show.
Plus, when your headphone cord breaks off in the Lightning port, you'll still be able to charge the phone... until you break a second headphone cord, anyway.
Not the thin ones they use in phones. But still, it's a solvable problem. It has been solved many times by many companies. Basically, waterproofing is nothing more than an excuse.
You could always get a keyboard case. For sure, there's a landscape-mode keyboard case for various iPhones. Not sure about the Android world, but I would assume that they exist there, too.
Statistically, almost everyone:
There are probably others, but most users have at least a few sites that use shared passwords, and most of them are the fault of the people who designed the websites.
With a 3 GB data plan, gigabit data is good for what... 24 seconds? Awesome!
The thing is, lack of upgrades usually indicates a design problem. For services like this, the software should be distributed using git so that local changes can be merged sanely. Instead, most of these bulletin boards involve moving aside the existing installation, extracting a tarball, and running some sort of installer script that does who-knows-what. So upgrading can be nightmarish for sites that involve any sort of customization.
Also, this sort of software should be designed in such a way that it never makes backwards-incompatible changes to data structures, at least for a reasonable period of time (say a year or two). It should be possible to clone your installation to a new directory, apply the patches to the new version, start it up, and let it add additional database fields, etc. as needed, but the new version should be tolerant of partial data created by the old version (and should upgrade it on the fly), and should create data in such a way that the old version can still read it. This ensures that you can test the migration to a new version without having to set up a full clone of your entire infrastructure, with the ability to roll back if it breaks something.
And ideally, a built-in upgrade scheme should be designed into the software. For example, it could have a script that clones itself into a directory beside the original and does a "git pull" in that subdirectory. After you fix any conflicts, it should let you access the new version by symlinking the new version into a subdirectory in the original version's tree. When you're satisfied, it should provide a one-button command that atomically deploys the new version by swapping out the symlink that currently points to the old version with a symlink that points to the new version.
Oh, and it should check for updates automatically and email the admin every time there's an update. And it should allow you to auto-upgrade (with automatic email notification if the upgrade fails because of git conflicts) if you configure it to do so. And it should also have an intermediate mode that always keeps the latest version ready to preview but doesn't enable the upgrade, for folks who want to verify the updates manually, but still want to be ready to quickly install security updates when they find out about an exploit.
With such a design, these systems would stay up-to-date much more consistently.
I understand the point of core hours perfectly. I don't understand the point of them being dictated from the top of the organization down. Realistically, until you have five people in the meeting, there's no chance of not being able to find a day when everyone can be there, and you shouldn't typically have that many people in a meeting unless it is either a team meeting or a broad cross-functional group meeting. Both of these should be repeating events. Decisions about which day to pick for team meetings should be determined by the team based on what works best for everyone, and everyone should agree upon a particular day each week when they all agree to be there. Broad cross-functional meetings don't require a specific person from any given team, so the team or the team's manager should decide who is responsible for representing their team in those meetings based on who will be there on that day of the week.
Workers should be willing to occasionally take brief phone calls on their days off if they need to answer an urgent question about something. More significantly, there should very rarely be anything so urgent that it can't wait a day if it happens to be that employee's day off. If you are finding that such urgent blockers come up frequently, either:
Any of these things indicates a failure of management that should be corrected ASAP, and not just because it makes flex-time easier. It is also the only real way to protect against the "hit by a bus" problem, the "won the lottery" problem, etc.
Singletons are a good default design pattern to use if you need something that should typically be shared across lots of pieces of code (e.g. a cache). With that said, my general policy is that you generally shouldn't design classes that are limited to use as a singleton. You should always provide the ability to allocate additional instances unless it is impossible to safely have more than one instance for some reason (and you must justify why this is the case).
Legally, they can't do that. For ACA purposes, for example, if someone works 30 hours or more, they're considered full-time employees legally, and you have to pay for their health insurance. And you cannot legally limit 401(k) matching unless the employee works fewer than 1,000 hours per year (19.23 hours per week).
At 30 hours per week, about the only thing they have any flexibility on is the number of vacation days. And nobody is going to join a company that makes them work 3/4 time with no vacations, so if they attempted that, it would quickly become a self-correcting problem.