Lan

I would assume the launch of the Switch successor is why they are clamping down. It's likely very similar architecturally to the Switch. Nobody knows how long it would take to hack it, someone could be silently sitting on an exploit that they've been saving to see if it'll work on the successor. In the event it's hacked quickly and there are still actively developed Switch emulators, it wouldn't be a stretch to believe support would quickly be added to those emulators for the successor.

Consider a scenario where you have a log file and in the log file is an IP address (172.217.5.14). You are not sure whose IP address it is. So you run the following commands:

# dig -x 172.217.5.14 +short

lga15s49-in-f14.1e100.net.

ord38s19-in-f14.1e100.net.

# dig lga15s49-in-f14.1e100.net. +short

172.217.5.14

# dig lga15s49-in-f14.1e100.net. +short

172.217.5.14

The first command (dig -x) checks the PTR record for the IP address 172.217.5.14. It returns two PTR records: lga15s49-in-f14.1e100.net. and ord38s19-in-f14.1e100.net.[0]. Those are subdomains of 1e100.net, which we know Google owns. However, you can set a PTR to pretty much whatever you want, so we now take an additional step as well. We run the dig command again to check the A records for the domains. This returns the same IP address we started with, which is good. Since Google controls the DNS for 1e100.net we can be reasonably sure that it is in fact a Google server. This is called Forward-confirmed reverse DNS (FCrDNS) and is one tool you can use to determine the ownership of an IP address. For example, it is frequently used as a weight in email spam filters. Although, because of the intricacies of email, in that case it is usually not used for identification and instead used as a general purpose check to determine whether a mail server is rogue or not, since spam servers very often do not have proper FCrDNS.

There are other tools to determine who owns an IP address, like whois, but in some instances one will garner useful information and the other will not. So it's nice to have both at your disposal.

[0] As a side note: the trailing . in those PTR records returned by dig is not a typo. All domains actually end in a dot, it's just usually implied.

Visual changes are an easy feather-in-the-cap for both front-end developers and for management. A design overhaul is immediately obvious to everyone. It's something you can show off. It's something you can add eye-candy to. Changes like that are more glamorous than performance improvements. People that are trying to justify their position love to attach their name to those types of things.

There are already a plethora of fly-by-night Javascript frameworks. Outside of hobby projects, I'd wager that most people prefer not to use frameworks that lack an established track record. For a business, the cost of switching frameworks after the fact is simply too great. Unless the framework has a sizable userbase and has been around for a few years, I wouldn't use it in any serious projects. To get a large enough userbase that people will feel comfortable using it in serious projects, you're going to need them to use your framework in those hobby projects. However, those projects are the least likely to have a budget, and the most likely to utilize free resources. This is why I do not think a commercial framework can succeed.

Not a whole lot. The fastest CPUs will net you less than 100 MH/s [0]. The fastest single-card GPU configurations will net you around 1,000 MH/s [0]. The current total hash rate is around 5,000,000,000,000 MH/s [1]. WannaCry affected around 300,000 PCs [2]. So if every WannaCry miner was operating off CPU and getting 100 MH/s, it would only be 30,000,000 MH/s. Or 0.0006% of the current total hash rate. If they all had high-end GPUs getting them 1,000 MH/s then that would bring it up to 300,000,000 MH/s. Or 0.006% of the current total hash rate. So WannaCry wouldn't even be a drop in the bucket. If you're wondering how the hash rate is so high, it's because mining has switched to using ASICs, the fastest of which run around 14,000,000 MH/s [3].

[0] https://en.bitcoin.it/wiki/Non-specialized_hardware_comparis...

[1] https://blockchain.info/charts/hash-rate

[2] https://en.wikipedia.org/wiki/WannaCry_ransomware_attack

[3] https://en.bitcoin.it/wiki/Mining_hardware_comparison

You could try an all-in-one solution like iRedMail[0] or Mail-in-a-Box[1]. Those supposedly do most of the leg work for you and set up a commonly used stack (Postfix, Dovecot, SpamAssassin, Roundcube, etc). I've never used either of them since I just install everything piecemeal, but I imagine there is an ease of use tradeoff compared to setting the same stack up yourself. In other words, it'll be easier to set up initially, but the downside is that you wont learn the ins and outs of the individual components. So if something breaks or you need to make an adjustment you're going to have a more difficult time at that point.

That said, there are some things you should be aware of when running a mail server:

1. You need to make sure that the IP address and domain name that SMTP is bound to is not on a blacklist[2]. You also need to consider the trustworthiness of your host because you could very well get caught in the cross-fire if one of their other customers gets them range banned. Certain cloud providers that make it very easy to change IP will more than likely have all of their addresses on some blacklist or another.

2. You also need to make sure you have matching forward (A record) and reverse (PTR record) DNS records for that IP address. This is called Forward-confirmed reverse DNS, aka FCrDNS. Many mail servers will reject email from servers that do not have or have mismatching records for FCrDNS.

3. You must set up SPF and DKIM. Many mail servers will either reject mail from servers without these, or at least weight heavily against it.

4. You probably want to make sure TLS is set up properly, otherwise your mail is going to travel the internet in plaintext.

5. The IP address you're sending from is going to start off with no reputation. The volume, type of mail, and how many people mark your mail as spam is going to decide whether other mail servers start filtering you or not. You may have no problems here. If you're unlucky, you will need to try to reach out to whichever major mail provider is filtering your mail. Many of them have a ticketing system for this, but you'll be at the mercy of whomever is working that ticket. There are also various whitelists that might be worth trying your server on. They're usually very selective and will probably reject your request.

