It's not just an issue of understanding, it's apathy and laziness.
Yes, laziness on the part of the programmers of the device.
The default password should allow you to access exactly one function on the device: the "pick a username and password for a new admin" feature. Once that finishes, either the default password is set to cat <
Just because a door is unlocked does not mean you may walk inside, even if it is to tell the owner their door is unlocked.
This is a good analogy, because it is impossible to tell if a door is unlocked (or if a camera has the default username/password) without trying to open the door.
So, what your advice boils down to is that you never can accurately inform someone their door (system) is unlocked..
So you don't think that a combination of factors such as where you live, how much you get paid, relative market rates, current job market conditions, your recent payrises, your recent year end appraisal scores, where your partner works, your age, your time since last promotion or anything else the company has or can easily gain access to would be an indicator of how likely you are to leave?
Not for some jobs. In a lot of the tech world, the algorithm would be pretty much exactly as the GP listed, at least for talented people who are desired by employers.
And, what does the company do when "big data" says somebody is or isn't going to leave in the next year? If they use just that metric, the will find out that a lot of people who they thought weren't going to leave end up gone..."we don't need to give him that big of a raise...the computer says he won't leave anyway". Or, "hey, we better find a cheaper replacement for this guy, because he's leaving in the next year" will be a lot more likely than giving the guy what it takes to keep him.
Then, too, there's a lot of employees who won't ever leave their existing job because they can't do any better anywhere else. Sadly, many of those people are the ones that you might want to encourage to leave.
Given a choice, they'd still be using iPads.
This is the first season that any electronic device could be used by coaches and players during an NFL game. They weren't using iPads before...they were using steno pads.
That's code for "we pay well under market", and are to be avoided.
One thing that hurts where I work is that we generally have 40-hour weeks, with at most 4-5 hours per month extra for maintenance (depending on the month, your group, ongoing projects, etc.).
So, although we do pay "under market value", the hourly wage is actually higher than a 50-hours-per-week-required job. Add in the fact that the commute is much better than most people's in this region, and you end up spending about 47 hours per week on "work" (including commute), compared to the area average of nearly 60.
You're not logging into each individual server and firing off Windows Update every Patch Tuesday. In fact if you're wasting your time doing crap like that I would argue you're not a very good system administrator, because you're not learning and growing, you're simply caring and feeding.
Until that one time the automated patching system causes the critical server to fail in some way that could have been easily cleared if a human was watching.
Seriously, we automate all the patching we can, but some of the bizarre software running on our VMs means they have to be rebooted manually so that if something screws up, it can be fixed fast. And, yes, I know that for any critical service, there should be some sort of clustering, but generally I'm taking about VMs that interact with specific scientific instruments, and the vendor doesn't support any kind of high-availability. We also can't afford to spend $5M on an extra piece of hardware so that we can have a dev environment to test patches before rolling out to production.
The real problem is that although the OS image is consistent, we have so many apps that are installed on just one VM, and that ends up making every VM unique.
You need a 4th one for the time. Without an accurate time reference, you can't determine distance to satellites.
Every GPS signal is the time...that's how it works.
The signal from different satellites (which includes the time, the satellite ID, and the satellite position) is enough by itself to give you everything you need, and by determining how long each signal took to reach the receiver, the position can be fixed.
You only need 3 satellites if your position is already generally known (i.e., what hemisphere), or if the receiver assumes you are reasonably close to sea level. With 4 satellites, you can get a fix with no previous knowledge of where you were. Four will also give you accurate altitude after a few iterations.
Good thing they patented it. Now nobody else will try to implement it.
Google's PageRank already implements some version of this, at the request of the **AA.
Basically, when Google receives a DMCA takedown for a site in its index (which it honors, even though it doesn't have to because it isn't hosting the content), that site gets down-ranked for at least some searches.
So, Disney—a member of the MPAA—now has a patent that gives Google a reason to stop doing what the MPAA asked it to do.
Even if Macs weren't so expensive, something cross-platform, like BASIC, would be better.
What made Hypercard so great is that it allowed you to build a fairly decent GUI with almost no work.
Although I agree that cross-platform is the way to go, without the ability to "draw" your windows and dialog boxes, it would be just like the original BASIC, where pretty much only geeks used it.
Visual Basic is a convoluted joke.
And yet, it's much closer to what a modern Hypercard should be like than most other dev environments.
3 IDENTICAL channels up front -- not two big "mains" and a ridiculously tiny "center." You need three of the same speaker up front
5. Surrounds identical to the front (or at least from the same family)
This isn't really necessary anymore. With DSP technology, I can have my A/V receiver match the rest of the speakers to any I pick as a reference. It's scary to hear how good it does, because the horn-loaded mains sound very different from the other speakers. I just have the system adjust everything to flat response, and it evens everything out.
All my surround speakers are matched, and I'll eventually match the front 3 to the rears, but it's not a priority right now.
All my audio gear is 10+ years old, some of it sourced from Craigslist.
How do you do multi-channel sound with hardware that doesn't understand any of the newer codecs? I know it's possible to run 7 analog cables from a device to the amp, but most amps have at most one such input. Even with in-device decoding and HDMI for PCM transport, I had to update to a A/V receiver with more HDMI inputs because many newer devices don't have any other output, and there's no way 10-year-old hardware will understand a new enough HDMI standard to work with new devices.
It takes commitment and a certain degree of crazy to make a proper home cinema.
I've been doing it for 28 years now (laserdisc & matrixed surround sound back then), so it's either become normal or is way past crazy.
Because the 128GB of flash in your phone isn't enough to cap a two hour movie without a network connection?
A very reasonable bitrate for 720p video results in about 2GB/hour (including 2-channel sound).
Even a relatively insane 8GB/hour (17Mbps) would fit on a 32GB device. If you do have the ability to add a 128GB micro-SD, then the bitrate could be so far beyond the actual quality offered by a handheld camera that the codec would literally be filling frames with NOPs to keep to the requested bitrate.
The G2 is a 5.2" smartphone.
Of course, a consequence of phablets is that they're obnoxiously big to dig out of your pocket constantly
Yes, but the G2 is a 5.2" screen in a 5.5"x2.8" body, and is barely larger than the iPhone 6 (which has a 4.7" screen in a 5.4"x2.6" body). Screen size only puts the minimum limit on phone size, and doesn't always give you an idea of the real phone size.
I really don't understand people who put their phone in their pocket...I don't have a pocket that I always wear that will fit any phone comfortably and keep it safe, until phones are iPod Nano sized.
It hardly matters at all, since if you added the repository you probably set it up to prefer at least one package from there.
Yes, if a repository that you get a crucial package from is pwned, you are hosed.
But, by locking packages to a repository, you won't update openssh from "Joe's Repository for Cool Games", since the current version comes from a more official repository that hopefully will have better security (and more eyes on it).
Except that you still have to upgrade the distros that run on those VMs. So now we have to update 10+ systems instead of just one, and we need to pay someone for the server VM solution...
We set up a mirror of the repos that keeps a couple of old versions of each package. New packages are first added to the repo copy that development machines use. If all goes well there, then the packages are added to the production repo. With this setup, updates for Linux can be a cron job.
Yes, surely the VMs could start up in parallel, but I somehow doubt that it comes without its own performance penalties when all we have are spinning disks.
I understand...your lack of good a good architecture has forced you into your situation. It's not my fault that you didn't think ahead. By generally storing our VMs on shared spinning disk, we were able to allocate our limited SSDs to the systems with the highest requirements. Since then, we have added SSD cache to front all the spinning disks.
Surely there's memory deduplication, but all those images are still stored separately and all those extra pages have to be read from the spinning drives. So while we'd pay no RAM penalty for the fact that we'd be running 10 copies of RHEL on top of ESXi or KVM, at startup it'd still hammer the hard drives with redundant reads spread across all of the identical pages in those VM images. Unless ESXi or KVM somehow deduplicate the VM images on disk as well - do they? I can't bother to figure it out from the marketing fluff at the moment.
On-disk data de-duplication can be done at many levels...VMware can use linked clones, SANs can de-dupe, etc. If you don't know about these technologies, that explains why you ended up in the situation you are in.
I know people mention various race conditions, missing dependencies and such, but if those problems aren't known and solved then they are bugs and should be fixed.
When 3-year-old very repeatable bugs in systemd (and related apps) haven't even been assigned to a developer, I have no faith that any new, hard to track down bug will be fixed.
I tell them to turn to the study of mathematics, for it is only there that they might escape the lusts of the flesh. -- Thomas Mann, "The Magic Mountain"
