With Project Treble now supported by all Android phone makers, in theory updates should roll out to us faster than before.
This is a rather interesting edit of a sentence from the actual linked article which says:
With Project Treble now supported by key Android flagships, in theory updates should roll out to us faster than ever before.
msmash, you do realize that the two versions do mot mean the same thing, right?
Whatever msmash did or didn't mean, here's the reality of the situation: Treble was mandated by Google for all devices that initially launched with Oreo (8.0) or later. If you buy a device that once ran Nougat or below, it probably doesn't support Treble. If you buy a newer device model that never ran anything pre-Oreo, it does.
Anyway nowadays it's hard to Root and get SuperUser and I don't understand why.
This is my fault. Not only mine, not even mostly mine, but definitely my team's fault -- and I, personally, have a little of the blame. So that makes me a good person to explain.
First, let me point out that my teammates and I have no interest in preventing you from rooting your device. None whatsoever. We are skeptical that you can make good use of root without compromising your own security, but we also believe that if you want to compromise your security, you should be free to do so!
So, if we don't hate rooting, why have we made it hard?
We haven't, exactly. Let me explain.
Let's start with the bootloader. If your device has a locked bootloader (note that this is completely different from carrier locking, AKA SIM locking, which is what people usually mean when they talk about an Android device that is locked or unlocked), then you may not install your own software on it. All of the devices from Google ship with bootloaders that can be unlocked, because we think people should be able to do what they want with their devices. Most other Android device makers feel differently about this and ship bootloaders that cannot be unlocked. Some of them will sell you a "developer edition" that is unlockable.
It's always been this way. Nexus/Pixel devices have always been unlockable, most others have not. Those G1s you were rooting almost certainly did not have unlockable bootloaders. So... how did you root them?
You exploited vulnerabilities. There were lots of them. There was no software integrity checking, so once you exploited a vulnerability you were able to modify the system and keep it in the exploited state.
These vulnerabilities were nice for you because they let you root. They were also nice for anyone who wanted to hack into your phone and get your personal data out. Useful to good guys, but also to bad guys. On balance, that's a bad thing.
What we did was to fix a lot of vulnerabilities. Not all; no software system of substantial size will ever be free of vulnerabilities. Recognizing that, we built defense in depth. SELinux is a big component of this defense in depth. Today in Android it's almost unheard of to find a single vulnerability that allows the attacker to pwn the entire system. Vulnerabilities still exist, but now attackers need long exploit chains. They use one vulnerability to open a chink in a part of the system that then lets them find and exploit another vulnerability, and so on, until they finally get to the data they're trying to get, or -- better yet -- pop the kernel. Root isn't good enough any more; for free reign of the system you need to pop the kernel and disable SELinux. Today's exploit chains often use five to ten separate vulnerabilities, because less than that doesn't do you any good. Working exploit chains for major device models sell for $1M+ on black markets. That's because they're hard to find.
In addition to that, we also added verified boot, so that every piece of the system software is validated as its loaded. This means that once you find and exploit a long chain of vulnerabilities to get control, you can't just change the system software so that you always have it, because if you modify the system the device won't work any more. You have to re-exploit the vulnerabilities after every boot. (Note that a new class of techniques makes so-called "systemless root" possible; which gives you persistent root without changing the system. We're shutting those down, too.)
In addition to that, we got much more aggressive about making device makers patch the vulnerabilities. So if you find a sequence of vulns that gets you control, you'd better keep it secret or it'll stop working after the next update. Oh, and we also made it basically impossible to install an older version of the software to get back to a version that had known vulnerabilities you could use.
I max out my 401k every year (limit is up to $19k this year btw) and put money in an IRA (limit is $6k this year) and invest directly on top of that.
You should see if whoever runs your 401K supports the Roth mega backdoor.
The idea is that you can contribute after-tax money to your 401K, which goes into a normal after-tax investment account. But... then you can "recharacterize" that as a Roth contribution. You can do this with up to $37K annually. I'm sure you're aware, but for those who aren't: Roth IRA contributions are taxed now, but tax-free when you withdraw them after retirement. Not just your original contributions but any capital gains are tax-free as well.
Also, you should seriously consider finding a job you like better. Figure out what makes a job more fulfilling for you -- better co-workers, more impactful projects, more interesting work, whatever -- and go find that. Also keep saving because I'm with you that not working is better than working, but given the amount of your life you spend working, enjoying it at least somewhat should be a high priority.
The shutdown is handled in an unprofessional way. It starts by giving us bogus reasons. If the API is the problem, fix it or disable it and the problem is solved. But the shutdown is not even close to a logical conclusion. They have other reasons but decide to give us just PR bullsh*t.
I think the API was the reason, in the sense that it was the straw that broke the camel's back. It pushed G+ from being a minor waste of engineering resources to a potential PR disaster which would have required significant investment.
I don't think fixing the API (which is actually pretty hard) was ever a realistic option. I think the choice was between shutting down the public-facing APIs entirely and shutting down the whole thing.
For as much as I might not like Microsoft, at least their enterprise products have a chance of existing in a couple of years time and have an upgrade path, I can't honestly say the same for Google.
You can say that for Google enterprise products. Most anything you pay real money for, actually. Note that Hangouts is not going away, it's becoming an enterprise-only tool.
You know what I blame this on most? Their real names policy. The web already had a social network which required real names, called Facebook. It didn't require another.
At the time the motivation for the policy was prevention of trolling and hate speech. Remember that Google already had one social media site when it launched G+ -- YouTube. And YouTube comments were an utter cesspool (and are only a little better today). The theory was that if people had to post under their real names, they would behave more like they do in the real world, which almost never includes spewing bile at random strangers. I don't think this theory is correct, but it did appear to work for quite a while.
Google users were used to going by a psuedonym (Google hates anonymity so much it refused to even autocomplete that word...)
Google doesn't hate anonymity or pseudonymity (and that word didn't automplete because you spelled it wrong -- it's pseudonym, not psuedonym).
Quantity is not quality.
FB is the home of memes. G+ was the home of quite a few interesting discussions.. To be honest, I much preferred G+, the problem being not enough of my friends used it, as they already had Facebook, which I can entirely understand.
In other-words, it was a ghost town.
Sure, in the same sense that New York City is a ghost town, because only a tiny percentage of the global population lives there. G+ was very engaging and active for users who used it to explore interests and make new friends. It wasn't very effective for those looking to connect with their existing real-life friends.
I would think that a project as mature a Google+ wouldn't cost too much to maintain, specially for company the size of Google.
You'd be wrong. Running any decent social media system is a constant battle against spam and ToS-violating content. Unless you want your system to become an ad-ridden cesspool, it takes constant work to adapt systems, policies and processes to the changing strategies of the spammers, pornographers, trolls, etc.
In addition, any system in Google requires constant attention to maintain, even when the system itself doesn't have to change at all. This is a consequence of Google's internal source management and architecture policies. With only a few exceptions, all of Google runs from HEAD (well, very close to HEAD), and has a single-version policy for libraries, tools (e.g. compilers, build system) and infrastructure components (e.g. storage and messaging). So there's a significant level of work required to adapt to the changing environment. This work is usually not performed by the project team, because that would impose constantly-fluctuating engineering resource demands on the team and make it difficult for them to plan their own forward progress. Instead, it's performed by the teams that build the infrastructure components and maintain the libraries. When they decide to make a change in, for example, the core C++ libraries, or upgrade a compiler, or update a third-party library, they have to update all of the project code that depends on their changes.
This is feasible because Google uses a single source repository which all engineers have access to, and because Google has a centralized build system and test infrastructure. So an engineer who changes a library can issue a single command that will rebuild every Google system and run all of their automated tests, to see what breaks. There is also tooling that enables automating changes to code across hundreds of projects and facilitates the management of very large numbers of change lists (commits, or perhaps pull requests, in git terminology). Of course, those change lists have to be approved by project owners before they're merged, so there is some effort required of the project teams, to read and approve.
For bigger, systemic changes, like, say, replacing one storage infrastructure component with another, the process is different. The replacement is built and deployed in a mostly-functional state and then the announcement is made that the to-be-replaced component is deprecated. Project teams then have to build their own migration plans and strategies. For complex and important components, the time between deprecation and turndown is measured in years, so the transition generally isn't urgent, but it does have to be made eventually. A common jokey lament among Google engineers is that for whatever you need to do there are always two options in Google: one that's deprecated and one that's incomplete. Sometimes this complaint is less of a joke and more of a problem, but it's so often true that everyone gets the joke.
The upshot of this is that even a mature, stable system that isn't actively being changed requires significant ongoing code maintenance as the foundations on which it rests are continually rebuilt to accommodate the needs of other projects. Even if most of this work isn't done by the project team, it still has to be done, so there's pressure from the infrastructure teams to shut down under-performing projects to reduce their workload and increase their agility.
The benefit of running from HEAD and enforcing the single-version policy is elimination of dependency hell, reduced fragmentation, reduced server memory use and greater agility. The downside is that mature, stable projects cannot simply be left to run without engineering staff, and even a skeleton crew is often insufficient. That, combined with the fact that such projects find it difficult to retain staff, who tend to move to other teams doing more exciting work (like building the umpteenth chat clie
Rust is an interesting language. It's the first credible attempt to displace C++ in areas where C++ is king.
There are areas where the utterly borked C++ is king?
Lots and lots of them. Basically anywhere you need the low-level performance and control of C, but need the greater productivity provided by an object-oriented language.
That language is so badly designed it is staggering.
C++ wasn't designed so much as accreted. However, if you look at modern C++, there is a smaller, cleaner, safer language emerging. Using it requires discipline since you need to avoid all of the other stuff that's still there because it can't be taken away. I'm actually really enjoying C++ since C++11, and it's still getting better.
That said, I'm also very interested in Rust as an alternative. It seems to hit the same targets as C++, and it doesn't carry C++'s baggage.
Your first error was in assuming C++ is replaceable. You can stop using C++ and use something else because C++ is good at one thing and better than anything else at that one thing. Don't want C++? Choose the best choice. You don't use a language to replace another language. You use a language because its what you want.
Nonsense.
For any given context, there is no single perfect language. There are always different options, with various pros and cons. And as the options and the context both change over time, it often does begin to make sense to replace one language with another. The value of the new language has to be very significant to justify rewriting working code, though.
Those polls that are completely and utterly useless in pretty much every respect? Wake me up when something newsworthy happens.
The fact that Trump is both sufficiently egotistical and sufficiently amoral to try to manipulate the poll results is newsworthy, or would be if we didn't already have a thousand other data points regarding the man's narcissism and lack of moral fiber. And ineffectiveness, since he obviously failed.
On second thought, you're right. Old news. Carry on.
When I read the summary I wondered whether the researchers involved had a track record of interesting work in this area, or in cryptography more generally. It took some searching but I found the list of names here: https://dtr.org/research/#rese....
FWIW, neither I nor my academic cryptographer friends immediately recognized any of these people. I do see that Andrew Miller is on the ZCash board, which gives him some credibility in my book.
That I don't recognize them doesn't mean that much, but I'd be more inclined to follow this work closely if it were done by people with a solid track record in the space. Time will tell.
The repeated search history and patterns add up to the discovery of the person.
A VPN does not change the words used to search. Its just a new IP every search.
The terms used to search are the key to tracking a person not just their ISP/IP.
If it's a different IP and a private/incognito tab, there's no way to connect one search to another, so no way to link them to a person, and therefore no way to "discover" a person.
60, but, yes, a supermajority. Unless the leadership chooses to change the rules, which they can do with a simple majority -- or a tie, if they have the VP on their side, which they did.
My statement was based on the DV vs. EV thing. However you make a great point about the current lack of indication in browsers for EV certificates. I had not noticed that such indication has gone away.
Yeah, it took me a long time to notice it, too. And that, of course, demonstrates that it was useless. If even the people who understand it don't notice whether the EV indication is present, it clearly isn't accomplishing anything.
Am I the only person that finds it oddly predictable that, in response to a story about TLS, almost every single comment is a biased (one way or the other) comment about "the Wall" or the Donald or the Problem with America Today.
Just for you, I wrote several posts about certificate validation levels:-)
Cert expiration is a problem mostly because certificates cannot be renewed. They must be replaced, and as close to expiration as possible. If only there were a way to push the expiration out.. maybe by having a replacement cert, or a see-next-instance logic.
I think the Let's Encrypt approach is good. Automated, frequent replacement -- Let's Encrypt certs are only valid for 90 days which would be a huge pain if the update process weren't fully automated.
But from the US Government's perspective, you need more than that.
Extended validation certificates only have value if users know and care. Specifically, if they distrust and avoid sites without extended validation. But users don't know, and don't care. To a user there is absolutely no difference between a domain validated and an extended validation certificate. Browsers don't even bother displaying any visual indicator of the difference any more, because users didn't notice it when they did.
Putting a certificate on a website does two main things: 1) Allows the traffic to be encrypted, and 2) Provides assurance to people using the website that the website is genuine. Let's Encrypt only does the first thing - allows encryption.
False.
There are three levels of certificate validation: Domain Validated (DV), Organization Validated (OV) and Extended Validation (EV).
Let's Encrypt provides DV certificates. If you visit www.foo.com and it has a Let's Encrypt certificate, you not only know that your data is encrypted, but you also know that you're connected to the actual www.foo.com, and not someone spoofing the domain.
No one uses OV certificates, which require that the issuing CA do some basic due diligence to validate that the business or other organization behind the web site really exists and is the one requesting the cert.
Extended Validation certificates require much more extensive verification, and in theory this gives users more confidence that the sites are trustworthy. In practice, no one cares. It used to be that browsers gave a visual indicator for sites with EV certificates, but studies showed that users didn't notice (quick, without testing: Do you know if your browser displays EV sites differently from OV/DV sites, and how?), so browsers have largely stopped bothering.
Some government sites do use EV certs. I just checked a few and found that whitehouse.gov and irs.gov do, but nasa.gov does not. And none of them should bother. EV certs are a waste of time and money.
Airports aren't mandated to use TSA. Some airports (San Francisco International for example) have private organizations performing the passenger screening.
How credulous do you have to be to think a survey like this means anything? Might as well ask, "Who here doesn't want to get fired?" Damn.
Meh. Typically these surveys are anonymous, and collected and analyzed at a high level, over large groups, so there's no way to figure out who said what.
Not always, though. Google's annual internal employee survey is confidential but not anonymous, and people answer quite honestly because they know that there will be no negative consequences for them. If an area of the survey shows lots of negative responses, it's just a signal that that's an area where something needs to be improved.
Further, Google has an internal ongoing longitudinal study called gDNA that asks very invasive questions and is also confidential but not anonymous, because they want to compare peoples' responses over time. Much of it is about life and job satisfaction, but it also includes a lot of standard psychological tests which attempt to gauge personality, work style, personal attributes, capabilities, aspirations, etc., and these things are explicitly correlated against job performance. It's intended as an "work life" analogue of the Framingham Heart Study; a long-term (planned duration is 100 years), in-depth research project into how employee life and job satisfaction, personal characteristics and job performance correlate.
This sort of thing is obviously potentially very risky for the employee, but everyone I know that participates (I do; I've filled out all but two of the twelve semi-annual surveys so far) answers honestly and fully. The HR team that runs the study takes confidentiality seriously, and employees are confident we can trust them -- which means HR can have confidence in our honesty. Participants get feedback on their personalized study results, including how they compare to coworkers in their product area and across Google. This is usually interesting and sometimes even useful information.
Anyway, my point is that it's absolutely possible to get useful information from employee surveys. You just have to make sure that all of the employees can be confident that any "negative" responses won't be used against them individually, and might be used to make their jobs better, and/or give them ideas about how they can improve their performance and life and job satisfaction.
They intentionally collected mass amounts of data, for the sole purpose of tracking and distributing that data to other companies. If they didn't want the data shared they would of either not collected it, or made the data functionally useless to the other parties, through encryption, hashing or other means of obfuscation.
I'm confused... who is the "they" you're referring to? Google didn't collect the data, T-Mobile and Sprint did. Google asked them not to sell it.
Why did Paul Ryan and Mitch McConnell want to prevent him from getting that key campaign promise through?
Couple things. Paul Ryan delivered on the $5.7 but the Senate didn't have enough votes (10 democrats).
10 Democrats what? The Republicans had a clear Senate majority, as well as the tie-breaking vote. The bill could have been passed without a single Democrat voting for it, they could even have survived four defections... but they had a lot more than that, didn't they?
By waiting till after the election (especially after losing the House) McConnell, Trump, and Ryan have made the division in government clear.
You should re-read your own post. They haven't made the division clear, they're trying to pull a fast one and make it look like it's GOP vs Dems, when really it's Trump vs an alliance of part of the GOP & the Dems. The narrative that "Trump fights his own party" is, in fact, the truth with respect to wall funding (as well as some other areas). Also, "never Trump" is a mischaracterization of Flake and others who supported plenty of Trump's initiatives. Those GOP members aren't "never Trump", they just aren't "always Trump", and in Trump's narrative you're either with him or against him; there's no room for nuanced disagreement.
FWIW, I'm a Republican-leaning libertarian who rarely agrees with Trump, but believes that even when he's right he's still bad for the country.
the democrats are not acting based on principle but rather "Never Trump".
Actually, I think it's both. Even without the Trump hatred I still don't think the Democrats would want to fund this boondoggle of a wall. It goes against their principles, even though they rarely see a government program they don't love. I could be wrong, of course; heaven knows both parties have funded untold boondoggles.
Slashdot Mirror
With Project Treble now supported by all Android phone makers, in theory updates should roll out to us faster than before.
This is a rather interesting edit of a sentence from the actual linked article which says:
With Project Treble now supported by key Android flagships, in theory updates should roll out to us faster than ever before.
msmash, you do realize that the two versions do mot mean the same thing, right?
Whatever msmash did or didn't mean, here's the reality of the situation: Treble was mandated by Google for all devices that initially launched with Oreo (8.0) or later. If you buy a device that once ran Nougat or below, it probably doesn't support Treble. If you buy a newer device model that never ran anything pre-Oreo, it does.
Anyway nowadays it's hard to Root and get SuperUser and I don't understand why.
This is my fault. Not only mine, not even mostly mine, but definitely my team's fault -- and I, personally, have a little of the blame. So that makes me a good person to explain.
First, let me point out that my teammates and I have no interest in preventing you from rooting your device. None whatsoever. We are skeptical that you can make good use of root without compromising your own security, but we also believe that if you want to compromise your security, you should be free to do so!
So, if we don't hate rooting, why have we made it hard?
We haven't, exactly. Let me explain.
Let's start with the bootloader. If your device has a locked bootloader (note that this is completely different from carrier locking, AKA SIM locking, which is what people usually mean when they talk about an Android device that is locked or unlocked), then you may not install your own software on it. All of the devices from Google ship with bootloaders that can be unlocked, because we think people should be able to do what they want with their devices. Most other Android device makers feel differently about this and ship bootloaders that cannot be unlocked. Some of them will sell you a "developer edition" that is unlockable.
It's always been this way. Nexus/Pixel devices have always been unlockable, most others have not. Those G1s you were rooting almost certainly did not have unlockable bootloaders. So... how did you root them?
You exploited vulnerabilities. There were lots of them. There was no software integrity checking, so once you exploited a vulnerability you were able to modify the system and keep it in the exploited state.
These vulnerabilities were nice for you because they let you root. They were also nice for anyone who wanted to hack into your phone and get your personal data out. Useful to good guys, but also to bad guys. On balance, that's a bad thing.
What we did was to fix a lot of vulnerabilities. Not all; no software system of substantial size will ever be free of vulnerabilities. Recognizing that, we built defense in depth. SELinux is a big component of this defense in depth. Today in Android it's almost unheard of to find a single vulnerability that allows the attacker to pwn the entire system. Vulnerabilities still exist, but now attackers need long exploit chains. They use one vulnerability to open a chink in a part of the system that then lets them find and exploit another vulnerability, and so on, until they finally get to the data they're trying to get, or -- better yet -- pop the kernel. Root isn't good enough any more; for free reign of the system you need to pop the kernel and disable SELinux. Today's exploit chains often use five to ten separate vulnerabilities, because less than that doesn't do you any good. Working exploit chains for major device models sell for $1M+ on black markets. That's because they're hard to find.
In addition to that, we also added verified boot, so that every piece of the system software is validated as its loaded. This means that once you find and exploit a long chain of vulnerabilities to get control, you can't just change the system software so that you always have it, because if you modify the system the device won't work any more. You have to re-exploit the vulnerabilities after every boot. (Note that a new class of techniques makes so-called "systemless root" possible; which gives you persistent root without changing the system. We're shutting those down, too.)
In addition to that, we got much more aggressive about making device makers patch the vulnerabilities. So if you find a sequence of vulns that gets you control, you'd better keep it secret or it'll stop working after the next update. Oh, and we also made it basically impossible to install an older version of the software to get back to a version that had known vulnerabilities you could use.
That's a small taste; a lot m
I max out my 401k every year (limit is up to $19k this year btw) and put money in an IRA (limit is $6k this year) and invest directly on top of that.
You should see if whoever runs your 401K supports the Roth mega backdoor.
The idea is that you can contribute after-tax money to your 401K, which goes into a normal after-tax investment account. But... then you can "recharacterize" that as a Roth contribution. You can do this with up to $37K annually. I'm sure you're aware, but for those who aren't: Roth IRA contributions are taxed now, but tax-free when you withdraw them after retirement. Not just your original contributions but any capital gains are tax-free as well.
Also, you should seriously consider finding a job you like better. Figure out what makes a job more fulfilling for you -- better co-workers, more impactful projects, more interesting work, whatever -- and go find that. Also keep saving because I'm with you that not working is better than working, but given the amount of your life you spend working, enjoying it at least somewhat should be a high priority.
It's your value system that's suspect.
Valuing entertainment is suspect?
Treat every Google product you use as if it may disappear into the ether tomorrow.
Unless you pay for it.
The shutdown is handled in an unprofessional way. It starts by giving us bogus reasons. If the API is the problem, fix it or disable it and the problem is solved. But the shutdown is not even close to a logical conclusion. They have other reasons but decide to give us just PR bullsh*t.
I think the API was the reason, in the sense that it was the straw that broke the camel's back. It pushed G+ from being a minor waste of engineering resources to a potential PR disaster which would have required significant investment.
I don't think fixing the API (which is actually pretty hard) was ever a realistic option. I think the choice was between shutting down the public-facing APIs entirely and shutting down the whole thing.
For as much as I might not like Microsoft, at least their enterprise products have a chance of existing in a couple of years time and have an upgrade path, I can't honestly say the same for Google.
You can say that for Google enterprise products. Most anything you pay real money for, actually. Note that Hangouts is not going away, it's becoming an enterprise-only tool.
You know what I blame this on most? Their real names policy. The web already had a social network which required real names, called Facebook. It didn't require another.
At the time the motivation for the policy was prevention of trolling and hate speech. Remember that Google already had one social media site when it launched G+ -- YouTube. And YouTube comments were an utter cesspool (and are only a little better today). The theory was that if people had to post under their real names, they would behave more like they do in the real world, which almost never includes spewing bile at random strangers. I don't think this theory is correct, but it did appear to work for quite a while.
Google users were used to going by a psuedonym (Google hates anonymity so much it refused to even autocomplete that word...)
Google doesn't hate anonymity or pseudonymity (and that word didn't automplete because you spelled it wrong -- it's pseudonym, not psuedonym).
Quantity is not quality. FB is the home of memes. G+ was the home of quite a few interesting discussions.. To be honest, I much preferred G+, the problem being not enough of my friends used it, as they already had Facebook, which I can entirely understand.
In other-words, it was a ghost town.
Sure, in the same sense that New York City is a ghost town, because only a tiny percentage of the global population lives there. G+ was very engaging and active for users who used it to explore interests and make new friends. It wasn't very effective for those looking to connect with their existing real-life friends.
I would think that a project as mature a Google+ wouldn't cost too much to maintain, specially for company the size of Google.
You'd be wrong. Running any decent social media system is a constant battle against spam and ToS-violating content. Unless you want your system to become an ad-ridden cesspool, it takes constant work to adapt systems, policies and processes to the changing strategies of the spammers, pornographers, trolls, etc.
In addition, any system in Google requires constant attention to maintain, even when the system itself doesn't have to change at all. This is a consequence of Google's internal source management and architecture policies. With only a few exceptions, all of Google runs from HEAD (well, very close to HEAD), and has a single-version policy for libraries, tools (e.g. compilers, build system) and infrastructure components (e.g. storage and messaging). So there's a significant level of work required to adapt to the changing environment. This work is usually not performed by the project team, because that would impose constantly-fluctuating engineering resource demands on the team and make it difficult for them to plan their own forward progress. Instead, it's performed by the teams that build the infrastructure components and maintain the libraries. When they decide to make a change in, for example, the core C++ libraries, or upgrade a compiler, or update a third-party library, they have to update all of the project code that depends on their changes.
This is feasible because Google uses a single source repository which all engineers have access to, and because Google has a centralized build system and test infrastructure. So an engineer who changes a library can issue a single command that will rebuild every Google system and run all of their automated tests, to see what breaks. There is also tooling that enables automating changes to code across hundreds of projects and facilitates the management of very large numbers of change lists (commits, or perhaps pull requests, in git terminology). Of course, those change lists have to be approved by project owners before they're merged, so there is some effort required of the project teams, to read and approve.
For bigger, systemic changes, like, say, replacing one storage infrastructure component with another, the process is different. The replacement is built and deployed in a mostly-functional state and then the announcement is made that the to-be-replaced component is deprecated. Project teams then have to build their own migration plans and strategies. For complex and important components, the time between deprecation and turndown is measured in years, so the transition generally isn't urgent, but it does have to be made eventually. A common jokey lament among Google engineers is that for whatever you need to do there are always two options in Google: one that's deprecated and one that's incomplete. Sometimes this complaint is less of a joke and more of a problem, but it's so often true that everyone gets the joke.
The upshot of this is that even a mature, stable system that isn't actively being changed requires significant ongoing code maintenance as the foundations on which it rests are continually rebuilt to accommodate the needs of other projects. Even if most of this work isn't done by the project team, it still has to be done, so there's pressure from the infrastructure teams to shut down under-performing projects to reduce their workload and increase their agility.
The benefit of running from HEAD and enforcing the single-version policy is elimination of dependency hell, reduced fragmentation, reduced server memory use and greater agility. The downside is that mature, stable projects cannot simply be left to run without engineering staff, and even a skeleton crew is often insufficient. That, combined with the fact that such projects find it difficult to retain staff, who tend to move to other teams doing more exciting work (like building the umpteenth chat clie
Rust is an interesting language. It's the first credible attempt to displace C++ in areas where C++ is king.
There are areas where the utterly borked C++ is king?
Lots and lots of them. Basically anywhere you need the low-level performance and control of C, but need the greater productivity provided by an object-oriented language.
That language is so badly designed it is staggering.
C++ wasn't designed so much as accreted. However, if you look at modern C++, there is a smaller, cleaner, safer language emerging. Using it requires discipline since you need to avoid all of the other stuff that's still there because it can't be taken away. I'm actually really enjoying C++ since C++11, and it's still getting better.
That said, I'm also very interested in Rust as an alternative. It seems to hit the same targets as C++, and it doesn't carry C++'s baggage.
Your first error was in assuming C++ is replaceable. You can stop using C++ and use something else because C++ is good at one thing and better than anything else at that one thing. Don't want C++? Choose the best choice. You don't use a language to replace another language. You use a language because its what you want.
Nonsense.
For any given context, there is no single perfect language. There are always different options, with various pros and cons. And as the options and the context both change over time, it often does begin to make sense to replace one language with another. The value of the new language has to be very significant to justify rewriting working code, though.
Those polls that are completely and utterly useless in pretty much every respect? Wake me up when something newsworthy happens.
The fact that Trump is both sufficiently egotistical and sufficiently amoral to try to manipulate the poll results is newsworthy, or would be if we didn't already have a thousand other data points regarding the man's narcissism and lack of moral fiber. And ineffectiveness, since he obviously failed.
On second thought, you're right. Old news. Carry on.
When I read the summary I wondered whether the researchers involved had a track record of interesting work in this area, or in cryptography more generally. It took some searching but I found the list of names here: https://dtr.org/research/#rese....
FWIW, neither I nor my academic cryptographer friends immediately recognized any of these people. I do see that Andrew Miller is on the ZCash board, which gives him some credibility in my book.
That I don't recognize them doesn't mean that much, but I'd be more inclined to follow this work closely if it were done by people with a solid track record in the space. Time will tell.
The repeated search history and patterns add up to the discovery of the person. A VPN does not change the words used to search. Its just a new IP every search. The terms used to search are the key to tracking a person not just their ISP/IP.
If it's a different IP and a private/incognito tab, there's no way to connect one search to another, so no way to link them to a person, and therefore no way to "discover" a person.
60, but, yes, a supermajority. Unless the leadership chooses to change the rules, which they can do with a simple majority -- or a tie, if they have the VP on their side, which they did.
My statement was based on the DV vs. EV thing. However you make a great point about the current lack of indication in browsers for EV certificates. I had not noticed that such indication has gone away.
Yeah, it took me a long time to notice it, too. And that, of course, demonstrates that it was useless. If even the people who understand it don't notice whether the EV indication is present, it clearly isn't accomplishing anything.
Am I the only person that finds it oddly predictable that, in response to a story about TLS, almost every single comment is a biased (one way or the other) comment about "the Wall" or the Donald or the Problem with America Today.
Just for you, I wrote several posts about certificate validation levels :-)
Cert expiration is a problem mostly because certificates cannot be renewed. They must be replaced, and as close to expiration as possible. If only there were a way to push the expiration out.. maybe by having a replacement cert, or a see-next-instance logic.
I think the Let's Encrypt approach is good. Automated, frequent replacement -- Let's Encrypt certs are only valid for 90 days which would be a huge pain if the update process weren't fully automated.
But from the US Government's perspective, you need more than that.
Extended validation certificates only have value if users know and care. Specifically, if they distrust and avoid sites without extended validation. But users don't know, and don't care. To a user there is absolutely no difference between a domain validated and an extended validation certificate. Browsers don't even bother displaying any visual indicator of the difference any more, because users didn't notice it when they did.
That really depends on the end user.
What percentage of end users examine the certificate of sites they visit? Do you?
Putting a certificate on a website does two main things: 1) Allows the traffic to be encrypted, and 2) Provides assurance to people using the website that the website is genuine. Let's Encrypt only does the first thing - allows encryption.
False.
There are three levels of certificate validation: Domain Validated (DV), Organization Validated (OV) and Extended Validation (EV).
Let's Encrypt provides DV certificates. If you visit www.foo.com and it has a Let's Encrypt certificate, you not only know that your data is encrypted, but you also know that you're connected to the actual www.foo.com, and not someone spoofing the domain.
No one uses OV certificates, which require that the issuing CA do some basic due diligence to validate that the business or other organization behind the web site really exists and is the one requesting the cert.
Extended Validation certificates require much more extensive verification, and in theory this gives users more confidence that the sites are trustworthy. In practice, no one cares. It used to be that browsers gave a visual indicator for sites with EV certificates, but studies showed that users didn't notice (quick, without testing: Do you know if your browser displays EV sites differently from OV/DV sites, and how?), so browsers have largely stopped bothering.
Some government sites do use EV certs. I just checked a few and found that whitehouse.gov and irs.gov do, but nasa.gov does not. And none of them should bother. EV certs are a waste of time and money.
Airports aren't mandated to use TSA. Some airports (San Francisco International for example) have private organizations performing the passenger screening.
Only under TSA supervision. https://www.law.cornell.edu/us...
How credulous do you have to be to think a survey like this means anything? Might as well ask, "Who here doesn't want to get fired?" Damn.
Meh. Typically these surveys are anonymous, and collected and analyzed at a high level, over large groups, so there's no way to figure out who said what.
Not always, though. Google's annual internal employee survey is confidential but not anonymous, and people answer quite honestly because they know that there will be no negative consequences for them. If an area of the survey shows lots of negative responses, it's just a signal that that's an area where something needs to be improved.
Further, Google has an internal ongoing longitudinal study called gDNA that asks very invasive questions and is also confidential but not anonymous, because they want to compare peoples' responses over time. Much of it is about life and job satisfaction, but it also includes a lot of standard psychological tests which attempt to gauge personality, work style, personal attributes, capabilities, aspirations, etc., and these things are explicitly correlated against job performance. It's intended as an "work life" analogue of the Framingham Heart Study; a long-term (planned duration is 100 years), in-depth research project into how employee life and job satisfaction, personal characteristics and job performance correlate.
This sort of thing is obviously potentially very risky for the employee, but everyone I know that participates (I do; I've filled out all but two of the twelve semi-annual surveys so far) answers honestly and fully. The HR team that runs the study takes confidentiality seriously, and employees are confident we can trust them -- which means HR can have confidence in our honesty. Participants get feedback on their personalized study results, including how they compare to coworkers in their product area and across Google. This is usually interesting and sometimes even useful information.
Anyway, my point is that it's absolutely possible to get useful information from employee surveys. You just have to make sure that all of the employees can be confident that any "negative" responses won't be used against them individually, and might be used to make their jobs better, and/or give them ideas about how they can improve their performance and life and job satisfaction.
They intentionally collected mass amounts of data, for the sole purpose of tracking and distributing that data to other companies. If they didn't want the data shared they would of either not collected it, or made the data functionally useless to the other parties, through encryption, hashing or other means of obfuscation.
I'm confused... who is the "they" you're referring to? Google didn't collect the data, T-Mobile and Sprint did. Google asked them not to sell it.
Why did Paul Ryan and Mitch McConnell want to prevent him from getting that key campaign promise through?
Couple things. Paul Ryan delivered on the $5.7 but the Senate didn't have enough votes (10 democrats).
10 Democrats what? The Republicans had a clear Senate majority, as well as the tie-breaking vote. The bill could have been passed without a single Democrat voting for it, they could even have survived four defections... but they had a lot more than that, didn't they?
By waiting till after the election (especially after losing the House) McConnell, Trump, and Ryan have made the division in government clear.
You should re-read your own post. They haven't made the division clear, they're trying to pull a fast one and make it look like it's GOP vs Dems, when really it's Trump vs an alliance of part of the GOP & the Dems. The narrative that "Trump fights his own party" is, in fact, the truth with respect to wall funding (as well as some other areas). Also, "never Trump" is a mischaracterization of Flake and others who supported plenty of Trump's initiatives. Those GOP members aren't "never Trump", they just aren't "always Trump", and in Trump's narrative you're either with him or against him; there's no room for nuanced disagreement.
FWIW, I'm a Republican-leaning libertarian who rarely agrees with Trump, but believes that even when he's right he's still bad for the country.
the democrats are not acting based on principle but rather "Never Trump".
Actually, I think it's both. Even without the Trump hatred I still don't think the Democrats would want to fund this boondoggle of a wall. It goes against their principles, even though they rarely see a government program they don't love. I could be wrong, of course; heaven knows both parties have funded untold boondoggles.