I'll be shocked when I can believe the virtual reality business is a real thing instead of just hype.
I'll be shocked when I can believe the virtual reality business is a real thing instead of just hype.
I'm not surprised, because I've occasionally gotten a look at the resumes and candidates who didn't get to the hiring manager (discarded by HR as not meeting the qualifications). I've found more better-qualified candidates in the discard pile than in the list we got to do phone interviews with, and the consistent pattern is that the HR screening systems put too much emphasis on strong matches with too-specific keywords and not enough emphasis on "knows the subject and has a proven ability to learn the tools". Even with the improvements in AI and expert systems, the screening's still subject to the same old problems.
Software courses are in my book really field-specific. If you're doing operating-system development or embedded-hardware programming then the classes are useful, but outside of those fields that kind of course isn't really helpful and the university computer-science and computer-engineering programs seem to deliberately avoid teaching the things that are useful (eg. how to understand and use standard frameworks (not a specific framework either, the concepts needed to pick up any framework and work with it), how to figure out which design patterns are most applicable and when you're dealing with an anti-pattern that has to be removed, the common idioms in different categories of software architectures, that sort of thing).
It's sad that after 35 years at this I'm still seeing the same malfunctions and watching the same kind of job-shop schmo mishandle things in the same old ways. WiPro or Andersen, plus ça change...
And you set yourself up here. Take your "alicebob" password example. If you allow all-lower-case passwords an attacker trying concatenations of obvious words needs to try 4 possibilities to crack that password. OTOH if he knows you prohibit all-lower-case he only needs to try 3 since "alicebob" is illegal. You've just decreased the amount of time he needs by 25. That's significant. The fact that "alicebob" couldn't be used as a password is exactly why the attack is faster, it's a vulnerability and not a feature.
As far as passwords being replaced by "something better", I doubt there's anything better for the obvious reasons (eg. biometrics are unchangeable if breached and even more predictable than passwords since there's (in theory) only one possibility for a given user and knowing the user an attacker can determine what that sole possibility is). We'd be better-off sticking with passwords and looking at ways to remove the need to commit them to fallible human memory and enter them in error-prone ways like typing, which are probably the two greatest contributors to password vulnerability. #3 is very probably transmitting the password itself over the connection in order for the remote end to validate it, and we've had the methods to eliminate that for decades (all browsers support challenge-response authentication for instance, the only reason it wasn't used was because of IE6's brain-dead rules about which method to use if more than one was available).
Hello ActiveX, its been a while! And you never had any security issues did you, noooo, perfectly safe. Thats why its still around today... err, oh, wait...
Yup. We've been this route before. Not to mention compiling native code for multiple versions of multiple operating systems on multiple CPU architectures. Avoiding that's one of the attractions of browser-based applications. Look, a security and development nightmare in the same package!
Mandatory character classes never increase the search space, they can only decrease it. In your example, if based on your rules I know that all-lower-case passwords aren't legal because they lack a mandatory character class then I can immediately exclude all all-lower-case possibilities from my search. That can only speed up my search for passwords compared to having to check those possibilities even if users aren't using them (as an attacker I don't know if they are or not unless you tell me in your rules that your system won't let them).
It also complicates things for anyone using any password generator because they've got to check their policies and make sure they're using the one that matches your particular set of mandatory character classes. Remember that users don't have to create passwords just for your system, they have to create them for every system they use. The fewer variations they have to deal with, the less likely they are to do something stupid setting up for any particular variation.
Before it hurt them, though, they'd file suit objecting to the penalty. It'd be a decade or more before it all got sorted out, and in the meantime it'd be business as usual for them.
The cable companies in fact can do something about such competition. They gave the municipalities Hobson's Choice: give them monopoly access to the rights-of-way, or do without cable TV. Shopping around doesn't help the municipality, all the big cable companies are demanding the same thing and the smaller ones can't get licenses for the content so they don't have anything to put on the air. I lived through that period, and there really wasn't much the cities could do about it. Now it just gives the telecoms another point of leverage so even if you get officials in place who'll fight they just end up tied up in court trying to break the contracts.
This sort of lawsuit won't do much, even if the state wins. What would do something about the problem is for the state or the municipalities to take the position that the cable companies have breached the contracts that give them monopoly access to public right-of-way for their wiring, then open the access up to other companies under terms that'd prevent any company from blocking or interfering with use by others. That'd still leave some roadblocks, but it'd remove one of the most important ways the telecoms maintain their monopoly position.
This wouldn't involve the ISP, it'd be entirely within the router. The router could access any DNS server, but hosts on the internal side could only access the router's caching DNS server unless the user authorized an exception for them. It wouldn't entirely prevent attacks like this one, but it'd prevent direct attacks and forcing the attacks through multiple levels of caching would blunt the attack to a degree and make it easier to throttle the sources of the malicious requests.
Ultimately, it's the groups that initiated the DDoS who are to blame. But others have to take some responsibility for failing to do what they could to mitigate the opportunities to initiate attacks:
1. ISPs could implement measures based on RFCs 3704 and 2827 that would make spoofed traffic difficult to impossible to generate.
2. Router makers could implement RFC 3704 and 2827 rules in their firewalls by default, could implement default rules that blocked access to external DNS to everything except the router (with the option for the user to allow some or all access), could provide a separate network for IoT devices that defaults to no Internet access and the user has to specifically authorize access per device, and could make randomized default passwords the standard for factory-default configurations.
3. IoT manufacturers could make randomized default passwords standard and design their devices to not require Internet access to configure.
4. Consumers could acknowledge that they're responsible for their own networks and routinely make use of the available tools to check on the health of their networks and the status of the devices on it.
"We can't create a culture that says it cares about diversity and then excludes almost half the country because they back a political candidate," Zuckerberg wrote. "There are many reasons a person might support Trump that do not involve racism, sexism, xenophobia, or accepting sexual assault."
Certainly there are reasons, but that's not the point and not why Project Include won't work with Y Combinator. Support of Trump involves considering sexual assault, racism, sexism and xenophobia to be acceptable. That holds regardless of the reasons you have for supporting him. Project Include is saying "No, those things that Trump loudly and proudly stands for are not acceptable, period. We don't care why you think they're acceptable because we don't believe there's any reason you could give us that could make them acceptable.". And this isn't just the candidate's supporters espousing those positions, it's the candidate himself making his enthusiastic support of those positions the centerpiece of his speeches and campaign.
There'll be plenty of jobs. What there won't be will be employee positions. Companies will increasingly replace employees with robotics and software. Work will shift to self-employment. A contract software engineer will contract with an accountant to handle accounting, with an advertising firm to handle ad placement, with their hosting services to handle routine administration of their servers and so on. An author would contract with someone to screen calls and mail and act as a secretary/receptionist, with someone else to proofread and edit their manuscripts and so on, and would publish directly through distribution channels like Amazon's Kindle Store. A seamstress would contract for advertising services and for janitorial services for the store. Lots of work, but no employees.
My argument in favor of basic income is that starting all of that requires a certain stability. You can't start a contract software consulting business, or start writing full-time, or start a dressmaking store, if you're scrambling to keep food on the table and a roof over your family's head. You can't get a full-time job to cover the bills because those full-time jobs won't exist. So what's the alternative to a basic income if you want people to work? If it's not there they won't be able to afford to spare the concentrated effort needed to get a successful business off the ground, it'll all be sucked up by the scramble to get enough cash this week to buy groceries. If they put in the effort, their family'll be out on the streets and starving in the time it takes for the effort to start producing results.
There's no one single way, but there are several much more useful ways such that files created through Windows have the expected permissions in Cygwin (user read/write) and files created through Cygwin are accessible in Windows (user can read and write them). There's no excuse for the Linux subsystem not being able to do something reasonable. And yes I've dealt with Cygwin files in Windows and Windows files in Cygwin. It works because Cygwin understands Windows ACLs (see POSIX accounts, permission, and security). Amusingly the mapping system Cygwin uses was based on Microsoft's own mapping system from Services for Unix. So not only does Microsoft have the code for an example of a working method available (Cygwin's code), they wrote the code for a working method (SFU).
So basically MS's Linux subsystem can't even do the job Cygwin does quite nicely? I think MS ought to go and read the code, learn some lessons and carry it back. It's not like you can't translate Unix permissions to Windows' permissions system and vice-versa, the code's even right there to read.
Using a straight hosting service like Linode involves owning your own domain name, controlling the DNS and having your own SMTP and IMAP server running. That's all stuff that isn't specific to Linode, the same setup'll work on any service that offers virtual machine hosting. If Linode disconnects you you can drop your setup onto a host on Rackspace or any other service, update your DNS records to point to the new host's addresses and you're back in business. That's much easier than if you've no control over the domain, the DNS or the server software.
The bogosity meter just pegged.