6. You really, really need to make sure you've got your policies set up correctly because you do not want to accidentally set up an open relay[3] that will be used to spam other people.

7. Greylisting is a very, very effective means of spam filtering. The downside is that mail from new servers wont be delivered instantaneously and will instead be delivered whenever their mail server tries to deliver it again. Other than that, most spam is malformed in some way so some basic DNS checks will filter a ton of it. There are also free RBL and DNSBL lists that will pick up the slack.

[0] http://www.iredmail.org/ [1] https://mailinabox.email/ [2] https://mxtoolbox.com/blacklists.aspx [3] https://en.wikipedia.org/wiki/Open_mail_relay

To be honest, if he was that disoriented it sounds like your dad should have been calling 911 and not Uber. I have no idea how you could expect anything short of an ambulance with trained medical personnel to provide the requisite support that a mentally incapacitated cancer patient may require.

It might be better to ask what you had expected the outcome in this scenario to be?

Consider the three most common authentication factors:

* Something you know

* Something you have

* Something you are

A conventional password-based login implements "something you know" (i.e. your password). A password-less login implements "something you have" (e.g. email access). That doesn't make it more secure, it's just substituting one authentication factor for another. One could argue that it's more convenient but that's subjective since people that use password lockers might actually find it less convenient.

An argument against password-less logins might be that they should be implementing multi-factor authentication in the first place. Password-less login is by nature not at least two-factor authentication. Even if you have two-factor authentication enabled for your email, it will still just be "something you have" because someone that gains access to your PC or phone will probably have access to your email as well. The easiest second factor to add into the mix is "something you know" (e.g. a password) and now you're back to conventional two-factor authentication practices.

>He found no evidence it was copied and reported his findings in a piece titled ‘Did Bill Gates Steal the Heart of DOS?‘.

More supporting evidence that any title that ends in a question mark can be safely summed up as 'No'.

Until you convince those CAs to start signing for code, they still cost $400+. And remember, that's per year. The driver will continue to function after that year, but they will either need to cough up another $400 the next year, or cease development. Even at $100-200 per year that's still an unreasonable cost for hobby projects.

Actually, my complaint is that if you go through the effort of manually disabling driver verification checks at boot time, Microsoft should respect your decision and allow you to persist that decision for that driver, even if you reboot and turn verification back on. They don't, and instead give you an all or nothing approach, with the nothing approach being a hassle and leaving a permanent watermark in the bottom right corner of your display.

I disagree. I think Microsoft's current driver policies are unreasonable. Most end-users don't want to run their PC in testing mode, and will look for an easier way around it. This has a negative effect on free and open-source software. For example, there is software out there that allows you to use Playstation 3 controllers with your PC. In the past, there were pretty much two software solutions for Windows. One driver was unsigned, and the other was signed. Many people used the latter because it was much easier to get working. The problem is that it also installed alongside Chinese malware. Driver signing didn't save anyone there. If anything, it made the issue worse.

Windows 7 has extended support through January 14, 2020[1], so even if he was forced to do so for some reason, it likely wont be years. And with the rate things are changing, who is to say that Windows will even be a requirement for him in 2020?

[1] https://support.microsoft.com/en-us/help/13853/windows-lifec...

Bitcoin mining is done with clusters of specially designed ASICs these days. GPU mining, let alone CPU mining, isn't viable by a long shot. I'd be shocked if you got any payout at all from a mining pool with it.

>You could, however, install a proxy or a router inside your private network

Sounds like a good way to get fired depending on how strict their policies are.

Look for cables made by Volutz. I had never heard of the company before I tried them, but their cables are incredibly durable. They're also 24/20 AWG and I've never seen USB cables that thick sold by anyone else.

$599.00 is the official price before tax and shipping.

Another cheap rPi alternative that doesn't solve any new problems. What I'd like to see is one of these with a few SATA ports and ECC memory. Then you'd have a viable low-cost, low-power server, in a market that is sorely lacking those things considering the closest alternative is one of the newer Intel Atom boards that costs upwards of $250.

There were notable instances of benchmarking suites being compiled with ICC. So even if most applications didn't exhibit the issue, reviews for AMD processors did. And it was a prominent enough issue that a tool was written to search your PC for software compiled with ICC and patch it to work correctly.

>That's not how WiFi works. They cannot know for a fact that these WiFi hotspots are within the convention space, they could and likely are, blocking WiFi located outside of that space.

To play devil's advocate, some APs support rogue triangulation. Ours plot any rogues on a building map so we know exactly where they are. When combined with a proper wireless survey, you could ensure that they don't deauth anything beyond the building perimeter. Not that I recommend that, since at the very least someone should be able to tether their phone if they want. But also because it puts additional overhead on your APs, which are usually already taxed in high-usage areas.

How long it takes to switch services depends on how long you have your TTL set on your MX records. If he set it to expire after days or weeks, it would take days or weeks to switch services. Usually the default is a much lower value, but there are some legitimate reasons to want a high TTL (It could help mitigate a domain hijacking for example).

Browser fingerprinting fails for cases where a computer is shared. That includes both home and public terminals. Not to mention it creeps people out and lacks any type of security.

I usually find that sites that implement it place form above functionality. Sure, they look nice, but it's usually much more difficult to find information. If you intend for that page to be an art exhibit that's one thing, otherwise you may want to reconsider forcing your users to scroll endlessly to gather tiny breadcrumbs of text.

I can see this causing some issues with users that have multiple email addresses. It may cause panic if they log in, see that it is successful, but do not see any of their normal account data. They may assume that their account has been deleted or their data lost.