I conclude that password authentication on servers is alive and well, as long as done right.
Depends on the service and whether it does rate-limiting of attack attempts.
For SSH-based services? There's really no excuse not to use a password-protected SSH public key pair, and turn off password-authentication for SSH. Plus disallowing the ability for "root" to login over SSH. It raises the bar by an order of magnitude. Unless the attackers can get a copy of your private key file, and the password to decrypt it, and know which servers that key is used on, they can't get in. That's a pretty tall order for a non-focused attack.
Moving your SSH service to an alternate and non-standard port in the upper part 1-1024 range is also a good idea. Mostly because it keeps your log files from being cluttered up by the brain-dead attacks which only look for tcp/22. That makes it easier for you to spot the more dangerous attackers who took the time to figure out what port you had SSH running on.
That's the dreaded TOC error. There are (far more) expensive drives that will ignore TOC errors and let you dump the disk to an ISO file. But for us mere mortals a TOC error means you are well and truly hosed.
But for any situation where you are dealing with the far more common errors that the sector-level ECC can't deal with, the recovery data files give you the option to recover everything.
dogecoin - too much of a joke
litecoin - neutral sounding name, might do okay
ripple - another good neutral sounding name
A lot of the others have names that are either too geeky (primecoin) or reek of "against all authoriy" like ones with "counter" in the name or are too close to existing trademarks "mastercoin" (vs Mastercard).
When you hit this quantity of data theres not much thats really competitive. OP may want to get an autoloader, which ARE a bit pricey at $3k/each, but once youve spent the initial money the actual storage is cheap; you could populate it with ~25TB of storage for under $200.
That's the big problem with tape, the cost of the drives. And most of the cheaper autoloaders are not without issue, resulting in jammed/broken tapes. Especially in a home environment where there is more foot traffic around to bump into things. The more enclosed and robust solutions are closer to $5k.
Then there's the problem that LTO-6 tapes are $65 each (and they hold 2.5TB each, maybe 3-4 with compression). So to backup 20TB you are going to need around 8 tapes. That's closer to $500 instead of $200 because most bulk media does not compress well.
And finally, you get into the problem of wear and tear on the tapes. Best-case, you can read/write 2.5TB from the tape about 200 times before it is worn out. So figure on replacing all your tapes every year or two.
What starts to be tempting is the 8x external RAID enclosures. Good ones can be found as low as $300-$500 for backup purposes, plus 8x 4TB drives for $175 each. That gives you around 22-23TB of backup space using RAID-6 for around $2000.
RAID-5 uses up 1 disk worth for striping, so net space in an 8-drive array is 7-drives worth (about 27TB using 4TB drives). The problem with RAID-5 is that you are 2 disks away from failure and rebuilds often kill the disks.
RAID-6 uses 2 disks worth for striping, so net space in an 8-drive array is 6-drives worth (about 23TB using 4TB drives). Is able to survive a double-disk failure before data loss. Still has some of the same issues as RAID-5.
I do that as well, but I found out to my horror that all my DVD's had become unreadable over time. So, probably good idea to test your backups from time to time
That's why you should reserve 10-15% of the disk for parity data. While DVD-R format has built in error-recovery at the sector level, by the time you figure out that the disk is going bad it is too late. By adding even more recovery data at the file level, you can treat the disk errors as an early-warning system, then use the recovery data files to get your data off the disc.
The old standard was QuickPAR (PAR3), the new version is called MultiPAR.
With PAR3, you can even write the disc image to an ISO file, make a copy of that ISO file and rename with the PAR3 extension, then let QuickPAR or MultiPAR use the PAR3 filename to search the ISO filename. Which lets you retrieve data from a disc, even if the file system has become corrupted.
(About the only thing you can't easily recover from is a "track zero" error where the TOC of the disc has been broken.)
Wells Fargo switched a while ago to allowing longer passwords. They still limit you to "6-14 characters, no more then 8 numbers, and must contain at least one letter and one number.
a) SSDs are not designed for bulk storage. They will probably never match the $/GB of old HDs. If you want bulk storage, then put those bulky files on magnetic media (i.e. traditional hard drives).
b) Backups, backup, backups. Put a 2nd (or 3rd) magnetic HD on the system and use one (or both) as a target for an Acronis True Image Home backup each month. It's dirt-cheap at $30 (or the 3-pack for $75) and gives you a way to restore the customer's machine to a previous point in time. Even if the SSD dies, you are covered and can get back up and running quickly.
c) Most of the SSD sudden death issues are due to crappy controllers. Pay attention to reviews and avoid the bottom of the barrel SSDs. Image the SSD regularly so that you can restore the system to a new SSD when the existing one dies. Again backups, backups, backups.
SSDs just aren't that expensive any more. Prices are down in the $0.60 to $0.80 per GB range. If you can't afford that, then look into 10k RPM SATA for around $0.30/GB. Both choices are very good for your primary operating system drive and will goose up the responsiveness of an older system so that it can be used a few more years.
And if you're not willing to pay attention to the "backups, backups, backups" mantra, then you deserve to lose your data. Because it obviously wasn't important enough to you to back it up.
What good does it do to have 1TB optical disks, if the write speed is only 350kB/sec? It would take more than a month of steady writing to fill up a disk.
It will probably be faster than that, but who knows? I checked TFA, and it says absolutely nothing about bandwidth, either read or write.
A safe bet, based on previous CD-R, DVD+-R write times is that it will start at around 1-2 hours per side and slowly decrease to the 10-15 minute range per side. So 150GB across 2 hours is about 21MB/sec, which sounds easy to achieve.
Old DVD-R 1x was around 1.3-1.5 MB/s, these days you can usually get 8x DVD rates of around 11 MB/s.
(All of this is SWAG because until it hits the streets in a buyable form, it's all conjecture and wishful thinking.)
I couldn't believe, when I left New York to go to college, how many people stored things in their back pockets. I used to tell them all the same little rhyme --
Yeah, ever since I started traveling for business on public transport, I no longer keep a wallet in my back pocket. Instead it goes in a front pocket, which is more difficult to pick pocket. Works well with jeans. This doesn't do so well if you are wearing dress slacks with loose pockets, so you'll have to resort to other means like the various types of hidden / zippered pockets.
It's just too easy to have your back pocket searched when riding public transportation. And inside coat pockets aren't much better unless they have a button or zipper.
Backpacks aren't safe either, a good thief can unzip it and look inside without being noticed. I prefer a messenger type bag with a cover that folds over the top and is latched down by snap-buckles combined with velcro. Harder to open quietly and I always have an arm wrapped around it anyway.
Besides, SELinux is serious black magic and consequently there aren't many people who know how to correctly configure it.
There's only a handful of commands needed these days on CentOS/RHEL boxes. And the "sealert" command will guide you about 90% of the way.
I estimate that 80-90% of issues are mislabeled files (or ports) on the file system. Either because you have put files for a service that is protected with SELinux in a non-standard spot, or because the SELinux policy is out of date. Once you put your files in the proper location or use "semanage fcontext" to define the file context that should be applied to a particular path/file and relabel, those problems go away. The hardest part of this is defining the regex string to apply the right label to your file system.
Other issues are handled by setting one of the SELinux boolean flags which enable optional parts of the security policy for the service (such as httpd). These loosen up the SELinux restrictions for cases that don't apply to everyone. The "getsebool" and "setsebool" flags handle this functionality. For example "httpd_enable_cgi" allows CGI scripts to execute. The nice part about the booleans is that you can turn them on/off at will to see if it fixes your issue before making the change permanent.
And sometimes you have to use the brute-force "audit2allow" tool to write a customized policy that lets you do what you want to do. Just like any other tool, if you don't pay attention to what it is doing, you can shoot yourself in the foot.
Her laptop has win 7 on it but due to being 4 years old and only having a Intel core-2 duo processor, the effects of aging started to manifest themselves with a lot of freezing while she is on firefox, watching a tv show (in some sort of shockwave plug-in) and I noticed with the lot of updates pushed by micro$oft, the boot times are getting lengthy or feels liket hat to me.
A SSD will cure a lot of those woes. Nor are SSDs very expensive any longer. I'm still using a dual-core Intel Core2 Duo 2.2GHz Thinkpad T61p, with 8GB RAM and Win7 on top of a SSD as my primary laptop. This unit is from 2006 (almost 8 years old now). I was ready to replace it 2-3 years ago before putting in the SSD.
The main issue of the moment is the CPU. I really need to move up to a quad-core i5 or i7. Full-screen video from Netflix sometimes requires more CPU power then I have available (depends on the codec they used).
Since I have a far more powerful desktop unit sitting beside me (8-cores, 16GB, oodles of disk space), I'm not quite ready to upgrade. I might even manage to keep this laptop running into 2015 at which point I'll be making the jump to Linux (with Win7 in a VM).
Printers should be smart, blackboxes, with a universal interface advertising their capabilities.
yes.
Postscript printerts, 3.5" floppies, parallel ports, serial ports, and dropping Flash support on iphones all were logical moves, that while causing a little pain, ultimately ushered in the right way of doing things.
Er... there are usually only (3) languages spoken by printers these days in the corporate world. PCL5, PCL6 and Postscript.
Postscript has not died and has instead become the defacto language that most network-based printers speak.
Personally, for archive-stuff, I wouldn't go lower then quality=95 which would probably be around a 14MB file (at a guess). Quality of 85-90 is fine for most websites, but you should really archive at 95-98 level.
Thumbnails can sometimes be pushed as low as 75-80 quality, but you start to notice the JPEG artifacts.
Eeeeehhhhhhh.... that doesn't really apply. IBM had to change, typewriters and Mainframes were going the way of the dinosaur.
I don't see Windows doing that, actually worse, things that Microsoft hope would go extinct aren't (ie. XP).
Windows is very much in danger of becoming extinct. It no longer commands 98% of the O/S market for devices (even if you restrict that to desktop computers and full sized laptops). There's now OS X with a 5-10% share of the computer market, and Apple charges nothing or next to nothing for upgrades. Then there's the whole mobile device market where Microsoft is simply an "also-ran" in distant 3rd or 4th place.
What that means on the ground is that people are now used to using something other then Microsoft Windows. And if Microsoft's O/S doesn't play nicely with their devices (or their friend's devices) or if it costs too much, people are going to use the alternatives. They're no longer 1:100 and being felt like outcasts, they're now a sizable minority and there are enough other people like them using different O/S's. That's a seismic shift that is going to continue to shake up the industry and break MS's stranglehold on the ecosystem.
The days of MS being able to charge $100-$200 for an operating system are drawing to a close. Android and Linux are free and very capable now, and iOS / OS X upgrades are free or nearly so. A lot of software these days is cross-platform, so moving between Linux / OS X / Windows gets easier every year.
To my (admittedly untrained) eye, I'm not sure what Microsoft could have done differently.
Divest itself of the operating system business. The handwriting was on the wall 10 years ago that there is a coming race to zero for the price of what an operating system is worth to the end-user.
I still maintain that the US Justice Department splitting Microsoft into multiple companies would have done wonderful things for Microsoft. The operating system people would be forced to compete and free to pursue their goals of making the best O/S without influence from the applications, enterprise software, and hardware sides of the company. The MSOffice team could have embraced the concept of running across multiple platforms earlier (iOS, Android, Linux...).
Not a joke. Trains are "assembled" (built) at a rail yard by a yard engine moving freight cars around on the various sidings until you hook up the long-haul engine. Depending on the number of sidings and number of connections between freight cars that need to be made, this can take 30 minutes or a few hours.
I used to take a train from central Pennsylvania up to NYC every few weeks. We had a 20-30 minute layover in Philadelphia on each trip while they switched engines from diesel to electric. That was always a 10-15 minute process.
That being said, putting containers on/off a freight train only takes a few minutes per container. Maybe less depending on travel distance. But if you have 30-50 freight containers to load per loader, that time adds up to a few hours. Plus the time your driver spends waiting in line to get their container. So it really only makes sense for trips of 500-600 miles or longer. For distances less then that, you can have a driver on each end meet in the middle to swap loads, without having to pay them overnight rates or have either driver work more then 9 hours.
You'll never go back to a 7200 RPM drive for your operating system / primary storage again. The performance when multi-tasking is just too good.
As for the warm and fuzzy feeling side. Get a good backup program like Acronis True Image Home or learn to use rdiff-backup or whatever and write your backups to two different physical drives.
And in EQ2, they do it through Vitality. If you have Vitality, you are earning XP with a 200% bonus. That usually runs out after a few levels, depending on how much you mob grind vs quest grind and takes a while to refill back to full.
So the player who only has time to login a few hours each week, will be running on +200% XP for most of their play time.
It mostly works. There are trinkets on 7-day cooldowns that you can use to refill your vitality meter, and potions that you can buy with RL funds to refill your vitality.
(Note that EQ2 also now offers a level 85 character for 3500 station cash or about $35. Current level cap is 95. So they do the pay-to-level method as well.)
Changing the SSH port is effective in reducing the number of entries in your log files. It's not effective in increasing your security. I do find the log file thing a great enough benefit to go ahead and do this.
It removes your system from being the low-hanging fruit on the bottom branch, to something harder to reach from the ground. That it also lessens the amount of entries in the log files is a nice bonus. Instead of being attacked a few hundred times per day on the standard port, now you're only being attacked maybe once per week.
(And usually far less then that... we never see brute-force attempts on our non-standard SSH ports. Combined with public-key pairs, SSH is probably not the weakest link on the system.)
SoGo. We run postfix/dovecot for our mail server and SoGo will be the next piece we install.
And postfix/dovecot is so much better at dealing with large mailboxes then MSExchange ever was. The sieve scripting language is just icing on the cake. And being proper IMAP, add-in software just works without having to worry about some Microsoft incompatibility with their custom flavor of IMAP.
Client side, we just run Thunderbird + Lightning (calendar/tasks). Which also deals well with mailboxes measured in gigabytes and hundreds of thousands of messages.
Samba4 works pretty well. The main place it still fails to deliver is replication of the SYSVOL, which is where your GPOs are stored. You have to make sure to only edit GPOs on a single server, then make sure to synchronize those files to all of the other domain controllers. It's not difficult, just not out-of-the-box easy.
For a single-server shop, Samba4 is a good choice (even for migration away from a Windows server). For sites where you need more then one DC, there's still room for improvement.
We started migrating off of Windows starting 5-8 years ago when we put in our first Linux server. Since then, any new "server" application has been chosen to work on a Linux server. We went from 90% windows servers down to just a handful left. Samba 4.1 will kill off the remaining file/print servers for us. We might have zero Windows servers by the end of 2014.
On the desktops, we have very few applications that tie us to Windows and we're constantly working on reducing that count. Which gives us the flexibility to deploy either OS X or Linux to more end-user desktops instead of being 90% Windows.
I'd suggest splitting that up into multiple text files (one per site) and then putting it into git or SVN or some other version control system. Which will make it easier to sync between systems. It also makes it possible to use multiple or different keys for different accounts, depending on the protection level needed for that account.
I do mine as regular text files with GPG armored ASCII inside, then use the GnuPG clipboard editor to decrypt the ASCII block as needed. The really important sites get printed and stored in a safe, along with a printed (but encrypted) copy of the private keys. There's also a USB-key in the safe with the key rings and files, but it may not survive a fire like the paper likely will.
With ASCII-armored content, you could (worst-case) restore by OCR'ing or hand-keying off a printed page or fax page.
For low-security sites (99% of all web forums), using Firefox with a "master password" and then having Firefox remember the password is just fine. And you can run your FF profile in portable mode or something to synchronize between systems.
All of my low-security, don't care if I can't get in them for a day or three, sites use a completely random 15-30 character alphanumeric password. Then I just have the browser remember it.
As a backup to that, I keep all passwords in individual text files, with the contents protected by PGP/GPG. That has the advantage that I really only need to remember my (long) GPG passphrase in order to retrieve any password. Plus, since they are simple text files, I can store them in just about anything at all (such as git or SVN) to synchronize them across machines.
My high-security site (financial) authentication details only exist in GPG-encrypted files. Those are decrypted in the GnuPG clipboard editor just long enough to enter into the password box.
Slashdot Mirror
I conclude that password authentication on servers is alive and well, as long as done right.
Depends on the service and whether it does rate-limiting of attack attempts.
For SSH-based services? There's really no excuse not to use a password-protected SSH public key pair, and turn off password-authentication for SSH. Plus disallowing the ability for "root" to login over SSH. It raises the bar by an order of magnitude. Unless the attackers can get a copy of your private key file, and the password to decrypt it, and know which servers that key is used on, they can't get in. That's a pretty tall order for a non-focused attack.
Moving your SSH service to an alternate and non-standard port in the upper part 1-1024 range is also a good idea. Mostly because it keeps your log files from being cluttered up by the brain-dead attacks which only look for tcp/22. That makes it easier for you to spot the more dangerous attackers who took the time to figure out what port you had SSH running on.
That's the dreaded TOC error. There are (far more) expensive drives that will ignore TOC errors and let you dump the disk to an ISO file. But for us mere mortals a TOC error means you are well and truly hosed.
But for any situation where you are dealing with the far more common errors that the sector-level ECC can't deal with, the recovery data files give you the option to recover everything.
Of the list of the more popular cryptocoins...
dogecoin - too much of a joke
litecoin - neutral sounding name, might do okay
ripple - another good neutral sounding name
A lot of the others have names that are either too geeky (primecoin) or reek of "against all authoriy" like ones with "counter" in the name or are too close to existing trademarks "mastercoin" (vs Mastercard).
When you hit this quantity of data theres not much thats really competitive. OP may want to get an autoloader, which ARE a bit pricey at $3k/each, but once youve spent the initial money the actual storage is cheap; you could populate it with ~25TB of storage for under $200.
That's the big problem with tape, the cost of the drives. And most of the cheaper autoloaders are not without issue, resulting in jammed/broken tapes. Especially in a home environment where there is more foot traffic around to bump into things. The more enclosed and robust solutions are closer to $5k.
Then there's the problem that LTO-6 tapes are $65 each (and they hold 2.5TB each, maybe 3-4 with compression). So to backup 20TB you are going to need around 8 tapes. That's closer to $500 instead of $200 because most bulk media does not compress well.
And finally, you get into the problem of wear and tear on the tapes. Best-case, you can read/write 2.5TB from the tape about 200 times before it is worn out. So figure on replacing all your tapes every year or two.
What starts to be tempting is the 8x external RAID enclosures. Good ones can be found as low as $300-$500 for backup purposes, plus 8x 4TB drives for $175 each. That gives you around 22-23TB of backup space using RAID-6 for around $2000.
i'll guess RAID striping eats some space
RAID-5 uses up 1 disk worth for striping, so net space in an 8-drive array is 7-drives worth (about 27TB using 4TB drives). The problem with RAID-5 is that you are 2 disks away from failure and rebuilds often kill the disks.
RAID-6 uses 2 disks worth for striping, so net space in an 8-drive array is 6-drives worth (about 23TB using 4TB drives). Is able to survive a double-disk failure before data loss. Still has some of the same issues as RAID-5.
I do that as well, but I found out to my horror that all my DVD's had become unreadable over time. So, probably good idea to test your backups from time to time
That's why you should reserve 10-15% of the disk for parity data. While DVD-R format has built in error-recovery at the sector level, by the time you figure out that the disk is going bad it is too late. By adding even more recovery data at the file level, you can treat the disk errors as an early-warning system, then use the recovery data files to get your data off the disc.
The old standard was QuickPAR (PAR3), the new version is called MultiPAR.
With PAR3, you can even write the disc image to an ISO file, make a copy of that ISO file and rename with the PAR3 extension, then let QuickPAR or MultiPAR use the PAR3 filename to search the ISO filename. Which lets you retrieve data from a disc, even if the file system has become corrupted.
(About the only thing you can't easily recover from is a "track zero" error where the TOC of the disc has been broken.)
Put bind or some other DNS server on your firewall and go with DNSSEC.
Which makes it a whole lot harder for someone to MitM your DNS trafffic without being noticed.
Wells Fargo switched a while ago to allowing longer passwords. They still limit you to "6-14 characters, no more then 8 numbers, and must contain at least one letter and one number.
Still not great, but better then it was.
a) SSDs are not designed for bulk storage. They will probably never match the $/GB of old HDs. If you want bulk storage, then put those bulky files on magnetic media (i.e. traditional hard drives).
b) Backups, backup, backups. Put a 2nd (or 3rd) magnetic HD on the system and use one (or both) as a target for an Acronis True Image Home backup each month. It's dirt-cheap at $30 (or the 3-pack for $75) and gives you a way to restore the customer's machine to a previous point in time. Even if the SSD dies, you are covered and can get back up and running quickly.
c) Most of the SSD sudden death issues are due to crappy controllers. Pay attention to reviews and avoid the bottom of the barrel SSDs. Image the SSD regularly so that you can restore the system to a new SSD when the existing one dies. Again backups, backups, backups.
SSDs just aren't that expensive any more. Prices are down in the $0.60 to $0.80 per GB range. If you can't afford that, then look into 10k RPM SATA for around $0.30/GB. Both choices are very good for your primary operating system drive and will goose up the responsiveness of an older system so that it can be used a few more years.
And if you're not willing to pay attention to the "backups, backups, backups" mantra, then you deserve to lose your data. Because it obviously wasn't important enough to you to back it up.
What good does it do to have 1TB optical disks, if the write speed is only 350kB/sec? It would take more than a month of steady writing to fill up a disk.
It will probably be faster than that, but who knows? I checked TFA, and it says absolutely nothing about bandwidth, either read or write.
A safe bet, based on previous CD-R, DVD+-R write times is that it will start at around 1-2 hours per side and slowly decrease to the 10-15 minute range per side. So 150GB across 2 hours is about 21MB/sec, which sounds easy to achieve.
Old DVD-R 1x was around 1.3-1.5 MB/s, these days you can usually get 8x DVD rates of around 11 MB/s.
(All of this is SWAG because until it hits the streets in a buyable form, it's all conjecture and wishful thinking.)
I couldn't believe, when I left New York to go to college, how many people stored things in their back pockets. I used to tell them all the same little rhyme --
Yeah, ever since I started traveling for business on public transport, I no longer keep a wallet in my back pocket. Instead it goes in a front pocket, which is more difficult to pick pocket. Works well with jeans. This doesn't do so well if you are wearing dress slacks with loose pockets, so you'll have to resort to other means like the various types of hidden / zippered pockets.
It's just too easy to have your back pocket searched when riding public transportation. And inside coat pockets aren't much better unless they have a button or zipper.
Backpacks aren't safe either, a good thief can unzip it and look inside without being noticed. I prefer a messenger type bag with a cover that folds over the top and is latched down by snap-buckles combined with velcro. Harder to open quietly and I always have an arm wrapped around it anyway.
Besides, SELinux is serious black magic and consequently there aren't many people who know how to correctly configure it.
There's only a handful of commands needed these days on CentOS/RHEL boxes. And the "sealert" command will guide you about 90% of the way.
I estimate that 80-90% of issues are mislabeled files (or ports) on the file system. Either because you have put files for a service that is protected with SELinux in a non-standard spot, or because the SELinux policy is out of date. Once you put your files in the proper location or use "semanage fcontext" to define the file context that should be applied to a particular path/file and relabel, those problems go away. The hardest part of this is defining the regex string to apply the right label to your file system.
Other issues are handled by setting one of the SELinux boolean flags which enable optional parts of the security policy for the service (such as httpd). These loosen up the SELinux restrictions for cases that don't apply to everyone. The "getsebool" and "setsebool" flags handle this functionality. For example "httpd_enable_cgi" allows CGI scripts to execute. The nice part about the booleans is that you can turn them on/off at will to see if it fixes your issue before making the change permanent.
And sometimes you have to use the brute-force "audit2allow" tool to write a customized policy that lets you do what you want to do. Just like any other tool, if you don't pay attention to what it is doing, you can shoot yourself in the foot.
Her laptop has win 7 on it but due to being 4 years old and only having a Intel core-2 duo processor, the effects of aging started to manifest themselves with a lot of freezing while she is on firefox, watching a tv show (in some sort of shockwave plug-in) and I noticed with the lot of updates pushed by micro$oft, the boot times are getting lengthy or feels liket hat to me.
A SSD will cure a lot of those woes. Nor are SSDs very expensive any longer. I'm still using a dual-core Intel Core2 Duo 2.2GHz Thinkpad T61p, with 8GB RAM and Win7 on top of a SSD as my primary laptop. This unit is from 2006 (almost 8 years old now). I was ready to replace it 2-3 years ago before putting in the SSD.
The main issue of the moment is the CPU. I really need to move up to a quad-core i5 or i7. Full-screen video from Netflix sometimes requires more CPU power then I have available (depends on the codec they used).
Since I have a far more powerful desktop unit sitting beside me (8-cores, 16GB, oodles of disk space), I'm not quite ready to upgrade. I might even manage to keep this laptop running into 2015 at which point I'll be making the jump to Linux (with Win7 in a VM).
Printers should be smart, blackboxes, with a universal interface advertising their capabilities.
yes.
Postscript printerts, 3.5" floppies, parallel ports, serial ports, and dropping Flash support on iphones all were logical moves, that while causing a little pain, ultimately ushered in the right way of doing things.
Er... there are usually only (3) languages spoken by printers these days in the corporate world. PCL5, PCL6 and Postscript.
Postscript has not died and has instead become the defacto language that most network-based printers speak.
Personally, for archive-stuff, I wouldn't go lower then quality=95 which would probably be around a 14MB file (at a guess). Quality of 85-90 is fine for most websites, but you should really archive at 95-98 level.
Thumbnails can sometimes be pushed as low as 75-80 quality, but you start to notice the JPEG artifacts.
Eeeeehhhhhhh.... that doesn't really apply. IBM had to change, typewriters and Mainframes were going the way of the dinosaur. I don't see Windows doing that, actually worse, things that Microsoft hope would go extinct aren't (ie. XP).
Windows is very much in danger of becoming extinct. It no longer commands 98% of the O/S market for devices (even if you restrict that to desktop computers and full sized laptops). There's now OS X with a 5-10% share of the computer market, and Apple charges nothing or next to nothing for upgrades. Then there's the whole mobile device market where Microsoft is simply an "also-ran" in distant 3rd or 4th place.
What that means on the ground is that people are now used to using something other then Microsoft Windows. And if Microsoft's O/S doesn't play nicely with their devices (or their friend's devices) or if it costs too much, people are going to use the alternatives. They're no longer 1:100 and being felt like outcasts, they're now a sizable minority and there are enough other people like them using different O/S's. That's a seismic shift that is going to continue to shake up the industry and break MS's stranglehold on the ecosystem.
The days of MS being able to charge $100-$200 for an operating system are drawing to a close. Android and Linux are free and very capable now, and iOS / OS X upgrades are free or nearly so. A lot of software these days is cross-platform, so moving between Linux / OS X / Windows gets easier every year.
To my (admittedly untrained) eye, I'm not sure what Microsoft could have done differently.
Divest itself of the operating system business. The handwriting was on the wall 10 years ago that there is a coming race to zero for the price of what an operating system is worth to the end-user.
I still maintain that the US Justice Department splitting Microsoft into multiple companies would have done wonderful things for Microsoft. The operating system people would be forced to compete and free to pursue their goals of making the best O/S without influence from the applications, enterprise software, and hardware sides of the company. The MSOffice team could have embraced the concept of running across multiple platforms earlier (iOS, Android, Linux...).
5)wait for a train to be built.
good joke.
Not a joke. Trains are "assembled" (built) at a rail yard by a yard engine moving freight cars around on the various sidings until you hook up the long-haul engine. Depending on the number of sidings and number of connections between freight cars that need to be made, this can take 30 minutes or a few hours.
I used to take a train from central Pennsylvania up to NYC every few weeks. We had a 20-30 minute layover in Philadelphia on each trip while they switched engines from diesel to electric. That was always a 10-15 minute process.
That being said, putting containers on/off a freight train only takes a few minutes per container. Maybe less depending on travel distance. But if you have 30-50 freight containers to load per loader, that time adds up to a few hours. Plus the time your driver spends waiting in line to get their container. So it really only makes sense for trips of 500-600 miles or longer. For distances less then that, you can have a driver on each end meet in the middle to swap loads, without having to pay them overnight rates or have either driver work more then 9 hours.
the first SSD I've ever owned.
You'll never go back to a 7200 RPM drive for your operating system / primary storage again. The performance when multi-tasking is just too good.
As for the warm and fuzzy feeling side. Get a good backup program like Acronis True Image Home or learn to use rdiff-backup or whatever and write your backups to two different physical drives.
And in EQ2, they do it through Vitality. If you have Vitality, you are earning XP with a 200% bonus. That usually runs out after a few levels, depending on how much you mob grind vs quest grind and takes a while to refill back to full.
So the player who only has time to login a few hours each week, will be running on +200% XP for most of their play time.
It mostly works. There are trinkets on 7-day cooldowns that you can use to refill your vitality meter, and potions that you can buy with RL funds to refill your vitality.
(Note that EQ2 also now offers a level 85 character for 3500 station cash or about $35. Current level cap is 95. So they do the pay-to-level method as well.)
Changing the SSH port is effective in reducing the number of entries in your log files. It's not effective in increasing your security. I do find the log file thing a great enough benefit to go ahead and do this.
It removes your system from being the low-hanging fruit on the bottom branch, to something harder to reach from the ground. That it also lessens the amount of entries in the log files is a nice bonus. Instead of being attacked a few hundred times per day on the standard port, now you're only being attacked maybe once per week.
(And usually far less then that... we never see brute-force attempts on our non-standard SSH ports. Combined with public-key pairs, SSH is probably not the weakest link on the system.)
SoGo. We run postfix/dovecot for our mail server and SoGo will be the next piece we install.
And postfix/dovecot is so much better at dealing with large mailboxes then MSExchange ever was. The sieve scripting language is just icing on the cake. And being proper IMAP, add-in software just works without having to worry about some Microsoft incompatibility with their custom flavor of IMAP.
Client side, we just run Thunderbird + Lightning (calendar/tasks). Which also deals well with mailboxes measured in gigabytes and hundreds of thousands of messages.
Samba4 works pretty well. The main place it still fails to deliver is replication of the SYSVOL, which is where your GPOs are stored. You have to make sure to only edit GPOs on a single server, then make sure to synchronize those files to all of the other domain controllers. It's not difficult, just not out-of-the-box easy.
For a single-server shop, Samba4 is a good choice (even for migration away from a Windows server). For sites where you need more then one DC, there's still room for improvement.
We started migrating off of Windows starting 5-8 years ago when we put in our first Linux server. Since then, any new "server" application has been chosen to work on a Linux server. We went from 90% windows servers down to just a handful left. Samba 4.1 will kill off the remaining file/print servers for us. We might have zero Windows servers by the end of 2014.
On the desktops, we have very few applications that tie us to Windows and we're constantly working on reducing that count. Which gives us the flexibility to deploy either OS X or Linux to more end-user desktops instead of being 90% Windows.
I'd suggest splitting that up into multiple text files (one per site) and then putting it into git or SVN or some other version control system. Which will make it easier to sync between systems. It also makes it possible to use multiple or different keys for different accounts, depending on the protection level needed for that account.
I do mine as regular text files with GPG armored ASCII inside, then use the GnuPG clipboard editor to decrypt the ASCII block as needed. The really important sites get printed and stored in a safe, along with a printed (but encrypted) copy of the private keys. There's also a USB-key in the safe with the key rings and files, but it may not survive a fire like the paper likely will.
With ASCII-armored content, you could (worst-case) restore by OCR'ing or hand-keying off a printed page or fax page.
For low-security sites (99% of all web forums), using Firefox with a "master password" and then having Firefox remember the password is just fine. And you can run your FF profile in portable mode or something to synchronize between systems.
All of my low-security, don't care if I can't get in them for a day or three, sites use a completely random 15-30 character alphanumeric password. Then I just have the browser remember it.
As a backup to that, I keep all passwords in individual text files, with the contents protected by PGP/GPG. That has the advantage that I really only need to remember my (long) GPG passphrase in order to retrieve any password. Plus, since they are simple text files, I can store them in just about anything at all (such as git or SVN) to synchronize them across machines.
My high-security site (financial) authentication details only exist in GPG-encrypted files. Those are decrypted in the GnuPG clipboard editor just long enough to enter into the password box.