I use a Yubikey Neo mainly for 2FA with Google's services. The main security boost from it for me is that it is a physical object, and the main avenue of attack for my stuff is via remote. Same reason I use Google's Authenticator app as backup on my smartphone.
Since my Yubikey devices tend to be sessile resiliency isn't that important... but I am definitely not impressed with the durability. My eTokens [1] from SafeNet are far more durable, tamper resistant (once they started one piece epoxy manufacture), and can handle far more insertion cycles than the YubiKey can.
I wish Yubico could charge more, and put some money into a stronger USB keyfob. For me, the delicate construction is OK (because I use multiple keys that stay with my devices)... but for people like the parent who actually tote it around, the construction is pretty much unacceptable.
As for a key format for security, I wish the industry would have a special slot for that, as in some cases, NFC isn't acceptable. The best I've seen was the old Dallas Semiconductor "one wire" reader which worked even with high traffic. Since that is long gone, perhaps it is time to have something, even if it is just two small, durable conductive contacts on the side of a device for using a key, or using it for a key interchange.
[1]: I have multiple for PGP, and use the keys as ADKs (which were generated on the device and never leave.) Other than finding drivers for them, they have served me well. Plus, if one uses PGP Desktop (er, now SED), one can use the eTokens as keys, so an attacker would have to have the token, and the PIN (which can be set to lock for good after a certain amount of guesses) in order to boot the machine.
I recommend Deoxit for stuff like this. It not just de-gunks contacts, but leaves a coating of residue to help with further oxidation. I'd also find a way to cover the tip of it as well.
I've mentioned this before... but times have changed. For better or for worse, BitCoin is the currency that people have latched onto, similar to how Facebook is the social network of choice these days.
Even though there are details that the currency is fraught with, it is becoming stable and accepted by the mainstream, where it is becoming trusted enough for people to actually not just use it for a means of exchange (quickly changing from their preferred unit of stored value to BTC, then the seller quickly changing from BTC to their favorite unit), but as a means of holding wealth, since it is a deflationary currency.
Satoshi has dropped out of sight long enough that statute of limitations laws are going to come into play soon, especially once the seven year mark hits. The only two things that are able to be used in the US are murder or failing to file a tax return, and an anonymous entity has no requirement to file a tax return.
Even if taxes are involved, it would be similar to capital gains. Satoshi would not have to pay taxes until those coins are sold or exchanged. If kept "under the mattress", they can legally stay out of play indefinitely.
A local place (Solid Concepts) made a 1911 out of DMLS sintered Iconel. All parts including the barrel, sear, trigger mechanism... everything but the grips. It didn't blow up or have any issues after 1000 rounds ran through it.
Mitsubishi has a DMLS machine that does both the sintering and machining (both additive and subtractive), which not just would allow a 1911 to be made, but the parts coming out just needing final assembly.
I remember it called stereolithography, but that was mainly a type of 3D printing that used a laser and either a photosensitive liquid or powder which fused together, combined with a tray that slowly moved.
These days, I'd just go with a DMLS setup, since if I use a decent Iconel alloy, the finishing/grinding/polishing needed iis minimal.
Even with programs that can import Word/Excel/etc. documents, they do a good job, about 99% well. However, that one percent that is missed can do quite a number on a document.
The answer for a document format... depends.
For a document format that keeps formatting exactly, and isn't intended to be edited, PDF/A is the best thing going, since barring a major world-ending disaster, we will still have utilities that can read PDFs, and PDF/A ensures that the fonts and such are present and readable.
For a document that is edited... there are a number of different standards. As stated elsewhere, it might be best to have a tarball or ZIP file that has multiple document formats in it, where there is a.txt and.PDF file available for quick viewing, then SGML/HTML/XML/nroff/TeX/LaTeX version included for editing.
With all the UI churn of not just Gmail, but every other provider, I've thrown in the towel, and just use a decent MUA (Thunderbird for E-mail, Outlook for calenders/meetings/tasks/contacts.)
A MUA is a lot more resistant against attack than a Web browser, and gives more options when it comes to rulesets (I can move vital E-mails that hit Yahoo to my hosted Exchange server which I actually look at.) Plus, I can use features like PGP or S/MIME quite easily with it.
I'm curious about its properties as an insulation. It might be useful as both an insulator and as a load bearing material, either alone, or perhaps as a composite.
When cleaning PCs of malware, almost all of them have either perfectly functioning AV programs, or appear to do so. AV is useful on a legal eagle standpoint [1].
As a usable tool of defense, I'd say that adblocking, blocking by IP address, using a hosts file, virtualization, and putting the web browser in a container/sandbox/VM will go far further in keeping malware at bay than any AV program. That, and not running randomly downloaded executables.
We have had oddball places to store code since early on. In the early 1990s, System 6 and 7 would rely on a stub of code coming from a SCSI device as a driver, unless the code was furnished via an extension. One could easily hide code in there, which would be one of the first things loaded on an internal SCSI drive, and couldn't be bypassed. Just plugging the drive into another Mac would get the hard disk driver to load and run that code on the second Mac. That combined with WDEF or CDEF made for a nasty infection vector... just insert a floppy, and the machine was pwned. Thankfully nobody made a virus that infected the Mac hard disk driver (at best, there was code that would check if a program was running and hide the drive from the system, as with Highware's FileGuard, Kent-Marsh's NightWatch, or Kent-Marsh's Folderbolt.)
[1]: Even on AIX LPARs, having McAfee run from two cron tasks... one to fetch definitions, the second to scan the filesystem, is good enough to check that "all computers have AV installed on them" box.
You may notice that, as well as most Slashdotters... but how many users actually know anything about performance baselines or know/care about that?
Most users will just complain that their laptop's battery life is shorter and that their laptop runs hotter, maybe blaming the PC maker on the topic.
You can't really hide GPU usage, but most users or AV software are not going to be looking at that subsystem. Think Life of Bryan and the Roman legions searching one house multiple times. They won't check what is holding up the lampshade.
It wouldn't be nice, but it wouldn't be the end of the world. The US has a ton of fabs, most of it ASIC work. If the fabs overseas were destroyed, it might take a year or so to build the latest and greatest on US soil, but it is doable.
Even without the latest generation, there is a point where general purpose CPUs are "good enough", so even a 1-2 generation back fab would still be useful.
ARM is even easier.
The big worry is the fabs for SSDs, RAM and storage. CPUs are something that has some give.
"Suit wearing chatter monkey" describes so many of those out there out there, especially "security consultants" which are sprouting up left and right. I have cleaned up the messes that those types leave behind, especially after they "do" a job for six months, and the fundamental issues are still present. Usually they may be familiar with one tool, and because they have that hammer, everything is a nail.
I can see the NIH mentality of embedded programmers, since those are the types who usually are proud of the fact that their code is as close to mathematically perfect as one can get. A probable compromise is to hand them the libraries, then demand that their code match the testsuite given to ensure their stuff encodes/decodes correctly. It may not be perfect, but at least it will pass muster in that respect. The ideal is to use a known, tested, certified library, but rigorous testing of a reinvented wheel is better than nothing.
Homegrown crypto has been a constant menace since the 1990s when people sold numerous encryption programs, usually sporting their own encryption algorithm and DES.
A few I've seen were running 1-2 rounds of DES at most (FWB Hammer's hard disk drivers for Macs did this, but at the time, it was the best encryption one could get due to the relatively slow CPUs like 68000s at the time.) Others were seeding random() with a CRC of the password and XORing the output with the plaintext.
However, back then, there were no government entities standardizing functions like is done now with AES, RSA, and other algos, so people had to write their own, and if it jumbled and unjumbled stuff, it was good enough, since not much in the way of ciphertext was really being attacked.
Times are different now.
These days, with most ARM, AMD, SPARC, POWER, and Intel CPUs having hardware AES acceleration, why would one want to roll their own algorithm?
If one thinks AES is backdoored, cascade it with another known good algorithm like SERPENT, Threefish, heck, maybe even an older one like IDEA, 3DES, or even 3-Skipjack. There are other less known algorithms which have withstood testing as well. Cascading isn't intended to expand the bit width, but to have protection should one algorithm get broken. TrueCrypt offers/offered this functionality.
Same with public key algorithms. Worried about RSA? Have two signatures, one RSA, and one with ECC or a lattice based algorithm that is resistant to TWIRL and quantum factoring, and validate both sigs.
As for crypto implementations, if a user needs to encrypt a file, OpenPGP is a known standard. For communicating across the wire, SSH and SSL are known standards that are decently robust. For encrypting stuff in RAM, almost all modern operating systems have a facility like KeyChain to keep sensitive data from being swapped out, or if it is, have it encrypted.
With almost every programming language offering hooks for AES and RSA, there isn't a need to roll crypto, even for obfuscation reasons. If one just needs obfuscation, use an AES() function with all zeroes as the key.
At the time, it was OK to publish source code in a printed book... but stored online as a computer document and exported, it was an ITAR violation. So, one encryption company (think ViaCrypt) printed out the source code of PGP and made a book out of it, which was freely and legally exported. Then it was scanned in and OCR-ed for the source code.
This is one reason why that law eventually just got pulled, and export limited to the few countries on the blacklist.
I wouldn't be surprised to see far worse things come down the pipe, especially malware that exploited domain admin rights to compromise the entire AD forest.
However, we have one big defense against all of this: Virtualization. Not just VM farms, but VDI (so a compromised desktop can just be rolled back to a known good snapshot almost instantly.) If the malware can't touch hardware, it can still destroy/corrupt files, but VMs have a lot more tools available for mitigating/reversing such attacks, even if it is just a simple snapshot of files taken daily which persists a week before expiring. Of course, snapshots are not backups, but they are a tool to help with RTO/RPO.
Another defense is separation. The AD domain used for authenticating to the NetBackup server, SAN, and tape drive is completely separate than the AD forest used for day to day user work. This way, a domain or enterprise admin account that gets compromised on a user's desktop cannot be used to destroy all data on a silo, SAN, or NAS. It will still be pure hell rebuilding the AD structure if malware does use it as a propagation vector, but at least the core appliances won't be affected.
Of course, the final defense are good backup and archival policies. For example, a backup is done daily, and is kept 7-14 days. Another backup is done weekly, kept 4-8 weeks. A monthly backup is fired off, kept 12-24 months, and a quarterly backup is kept 7-20 years on WORM media. Of course, offsite and verification policies go without saying as well. It also doesn't hurt to run a hash of stored files and cryptographically sign that on an offline machine, just as a last resort for detecting tampering.
I have a feeling we will not just see more destructive attacks, but more subtle ones. A simple change in a purchase order can bankrupt a company. So, because this actually hurts businesses (as opposed to the previous "copy data and leave everything alone" intrusions of the past), we might see actual money spent for handling data integrity as part of enterprise security.
Some of the bands I support have been doing boxed sets, as well as LPs.
Yes, CDs as a distribution medium solely are long since dead, replaced by the 99 cent track [1]. However, bands are selling boxed sets which seem to be making them a decent amount of money, where the box contains a CD, a T-shirt, an amulet, and other items. LPs also sell because they are less for the music value, as opposed to the large surface for album art, which isn't nearly as relevant when on a postage-stamp sized screen on a MP3 player.
[1]: This can be argued to be one of the major reasons why the music industry collapsed, and why the big labels make (not sign) their bands now.
IPv6 seems like it would be the ideal solution in this case. No NAT trickery needed.
Of course, it would be wise to have firewalls in place. Even with a mesh, there needs to be a boundary with firewalls in place, maybe even thought for core/edge fabric design as well.
On the other hand, once you learn a few programming languages, it becomes easier to know others, (assuming something that isn't completely different, such as a procedural language (C or Java) versus a functional programming language (Lisp, Scheme), versus assembly language.
If you know C, you can consult the camel and make functioning perl code. So, it might not hurt knowing a non mainstream language, and may not take too much of your time, relatively.
Yik Yak isn't that bad for the most part. A lot of it is people asking for kik IDs and wanting a good time, there are a few tired witticisms posted every so often, a few things about human sexuality popping up quite often...
In general, if one plays/or ever played WoW, it is like Barrens chat, or present-day General/Trade in the garrison.
Of course, you get the people who say something stupid, but the reporting mechanism takes care of that pretty quickly.
The way to get Linux into the desktop space isn't by drawing individual users in. It is how IBM's PC became the standard -- take over business, then personal stuff follows.
The trick is to get businesses to embrace a desktop distribution, by having the OS be able to be managed and policies set by Active Directory GPOs to being able to be audited/updated with existing management tools, to being able to be images and said images updated and maintained so reimaging a desktop is as simple as a PXE boot.
Trying to woo individual users is like herding cats. Instead, get the big boys using your OS, and the personal users will follow.
SystemD, (and to a lesser extent FirewallD) have their points... but as anything in IT, it is good to at least learn the basics of them in order to get around, just like one has to learn how to use SELinux and not just disable it completely.
I personally am on the fence... SystemD provides a lot of functionality, especially with just one command (systemctl). However, I will have a lot more faith in this new functionality once the code certification and auditing is complete.
It follows the same path that OS X and Solaris 11 do, with the root user disabled by default, with the first user created having sudo access to root. A quick change of root's password can enable this if needed.
All and all, this is a good thing. There are a lot of security audit checklists that are starting to require root not be able to be logged on directly, so shipping an OS that has this locked down is not unusual.
For personal use, there isn't anything wrong with unlocking root and using that with su or just logging directly in. However, in business/enterprise settings, it does make sense to have a user stage, even if it is just having different RSA keys in root's authorized_hosts file that belongs to each individual user. I like unlocking root locally, so I can log in with that in single user mode, but having remote root access completely disabled.
There is also battery life. Take NiFe batteries. They have less energy density than lead-acid... but properly watered, they have an extremely long lifespan.
Yes, a rack of NiFe cells would take up a more room than Tesla's technology... but they will still be working and storing energy long after the current generation of lithium batteries have hit the landfills.
Slashdot Mirror
I use a Yubikey Neo mainly for 2FA with Google's services. The main security boost from it for me is that it is a physical object, and the main avenue of attack for my stuff is via remote. Same reason I use Google's Authenticator app as backup on my smartphone.
Since my Yubikey devices tend to be sessile resiliency isn't that important... but I am definitely not impressed with the durability. My eTokens [1] from SafeNet are far more durable, tamper resistant (once they started one piece epoxy manufacture), and can handle far more insertion cycles than the YubiKey can.
I wish Yubico could charge more, and put some money into a stronger USB keyfob. For me, the delicate construction is OK (because I use multiple keys that stay with my devices)... but for people like the parent who actually tote it around, the construction is pretty much unacceptable.
As for a key format for security, I wish the industry would have a special slot for that, as in some cases, NFC isn't acceptable. The best I've seen was the old Dallas Semiconductor "one wire" reader which worked even with high traffic. Since that is long gone, perhaps it is time to have something, even if it is just two small, durable conductive contacts on the side of a device for using a key, or using it for a key interchange.
[1]: I have multiple for PGP, and use the keys as ADKs (which were generated on the device and never leave.) Other than finding drivers for them, they have served me well. Plus, if one uses PGP Desktop (er, now SED), one can use the eTokens as keys, so an attacker would have to have the token, and the PIN (which can be set to lock for good after a certain amount of guesses) in order to boot the machine.
I recommend Deoxit for stuff like this. It not just de-gunks contacts, but leaves a coating of residue to help with further oxidation. I'd also find a way to cover the tip of it as well.
I've mentioned this before... but times have changed. For better or for worse, BitCoin is the currency that people have latched onto, similar to how Facebook is the social network of choice these days.
Even though there are details that the currency is fraught with, it is becoming stable and accepted by the mainstream, where it is becoming trusted enough for people to actually not just use it for a means of exchange (quickly changing from their preferred unit of stored value to BTC, then the seller quickly changing from BTC to their favorite unit), but as a means of holding wealth, since it is a deflationary currency.
Satoshi has dropped out of sight long enough that statute of limitations laws are going to come into play soon, especially once the seven year mark hits. The only two things that are able to be used in the US are murder or failing to file a tax return, and an anonymous entity has no requirement to file a tax return.
Even if taxes are involved, it would be similar to capital gains. Satoshi would not have to pay taxes until those coins are sold or exchanged. If kept "under the mattress", they can legally stay out of play indefinitely.
A local place (Solid Concepts) made a 1911 out of DMLS sintered Iconel. All parts including the barrel, sear, trigger mechanism... everything but the grips. It didn't blow up or have any issues after 1000 rounds ran through it.
Mitsubishi has a DMLS machine that does both the sintering and machining (both additive and subtractive), which not just would allow a 1911 to be made, but the parts coming out just needing final assembly.
Of course, there are other uses than firearms.
I remember it called stereolithography, but that was mainly a type of 3D printing that used a laser and either a photosensitive liquid or powder which fused together, combined with a tray that slowly moved.
These days, I'd just go with a DMLS setup, since if I use a decent Iconel alloy, the finishing/grinding/polishing needed iis minimal.
Even with programs that can import Word/Excel/etc. documents, they do a good job, about 99% well. However, that one percent that is missed can do quite a number on a document.
The answer for a document format... depends.
For a document format that keeps formatting exactly, and isn't intended to be edited, PDF/A is the best thing going, since barring a major world-ending disaster, we will still have utilities that can read PDFs, and PDF/A ensures that the fonts and such are present and readable.
For a document that is edited... there are a number of different standards. As stated elsewhere, it might be best to have a tarball or ZIP file that has multiple document formats in it, where there is a .txt and .PDF file available for quick viewing, then SGML/HTML/XML/nroff/TeX/LaTeX version included for editing.
With all the UI churn of not just Gmail, but every other provider, I've thrown in the towel, and just use a decent MUA (Thunderbird for E-mail, Outlook for calenders/meetings/tasks/contacts.)
A MUA is a lot more resistant against attack than a Web browser, and gives more options when it comes to rulesets (I can move vital E-mails that hit Yahoo to my hosted Exchange server which I actually look at.) Plus, I can use features like PGP or S/MIME quite easily with it.
If it has as good structural strength as TFA states, this would be very useful for automobile or RV applications:
1: Rodents are not going to chew through it, which can make it useful for walls.
2: If it is good at handling deformation resistance, it might be able to be used in car doors for better safety in T-bone wrecks.
3: If it is resistant to tools, it might be useful to slow down the meth-heads who like using a long screwdriver as a master key in RV storage lots.
This technology has a lot of promise... maybe even in aerospace applications.
I'm curious about its properties as an insulation. It might be useful as both an insulator and as a load bearing material, either alone, or perhaps as a composite.
When cleaning PCs of malware, almost all of them have either perfectly functioning AV programs, or appear to do so. AV is useful on a legal eagle standpoint [1].
As a usable tool of defense, I'd say that adblocking, blocking by IP address, using a hosts file, virtualization, and putting the web browser in a container/sandbox/VM will go far further in keeping malware at bay than any AV program. That, and not running randomly downloaded executables.
We have had oddball places to store code since early on. In the early 1990s, System 6 and 7 would rely on a stub of code coming from a SCSI device as a driver, unless the code was furnished via an extension. One could easily hide code in there, which would be one of the first things loaded on an internal SCSI drive, and couldn't be bypassed. Just plugging the drive into another Mac would get the hard disk driver to load and run that code on the second Mac. That combined with WDEF or CDEF made for a nasty infection vector... just insert a floppy, and the machine was pwned. Thankfully nobody made a virus that infected the Mac hard disk driver (at best, there was code that would check if a program was running and hide the drive from the system, as with Highware's FileGuard, Kent-Marsh's NightWatch, or Kent-Marsh's Folderbolt.)
[1]: Even on AIX LPARs, having McAfee run from two cron tasks... one to fetch definitions, the second to scan the filesystem, is good enough to check that "all computers have AV installed on them" box.
You may notice that, as well as most Slashdotters... but how many users actually know anything about performance baselines or know/care about that?
Most users will just complain that their laptop's battery life is shorter and that their laptop runs hotter, maybe blaming the PC maker on the topic.
You can't really hide GPU usage, but most users or AV software are not going to be looking at that subsystem. Think Life of Bryan and the Roman legions searching one house multiple times. They won't check what is holding up the lampshade.
It wouldn't be nice, but it wouldn't be the end of the world. The US has a ton of fabs, most of it ASIC work. If the fabs overseas were destroyed, it might take a year or so to build the latest and greatest on US soil, but it is doable.
Even without the latest generation, there is a point where general purpose CPUs are "good enough", so even a 1-2 generation back fab would still be useful.
ARM is even easier.
The big worry is the fabs for SSDs, RAM and storage. CPUs are something that has some give.
"Suit wearing chatter monkey" describes so many of those out there out there, especially "security consultants" which are sprouting up left and right. I have cleaned up the messes that those types leave behind, especially after they "do" a job for six months, and the fundamental issues are still present. Usually they may be familiar with one tool, and because they have that hammer, everything is a nail.
I can see the NIH mentality of embedded programmers, since those are the types who usually are proud of the fact that their code is as close to mathematically perfect as one can get. A probable compromise is to hand them the libraries, then demand that their code match the testsuite given to ensure their stuff encodes/decodes correctly. It may not be perfect, but at least it will pass muster in that respect. The ideal is to use a known, tested, certified library, but rigorous testing of a reinvented wheel is better than nothing.
Homegrown crypto has been a constant menace since the 1990s when people sold numerous encryption programs, usually sporting their own encryption algorithm and DES.
A few I've seen were running 1-2 rounds of DES at most (FWB Hammer's hard disk drivers for Macs did this, but at the time, it was the best encryption one could get due to the relatively slow CPUs like 68000s at the time.) Others were seeding random() with a CRC of the password and XORing the output with the plaintext.
However, back then, there were no government entities standardizing functions like is done now with AES, RSA, and other algos, so people had to write their own, and if it jumbled and unjumbled stuff, it was good enough, since not much in the way of ciphertext was really being attacked.
Times are different now.
These days, with most ARM, AMD, SPARC, POWER, and Intel CPUs having hardware AES acceleration, why would one want to roll their own algorithm?
If one thinks AES is backdoored, cascade it with another known good algorithm like SERPENT, Threefish, heck, maybe even an older one like IDEA, 3DES, or even 3-Skipjack. There are other less known algorithms which have withstood testing as well. Cascading isn't intended to expand the bit width, but to have protection should one algorithm get broken. TrueCrypt offers/offered this functionality.
Same with public key algorithms. Worried about RSA? Have two signatures, one RSA, and one with ECC or a lattice based algorithm that is resistant to TWIRL and quantum factoring, and validate both sigs.
As for crypto implementations, if a user needs to encrypt a file, OpenPGP is a known standard. For communicating across the wire, SSH and SSL are known standards that are decently robust. For encrypting stuff in RAM, almost all modern operating systems have a facility like KeyChain to keep sensitive data from being swapped out, or if it is, have it encrypted.
With almost every programming language offering hooks for AES and RSA, there isn't a need to roll crypto, even for obfuscation reasons. If one just needs obfuscation, use an AES() function with all zeroes as the key.
At the time, it was OK to publish source code in a printed book... but stored online as a computer document and exported, it was an ITAR violation. So, one encryption company (think ViaCrypt) printed out the source code of PGP and made a book out of it, which was freely and legally exported. Then it was scanned in and OCR-ed for the source code.
This is one reason why that law eventually just got pulled, and export limited to the few countries on the blacklist.
I wouldn't be surprised to see far worse things come down the pipe, especially malware that exploited domain admin rights to compromise the entire AD forest.
However, we have one big defense against all of this: Virtualization. Not just VM farms, but VDI (so a compromised desktop can just be rolled back to a known good snapshot almost instantly.) If the malware can't touch hardware, it can still destroy/corrupt files, but VMs have a lot more tools available for mitigating/reversing such attacks, even if it is just a simple snapshot of files taken daily which persists a week before expiring. Of course, snapshots are not backups, but they are a tool to help with RTO/RPO.
Another defense is separation. The AD domain used for authenticating to the NetBackup server, SAN, and tape drive is completely separate than the AD forest used for day to day user work. This way, a domain or enterprise admin account that gets compromised on a user's desktop cannot be used to destroy all data on a silo, SAN, or NAS. It will still be pure hell rebuilding the AD structure if malware does use it as a propagation vector, but at least the core appliances won't be affected.
Of course, the final defense are good backup and archival policies. For example, a backup is done daily, and is kept 7-14 days. Another backup is done weekly, kept 4-8 weeks. A monthly backup is fired off, kept 12-24 months, and a quarterly backup is kept 7-20 years on WORM media. Of course, offsite and verification policies go without saying as well. It also doesn't hurt to run a hash of stored files and cryptographically sign that on an offline machine, just as a last resort for detecting tampering.
I have a feeling we will not just see more destructive attacks, but more subtle ones. A simple change in a purchase order can bankrupt a company. So, because this actually hurts businesses (as opposed to the previous "copy data and leave everything alone" intrusions of the past), we might see actual money spent for handling data integrity as part of enterprise security.
Some of the bands I support have been doing boxed sets, as well as LPs.
Yes, CDs as a distribution medium solely are long since dead, replaced by the 99 cent track [1]. However, bands are selling boxed sets which seem to be making them a decent amount of money, where the box contains a CD, a T-shirt, an amulet, and other items. LPs also sell because they are less for the music value, as opposed to the large surface for album art, which isn't nearly as relevant when on a postage-stamp sized screen on a MP3 player.
[1]: This can be argued to be one of the major reasons why the music industry collapsed, and why the big labels make (not sign) their bands now.
IPv6 seems like it would be the ideal solution in this case. No NAT trickery needed.
Of course, it would be wise to have firewalls in place. Even with a mesh, there needs to be a boundary with firewalls in place, maybe even thought for core/edge fabric design as well.
On the other hand, once you learn a few programming languages, it becomes easier to know others, (assuming something that isn't completely different, such as a procedural language (C or Java) versus a functional programming language (Lisp, Scheme), versus assembly language.
If you know C, you can consult the camel and make functioning perl code. So, it might not hurt knowing a non mainstream language, and may not take too much of your time, relatively.
Yik Yak isn't that bad for the most part. A lot of it is people asking for kik IDs and wanting a good time, there are a few tired witticisms posted every so often, a few things about human sexuality popping up quite often...
In general, if one plays/or ever played WoW, it is like Barrens chat, or present-day General/Trade in the garrison.
Of course, you get the people who say something stupid, but the reporting mechanism takes care of that pretty quickly.
The way to get Linux into the desktop space isn't by drawing individual users in. It is how IBM's PC became the standard -- take over business, then personal stuff follows.
The trick is to get businesses to embrace a desktop distribution, by having the OS be able to be managed and policies set by Active Directory GPOs to being able to be audited/updated with existing management tools, to being able to be images and said images updated and maintained so reimaging a desktop is as simple as a PXE boot.
Trying to woo individual users is like herding cats. Instead, get the big boys using your OS, and the personal users will follow.
SystemD, (and to a lesser extent FirewallD) have their points... but as anything in IT, it is good to at least learn the basics of them in order to get around, just like one has to learn how to use SELinux and not just disable it completely.
I personally am on the fence... SystemD provides a lot of functionality, especially with just one command (systemctl). However, I will have a lot more faith in this new functionality once the code certification and auditing is complete.
It follows the same path that OS X and Solaris 11 do, with the root user disabled by default, with the first user created having sudo access to root. A quick change of root's password can enable this if needed.
All and all, this is a good thing. There are a lot of security audit checklists that are starting to require root not be able to be logged on directly, so shipping an OS that has this locked down is not unusual.
For personal use, there isn't anything wrong with unlocking root and using that with su or just logging directly in. However, in business/enterprise settings, it does make sense to have a user stage, even if it is just having different RSA keys in root's authorized_hosts file that belongs to each individual user. I like unlocking root locally, so I can log in with that in single user mode, but having remote root access completely disabled.
There is also battery life. Take NiFe batteries. They have less energy density than lead-acid... but properly watered, they have an extremely long lifespan.
Yes, a rack of NiFe cells would take up a more room than Tesla's technology... but they will still be working and storing energy long after the current generation of lithium batteries have hit the landfills.