For me it always came down to what kind of code it was. If it was "I know what I want to do, what's the right/best way to express that in $LANGUAGE / using $FRAMEWORK?", we're talking about just mechanics. If I was looking for how to do something, where I needed the actual algorithm or data structure rather than just "What's the syntax?" or "Which operator's best?", that's getting into the creative side where you need to at a minimum do attribution. Almost all of what I get off of SO falls into the first category.
Yep. You probably wouldn't fry a nearby city, but even on the low end the yields are high enough that anything within a mile or so of ground zero's going to end up extra-crispy. That also makes "precision" a highly relative term. I'd rather reserve the nukes for when we intend to go all-in.
Not that we need nukes to do the job. Thermobaric and fuel-air bombs don't have the explosive yields of nukes, but they can do almost as good a job on surface structures and in populated areas. Even good old incendiaries will do the trick, see Dresden and Tokyo during WWII for examples.
Your argument runs smack into a principle of jurisprudence that says that the court should not read a law in such a way as to make it nonsensical if there's any other plausible reading of it. All biometric ID systems work off of photos (usually digital) taken by the imaging sensor. All scans of face geometry work off of a digital photo from the imaging sensor. The image of the face needs turned into digital data so it can be processed to produce the biometric ID or face geometry data, which means turning the face itself into a digital photograph. So by your reading no biometric identifiers and no uses of them could be outlawed. But the law was specifically written to outlaw certain uses of biometric identifiers. Your reading of the law would make it nonsensical.
And there is another plausible reading: that photographs and things derived from them are not covered by the law as long as they aren't processed into biometric identifiers. That reading would still give the exemption a purpose, to foreclose the argument that you can't store digitized photographs of people just because they contain all the information needed (after proper processing) to create a biometric identifier, but would avoid making the entire law nonsensical.
Planned attack? It doesn't need that, just a couple of accidents or screw-ups at the same inopportune times. One mistake by a rookie engineer in Arizona took out the grid for most of southern California. One or two more mistakes or equipment failures while they were still trying to recover from the first one could've seen the entire grid west of the Rockies go down. And the main cause is frankly the profit motive: for the sake of efficiency and cost-effectiveness the generation and transmission companies have eliminated the majority of the redundancy in the system and put off expensive maintenance and upgrades as long as the system wasn't failing during normal operation. It wouldn't take a group of terrorists, just a couple of maintenance engineers more interested in getting home for dinner than in following every rule to the letter or system operators who haven't had their morning coffee and are still a bit groggy.
Yeah, someone's just trying to make drama where there isn't much. Shiman's using his own email for the contact email, and possibly his own personal phone numbers, but the registrant name is "X.ORG Foundation, LLC". Probably all it is is X.org doesn't have the credentials for the registrar account to manage the domain themselves, so they'll need to jump through the hoops with NetSol to prove they're really X.org and get the domain moved to their account. A copy of the letters of incorporation should do the trick, and accompanying it with payment should get NetSol to extend the registration while this is being cleared up.
Part of this I blame on the registrars who don't make it obvious how to set up a domain so that several registrar accounts can manage/access it, or who don't provide a way to register a domain with a new account owning it and yours just being assigned to manage it.
Firstly, the attackers here had enough control to alter the site's DNS data. If they've got that much control, likely they also have access to the SSL private keys for the site. Even if they don't, they've enough control that they can do anything they want anyway by using subdirectories on existing servers. So, any changes Let's Encrypt might make still won't protect against this attack. SSL server certificates insure you're talking to the host you think you're talking to, they say nothing about whether that server's controlled by who you think it is or whether it's content can be trusted.
That said, Let's Encrypt should at least verify control of the domain a certificate's being requested for before issuing it. There's several options: give the user a random nonce and confirm they can add a TXT record with the nonce in it (at either the hostname requested or higher up in the hierarchy, they can then request certificates for any hostname at or below the point they could add the record at), have the user add that nonce as an HTTP header or HTML meta header on the root page of the site, send the nonce by e-mail to an administrative mailbox for the domain and require the user to enter it (showing they at least have access to an administrative e-mail account in the domain)... there's probably more options. I think it's non-controversial that being able to get a valid trusted SSL certificate for a host in someone else's domain without the participation of that someone else is a Bad Thing.
Then it should be just as easy for Webkit to make the standardized properties aliases for the Webkit-prefixed ones. And then Webkit-prefixed stuff can be dropped and the site maintainers and devs have an easier time of it as they can just use the standardized properties and not worry about whether it's rendering on Webkit or not. Updating the stylesheets ought to be straightforward property-name replacement. I really really don't want to go back to the bad old days of browser detection and companies specifying not just an official browser but an officially-supported version of that browser (oh, the joys of "you can't use any version of IE higher than 6 but you can't use any version of IE lower than 8").
What configuration on the host? All configuration would be done on the router, since the last rule on the WAN IN ruleset would be to drop everything. The first rule would be to allow ESTABLISHED and RELATED traffic so the return for outbound connections works properly (assuming you want it to work, if not then just omit that rule). After that nothing outside your network's going to be able to connect inbound to your hosts unless you add rules to the middle of the WAN IN ruleset specifying exactly what you want to allow in for each host. The FORWARD rulesets follow the same pattern, adjusted for whether you want to allow outbound by default or not. I've written the rules for an IPv6 firewall, and they're remarkably parallel to the IPv4 rules.
And as pointed out, if you want a truly isolated segment you just don't advertise a routable prefix on the LAN side of your router and autoconfiguration will give you hosts with addresses that're only valid within the segment and can't be routed outside it without some black magic in the router (don't bother, it's easier to just give them routable prefixes and then leave rules for those prefixes out of the FORWARD ruleset on your router so traffic to/from those prefixes just bounces off the the interfaces).
What do you mean IPv6 messed with things? What you're describing is simply the ending of the aberration that is masquerade-mode NAT and the return to the way IPv4 networks operated for most of their existence. Masquerade-mode NAT was a nasty, awkward kludge to normal routing created to work around the refusal of the DSL and cable ISPs to offer more than a single IP address to a subscriber at a time when subscribers were starting to have multiple computers in their households. Up until that point computers on IPv4 networks were directly connected to the Internet with their IP address visible to the world. That's how I used to run servers on dial-up lines, no router involved (at least on my end). All you have to do to protect your IPv6 networks is set up the equivalent to a standard IPv4 firewall. Like IPv4 you have to pay attention to what ports are allowed inbound to which hosts, but that's nothing new and IPv6 gives you more tools to help segregate desired inbound connections from unwanted ones.
Then again, I suppose most people these days haven't written firewall rules or even thought about them, masquerade-mode NAT hid the issues by terminating all non-ESTABLISHED non-RELATED traffic on the router's WAN port and the router didn't have any services except DHCP and DNS listening on the WAN side. Well, it wasn't supposed to anyway, but turns out quite a few did have things listening and those things had pretty much crap authentication so attackers could pretty much walk straight on through without breaking stride. Hence why I prefer explicit firewall rules where I know the packets are going down a black hole before anything that might be listening can even see them.
That wouldn't slow down even the current generation of autonomous drones, which is what anyone serious about getting pictures inside a secured military base would be using. No sense in making yourself a target by broadcasting a nice traceable control signal after all. Drone's launched by the operator so no way to make it refuse to launch. Drone follows prescribed flight path using dead-reckoning off it's internal gyros, updated by GPS fixes (using commercially-available AGPS data to reduce reliance on the parts of the GPS signal that're easiest to jam) whenever it can get a solid GPS lock-on. The drone doesn't transmit anything in flight, everything's recorded on a flash drive for retrieval when it lands. It doesn't receive any signals either except for GPS so it's underside can be designed as an RF shield which would also shield the GPS antennas from ground-generated interference. Facet the RF shield and you've even got first-generation stealth design going for you (see the design of the F-117). All of which can be done with a well-stocked home workshop plus a laptop (or even a modern smartphone with the right software and an externally-accessible micro-SD slot).
Physical destruction, OTOH, tends to stop just about anything regardless of control mechanism or programming.
Do they want the drone intact afterwards, and what kind of range are they looking at? Up to about 50-60 meters a 12-gauge shotgun with #9-10 shot should pretty thoroughly disrupt any imaginable control and return-to-launch functions a drone could have, along with doing a pretty good job disrupting it's structural integrity. For longer ranges I'd use a custom round based on a rifled slug, tapered to a point like a rifle round for aerodynamics and filled with the same #9-10 shot around a timed dispersal charge made to throw the shot in a cone directed forward. Get range to drone, subtract about 10 yards to give the shot room to spread out so you don't need dead-on accuracy, set timer for the time needed for the round to travel that far, aim, fire. As a bonus, the squads get in skeet practice.
SoGo? Haven't heard of that one and can't find it in the catalog. There's Cardbook 5.2 which seems fairly complete and stable. As far as CalDAV, that's already built into Lightning.
I don't see any lack of development in Thunderbird (38.4 came out not that long ago), and I don't see any indication of it going EOL either. There isn't a lot of core development in the email part because as an email client it's pretty much feature-complete and open-source projects rarely make changes to stuff that's working well. Much of the work's been going on in extensions, and IMO that's a good thing because it makes it easier to concentrate on one piece of functionality at a time and if there's a problem with an extension you can disable it until it's fixed without losing all of TB at the same time.
I see no reason to stop using it right now. I'm not going to upset the client end of my email unless and until TB stops receiving security updates and bugfixes in a timely manner or someone comes up with a replacement for SMTP/IMAP that I find compelling and that TB won't be updated to support.
DHCP, as well as ARP/RARP, involve broadcast traffic. That means that your router will see not just your traffic but the traffic from everyone on your segment. 99+% of that traffic doesn't belong to you and isn't intended for you, and dropping the small fraction that does introduces far less of an error than including all that traffic that doesn't. And then there's all the Windows networking broadcast traffic I see on my segment from everyone else's directly-connected Windows boxes that're treating the segment as the local LAN, and the IPv6 homegroup traffic from the same set of boxes. If the ISP wants to charge that traffic against the originating subscriber that's one thing, but they don't get to bill each subscriber on the segment for the full amount of that same traffic too.
I think the only way is to not trust the ISP, do your own tracking of usage. Unfortunately the bandwidth usage tracking in most routers is all but useless for this, it tracks all traffic on the WAN port regardless of whether it's yours or not. You'd need to flash DD-WRT into the router and use a custom tracking solution that'd separate out ARP/RARP, DHCP, broadcast traffic and other outside traffic from the actual traffic you generate. And of course even if it's 100% accurate the ISP will just say it can't be accurate because you aren't them. You'd have to be... aggressively litigious to get them to cave if they're actually wrong.
It might be that I'm on Linux instead of Windows, but for me Thunderbird clearly says that the message storage type is "File per message (maildir)" and the directories exactly match the format of the maildir folders Dovecot uses on the server. You can even see the setting in the advanced preferences General tab although it's greyed out by default (the mail.server.default.canChangeStoreType setting probably controls that). I know Thunderbird used to use mbox files, but I've only ever seen it use maildir on Linux.
One option might be to set up a local IMAP server on your machine and archive your mail there. Then any mail client that talks IMAP could access it.
Thunderbird's nice in that it uses the standard maildir format (one file per message, mail folders are just directories under the root of the tree) for it's local copy. Most IMAP servers understand and can use that format so you can just dump a copy of the local mail store into the IMAP server's user mail directory (or if that doesn't work, use the Unix movemail command to suck everything up from the local mail store and send it to the IMAP server) and be set. The message files are text so grepping for content's still an option of last resort. There are database-based solutions that have more options for tagging and searching, but they tend to cost money and once your mail's in them it's more of a headache to get it back out when you want to change software (this is an archive, it's inevitable that your current software will be unsuitable/unavailable at least once before the archive becomes old enough to be irrelevant).
True, but cable TV companies can't treat subscribers only like that because effectively nobody subscribes to cable TV to watch ads. The cable companies have to treat us like customers buying content, and slip the advertising in without putting in so much that people stop subscribing.
Problem for the cable companies here being that how much advertising is too much depends on what alternatives are out there. Nobody's going to sit through 5 minutes of ads per 15 minutes for a show when they can go to Netflix and watch without ads, or when they can record the show on DVR and skip the ads. The era of ad-supported content is rapidly fading because the conditions that let it flourish are changing.
The cable companies won't find a solution until they accept that they're in 2 businesses:
The network provider business, where they supply the basic pipes that connect their customers to the world at large. This business doesn't deal with content except as streams of bits, and it lives or dies by it's ability to handle data to and from anyone anywhere. Users won't buy connectivity from a network provider that can't connect them reliably to whoever they want to connect to.
The content provider business, where they supply content that users view. This business can't care who it's customers buy connectivity from, it has to be able to deliver content to anyone, anywhere. Again, users won't buy from a content provider who can't deliver the content they've bought unless they have no other options (and yes, pirated content is always an option).
If the cable company limits it's content-provider customers to only it's network-provider customer base, it won't be able to take advantage of the scale of customer base of content providers like Netflix and Amazon. It won't have the customer base size to use as leverage to get licensing terms, and a smaller base means fewer customers to spread costs across and a higher per-capita cost. If they use their position as a network provider to try to force customers to their content, they're going to face even more of the backlash they're already seeing in support for network neutrality and for municipal broadband and other alternatives to their network access monopolies/duopolies. If they lose that monopoly position, they're done for.
If they had the smarts, they could leverage their positions and their infrastructure into being real powerhouses. But they're too afraid of spending money and too locked into an MBA's focus on next quarter's results to do it, so eventually they're going to be wiped out by a combination of dedicated content providers like Netflix and Amazon and Google plus dedicated network providers operated as either public utilities or as an adjunct to a content provider who considers that aspect of their operation just a necessity for their content distribution and is happy as long as the network part pays for it's own operating costs.
When Ballmer was at MS, he championed Microsoft-only because that was the way to keep people locked into Microsoft. MS had a dominant position already, and keeping things MS-only made sure any competition didn't have enough applications to be attractive. But now MS is going into a market where they don't have a dominant position, so MS-only just insures MS won't have enough to be attractive. The only option will be what MS did with IE back when Netscape ruled the Web: offer compatibility to lure users and especially businesses over, then slowly break compatibility to force a Hobson's choice.
The statement about contractors not having a right to bargain as a union isn't quite the full story. What contractors don't have is a right to have a union as the sole bargaining unit for all contractors. With employees, the union bargains on behalf of all employees whether they're members of the union or not. Contractors have every right to form a union and have it bargain on their behalf, but it can only bargain on behalf of those contractors who're members. If you aren't a member, you negotiate your own terms. And the company can't refuse to negotiate with the union because they aren't negotiating with the union, they're negotiating with you with the union acting as your agent. They can of course refuse to negotiate with you, but they could do that anyway (and frankly any sane contractor has an attorney involved in contract negotiations to make sure there aren't any hidden loopholes or gotchas in the contract, so refusing to deal with a representative would be a red flag that these aren't negotiations) and the basic idea behind a union is that refusing to deal with the union cuts the company off from so many contractors that they can't afford to do that.
The thing to be wary of is joining a union or other organization where the management has the right to overrule the membership. That's when things always go badly.
Gaming. It's not so much that you need to press 10 keys at once as that between fast typing and keyboard hardware macros you can wind up overlapping keystrokes. If you don't game high-end content you probably underestimate how much involves repeated sequences and how fast you can get when it's down to muscle memory rather than conscious typing. On a USB keyboard that results in lost keys and missed commands.
Hmm. My motherboard (Asrock X99 WS-E) has 3x SGPIO connectors, shouldn't be that hard to find a board that'd convert that into digital or analog I/O lines... yeah, the MAX72408 looks like overkill if you could find it as a basic kit instead of a bare chip.
Slashdot Mirror
For me it always came down to what kind of code it was. If it was "I know what I want to do, what's the right/best way to express that in $LANGUAGE / using $FRAMEWORK?", we're talking about just mechanics. If I was looking for how to do something, where I needed the actual algorithm or data structure rather than just "What's the syntax?" or "Which operator's best?", that's getting into the creative side where you need to at a minimum do attribution. Almost all of what I get off of SO falls into the first category.
Yep. You probably wouldn't fry a nearby city, but even on the low end the yields are high enough that anything within a mile or so of ground zero's going to end up extra-crispy. That also makes "precision" a highly relative term. I'd rather reserve the nukes for when we intend to go all-in.
Not that we need nukes to do the job. Thermobaric and fuel-air bombs don't have the explosive yields of nukes, but they can do almost as good a job on surface structures and in populated areas. Even good old incendiaries will do the trick, see Dresden and Tokyo during WWII for examples.
Your argument runs smack into a principle of jurisprudence that says that the court should not read a law in such a way as to make it nonsensical if there's any other plausible reading of it. All biometric ID systems work off of photos (usually digital) taken by the imaging sensor. All scans of face geometry work off of a digital photo from the imaging sensor. The image of the face needs turned into digital data so it can be processed to produce the biometric ID or face geometry data, which means turning the face itself into a digital photograph. So by your reading no biometric identifiers and no uses of them could be outlawed. But the law was specifically written to outlaw certain uses of biometric identifiers. Your reading of the law would make it nonsensical.
And there is another plausible reading: that photographs and things derived from them are not covered by the law as long as they aren't processed into biometric identifiers. That reading would still give the exemption a purpose, to foreclose the argument that you can't store digitized photographs of people just because they contain all the information needed (after proper processing) to create a biometric identifier, but would avoid making the entire law nonsensical.
Planned attack? It doesn't need that, just a couple of accidents or screw-ups at the same inopportune times. One mistake by a rookie engineer in Arizona took out the grid for most of southern California. One or two more mistakes or equipment failures while they were still trying to recover from the first one could've seen the entire grid west of the Rockies go down. And the main cause is frankly the profit motive: for the sake of efficiency and cost-effectiveness the generation and transmission companies have eliminated the majority of the redundancy in the system and put off expensive maintenance and upgrades as long as the system wasn't failing during normal operation. It wouldn't take a group of terrorists, just a couple of maintenance engineers more interested in getting home for dinner than in following every rule to the letter or system operators who haven't had their morning coffee and are still a bit groggy.
Yeah, someone's just trying to make drama where there isn't much. Shiman's using his own email for the contact email, and possibly his own personal phone numbers, but the registrant name is "X.ORG Foundation, LLC". Probably all it is is X.org doesn't have the credentials for the registrar account to manage the domain themselves, so they'll need to jump through the hoops with NetSol to prove they're really X.org and get the domain moved to their account. A copy of the letters of incorporation should do the trick, and accompanying it with payment should get NetSol to extend the registration while this is being cleared up.
Part of this I blame on the registrars who don't make it obvious how to set up a domain so that several registrar accounts can manage/access it, or who don't provide a way to register a domain with a new account owning it and yours just being assigned to manage it.
StartSSL does domain verification by sending e-mail to an administrative address (pulled from WHOIS data) (for their Class 1 certificates anyway).
Firstly, the attackers here had enough control to alter the site's DNS data. If they've got that much control, likely they also have access to the SSL private keys for the site. Even if they don't, they've enough control that they can do anything they want anyway by using subdirectories on existing servers. So, any changes Let's Encrypt might make still won't protect against this attack. SSL server certificates insure you're talking to the host you think you're talking to, they say nothing about whether that server's controlled by who you think it is or whether it's content can be trusted.
That said, Let's Encrypt should at least verify control of the domain a certificate's being requested for before issuing it. There's several options: give the user a random nonce and confirm they can add a TXT record with the nonce in it (at either the hostname requested or higher up in the hierarchy, they can then request certificates for any hostname at or below the point they could add the record at), have the user add that nonce as an HTTP header or HTML meta header on the root page of the site, send the nonce by e-mail to an administrative mailbox for the domain and require the user to enter it (showing they at least have access to an administrative e-mail account in the domain)... there's probably more options. I think it's non-controversial that being able to get a valid trusted SSL certificate for a host in someone else's domain without the participation of that someone else is a Bad Thing.
So, similar to the IBM 3850 family with write-once media and a massively higher media density?
Then it should be just as easy for Webkit to make the standardized properties aliases for the Webkit-prefixed ones. And then Webkit-prefixed stuff can be dropped and the site maintainers and devs have an easier time of it as they can just use the standardized properties and not worry about whether it's rendering on Webkit or not. Updating the stylesheets ought to be straightforward property-name replacement. I really really don't want to go back to the bad old days of browser detection and companies specifying not just an official browser but an officially-supported version of that browser (oh, the joys of "you can't use any version of IE higher than 6 but you can't use any version of IE lower than 8").
What configuration on the host? All configuration would be done on the router, since the last rule on the WAN IN ruleset would be to drop everything. The first rule would be to allow ESTABLISHED and RELATED traffic so the return for outbound connections works properly (assuming you want it to work, if not then just omit that rule). After that nothing outside your network's going to be able to connect inbound to your hosts unless you add rules to the middle of the WAN IN ruleset specifying exactly what you want to allow in for each host. The FORWARD rulesets follow the same pattern, adjusted for whether you want to allow outbound by default or not. I've written the rules for an IPv6 firewall, and they're remarkably parallel to the IPv4 rules.
And as pointed out, if you want a truly isolated segment you just don't advertise a routable prefix on the LAN side of your router and autoconfiguration will give you hosts with addresses that're only valid within the segment and can't be routed outside it without some black magic in the router (don't bother, it's easier to just give them routable prefixes and then leave rules for those prefixes out of the FORWARD ruleset on your router so traffic to/from those prefixes just bounces off the the interfaces).
What do you mean IPv6 messed with things? What you're describing is simply the ending of the aberration that is masquerade-mode NAT and the return to the way IPv4 networks operated for most of their existence. Masquerade-mode NAT was a nasty, awkward kludge to normal routing created to work around the refusal of the DSL and cable ISPs to offer more than a single IP address to a subscriber at a time when subscribers were starting to have multiple computers in their households. Up until that point computers on IPv4 networks were directly connected to the Internet with their IP address visible to the world. That's how I used to run servers on dial-up lines, no router involved (at least on my end). All you have to do to protect your IPv6 networks is set up the equivalent to a standard IPv4 firewall. Like IPv4 you have to pay attention to what ports are allowed inbound to which hosts, but that's nothing new and IPv6 gives you more tools to help segregate desired inbound connections from unwanted ones.
Then again, I suppose most people these days haven't written firewall rules or even thought about them, masquerade-mode NAT hid the issues by terminating all non-ESTABLISHED non-RELATED traffic on the router's WAN port and the router didn't have any services except DHCP and DNS listening on the WAN side. Well, it wasn't supposed to anyway, but turns out quite a few did have things listening and those things had pretty much crap authentication so attackers could pretty much walk straight on through without breaking stride. Hence why I prefer explicit firewall rules where I know the packets are going down a black hole before anything that might be listening can even see them.
That wouldn't slow down even the current generation of autonomous drones, which is what anyone serious about getting pictures inside a secured military base would be using. No sense in making yourself a target by broadcasting a nice traceable control signal after all. Drone's launched by the operator so no way to make it refuse to launch. Drone follows prescribed flight path using dead-reckoning off it's internal gyros, updated by GPS fixes (using commercially-available AGPS data to reduce reliance on the parts of the GPS signal that're easiest to jam) whenever it can get a solid GPS lock-on. The drone doesn't transmit anything in flight, everything's recorded on a flash drive for retrieval when it lands. It doesn't receive any signals either except for GPS so it's underside can be designed as an RF shield which would also shield the GPS antennas from ground-generated interference. Facet the RF shield and you've even got first-generation stealth design going for you (see the design of the F-117). All of which can be done with a well-stocked home workshop plus a laptop (or even a modern smartphone with the right software and an externally-accessible micro-SD slot).
Physical destruction, OTOH, tends to stop just about anything regardless of control mechanism or programming.
Do they want the drone intact afterwards, and what kind of range are they looking at? Up to about 50-60 meters a 12-gauge shotgun with #9-10 shot should pretty thoroughly disrupt any imaginable control and return-to-launch functions a drone could have, along with doing a pretty good job disrupting it's structural integrity. For longer ranges I'd use a custom round based on a rifled slug, tapered to a point like a rifle round for aerodynamics and filled with the same #9-10 shot around a timed dispersal charge made to throw the shot in a cone directed forward. Get range to drone, subtract about 10 yards to give the shot room to spread out so you don't need dead-on accuracy, set timer for the time needed for the round to travel that far, aim, fire. As a bonus, the squads get in skeet practice.
SoGo? Haven't heard of that one and can't find it in the catalog. There's Cardbook 5.2 which seems fairly complete and stable. As far as CalDAV, that's already built into Lightning.
I don't see any lack of development in Thunderbird (38.4 came out not that long ago), and I don't see any indication of it going EOL either. There isn't a lot of core development in the email part because as an email client it's pretty much feature-complete and open-source projects rarely make changes to stuff that's working well. Much of the work's been going on in extensions, and IMO that's a good thing because it makes it easier to concentrate on one piece of functionality at a time and if there's a problem with an extension you can disable it until it's fixed without losing all of TB at the same time.
I see no reason to stop using it right now. I'm not going to upset the client end of my email unless and until TB stops receiving security updates and bugfixes in a timely manner or someone comes up with a replacement for SMTP/IMAP that I find compelling and that TB won't be updated to support.
DHCP, as well as ARP/RARP, involve broadcast traffic. That means that your router will see not just your traffic but the traffic from everyone on your segment. 99+% of that traffic doesn't belong to you and isn't intended for you, and dropping the small fraction that does introduces far less of an error than including all that traffic that doesn't. And then there's all the Windows networking broadcast traffic I see on my segment from everyone else's directly-connected Windows boxes that're treating the segment as the local LAN, and the IPv6 homegroup traffic from the same set of boxes. If the ISP wants to charge that traffic against the originating subscriber that's one thing, but they don't get to bill each subscriber on the segment for the full amount of that same traffic too.
I think the only way is to not trust the ISP, do your own tracking of usage. Unfortunately the bandwidth usage tracking in most routers is all but useless for this, it tracks all traffic on the WAN port regardless of whether it's yours or not. You'd need to flash DD-WRT into the router and use a custom tracking solution that'd separate out ARP/RARP, DHCP, broadcast traffic and other outside traffic from the actual traffic you generate. And of course even if it's 100% accurate the ISP will just say it can't be accurate because you aren't them. You'd have to be... aggressively litigious to get them to cave if they're actually wrong.
It might be that I'm on Linux instead of Windows, but for me Thunderbird clearly says that the message storage type is "File per message (maildir)" and the directories exactly match the format of the maildir folders Dovecot uses on the server. You can even see the setting in the advanced preferences General tab although it's greyed out by default (the mail.server.default.canChangeStoreType setting probably controls that). I know Thunderbird used to use mbox files, but I've only ever seen it use maildir on Linux.
One option might be to set up a local IMAP server on your machine and archive your mail there. Then any mail client that talks IMAP could access it.
Thunderbird's nice in that it uses the standard maildir format (one file per message, mail folders are just directories under the root of the tree) for it's local copy. Most IMAP servers understand and can use that format so you can just dump a copy of the local mail store into the IMAP server's user mail directory (or if that doesn't work, use the Unix movemail command to suck everything up from the local mail store and send it to the IMAP server) and be set. The message files are text so grepping for content's still an option of last resort. There are database-based solutions that have more options for tagging and searching, but they tend to cost money and once your mail's in them it's more of a headache to get it back out when you want to change software (this is an archive, it's inevitable that your current software will be unsuitable/unavailable at least once before the archive becomes old enough to be irrelevant).
True, but cable TV companies can't treat subscribers only like that because effectively nobody subscribes to cable TV to watch ads. The cable companies have to treat us like customers buying content, and slip the advertising in without putting in so much that people stop subscribing.
Problem for the cable companies here being that how much advertising is too much depends on what alternatives are out there. Nobody's going to sit through 5 minutes of ads per 15 minutes for a show when they can go to Netflix and watch without ads, or when they can record the show on DVR and skip the ads. The era of ad-supported content is rapidly fading because the conditions that let it flourish are changing.
The cable companies won't find a solution until they accept that they're in 2 businesses:
If the cable company limits it's content-provider customers to only it's network-provider customer base, it won't be able to take advantage of the scale of customer base of content providers like Netflix and Amazon. It won't have the customer base size to use as leverage to get licensing terms, and a smaller base means fewer customers to spread costs across and a higher per-capita cost. If they use their position as a network provider to try to force customers to their content, they're going to face even more of the backlash they're already seeing in support for network neutrality and for municipal broadband and other alternatives to their network access monopolies/duopolies. If they lose that monopoly position, they're done for.
If they had the smarts, they could leverage their positions and their infrastructure into being real powerhouses. But they're too afraid of spending money and too locked into an MBA's focus on next quarter's results to do it, so eventually they're going to be wiped out by a combination of dedicated content providers like Netflix and Amazon and Google plus dedicated network providers operated as either public utilities or as an adjunct to a content provider who considers that aspect of their operation just a necessity for their content distribution and is happy as long as the network part pays for it's own operating costs.
When Ballmer was at MS, he championed Microsoft-only because that was the way to keep people locked into Microsoft. MS had a dominant position already, and keeping things MS-only made sure any competition didn't have enough applications to be attractive. But now MS is going into a market where they don't have a dominant position, so MS-only just insures MS won't have enough to be attractive. The only option will be what MS did with IE back when Netscape ruled the Web: offer compatibility to lure users and especially businesses over, then slowly break compatibility to force a Hobson's choice.
The statement about contractors not having a right to bargain as a union isn't quite the full story. What contractors don't have is a right to have a union as the sole bargaining unit for all contractors. With employees, the union bargains on behalf of all employees whether they're members of the union or not. Contractors have every right to form a union and have it bargain on their behalf, but it can only bargain on behalf of those contractors who're members. If you aren't a member, you negotiate your own terms. And the company can't refuse to negotiate with the union because they aren't negotiating with the union, they're negotiating with you with the union acting as your agent. They can of course refuse to negotiate with you, but they could do that anyway (and frankly any sane contractor has an attorney involved in contract negotiations to make sure there aren't any hidden loopholes or gotchas in the contract, so refusing to deal with a representative would be a red flag that these aren't negotiations) and the basic idea behind a union is that refusing to deal with the union cuts the company off from so many contractors that they can't afford to do that.
The thing to be wary of is joining a union or other organization where the management has the right to overrule the membership. That's when things always go badly.
Gaming. It's not so much that you need to press 10 keys at once as that between fast typing and keyboard hardware macros you can wind up overlapping keystrokes. If you don't game high-end content you probably underestimate how much involves repeated sequences and how fast you can get when it's down to muscle memory rather than conscious typing. On a USB keyboard that results in lost keys and missed commands.
Hmm. My motherboard (Asrock X99 WS-E) has 3x SGPIO connectors, shouldn't be that hard to find a board that'd convert that into digital or analog I/O lines... yeah, the MAX72408 looks like overkill if you could find it as a basic kit instead of a bare chip.