In general, if a device supports microSD cards of 64GB, they'll work fine past that point.
The original SD spec was limited in size. SDHC came out in 2006 and allowed for card capacity of up to 32GB. Most devices made in 2013 or earlier are SDHC with a 32GB limit (such as my Thinkpad T61p laptop and my Asus TF700T tablet). That means putting a 64GB card into a SDHC slot is a bad idea (it will probably corrupt the data once it tries to write past the 32GB mark).
SDXC was introduced three years later in 2009, and allows for cards up to 2TB in size. A lot of times, the manufacturers will only certify up to the size that was available when the device was released. So larger cards may very well work, up to the limits of the spec.
A lot of Java boilerplate code (and not just getters/setters) can be gotten rid of with a bit of AspectJ (Spring Roo leverages this heavily). With good use of AspectJ, your java objects look like POJOs (plain old java objects) with all of the extra stuff added at compile-time by the.aj files.
Best practice in the real world is four reference clocks or only one. With just three configured you run into the problem of ending up in the "just two clocks situation" more often then not. At which point, NTP is likely to oscillate between the two remaining good candidates (without the "prefer" keyword).
How you choose to configure NTP is a tricky art depending on how resilient you want to be and whether you have a local time source or need less then 5ms accuracy. For most situations (99% of servers), being within 500ms of the "internet time" is enough. Your goal is mostly to avoid the issue where the clock is off by tens of seconds or worse.
I send bulk email for an opt-in list with mailman (opt in as in you have to walk in the store and physically write your email on our sign up sheet).
It's not opt-in unless you send out a verification email to the address on the sign-up sheet. You have zero guarantee that the person writing down that address has the permission of the person who receives mail at that address. That verification email should explain how you obtained the address and require action on the recipient's part in order to remain on the list. If you get no response or the recipient takes no action, you should throw away that record.
No, you're not allowed to do advertising in that initial mailing either. And those "asking permission" emails should go out sooner (within a week) rather then later (months+).
It breaks a few mailing (discussion, not advertising) list programs (such as my uni's one) if you send from a SPF protected address because the list server forwards it with you address in the from boxs. Other then that it works well.
Then that mailing list is poorly maintained. I belong to dozens of mailing lists on a domain with very restrictive SPF records and have never had issues.
If you allow the mailing list to forge your email address, then *everyone* can forge your email address. The better mailing list software no longer forges your email address on outbound mail.
SPF is all about preventing joe-jobs where someone sends out malicious email and uses your email address to do it.
With properly configured SPF records (with "-all"), you're telling all of the mail servers of the world (or the majority which support SPF) that if the email doesn't come from a select (and small) group of IP addresses that they should discard it. A message that fails SPF verification is a very bad thing in most spam software and will get a severe down-vote.
That being said, SPF is not anti-spam - it's anti-forgery. DKIM is also anti-forgery.
(Yes there are teething pains with putting SPF on your domain. But you don't have to use it. But if you can, you should.)
My older Thinkpad T61p is around 6.0 lbs. We just got a T440s (which is Lenovo's thin version of the T440) and it's about 3.5 lbs. Macbook air units are 2.4-3.0 lbs.
(I was curious as to weights of various devices. And most of those figures don't include the weight of the charger.)
Eh, I'm looking forward to Systemd because it will be an improvement over init.d scripts. Especially when you have multiple services that depend on other services being up and running.
In today's world, you have to write some other non-standard script or use some other non-standard hack of the original init scripts to make sure that X starts before Y and that Z also gets notified that X restarted. That's a major pain point for anyone who doesn't depend solely on monolithic apps. Such as a mail server... (clamd, amavisd, postfix, dovecot, sogod all intertwined).
That being stated - there's no way I will roll out RHEL 7 or CentOS 7 until the 7.1 or 7.2 release (i.e. sometime in late 2015). I'm not convinced yet that systemd is fully baked yet. I have the same stance on btrfs, which is still a technology preview.
And binary logs are not a huge deal when it will make it far easier to find an event without having to look at a dozen different log files, each with a slightly different naming scheme or location. While the current log viewing tools are rudimentary, I expect that we'll see improved tools as people scratch the itches. The problem with binary logs is that people have really only dealt with Window's proprietary implementation (which is has been sucky for a decade-plus). There's no way to copy the log files off to a second server (if you can get the drives mounted) and the built-in log viewing tool is just horrible.
Try seafile - not saying they cover everything, but for file sync, it seems to work very well (and scales better then Owncloud when you have a few thousand files).
Writing down a password is not the big bug-a-boo that you make it out to be.
Writing it down and leaving it stuck to the monitor / keyboard is a problem (a social problem). Writing it down and keeping it in a secure location, not such a big deal (password manager software falls into the second category).
The trap that many system admins fall into is that they think requiring long and complex passphrases meshes well when combined with forced password expiration of less then a few years. When you force password resets on everyone on a week/monthly/quarterly basis, your users will figure out some trivial method that gets past your system or resort to just sticking passwords on notes stuck to monitors.
Far better to let them choose something reasonably complex (which is 14+ characters these days) then monitor for signs of unauthorized activity. And add in two-factor authentication using their corporate assigned phone or smart card or token thingy that kicks in if things look iffy.
When every developer in the offices pulls out every thing in the repository and tries to check the whole repo in after modifying the 1-2 files they changed, that is the problem.
That causes zero issues in SVN, because in SVN it only commits the files that have changed... now, if you have a developer editing dozens and dozens of files and doing a massive commit, that's a separate management issue. (i.e. they should be doing a feature branch)
Where SVN falls down is in complicated branch/merge scenarios, and they're constantly working to improve it. Git, Mercurial or other DVCS systems are just better at that.
(shrugs) I've looked at git, mercurial and subversion - and SVN is just easier for regular users to understand. The main hurdle they have is learning the update / modify / commit cycle and that the shorter the cycle, the better things work. Plus, learning not to leave their working copy / development areas dirty with uncommitted changes.
Battery life depends on a bunch of things...
- What you leave running in the background
- Whether bluetooth / wifi / cell / GPS are on/off
- Whether you have a good cellular signal (more bars = less power needed to talk with tower)
- Quality of the WiFi signal / network congestion
- Screen brightness
With the HTC One (m8), I have to charge it every 2-4 days. Depends on how much I'm using it, what the weather is like outside, how many hours I spent on the phone that day, and where it spent most of the day.
I spent about 2.5 hours on conference/phone calls today and the phone has been off the charger for about 18hrs. Battery is at 66%. GPS, WiFi and Bluetooth are all turned on. That's not fabulous but not horrible either.
It does matter. When I compare my older Asus TF700T (tablet, but same resolution as the phone) with a Quad-core 1.6 GHz Cortex-A9 compared to my HTC One (m8) with 2.3 GHz quad-core Snapdragon 801, the difference is immense. The HTC device is extremely responsive and snappy in comparison.
On the tablet, I'm constantly having to wait on it to pull up email, or switch to the chat program, or open browser pages. I'm not sure if that is because it is one Android revision behind the HTC or if Asus did something with the UI or if the Cortex A9 chip is just that much worse then the Snapdragon 801.
Now, once you get past the "knee" where you can switch apps in under about 0.25sec and where you are not stuck waiting 3-10 seconds for something to happen, then further performance increases won't matter anywhere near as much.
(It's just more obvious if you use multiple devices for a few weeks.)
VSS (Visual SourceSafe) was okay - as long as you locked it up behind a SourceOffSite (3rd party) server. The SOS service as the primary interface between the VSS repository and the clients prevented about 99% of corruption issues.
This was back when your options amounted to VSS, Perforce, and a few other high priced version control systems. About the only free solution back around 2000 was CVS, and that was just bad for other reasons.
(Some teams benefit from distributed version control systems like Mercurial/Git. Others benefit more from centralized VCS like SVN / TFS / Perforce. We prefer SVN because it is far easier for non-technical members, i.e. mere mortals, to understand and much harder for them to do the wrong thing.)
I greatly enjoy my (m8) that I got this past spring. The phone is very responsive, makes my 2-year old Asus TF700T tablet feel like a slug (even though both are quad-core and the speed on the HTC is not that much more).
BlinkFeed thing is eh... doesn't bother me and sometimes I use it to pass the time, but I wouldn't miss it either.
It's not a Google phone, but I am pretty happy with my HTC One (m8) and there's a newer less expensive version (HTC Desire?). Five inch, 1080p, and very little bloatware / UI lag. HTC did a good job and it's a very responsive UI, better then my Asus tablet.
Ebola would have to shed about 80% of its mass to get airborne. At which point, it probably would not be Ebola any longer. There's just a huge difference between fluid-borne and air-borne viruses in terms of mass.
Droplets are the big issue, small enough not to be visible to the naked eye, but with a range of 1-2m (3m if the wind blows hard).
Even if it never scales up past cell-phone battery size, the increased recharge ability (10,000 cycles) would make it far better then today's batteries which start to fade after ~200 to ~1000 cycles.
Which was one of the more annoying features of early Lithium Ion batteries...
Single-core performance has mostly stalled, yes. It used to double in power every 3 years, but since mid-2000s, that pace has slowed dramatically.
I'd estimate about 10-15% improvement per year these days. A modern 2.5GHz Intel i5/i7 is probably 50-75% faster then a 2.5GHz Intel Core/Core2 from 2007. Plus memory speed has gone from DDR2-533/800 to DDR3-1600 (or 2400-3200), which also makes for a 10-30% boost.
Over a 5-year time span, it's definitely noticeable. And a 7-year old machine (even with dual-core, a SSD + fresh install of Win7 + 8GB RAM) does feel a bit sluggish compared to a more recent machine. My AMD FX-8350 is much more enjoyable / responsive then my Intel Core2 Duo from 2007. And the older machine runs Win7, 8GB and a SSD.
Now, we're long past the days of needing to upgrade every 3 years just to do the bare minimums, but you can't run a machine forever. Keeping a machine for five years is pretty common, and you can stretch that to 7-10 years if the hardware holds up. Multi-core, plenty of RAM, and SSDs help greatly in that regards. Most of the PC retirements from when multi-core became common are likely to be hardware related.
Don't confuse incubation period with symptomatic period with infectious period. With Ebola, incubation can be 3-21 days, but you are only infectious once you become symptomatic. Because unless you come in contact with bodily fluids, you won't catch it. (The problem is that if the host is extremely symptomatic, there is thrashing / spatter of fluids everywhere.)
This is unlike the common flu where are are infectious, even if non-symptomatic.
Fortunately, it is also highly unlikely to switch from being spread by droplets / fluids to becoming completely airborne. AIDS/HIV have been known about for decades, but have never made the switch from being a blood / fluid spread virus into an airborne virus. The sequence of random mutations required in order to switch infection style is huge.
(The Reston Ebola study was not able to prove simian to simian airborne transmission. So it's not 100% proved that Ebola can spread without physical contact.)
OS/2 Warp was pretty good for the time (93-96 era). I ran OS/2 2.x and 3.x for a long while as my main operating system. But application selection was really limited, and running 16-bit Windows programs only got you so far.
Not having to reboot for weeks at a time was a very nice feature. This was back when Win95 could only run for about 40-some hours before crashing due to an overflow in a counter.
But there were no open-source development tools at the time, so in order to write OS/2 applications you had to pony up a few hundred dollars for the compiler, then more money for a GUI framework library, plus more money for documentation. That, I feel, was IBM's biggest mistake - charging for development tools. But then, this was the days when a 28k modem was high-speed and ISDN 128k lines were popular - so not sure how they would have distributed it.
Linux was still a minor blip at the time (I installed an early version of Red Hat in the late 90s).
Slashdot Mirror
In general, if a device supports microSD cards of 64GB, they'll work fine past that point.
The original SD spec was limited in size. SDHC came out in 2006 and allowed for card capacity of up to 32GB. Most devices made in 2013 or earlier are SDHC with a 32GB limit (such as my Thinkpad T61p laptop and my Asus TF700T tablet). That means putting a 64GB card into a SDHC slot is a bad idea (it will probably corrupt the data once it tries to write past the 32GB mark).
SDXC was introduced three years later in 2009, and allows for cards up to 2TB in size. A lot of times, the manufacturers will only certify up to the size that was available when the device was released. So larger cards may very well work, up to the limits of the spec.
A lot of Java boilerplate code (and not just getters/setters) can be gotten rid of with a bit of AspectJ (Spring Roo leverages this heavily). With good use of AspectJ, your java objects look like POJOs (plain old java objects) with all of the extra stuff added at compile-time by the .aj files.
Best practice in the real world is four reference clocks or only one. With just three configured you run into the problem of ending up in the "just two clocks situation" more often then not. At which point, NTP is likely to oscillate between the two remaining good candidates (without the "prefer" keyword).
How you choose to configure NTP is a tricky art depending on how resilient you want to be and whether you have a local time source or need less then 5ms accuracy. For most situations (99% of servers), being within 500ms of the "internet time" is enough. Your goal is mostly to avoid the issue where the clock is off by tens of seconds or worse.
I send bulk email for an opt-in list with mailman (opt in as in you have to walk in the store and physically write your email on our sign up sheet).
It's not opt-in unless you send out a verification email to the address on the sign-up sheet. You have zero guarantee that the person writing down that address has the permission of the person who receives mail at that address. That verification email should explain how you obtained the address and require action on the recipient's part in order to remain on the list. If you get no response or the recipient takes no action, you should throw away that record.
No, you're not allowed to do advertising in that initial mailing either. And those "asking permission" emails should go out sooner (within a week) rather then later (months+).
It breaks a few mailing (discussion, not advertising) list programs (such as my uni's one) if you send from a SPF protected address because the list server forwards it with you address in the from boxs. Other then that it works well.
Then that mailing list is poorly maintained. I belong to dozens of mailing lists on a domain with very restrictive SPF records and have never had issues.
If you allow the mailing list to forge your email address, then *everyone* can forge your email address. The better mailing list software no longer forges your email address on outbound mail.
SPF is all about preventing joe-jobs where someone sends out malicious email and uses your email address to do it.
With properly configured SPF records (with "-all"), you're telling all of the mail servers of the world (or the majority which support SPF) that if the email doesn't come from a select (and small) group of IP addresses that they should discard it. A message that fails SPF verification is a very bad thing in most spam software and will get a severe down-vote.
That being said, SPF is not anti-spam - it's anti-forgery. DKIM is also anti-forgery.
(Yes there are teething pains with putting SPF on your domain. But you don't have to use it. But if you can, you should.)
My older Thinkpad T61p is around 6.0 lbs. We just got a T440s (which is Lenovo's thin version of the T440) and it's about 3.5 lbs. Macbook air units are 2.4-3.0 lbs.
(I was curious as to weights of various devices. And most of those figures don't include the weight of the charger.)
Eh, I'm looking forward to Systemd because it will be an improvement over init.d scripts. Especially when you have multiple services that depend on other services being up and running.
In today's world, you have to write some other non-standard script or use some other non-standard hack of the original init scripts to make sure that X starts before Y and that Z also gets notified that X restarted. That's a major pain point for anyone who doesn't depend solely on monolithic apps. Such as a mail server... (clamd, amavisd, postfix, dovecot, sogod all intertwined).
That being stated - there's no way I will roll out RHEL 7 or CentOS 7 until the 7.1 or 7.2 release (i.e. sometime in late 2015). I'm not convinced yet that systemd is fully baked yet. I have the same stance on btrfs, which is still a technology preview.
And binary logs are not a huge deal when it will make it far easier to find an event without having to look at a dozen different log files, each with a slightly different naming scheme or location. While the current log viewing tools are rudimentary, I expect that we'll see improved tools as people scratch the itches. The problem with binary logs is that people have really only dealt with Window's proprietary implementation (which is has been sucky for a decade-plus). There's no way to copy the log files off to a second server (if you can get the drives mounted) and the built-in log viewing tool is just horrible.
Try seafile - not saying they cover everything, but for file sync, it seems to work very well (and scales better then Owncloud when you have a few thousand files).
Writing down a password is not the big bug-a-boo that you make it out to be.
Writing it down and leaving it stuck to the monitor / keyboard is a problem (a social problem). Writing it down and keeping it in a secure location, not such a big deal (password manager software falls into the second category).
The trap that many system admins fall into is that they think requiring long and complex passphrases meshes well when combined with forced password expiration of less then a few years. When you force password resets on everyone on a week/monthly/quarterly basis, your users will figure out some trivial method that gets past your system or resort to just sticking passwords on notes stuck to monitors.
Far better to let them choose something reasonably complex (which is 14+ characters these days) then monitor for signs of unauthorized activity. And add in two-factor authentication using their corporate assigned phone or smart card or token thingy that kicks in if things look iffy.
When every developer in the offices pulls out every thing in the repository and tries to check the whole repo in after modifying the 1-2 files they changed, that is the problem.
That causes zero issues in SVN, because in SVN it only commits the files that have changed... now, if you have a developer editing dozens and dozens of files and doing a massive commit, that's a separate management issue. (i.e. they should be doing a feature branch)
Where SVN falls down is in complicated branch/merge scenarios, and they're constantly working to improve it. Git, Mercurial or other DVCS systems are just better at that.
(shrugs) I've looked at git, mercurial and subversion - and SVN is just easier for regular users to understand. The main hurdle they have is learning the update / modify / commit cycle and that the shorter the cycle, the better things work. Plus, learning not to leave their working copy / development areas dirty with uncommitted changes.
Battery life depends on a bunch of things...
- What you leave running in the background
- Whether bluetooth / wifi / cell / GPS are on/off
- Whether you have a good cellular signal (more bars = less power needed to talk with tower)
- Quality of the WiFi signal / network congestion
- Screen brightness
With the HTC One (m8), I have to charge it every 2-4 days. Depends on how much I'm using it, what the weather is like outside, how many hours I spent on the phone that day, and where it spent most of the day.
I spent about 2.5 hours on conference/phone calls today and the phone has been off the charger for about 18hrs. Battery is at 66%. GPS, WiFi and Bluetooth are all turned on. That's not fabulous but not horrible either.
It does matter. When I compare my older Asus TF700T (tablet, but same resolution as the phone) with a Quad-core 1.6 GHz Cortex-A9 compared to my HTC One (m8) with 2.3 GHz quad-core Snapdragon 801, the difference is immense. The HTC device is extremely responsive and snappy in comparison.
On the tablet, I'm constantly having to wait on it to pull up email, or switch to the chat program, or open browser pages. I'm not sure if that is because it is one Android revision behind the HTC or if Asus did something with the UI or if the Cortex A9 chip is just that much worse then the Snapdragon 801.
Now, once you get past the "knee" where you can switch apps in under about 0.25sec and where you are not stuck waiting 3-10 seconds for something to happen, then further performance increases won't matter anywhere near as much.
(It's just more obvious if you use multiple devices for a few weeks.)
VSS (Visual SourceSafe) was okay - as long as you locked it up behind a SourceOffSite (3rd party) server. The SOS service as the primary interface between the VSS repository and the clients prevented about 99% of corruption issues.
This was back when your options amounted to VSS, Perforce, and a few other high priced version control systems. About the only free solution back around 2000 was CVS, and that was just bad for other reasons.
(Some teams benefit from distributed version control systems like Mercurial/Git. Others benefit more from centralized VCS like SVN / TFS / Perforce. We prefer SVN because it is far easier for non-technical members, i.e. mere mortals, to understand and much harder for them to do the wrong thing.)
I greatly enjoy my (m8) that I got this past spring. The phone is very responsive, makes my 2-year old Asus TF700T tablet feel like a slug (even though both are quad-core and the speed on the HTC is not that much more).
BlinkFeed thing is eh... doesn't bother me and sometimes I use it to pass the time, but I wouldn't miss it either.
It's not a Google phone, but I am pretty happy with my HTC One (m8) and there's a newer less expensive version (HTC Desire?). Five inch, 1080p, and very little bloatware / UI lag. HTC did a good job and it's a very responsive UI, better then my Asus tablet.
Ebola would have to shed about 80% of its mass to get airborne. At which point, it probably would not be Ebola any longer. There's just a huge difference between fluid-borne and air-borne viruses in terms of mass.
Droplets are the big issue, small enough not to be visible to the naked eye, but with a range of 1-2m (3m if the wind blows hard).
Even if it never scales up past cell-phone battery size, the increased recharge ability (10,000 cycles) would make it far better then today's batteries which start to fade after ~200 to ~1000 cycles.
Which was one of the more annoying features of early Lithium Ion batteries...
BoLS says unemployment is down to around 6%.
Now, you may argue with the specifics, but the general trend has been downward since 2009. Or a more detailed article.
Estimates are that care like that costs $800-$1000 per hour, possibly as much as double that (if isolation wards are needed).
So for 20 days, that would be in the realm of $500,000.
Thanks, my HTC One (m8) has "hardware backed" security.
My older Asus tablet does not.
That view is fine... as long as blackouts only extend to a minor geographical distance, such as 30 miles.
These days, you can be 300 miles away from the event, and be subject to blackout restrictions. That's asinine and overreaches.
Single-core performance has mostly stalled, yes. It used to double in power every 3 years, but since mid-2000s, that pace has slowed dramatically.
I'd estimate about 10-15% improvement per year these days. A modern 2.5GHz Intel i5/i7 is probably 50-75% faster then a 2.5GHz Intel Core/Core2 from 2007. Plus memory speed has gone from DDR2-533/800 to DDR3-1600 (or 2400-3200), which also makes for a 10-30% boost.
Over a 5-year time span, it's definitely noticeable. And a 7-year old machine (even with dual-core, a SSD + fresh install of Win7 + 8GB RAM) does feel a bit sluggish compared to a more recent machine. My AMD FX-8350 is much more enjoyable / responsive then my Intel Core2 Duo from 2007. And the older machine runs Win7, 8GB and a SSD.
Now, we're long past the days of needing to upgrade every 3 years just to do the bare minimums, but you can't run a machine forever. Keeping a machine for five years is pretty common, and you can stretch that to 7-10 years if the hardware holds up. Multi-core, plenty of RAM, and SSDs help greatly in that regards. Most of the PC retirements from when multi-core became common are likely to be hardware related.
Don't confuse incubation period with symptomatic period with infectious period. With Ebola, incubation can be 3-21 days, but you are only infectious once you become symptomatic. Because unless you come in contact with bodily fluids, you won't catch it. (The problem is that if the host is extremely symptomatic, there is thrashing / spatter of fluids everywhere.)
This is unlike the common flu where are are infectious, even if non-symptomatic.
Fortunately, it is also highly unlikely to switch from being spread by droplets / fluids to becoming completely airborne. AIDS/HIV have been known about for decades, but have never made the switch from being a blood / fluid spread virus into an airborne virus. The sequence of random mutations required in order to switch infection style is huge.
(The Reston Ebola study was not able to prove simian to simian airborne transmission. So it's not 100% proved that Ebola can spread without physical contact.)
OS/2 Warp was pretty good for the time (93-96 era). I ran OS/2 2.x and 3.x for a long while as my main operating system. But application selection was really limited, and running 16-bit Windows programs only got you so far.
Not having to reboot for weeks at a time was a very nice feature. This was back when Win95 could only run for about 40-some hours before crashing due to an overflow in a counter.
But there were no open-source development tools at the time, so in order to write OS/2 applications you had to pony up a few hundred dollars for the compiler, then more money for a GUI framework library, plus more money for documentation. That, I feel, was IBM's biggest mistake - charging for development tools. But then, this was the days when a 28k modem was high-speed and ISDN 128k lines were popular - so not sure how they would have distributed it.
Linux was still a minor blip at the time (I installed an early version of Red Hat in the late 90s).