Apple doesn’t “send down” any updates. You’re free to take or leave any OS update you like. They’re remind you a bit, but nobody is forced to upgrade the OS they have on their phone right now.
And do you *seriously* think Apple releases updates to “actively try to fuck up older but functioning hardware”? Paranoid much? Yes, some updates have made older hardware work less well. Other updates have improved long standing issues on older hardware. That’s the nature of software development. It’s not a good thing, but it’s a far distance between “didn’t test it as much on three-year-old hardware” and “let’s intentionally add this bug to make the old phone flake out.”
This isn’t a mid-model-year thing. They’re actively shipping both versions right now. Luck of the draw if you get the better or worse CPU, same price either way. That’s not the same as bought later, got a little better for no extra money.
The value of "very good chance" is up for significant debate. I've replaced failing drives in RAID-X (for X >1) arrays a few dozen times. Haven't had that second loss happen yet. I'm not saying it's not possible, but it's not something that keeps me awake at night given the other compensating controls I have in place.
Among those compensations: 1) ZFS resilver != MD resync. If I lose a 4TB drive that had 2TB of stuff actually on it, I'm only copying 2TB worth of blocks. 50% less wear & tear on the other array members, less liklihood of a getting shot a second time while the Doctor's regenerating...
2) ZFS self-healing on read. Every time blocks are read, any individual device read problems get detected (by checksum), repaired (by block relocation), and signaled to userland (by the `zpool status` command, and also as picked up by my system monitoring solution (Zabbix) and alerted to me via email & phone push).
3) `zfs scrub` which is an on-demand, read the entire drive & apply (2). Scheduled to run weekly, I know if there are issues starting to occur long before a device fails.
4) Freaking backups. On another machine. Maybe on tape if you've got the $$$. In my case, "last year's" (or 3-4 years's...) disks go in another server which gets powered weekly for zfs send/receive, then powered down again. Also RAIDz, also subject to maybe failing at the same time as the others, but we're well past lottery odds at that point I think...
Any errors signaled by 2 or 3 get a couple of shots at the reseat the device, retry game. After that, the drive gets subbed out. Sometimes the reseat is enough for months or years of additional error free operation, sometimes the device was really going. Either way, ZFS has warned me far enough in advance to remediate before a second failure.
Basically it is just the combination of the three into an integrated stack.
Basically just, that's exactly why it excels. The benefits from the integration are very significant in real world use. Zero overhead snapshots, resilver only used blocks instead of blindly copying an entire device block by block, scrubbing only used blocks in pool to ensure all copies are consistent across devices & no bit rot has occurred (and FIXING it if it has).
You dismiss the checksumming, but that's how ZFS detects bit rot, even on a RAID-1 mirror. Mirror a device without checksums, one device has a bad write but still readable (IE no device-level read error). Without checksumming, you have no way of knowing which is correct. ZFS can detect and recover from this during a scrub or automatically and transparently on read.
The integration really does make ZFS a superior system.
For me, lack of RAID-5 is enough reason to consider BTRFS deficient. The glowing accolades as to the reliability and accuracy of fsck tools for BTRFS leave a bit to be desired: https://btrfs.wiki.kernel.org/...
I looked long & hard at BTRFS about four months ago and was considering migrating from ZFS. It blew my mind how much was lacking in BTRFS in comparison and that anyone would consider it superior in any way other than that it's in-tree.
You've over-simplified what is & isn't a derivative work. Linus himself has written about the distinction specifically as it applied to the Andrew Filesystem:
According to Linus, a driver that was originally written independently of Linux for another system and simply ported *to* Linux is not a derivative work. That's exactly the case for what ZoL is.
You've also misrepresented what the ZFS modules do in terms of their contact with kernel internals:
touches unexported APIs of the kernel
Neither ZoL or the SPL layer that it depends on touch any non-public or GPL-only symbols of the kernel. If they did, you'd be correct in there being an issue. They don't, and there isn't.
Because you can always press delete, close the window, and walk away. Preferrably without posting a big rant complaining about why you’re ragequitting first, but whatev’s
That requirement would be in conflict with a lot of existing standards that require that no one except the employee know their password. PCI for one has a line item that forbids any kind of credential sharing. Wouldn't surprise me if SOx and others had similar. There's no accountability if anyone knows (or could know) your password. Administrative reset capability is different since it leaves an audit trail.
Absent a secondary access mechanism, the company very likely doesn't have the ability to unlock the phone. The worst penalty available would be to terminate the employee, which one would assume happened about the time charges were filed, if not before.
Looking through the iOS docs as of 8.x, it looks like passcode reset isn't an option for MDM any more. It was at least in iOS 6. Makes sense considering how much vital key material in the Secure Enclave is derived from the passcode at power on. Resetting the passcode would be very close to a device wipe in terms of the data that would become un-decryptable. With the (very good) direction Apple's been going, the idea of key escrow or something on the MDM server would be unthinkable.
So no secondary access mechanism available, at least on a recent iOS device. Fire their ass and sort it out in court...
The nice thing is that once precedent is set in a federal court, all cases in that district and *usually* similar cases in other districts are ruled the same.
So the upper class fought for their rights, but they trickle down to the little guy.
Could of course be decided differently in another district & need to go to SCOTUS for a final ruling, but for now it stands. Also possibility of direct appeal to SCOTUS.
I've tried other parts. (Just for science, mind you!) TouchID looks for ridge detail and won't enroll anything but a finger. Haven't tried toes, though.
(It was my nose, you perverts... Ever tried to use your phone on a cold winter day with gloves on? You can at least poke the Next Track button with your nose, but not unlock the phone.)
If you're in a situation where your phone might be confiscated, power it off completely. At least for iOS, TouchID will not unlock the device at power on. The full passcode must be entered. Using more than the 4 (or now 6) digit minimum would be a GoodIdea(TM).
If you're compelled to provide your finger under duress, do the best you can to "smear" the print or else provide fingers that aren't enrolled for TouchID. You only get five attempts. After that, the phone will require your passphrase and even the correct finger print will no longer unlock the device.
If you're in a time-sensitive situation or can touch but can't look at the phone, hold Home & Power down for five seconds or more to force a hard power off.
In any case, powered off is safer than locked as the Secure Enclave processor holds several session keys that are derived from your passcode. Powered on but locked, the keys are technically still "there" and vulnerabilities could conceivably expose them. Powered off, they're gone completely.
I want to hire lazy programmers with ADD. They'll be thinking about three things at once (on a *bad* day), and two of them are going to be ways to automate some menial task so they don't have to do it by hand any more. Automation complete, they're on to something else that they actually have to *think* about now that the boring stuff is scripted.
Absolutely the best technical people for the job. It does take some skill to manage them though....
Looking in from the outside, it's not always easy to tell the difference between someone who's showing no substantive results for a month because they're playing solitaire all day long versus someone who's showing no results because they're solving some meta-problem which will unravel the entire task they were assigned in five minutes. The difference is at the end of the month, the Mr. Klondike really has nothing to show for it while the lazy-ADD person just kicks off their script & finishes the task assigned. Then there's the darker side of people who spend all their time (badly) solving the meta-problems and never actually accomplishing anything that needs doing. It's a fine line...
A good manager learns to nurture the meta to a point, but herd them towards actually solving the problem if things go too far afield. The Gant chart obsessed pointy haired boss will ruin these people more often than not and either send them packing elsewhere or just grind the innovation out of them. Either way, opportunity lost.
But the South Africa test and this experiment are both strongly influenced by what the subjects thought
ding, ding, ding!!!!!
Congratulations! You've just stated exactly what the study proves and also confirmed why people who claim EMI-related illness are self-deluded crazies!
The proof of this test is specifically that people's belief that they are being bombarded by radio which they believe makes them sick is what makes people sick. The presence or absence of the radio signal had no bearing on how they felt. Only their belief that the radio was there affected them. The study proves that EMI-related illness is psychosomatic, not actually caused by the radio waves as claimed.
In other words, these people are a case for the P-sychiatrist. Turning the radio off won't make them feel better. (But ironically, convincingly lying to them that you *have* turned it off, *would* make them feel better).
I understood just fine that you were taking a class. That didn't change my answer. If you brought your own hardware in and plugged it into my network, I would have fired you as a customer and tried to have your cert credit revoked if it was even slightly tech or security related.
I also would have ensured that my snapshotted machines were kept up to date and would have accommodated your software needs assuming sufficient licenses were available. I probably also would have had NAC running on any customer accessible ports to make sure your hardware couldn't have been connected.
You ran into some lazy admins, but you also violated any reasonable company policy in connecting unapproved hardware in a way that might have run afoul of CFAA.
Two wrongs don't make a right. The ends don't justify the means when NetSec is involved.
In the vast majority of cases, the problems caused by "one of you" having too little access to a machine are significantly less dangerous than having too much access. The case you've described sounds more than a little BOFH-ish. That's unfortunate, but it happens. They still made the correct decision in restricting access to the machines.
If you'd brought your own laptop in and plugged it into my corporate network, you'd have been summarily dismissed same day, no questions asked.
The fact that you were trying to do something you think was okay doesn't change the fact that lots of end users try to do dumb and dangerous things daily. Many of them also see nothing wrong with what they're trying to do. Networks with wide open machines are full of compromised machines.
Not to sugar coat it, but IT knows better than end users when it comes to security and compliance. We get paid to be experts in it. End users get paid to be experts in other things and will (probably) never be equipped to make correct IT security decisions.
You don't have to like the restrictions, but you do have to live with them and comply with our security policy. Your other option is find another job.
In all seriousness, I think the vast majority of those who complain the most bitterly about IT restricting software installs are either looking to goof off (solitaire, sports, streaming, etc.) or demanding useless customizations (screen savers, themes, etc.).
A very small minority may be programmers or other engineers who would legitimately benefit from additional software but work in misguided shops that force restrictions on people who do know how to handle themselves correctly. My heart goes out to people stuck in that situation.
But yes, the vast majority of denied exceptions for additional software are denied for good reason.
I work for a large-ish state.gov. Somebody asks for a piece of software and makes a reasonable case as to why they need it to do work (or at least how it would help them work more effectively), and they get the exception. That's assuming the software isn't malware, privacy violating, pirated, etc. Default policy with exceptions granted on a per-case basis works just fine.
That's not to say there aren't complaints. No, your fish screensaver (that chews CPU all day long and may or may not actually be mining Bitcoin) isn't something you need to do work nor that will help you work more effectively. That's denied. "101 Favorite Solitaire?" Nope. Sorry...
Be a reasonable human being to your sysadmins, make a legitimate request with a clear justification, and everything works out fine. Throw a tantrum and complain about how it's broken and you can't do anything, and your call will be answered in the order it was *DIAL TONE*.
Have you ever in your life met an actual end user? What you're asking for is beyond the vast majority of end users. Further, most of them if told explicitly, "You will be responsible for bad things that happen on your computer as a result of your actions," will balk and refuse to accept that claiming that's IT's job (which is true: It is.)
They want all the power and none of the responsibility. Indeed, the user is the problem, but the user is not capable of understanding the problem they cause. It's far more complex than any of them have any interest in learning. They rely on IT to manage systems and keep them running. The way that IT does that is by configuring a platform that meets their needs and locking it down so they can't screw it up.
Slashdot Mirror
From TFA:
Different model #'s detectable in software, but not listed on the package.
Apple doesn’t “send down” any updates. You’re free to take or leave any OS update you like. They’re remind you a bit, but nobody is forced to upgrade the OS they have on their phone right now.
And do you *seriously* think Apple releases updates to “actively try to fuck up older but functioning hardware”? Paranoid much? Yes, some updates have made older hardware work less well. Other updates have improved long standing issues on older hardware. That’s the nature of software development. It’s not a good thing, but it’s a far distance between “didn’t test it as much on three-year-old hardware” and “let’s intentionally add this bug to make the old phone flake out.”
This isn’t a mid-model-year thing. They’re actively shipping both versions right now. Luck of the draw if you get the better or worse CPU, same price either way. That’s not the same as bought later, got a little better for no extra money.
The value of "very good chance" is up for significant debate. I've replaced failing drives in RAID-X (for X >1) arrays a few dozen times. Haven't had that second loss happen yet. I'm not saying it's not possible, but it's not something that keeps me awake at night given the other compensating controls I have in place.
Among those compensations:
1) ZFS resilver != MD resync. If I lose a 4TB drive that had 2TB of stuff actually on it, I'm only copying 2TB worth of blocks. 50% less wear & tear on the other array members, less liklihood of a getting shot a second time while the Doctor's regenerating...
2) ZFS self-healing on read. Every time blocks are read, any individual device read problems get detected (by checksum), repaired (by block relocation), and signaled to userland (by the `zpool status` command, and also as picked up by my system monitoring solution (Zabbix) and alerted to me via email & phone push).
3) `zfs scrub` which is an on-demand, read the entire drive & apply (2). Scheduled to run weekly, I know if there are issues starting to occur long before a device fails.
4) Freaking backups. On another machine. Maybe on tape if you've got the $$$. In my case, "last year's" (or 3-4 years's...) disks go in another server which gets powered weekly for zfs send/receive, then powered down again. Also RAIDz, also subject to maybe failing at the same time as the others, but we're well past lottery odds at that point I think...
Any errors signaled by 2 or 3 get a couple of shots at the reseat the device, retry game. After that, the drive gets subbed out. Sometimes the reseat is enough for months or years of additional error free operation, sometimes the device was really going. Either way, ZFS has warned me far enough in advance to remediate before a second failure.
You misunderstand the differing purposes of RAID-X and backup.
`sudo rm -rf /`
Tell me how having 27 redundant drives in my RAID array saved me from going to backup in my lifetime.
Basically just, that's exactly why it excels. The benefits from the integration are very significant in real world use. Zero overhead snapshots, resilver only used blocks instead of blindly copying an entire device block by block, scrubbing only used blocks in pool to ensure all copies are consistent across devices & no bit rot has occurred (and FIXING it if it has).
You dismiss the checksumming, but that's how ZFS detects bit rot, even on a RAID-1 mirror. Mirror a device without checksums, one device has a bad write but still readable (IE no device-level read error). Without checksumming, you have no way of knowing which is correct. ZFS can detect and recover from this during a scrub or automatically and transparently on read.
The integration really does make ZFS a superior system.
For me, lack of RAID-5 is enough reason to consider BTRFS deficient. The glowing accolades as to the reliability and accuracy of fsck tools for BTRFS leave a bit to be desired: https://btrfs.wiki.kernel.org/...
I looked long & hard at BTRFS about four months ago and was considering migrating from ZFS. It blew my mind how much was lacking in BTRFS in comparison and that anyone would consider it superior in any way other than that it's in-tree.
You've over-simplified what is & isn't a derivative work. Linus himself has written about the distinction specifically as it applied to the Andrew Filesystem:
http://yarchive.net/comp/linux...
According to Linus, a driver that was originally written independently of Linux for another system and simply ported *to* Linux is not a derivative work. That's exactly the case for what ZoL is.
You've also misrepresented what the ZFS modules do in terms of their contact with kernel internals:
Neither ZoL or the SPL layer that it depends on touch any non-public or GPL-only symbols of the kernel. If they did, you'd be correct in there being an issue. They don't, and there isn't.
Because you can always press delete, close the window, and walk away. Preferrably without posting a big rant complaining about why you’re ragequitting first, but whatev’s
How is this different than a mailto: link which can populate the subject, body, etc. but not actually send it until you tap send?
Is that a euphemism for masturbation?
That requirement would be in conflict with a lot of existing standards that require that no one except the employee know their password. PCI for one has a line item that forbids any kind of credential sharing. Wouldn't surprise me if SOx and others had similar. There's no accountability if anyone knows (or could know) your password. Administrative reset capability is different since it leaves an audit trail.
Absent a secondary access mechanism, the company very likely doesn't have the ability to unlock the phone. The worst penalty available would be to terminate the employee, which one would assume happened about the time charges were filed, if not before.
Looking through the iOS docs as of 8.x, it looks like passcode reset isn't an option for MDM any more. It was at least in iOS 6. Makes sense considering how much vital key material in the Secure Enclave is derived from the passcode at power on. Resetting the passcode would be very close to a device wipe in terms of the data that would become un-decryptable. With the (very good) direction Apple's been going, the idea of key escrow or something on the MDM server would be unthinkable.
So no secondary access mechanism available, at least on a recent iOS device. Fire their ass and sort it out in court...
The nice thing is that once precedent is set in a federal court, all cases in that district and *usually* similar cases in other districts are ruled the same.
So the upper class fought for their rights, but they trickle down to the little guy.
Could of course be decided differently in another district & need to go to SCOTUS for a final ruling, but for now it stands. Also possibility of direct appeal to SCOTUS.
I've tried other parts. (Just for science, mind you!) TouchID looks for ridge detail and won't enroll anything but a finger. Haven't tried toes, though.
(It was my nose, you perverts... Ever tried to use your phone on a cold winter day with gloves on? You can at least poke the Next Track button with your nose, but not unlock the phone.)
If you're in a situation where your phone might be confiscated, power it off completely. At least for iOS, TouchID will not unlock the device at power on. The full passcode must be entered. Using more than the 4 (or now 6) digit minimum would be a GoodIdea(TM).
If you're compelled to provide your finger under duress, do the best you can to "smear" the print or else provide fingers that aren't enrolled for TouchID. You only get five attempts. After that, the phone will require your passphrase and even the correct finger print will no longer unlock the device.
If you're in a time-sensitive situation or can touch but can't look at the phone, hold Home & Power down for five seconds or more to force a hard power off.
In any case, powered off is safer than locked as the Secure Enclave processor holds several session keys that are derived from your passcode. Powered on but locked, the keys are technically still "there" and vulnerabilities could conceivably expose them. Powered off, they're gone completely.
Alternative to feeling like myself, oh alcohol I still drink to your health.
Barenaked Ladies really knew what was up.
It's unquestionably an asset to programmers.
I want to hire lazy programmers with ADD. They'll be thinking about three things at once (on a *bad* day), and two of them are going to be ways to automate some menial task so they don't have to do it by hand any more. Automation complete, they're on to something else that they actually have to *think* about now that the boring stuff is scripted.
Absolutely the best technical people for the job. It does take some skill to manage them though....
Looking in from the outside, it's not always easy to tell the difference between someone who's showing no substantive results for a month because they're playing solitaire all day long versus someone who's showing no results because they're solving some meta-problem which will unravel the entire task they were assigned in five minutes. The difference is at the end of the month, the Mr. Klondike really has nothing to show for it while the lazy-ADD person just kicks off their script & finishes the task assigned. Then there's the darker side of people who spend all their time (badly) solving the meta-problems and never actually accomplishing anything that needs doing. It's a fine line...
A good manager learns to nurture the meta to a point, but herd them towards actually solving the problem if things go too far afield. The Gant chart obsessed pointy haired boss will ruin these people more often than not and either send them packing elsewhere or just grind the innovation out of them. Either way, opportunity lost.
$12k per gram? I'll stick with cocaine, thanks...
ding, ding, ding!!!!!
Congratulations! You've just stated exactly what the study proves and also confirmed why people who claim EMI-related illness are self-deluded crazies!
The proof of this test is specifically that people's belief that they are being bombarded by radio which they believe makes them sick is what makes people sick. The presence or absence of the radio signal had no bearing on how they felt. Only their belief that the radio was there affected them. The study proves that EMI-related illness is psychosomatic, not actually caused by the radio waves as claimed.
In other words, these people are a case for the P-sychiatrist. Turning the radio off won't make them feel better. (But ironically, convincingly lying to them that you *have* turned it off, *would* make them feel better).
I understood just fine that you were taking a class. That didn't change my answer. If you brought your own hardware in and plugged it into my network, I would have fired you as a customer and tried to have your cert credit revoked if it was even slightly tech or security related.
I also would have ensured that my snapshotted machines were kept up to date and would have accommodated your software needs assuming sufficient licenses were available. I probably also would have had NAC running on any customer accessible ports to make sure your hardware couldn't have been connected.
You ran into some lazy admins, but you also violated any reasonable company policy in connecting unapproved hardware in a way that might have run afoul of CFAA.
Two wrongs don't make a right. The ends don't justify the means when NetSec is involved.
In the vast majority of cases, the problems caused by "one of you" having too little access to a machine are significantly less dangerous than having too much access. The case you've described sounds more than a little BOFH-ish. That's unfortunate, but it happens. They still made the correct decision in restricting access to the machines.
If you'd brought your own laptop in and plugged it into my corporate network, you'd have been summarily dismissed same day, no questions asked.
The fact that you were trying to do something you think was okay doesn't change the fact that lots of end users try to do dumb and dangerous things daily. Many of them also see nothing wrong with what they're trying to do. Networks with wide open machines are full of compromised machines.
Not to sugar coat it, but IT knows better than end users when it comes to security and compliance. We get paid to be experts in it. End users get paid to be experts in other things and will (probably) never be equipped to make correct IT security decisions.
You don't have to like the restrictions, but you do have to live with them and comply with our security policy. Your other option is find another job.
In all seriousness, I think the vast majority of those who complain the most bitterly about IT restricting software installs are either looking to goof off (solitaire, sports, streaming, etc.) or demanding useless customizations (screen savers, themes, etc.).
A very small minority may be programmers or other engineers who would legitimately benefit from additional software but work in misguided shops that force restrictions on people who do know how to handle themselves correctly. My heart goes out to people stuck in that situation.
But yes, the vast majority of denied exceptions for additional software are denied for good reason.
I work for a large-ish state.gov. Somebody asks for a piece of software and makes a reasonable case as to why they need it to do work (or at least how it would help them work more effectively), and they get the exception. That's assuming the software isn't malware, privacy violating, pirated, etc. Default policy with exceptions granted on a per-case basis works just fine.
That's not to say there aren't complaints. No, your fish screensaver (that chews CPU all day long and may or may not actually be mining Bitcoin) isn't something you need to do work nor that will help you work more effectively. That's denied. "101 Favorite Solitaire?" Nope. Sorry...
Be a reasonable human being to your sysadmins, make a legitimate request with a clear justification, and everything works out fine. Throw a tantrum and complain about how it's broken and you can't do anything, and your call will be answered in the order it was *DIAL TONE*.
Have you ever in your life met an actual end user? What you're asking for is beyond the vast majority of end users. Further, most of them if told explicitly, "You will be responsible for bad things that happen on your computer as a result of your actions," will balk and refuse to accept that claiming that's IT's job (which is true: It is.)
They want all the power and none of the responsibility. Indeed, the user is the problem, but the user is not capable of understanding the problem they cause. It's far more complex than any of them have any interest in learning. They rely on IT to manage systems and keep them running. The way that IT does that is by configuring a platform that meets their needs and locking it down so they can't screw it up.