No. In your scenario, whether the 64-bit time is positive or negative, the called function will attempt to write the full 64 bits back into the 32-bit variable, thus overwriting the following 4 bytes. CPUs don't think to themselves, "Hmm, this is a positive 64-bit value that could fit into 32 bits, so I'll only store 32 bits."
This is inaccurate. The value is being passed by address to a a function that increments it or decrements it as a result of a "settings wheel". So it's basically doing math on the value passed by address.
Unless the math messes with something outside the low order 32 bits, it really doesn't matter what the increment or decrement does to them, it won't dick with the other 32 bits which aren't where they are expected to be.
As a bonus: This likely is not a problem on 32 bit hardware; you should try it on a non-64 bit Apple device and see if it causes problems there, too. My bet is that it will not.
Anyone who is going to be so fucking stupid as to think worse of you simply for a family member giving you a silly endorsement on LinkedIn is a pretentious dumbshit anyway.
Or they just are going to take everything you say with a grain of salt, if it's pretty clear you are getting your family members to inflate your endorsement numbers. That's not being a pretentious dumbshit, that's simply not being a dumbshit, period. Either I can trust the numbers, because I can trust the people endorsing you, or I can't trust the numbers.
I'm pretty sure that if you're applying for a position as biologist, it's statistically improbable that all the members of your immediate and extended family are also biologists, and therefore qualified to judge your ability, or have an opinion. In which case, I will scale my opinion of your ability (down) accordingly.
So how do you "test for correct behaviour of the products, overall"? It's not that hard to spell out -- and even automate -- the cases that a person expects to occur. The problem is accurately modeling the state space of the program and then figuring out which walks through it are incorrectly permitted. Even the most sophisticated known approaches fall down for the first part of that problem due to the vast size of an interesting program's state space.
Personally? If money were no object, I'd use software that cost thousands per engineer in about 1985 or so, but which is now sold as "McCabe IQ". By 1990 you could get three floating licenses for "only" $45,000 (not sure on the current precise price; it appears to *start* at $2,000.00/one-time/user, which generally means that a useful configuration would be more hefty in both price and capability than the "starter" version).
I'd use it to ensure that the requirements document is implemented by the software, and then do a branch path analysis on the resulting code to make sure that the test cases that get generated cover all possible code paths.
Given the substantial costs associated with the tools, most software engineers today have no exposure to *real* CASE tools (but if you care, you can obtain a 30 day free trial from them these days).
Obviously, it also possible to do this type of code coverage testing manually, but most test engineers are trained to do mostly ad hoc testing these days -- assuming you have actual test engineers on your project at all.
I made her delete the endorsement, on penalty of being delisted as a connection on LinkedIn if she did not do so, since there was no way in hell that she could legitimately claim domain knowledge for the endorsement, or lacking that, experience in an organization we were both in, justifying the endorsement on the basis of my past work.
This is the problem with associating with family members on professional, as opposed to things like Facebook, social networks: they think they are helping you, when really they are not.
While there are several organizations where we both worked simultaneously, they were all in the distant path. If she wanted to endorse me as an electrician or a telephone installer, or a small appliance repair person: yes, she has that domain knowledge. But that's not where I typically work these days, and it's not right for people to comment on things they don't know that way.
Probably, you should have just given your realtor the same speech I gave my sister, and in the limit, asked them to retract or to lose their connection to you, rather than just deleting your account.
My buzzspeak is a little rusty, but this sounds suspiciously like "Beat monkeys to code faster, send code out the door without testing, and just let the users figure it out". Did something get lost in translation?
Yeah.
They deploy to internal users -- LinkedIn employees -- via Enterprise Enrollment for iOS devices, and via Google Play’s alpha testing functionality and the developer console API. So it's not like they are sending the code without testing, and it appears that at any time, an internal user can torpedo a particular release candidate, so that what they end up with at the end of the week might be the same thing they had at the end of last week.
This still has a bunch of holes, just as any continuous integration process does, but at least by staging a 3 hour limit on things, they avoid falling into the trap that Google and Apple have leapt into willingly, where "it takes as long as it takes" to do integration acceptance testing.
In particular, both Google and Apple engage in reactionary testing paradigms. They build tests based on bugs they've previously encountered (because they are in fact able to test for those, since they've been well characterized during the process of being fixed), and stack them on top of all the previous tests.
This results in an ever-growing set of tests that test for regressions, but which do not test for correct behaviour of the products, overall. Instead, it lets you know when you've encountered a bug which you have previously encountered.
Further, since the testing is unbounded (and in fact, will stop the build process at Apple or Google by throwing a stick into the bicycle wheel of progress -- an event which is called "closing the tree", necessitates the existence of a "tree sheriff" role to deal with automated closures of the tree, and fails to automate the back-out of code leading to failure -- it leads to flaky tests.
The flaky tests come about because there's a human involved in making the decision, and in structuring the situation that way, with an unbounded closure interval -- practically bounded only by people showing up in your office (Apple) or open plan desk/cubicle (Google) and breathing down your neck -- there's a strong encouragement toward flaky tests, and there's a strong tendency do disempower the "tree sheriff" in favor of getting the expensive engineers back to work. And because of this, it's very hard to deep dive into flaky tests.
So we are left with the situation that flaky tests are both tolerated (as long as they are not "too flaky" -- or in Google-speak -- as long as they do not exhibit "too much 'jank' when run"), and the flaky tests do not get cleaned out eventually because the set of tests that you run are not pruned occasionally to run in bounded time, and if you try to do a deep dive to actually resolve the flakiness, you get the disapproval of your peers.
So a bounded time is a good thing, if you insist on having continuous integration, but it doesn't necessarily fix the other problems with continuous integration, and it doesn't fix the fact that most testing in organizations where engineers are involved in "agile methods", such as "Scrum Runs", where the primary goal is code base stabilization, rather than forward progress on the product for 2/3rds or more of the engineers time... well, combine that with an iterative process and it's a recipe for engineers who don't know about testing writing a lot of useless tests, because you are moving the goalposts on them iteratively anyway.
So they've done something relatively innovative, but it's probably not innovative enough. And it's probably an interesting experiment, but I would be wildly surprised if other organizations adopted their framework.
P.S.: The other problem with iterative models, particularly constant integration iterative models, is that you tend to only ever do evolutionary things, and never revolutionary things. There's not always a drunkards walk that gets you "from where we are" to "someplace new and fantastic". There are saddle points, and once you are in a saddle point, an iterative model will not get you out.
The problem is with a long or int (32 bit) value having its address passed in for a time_t (64 bit) value.
As long as the number is positive, it appears to work, but if it goes negative (and given that most of the people setting it to that date are West of GMT, it *will* go negative), then the underflow blows all the adjacent bits in the next 32 bit word over.
And it appears that something important was there. This will likely be a problem for the code after 19 January 2038, if that's the case.
This is why there should be strong type enforcement set in the compiler settings, to make sure it doesn't compile if you have this kind of bug in your code.
This should be a trivial fix, but it's pretty clear that you could fix the problem on your own by temporarily disconnecting the battery and/or letting the battery drain (which would likely take a very long time). So take it into your local Apple store and be done with it.
What about those of us with prosthetic hands who can't use touch screens for lack of capacitive coupling?
You know they have gloves with capacitive fingertips now so you can use such devices, right? They don't depend on your fingertip's capacitance. That's a solved problem.
Actually, it's a problem I solved for Bochs when I worked at Google. Because I had the need to solve the same problem for a robot that needed to be able to capacitively couple with touch devices. The gloves only work because they are conductively connected to a great big meat antenna (you), such that the cpacitive coupling works.
If you have an artificial limb, there's generally no electrical coupling to the meat antenna. So people with artificial limbs do not get to use touch devices.
The fix is to place a conductive film in the plasticine coating, and to hook it up to an antenna. It's a relatively simple hack, and you can pretty much use any WiFi or Cellular modem antenna from a laptop to do the trick.
And then, voila! Magically able to use touch screen devices. The prototype allowed a man in Germany to use the touchpad on his Lenovo Thinkpad for the first time in his life. Which meant he didn't have to carry a mouse around, since both his arms were prosthetic.
Yes, I am a genius. I'll even let you hire me if you have something interesting to work on. You probably don't.
We pushed crypto development to South Africa for FreeBSD back in the early 1990's to get around ITAR restrictions: "you can import, but you can't export".
We will happily route around this brain damage, too.
P.S.: The way to get better cryptographers in other countries is to make cryptographers criminals in the U.S.; obviously, it will not do fuck all to actually stop cryptography from happening, it'll just be that our people end up being shit at it compared to their people.
The underlying problem doesn't have to be resolved, because we can just ignore it by installing a bolder font than the one that uncovered the underlying problem in the first place by making it more obvious.
Does anyone else see this as a crap solution to the problem?
Does anyone else see the actual problem is people with bad vision trying to use eReaders?
What about those of us with prosthetic hands who can't use touch screens for lack of capacitive coupling? We should dumb down all of our devices so that the most handicapped among us can use them all. You know, instead of working to fix the handicaps or anything.
However, if I am designing an experiment, I try to limit any simultaneous changes to dependent variables.
That's not to say that I *won't* (I have) vary multiple independent variables at the same time, but if I do, I usually have at least a "hunch" that the direction I'm moving them both (all) is toward a saddle point.
Perhaps the person deciding this has already concluded the independence of the variables and the probable location of the saddle point. If so, good on them; from outside, I really haven't reached the same conclusion, but, alas, I do not have all of the data they have.
Which is why I stated my comment the way I did, rather than accusing them of bad judgement.
But I can't help but wonder in practice if it won't leave a lot of poor people with no internet access at all.
Sure, it's nice to have an even playing field. But when you're starving, do you really want the government telling McDonalds that they can't give you free food because that wouldn't be fair to Burger King?
This is the intent.
You didn't think that all the poor people with no internet access at all were the ones posting online about the lack of neutrality in the offering, did you? The people posting already have Internet access, and so the only impact on them would be:
(1) If they were one of the companies that refused to partner with Facebook, which means that they were unable to successfully compete in markets (e.g. job sites, etc.) where they were already underdogs, or
(2) They were ordinary Indians, more well off than the poor, who were suddenly forced to compete with well educated poor, who had the ability to apply for jobs which they coveted
(3) They were people who had to pay for their service, felt that if poor people received free service, they should too, and were upset that the free service was not as extensive as their current paid service
So it's basically a strategy to keep the target market segmentation of startup sites focussed on "not the poor", anti-competitive for labor, against the currently disenfranchised (keeping them that way), and people wanting their existing something for nothing, rather than a new thing that is a lesser something for nothing.
- 100% of the Falcon 9 Full Thrust landings have been successful. - 0% of the Falcon 9 v1.1 landings have been successful. - There has been one F9 FT flight so far. - The F9 FT has (among others) improved thrust (and thus more reserves for the return flight) and improved landing gear. - After the successful return of the F9 FT some things were noted about the FT drives and launches were pushed back 4-6 weeks as it looks right now.
Or the ground landing was a "Oops! We accidentally landed successfully! Let's blame the equipment! Back to the barge! Arrrrrr, maties!".
Multiple successful ground landings would have been good. But they aren't planning to refly the thing even if it's a successful landing at this point. But that does move us 3 launches to reuse from first landing to probably 6 launches to reuse. If they have money to burn on it because they are rolling it into launch costs, it makes sense to roll as much of it as you can into the costs before you end up being forced to drop the prices.
And yes, I know: being cheapest, they aren't "forced", but visible reuse would encourage others more, if it had corresponding visible cost reductions.
Why not use some sort of collar made of cables on some masts around the deck to support the top of the booster? When the booster come in, the hoop is wide open so as not to obstruct. As it passes though, the loop tightens and the booster is kept upright even if it tips. By the time it lands, the loops is snug against the top of the rocket and the booster is secure, even if the platform rocks.
That was actually my first reaction: "Oh, obviously it'll be something like 'this' that they'll be using...", the first time I heard they'd be landing them at all.
Then I got really annoyed at them not having something like that, and trying to land on a pitching platform.
The platform landings themselves make sense, particularly if you locate the launch and landing facilities out in international waters so that the world really has no say in whether or not you are allowed to launch and/or land, but really: there's a lot simpler tech that would work to avoid losing the things over and over again.
That said, once they get it right (assuming they ever do), and assuming the weather cooperates all the time, having solved the problem, the per launch additional equipment costs will be marginally lower than they would have been, had they gone with a "hug truss" system in the first place.
Personally, I was thinking they were going to do a least three dirt landings to give them a confidence interval and more data, since that data may change what they decide to do in the process of landing, which in turn might add complications to the water landings that they had not yet considered.
What about all the poor animals who have to live in the environment up there, polluted with space-junk? Particularly if that space junk ends up in their breeding grounds?
You know that they lifted the ban on second children last year, right? And that it never applied to everyone, just certain areas where there was overpopulation. Obviously many in the west would condemn their methods, but it isn't true to say that they have a problem with the rate that their population is expanding. They have it under control, at the rate they desire.
I'm well aware of the ban. It primary served to cause a rash of "SIDS" cases that left odd strangulation marks on female children. Ironically, given that there will be massive shortage of wives, and the families with daughters will pretty much be able to dowry for whatever they want. You would think that there would be a lot of efforts in the other direction, as a monetary investment.
As far as "at the rate they desire"... that rate being non-zero, that assumes that they are able to manufacture territory (which is what the comment was about) and support infrastructure (which was also what the comment was about).
I typed some of it, and pasted others, and manually formatted. I went to 5 sources.
A lot of countries have a lot of disputes; Taiwan is about as bad a China, actually, and there are areas of the Middle East that are pretty fired up, currently (particularly if you consider ISIS a state actor, rather than a marauding horde).
China needs to do more to keep NK under control, unless NK's games are tolerated by China for reasons unknown.
The reasons are far from unknown. China is currently grabbing as much territory as they can, anywhere they can:
Baekdu Mountain (North Korea) Bhutanese enclaves in Tibet (Bhutan) Demchok, Chumar, Kaurik, Shipki Pass, Jadh, and Lapthal (Taiwan, India) Hong Kong (Taiwan) Jiandao (North Korea, South Korea) Kula Kangri and points West, Haa District (Bhutan) Macclesfield Bank (Taiwan, Vietnam) Paracel Islands (Taiwan, Vietnam) Scarborough Shoal (Taiwan, Philippines) Senkaku Islands (Taiwan, Japan) Shaksgam Valley (India) Arunachal Pradesh (Taiwan, India) Spratly Islands (Taiwan, Vietnam, Philippines, Malaysia, Brunei) Taiwan (Taiwan) Eastern Bhutan (Taiwan, Bhutan) Mainland China, Hainan (Taiwan -- but the PRC has a pretty good claim here 8^)...) Western Heixiazi / Bolshoy Ussuriysky Island (Taiwan) Penghu, Jinmen,Matsu Islands, Pratas Islands (Taiwan) Songling District, Jiagedaqi District (Mongolia) Pamir Mountains (Tajikistan) Yalu River islands (North Korea, South Korea) Shaksgam Valley (India)
Anything that keeps peoples attention focussed elsewhere is all to the good, as far as China is concerned. The territorial waters claims in the South China Sea, in particular, are important to them in terms of extending their range of control, in order to control fishing rights, since their population is still rising, despite sterilizations after the second child, and similar measures.
It was a proxy for the ke ea Hawai‘i movement, which is a movement that is demanding some form of sovereignty for Hawaii. they have been around forever, and they make themselves a pain in the ass wherever they can in order to attempt to draw media attention to their cause.
Their favorite hobby horses are self-determination and self-governance, for Hawaii as an independent nation, or for people of native Hawaiian ancestry to obtain "tribal sovereignty" similar to the relationship with Native Americans, for Native Hawaiians.
They generally don't care about "sacred spots" unless caring about them publicly will get major headlines.
Alphabetically, the organizations involved include: ALOHA, Hawaiian Kingdom, Hawaiian Kingdom Government, Ka Lhui, Ka Pkaukau, Mauna Kea Anaina Hou, Nation of Hawai'i, Nou Ke Akua Ke Aupuni O Hawaii, Poka Laenui, and Protect Kahoolawe Ohana (PKO).
Frankly, I'm surprised there is not a "Bring Queen Lili'uokalani Back From The Dead Society". They are unhappy with the 1893 U.S. Marine invasion that got rid of the hereditary monarchy, and they are unhappy with the U.S. annexation of 1898.
If you want to get technical, had Windows not added the proprietary field, we're just talking a KDC implementation, as in Heimdal Kerberos, or before that, MIT
_just_ ? Try setting setting up IPA sometime. That's just LDAP and Kerberos too. Have fun...
LDAP is really easy. Well, it is for me:
From the OpenLDAP commit logs: === 1.1.4.1 Sat Aug 8 23:05:28 1998 UTC; 17 years, 6 months ago by kurt CVS Tags: FreeBSD_3_3; Branch: FreeBSD Changed since 1.1: +0 -0 lines Diffs to 1.1 (colored diff) Import of FreeBSD LDAP 3.3 Port --- 1.1 Sat Aug 8 22:43:17 1998 UTC; 17 years, 6 months ago by kurt Initial revision --- 1.1.3.1 Sat Aug 8 22:43:17 1998 UTC; 17 years, 6 months ago by kurt CVS Tags: LDAP_3_3+prerelease, UMICH_LDAP_3_3, BOOLEAN_LDAP, LDAP_POSTE, LDAPworld; Branch: UMICH ; Branch point for: RAGE Changed since 1.1: +0 -0 lines Diffs to 1.1 (colored diff) Import of Umich LDAP 3.3 ===
See that 1.1.4.1? Those are my patches to get OpenLDAP working from UMich LDAP sources. It added about 40 platforms. OpenLDAP started with the UMich LDAP, added my patches, and then went on from there. Originals of the (120K of) patches are HERE:
Slashdot Mirror
No. In your scenario, whether the 64-bit time is positive or negative, the called function will attempt to write the full 64 bits back into the 32-bit variable, thus overwriting the following 4 bytes. CPUs don't think to themselves, "Hmm, this is a positive 64-bit value that could fit into 32 bits, so I'll only store 32 bits."
This is inaccurate. The value is being passed by address to a a function that increments it or decrements it as a result of a "settings wheel". So it's basically doing math on the value passed by address.
Unless the math messes with something outside the low order 32 bits, it really doesn't matter what the increment or decrement does to them, it won't dick with the other 32 bits which aren't where they are expected to be.
As a bonus: This likely is not a problem on 32 bit hardware; you should try it on a non-64 bit Apple device and see if it causes problems there, too. My bet is that it will not.
Anyone who is going to be so fucking stupid as to think worse of you simply for a family member giving you a silly endorsement on LinkedIn is a pretentious dumbshit anyway.
Or they just are going to take everything you say with a grain of salt, if it's pretty clear you are getting your family members to inflate your endorsement numbers. That's not being a pretentious dumbshit, that's simply not being a dumbshit, period. Either I can trust the numbers, because I can trust the people endorsing you, or I can't trust the numbers.
I'm pretty sure that if you're applying for a position as biologist, it's statistically improbable that all the members of your immediate and extended family are also biologists, and therefore qualified to judge your ability, or have an opinion. In which case, I will scale my opinion of your ability (down) accordingly.
So how do you "test for correct behaviour of the products, overall"? It's not that hard to spell out -- and even automate -- the cases that a person expects to occur. The problem is accurately modeling the state space of the program and then figuring out which walks through it are incorrectly permitted. Even the most sophisticated known approaches fall down for the first part of that problem due to the vast size of an interesting program's state space.
Personally? If money were no object, I'd use software that cost thousands per engineer in about 1985 or so, but which is now sold as "McCabe IQ". By 1990 you could get three floating licenses for "only" $45,000 (not sure on the current precise price; it appears to *start* at $2,000.00/one-time/user, which generally means that a useful configuration would be more hefty in both price and capability than the "starter" version).
I'd use it to ensure that the requirements document is implemented by the software, and then do a branch path analysis on the resulting code to make sure that the test cases that get generated cover all possible code paths.
Given the substantial costs associated with the tools, most software engineers today have no exposure to *real* CASE tools (but if you care, you can obtain a 30 day free trial from them these days).
Obviously, it also possible to do this type of code coverage testing manually, but most test engineers are trained to do mostly ad hoc testing these days -- assuming you have actual test engineers on your project at all.
If you want a review of McCabe IQ, here's one from ~1990: http://stareast.techwelldev.co...
And here is a more recent company overview: http://www.bloomberg.com/resea...
My sister endorsed me for something.
I made her delete the endorsement, on penalty of being delisted as a connection on LinkedIn if she did not do so, since there was no way in hell that she could legitimately claim domain knowledge for the endorsement, or lacking that, experience in an organization we were both in, justifying the endorsement on the basis of my past work.
This is the problem with associating with family members on professional, as opposed to things like Facebook, social networks: they think they are helping you, when really they are not.
While there are several organizations where we both worked simultaneously, they were all in the distant path. If she wanted to endorse me as an electrician or a telephone installer, or a small appliance repair person: yes, she has that domain knowledge. But that's not where I typically work these days, and it's not right for people to comment on things they don't know that way.
Probably, you should have just given your realtor the same speech I gave my sister, and in the limit, asked them to retract or to lose their connection to you, rather than just deleting your account.
My buzzspeak is a little rusty, but this sounds suspiciously like "Beat monkeys to code faster, send code out the door without testing, and just let the users figure it out". Did something get lost in translation?
Yeah.
They deploy to internal users -- LinkedIn employees -- via Enterprise Enrollment for iOS devices, and via Google Play’s alpha testing functionality and the developer console API. So it's not like they are sending the code without testing, and it appears that at any time, an internal user can torpedo a particular release candidate, so that what they end up with at the end of the week might be the same thing they had at the end of last week.
This still has a bunch of holes, just as any continuous integration process does, but at least by staging a 3 hour limit on things, they avoid falling into the trap that Google and Apple have leapt into willingly, where "it takes as long as it takes" to do integration acceptance testing.
In particular, both Google and Apple engage in reactionary testing paradigms. They build tests based on bugs they've previously encountered (because they are in fact able to test for those, since they've been well characterized during the process of being fixed), and stack them on top of all the previous tests.
This results in an ever-growing set of tests that test for regressions, but which do not test for correct behaviour of the products, overall. Instead, it lets you know when you've encountered a bug which you have previously encountered.
Further, since the testing is unbounded (and in fact, will stop the build process at Apple or Google by throwing a stick into the bicycle wheel of progress -- an event which is called "closing the tree", necessitates the existence of a "tree sheriff" role to deal with automated closures of the tree, and fails to automate the back-out of code leading to failure -- it leads to flaky tests.
The flaky tests come about because there's a human involved in making the decision, and in structuring the situation that way, with an unbounded closure interval -- practically bounded only by people showing up in your office (Apple) or open plan desk/cubicle (Google) and breathing down your neck -- there's a strong encouragement toward flaky tests, and there's a strong tendency do disempower the "tree sheriff" in favor of getting the expensive engineers back to work. And because of this, it's very hard to deep dive into flaky tests.
So we are left with the situation that flaky tests are both tolerated (as long as they are not "too flaky" -- or in Google-speak -- as long as they do not exhibit "too much 'jank' when run"), and the flaky tests do not get cleaned out eventually because the set of tests that you run are not pruned occasionally to run in bounded time, and if you try to do a deep dive to actually resolve the flakiness, you get the disapproval of your peers.
So a bounded time is a good thing, if you insist on having continuous integration, but it doesn't necessarily fix the other problems with continuous integration, and it doesn't fix the fact that most testing in organizations where engineers are involved in "agile methods", such as "Scrum Runs", where the primary goal is code base stabilization, rather than forward progress on the product for 2/3rds or more of the engineers time... well, combine that with an iterative process and it's a recipe for engineers who don't know about testing writing a lot of useless tests, because you are moving the goalposts on them iteratively anyway.
So they've done something relatively innovative, but it's probably not innovative enough. And it's probably an interesting experiment, but I would be wildly surprised if other organizations adopted their framework.
P.S.: The other problem with iterative models, particularly constant integration iterative models, is that you tend to only ever do evolutionary things, and never revolutionary things. There's not always a drunkards walk that gets you "from where we are" to "someplace new and fantastic". There are saddle points, and once you are in a saddle point, an iterative model will not get you out.
I practically guarantee you...
The problem is with a long or int (32 bit) value having its address passed in for a time_t (64 bit) value.
As long as the number is positive, it appears to work, but if it goes negative (and given that most of the people setting it to that date are West of GMT, it *will* go negative), then the underflow blows all the adjacent bits in the next 32 bit word over.
And it appears that something important was there. This will likely be a problem for the code after 19 January 2038, if that's the case.
This is why there should be strong type enforcement set in the compiler settings, to make sure it doesn't compile if you have this kind of bug in your code.
This should be a trivial fix, but it's pretty clear that you could fix the problem on your own by temporarily disconnecting the battery and/or letting the battery drain (which would likely take a very long time). So take it into your local Apple store and be done with it.
What about those of us with prosthetic hands who can't use touch screens for lack of capacitive coupling?
You know they have gloves with capacitive fingertips now so you can use such devices, right? They don't depend on your fingertip's capacitance. That's a solved problem.
Actually, it's a problem I solved for Bochs when I worked at Google. Because I had the need to solve the same problem for a robot that needed to be able to capacitively couple with touch devices. The gloves only work because they are conductively connected to a great big meat antenna (you), such that the cpacitive coupling works.
If you have an artificial limb, there's generally no electrical coupling to the meat antenna. So people with artificial limbs do not get to use touch devices.
The fix is to place a conductive film in the plasticine coating, and to hook it up to an antenna. It's a relatively simple hack, and you can pretty much use any WiFi or Cellular modem antenna from a laptop to do the trick.
And then, voila! Magically able to use touch screen devices. The prototype allowed a man in Germany to use the touchpad on his Lenovo Thinkpad for the first time in his life. Which meant he didn't have to carry a mouse around, since both his arms were prosthetic.
Yes, I am a genius. I'll even let you hire me if you have something interesting to work on. You probably don't.
Who will be the first to legally change their name to "microsoft.com", and then demand to be forgotten?
These guys are morons.
We pushed crypto development to South Africa for FreeBSD back in the early 1990's to get around ITAR restrictions: "you can import, but you can't export".
We will happily route around this brain damage, too.
P.S.: The way to get better cryptographers in other countries is to make cryptographers criminals in the U.S.; obviously, it will not do fuck all to actually stop cryptography from happening, it'll just be that our people end up being shit at it compared to their people.
Yes, yes, bring us back the workaround.
The underlying problem doesn't have to be resolved, because we can just ignore it by installing a bolder font than the one that uncovered the underlying problem in the first place by making it more obvious.
Does anyone else see this as a crap solution to the problem?
Does anyone else see the actual problem is people with bad vision trying to use eReaders?
What about those of us with prosthetic hands who can't use touch screens for lack of capacitive coupling? We should dumb down all of our devices so that the most handicapped among us can use them all. You know, instead of working to fix the handicaps or anything.
By not upgrading unless it adds something you need?
But... but... 1.1.3 is soooooooooooooo much better than 1.1.2!!!!!
It has a +0.0.1!!!!!!!
This.
https://en.wikipedia.org/wiki/...
Yes.
However, if I am designing an experiment, I try to limit any simultaneous changes to dependent variables.
That's not to say that I *won't* (I have) vary multiple independent variables at the same time, but if I do, I usually have at least a "hunch" that the direction I'm moving them both (all) is toward a saddle point.
Perhaps the person deciding this has already concluded the independence of the variables and the probable location of the saddle point. If so, good on them; from outside, I really haven't reached the same conclusion, but, alas, I do not have all of the data they have.
Which is why I stated my comment the way I did, rather than accusing them of bad judgement.
But I can't help but wonder in practice if it won't leave a lot of poor people with no internet access at all.
Sure, it's nice to have an even playing field. But when you're starving, do you really want the government telling McDonalds that they can't give you free food because that wouldn't be fair to Burger King?
This is the intent.
You didn't think that all the poor people with no internet access at all were the ones posting online about the lack of neutrality in the offering, did you? The people posting already have Internet access, and so the only impact on them would be:
(1) If they were one of the companies that refused to partner with Facebook, which means that they were unable to successfully compete in markets (e.g. job sites, etc.) where they were already underdogs, or
(2) They were ordinary Indians, more well off than the poor, who were suddenly forced to compete with well educated poor, who had the ability to apply for jobs which they coveted
(3) They were people who had to pay for their service, felt that if poor people received free service, they should too, and were upset that the free service was not as extensive as their current paid service
So it's basically a strategy to keep the target market segmentation of startup sites focussed on "not the poor", anti-competitive for labor, against the currently disenfranchised (keeping them that way), and people wanting their existing something for nothing, rather than a new thing that is a lesser something for nothing.
Welcome to India.
- 100% of the Falcon 9 Full Thrust landings have been successful.
- 0% of the Falcon 9 v1.1 landings have been successful.
- There has been one F9 FT flight so far.
- The F9 FT has (among others) improved thrust (and thus more reserves for the return flight) and improved landing gear.
- After the successful return of the F9 FT some things were noted about the FT drives and launches were pushed back 4-6 weeks as it looks right now.
Or the ground landing was a "Oops! We accidentally landed successfully! Let's blame the equipment! Back to the barge! Arrrrrr, maties!".
Multiple successful ground landings would have been good. But they aren't planning to refly the thing even if it's a successful landing at this point. But that does move us 3 launches to reuse from first landing to probably 6 launches to reuse. If they have money to burn on it because they are rolling it into launch costs, it makes sense to roll as much of it as you can into the costs before you end up being forced to drop the prices.
And yes, I know: being cheapest, they aren't "forced", but visible reuse would encourage others more, if it had corresponding visible cost reductions.
Why not use some sort of collar made of cables on some masts around the deck to support the top of the booster? When the booster come in, the hoop is wide open so as not to obstruct. As it passes though, the loop tightens and the booster is kept upright even if it tips. By the time it lands, the loops is snug against the top of the rocket and the booster is secure, even if the platform rocks.
That was actually my first reaction: "Oh, obviously it'll be something like 'this' that they'll be using...", the first time I heard they'd be landing them at all.
Then I got really annoyed at them not having something like that, and trying to land on a pitching platform.
The platform landings themselves make sense, particularly if you locate the launch and landing facilities out in international waters so that the world really has no say in whether or not you are allowed to launch and/or land, but really: there's a lot simpler tech that would work to avoid losing the things over and over again.
That said, once they get it right (assuming they ever do), and assuming the weather cooperates all the time, having solved the problem, the per launch additional equipment costs will be marginally lower than they would have been, had they gone with a "hug truss" system in the first place.
Personally, I was thinking they were going to do a least three dirt landings to give them a confidence interval and more data, since that data may change what they decide to do in the process of landing, which in turn might add complications to the water landings that they had not yet considered.
Hooray for more space junk!
And since when this is a problem?
What about all the poor animals who have to live in the environment up there, polluted with space-junk? Particularly if that space junk ends up in their breeding grounds?
You know that they lifted the ban on second children last year, right? And that it never applied to everyone, just certain areas where there was overpopulation. Obviously many in the west would condemn their methods, but it isn't true to say that they have a problem with the rate that their population is expanding. They have it under control, at the rate they desire.
I'm well aware of the ban. It primary served to cause a rash of "SIDS" cases that left odd strangulation marks on female children. Ironically, given that there will be massive shortage of wives, and the families with daughters will pretty much be able to dowry for whatever they want. You would think that there would be a lot of efforts in the other direction, as a monetary investment.
As far as "at the rate they desire" ... that rate being non-zero, that assumes that they are able to manufacture territory (which is what the comment was about) and support infrastructure (which was also what the comment was about).
I definitely didn't turn out OK... in fact, I died of dysentery.
I typed some of it, and pasted others, and manually formatted. I went to 5 sources.
A lot of countries have a lot of disputes; Taiwan is about as bad a China, actually, and there are areas of the Middle East that are pretty fired up, currently (particularly if you consider ISIS a state actor, rather than a marauding horde).
China needs to do more to keep NK under control, unless NK's games are tolerated by China for reasons unknown.
The reasons are far from unknown. China is currently grabbing as much territory as they can, anywhere they can:
Baekdu Mountain (North Korea) ...)
Bhutanese enclaves in Tibet (Bhutan)
Demchok, Chumar, Kaurik, Shipki Pass, Jadh, and Lapthal (Taiwan, India)
Hong Kong (Taiwan)
Jiandao (North Korea, South Korea)
Kula Kangri and points West, Haa District (Bhutan)
Macclesfield Bank (Taiwan, Vietnam)
Paracel Islands (Taiwan, Vietnam)
Scarborough Shoal (Taiwan, Philippines)
Senkaku Islands (Taiwan, Japan)
Shaksgam Valley (India)
Arunachal Pradesh (Taiwan, India)
Spratly Islands (Taiwan, Vietnam, Philippines, Malaysia, Brunei)
Taiwan (Taiwan)
Eastern Bhutan (Taiwan, Bhutan)
Mainland China, Hainan (Taiwan -- but the PRC has a pretty good claim here 8^)
Western Heixiazi / Bolshoy Ussuriysky Island (Taiwan)
Penghu, Jinmen,Matsu Islands, Pratas Islands (Taiwan)
Songling District, Jiagedaqi District (Mongolia)
Pamir Mountains (Tajikistan)
Yalu River islands (North Korea, South Korea)
Shaksgam Valley (India)
Anything that keeps peoples attention focussed elsewhere is all to the good, as far as China is concerned. The territorial waters claims in the South China Sea, in particular, are important to them in terms of extending their range of control, in order to control fishing rights, since their population is still rising, despite sterilizations after the second child, and similar measures.
Oh, so they want to build tax free casinos on their tribal land. Now it all makes sense.
More like Texas secessionists.
This was actually the result of a proxy fight.
It was a proxy for the ke ea Hawai‘i movement, which is a movement that is demanding some form of sovereignty for Hawaii. they have been around forever, and they make themselves a pain in the ass wherever they can in order to attempt to draw media attention to their cause.
Their favorite hobby horses are self-determination and self-governance, for Hawaii as an independent nation, or for people of native Hawaiian ancestry to obtain "tribal sovereignty" similar to the relationship with Native Americans, for Native Hawaiians.
They generally don't care about "sacred spots" unless caring about them publicly will get major headlines.
Alphabetically, the organizations involved include: ALOHA, Hawaiian Kingdom, Hawaiian Kingdom Government, Ka Lhui, Ka Pkaukau, Mauna Kea Anaina Hou, Nation of Hawai'i, Nou Ke Akua Ke Aupuni O Hawaii, Poka Laenui, and Protect Kahoolawe Ohana (PKO).
Frankly, I'm surprised there is not a "Bring Queen Lili'uokalani Back From The Dead Society". They are unhappy with the 1893 U.S. Marine invasion that got rid of the hereditary monarchy, and they are unhappy with the U.S. annexation of 1898.
"President Obama is invested in the Vanguard 500 Index Fund"
Lol, so am I, because that's the lowest cost index fund which tracks the average market growth.
It's one of the lowest yield S&P index funds out there. You have to buy into their investment strategy for it to be worthwhile for you.
If you want to get technical, had Windows not added the proprietary field, we're just talking a KDC implementation, as in Heimdal Kerberos, or before that, MIT
_just_ ? Try setting setting up IPA sometime. That's just LDAP and Kerberos too. Have fun...
LDAP is really easy. Well, it is for me:
From the OpenLDAP commit logs:
===
1.1.4.1 Sat Aug 8 23:05:28 1998 UTC; 17 years, 6 months ago by kurt
CVS Tags: FreeBSD_3_3; Branch: FreeBSD
Changed since 1.1: +0 -0 lines
Diffs to 1.1 (colored diff)
Import of FreeBSD LDAP 3.3 Port
---
1.1 Sat Aug 8 22:43:17 1998 UTC; 17 years, 6 months ago by kurt
Initial revision
---
1.1.3.1 Sat Aug 8 22:43:17 1998 UTC; 17 years, 6 months ago by kurt
CVS Tags: LDAP_3_3+prerelease, UMICH_LDAP_3_3, BOOLEAN_LDAP, LDAP_POSTE, LDAPworld; Branch: UMICH ; Branch point for: RAGE
Changed since 1.1: +0 -0 lines
Diffs to 1.1 (colored diff)
Import of Umich LDAP 3.3
===
See that 1.1.4.1? Those are my patches to get OpenLDAP working from UMich LDAP sources. It added about 40 platforms. OpenLDAP started with the UMich LDAP, added my patches, and then went on from there. Originals of the (120K of) patches are HERE:
http://www.freebsd.org/~terry/...
Just because something is hard for you, doesn't make it hard for the rest of us. Some of us have been doing this for nearly two decades.