Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror

Comment My sister endorsed me for something. (Score 1) 31

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.

Comment Re:"Open Sourcing Testing Frameworks"? (Score 1) 31

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.

Comment I practically guarantee you... (Score 4, Insightful) 136

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.

Comment Re:Yes, yes, bring us back the workaround. (Score 1) 85

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.

Comment These guys are morons. (Score 4, Insightful) 151

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.

Comment Yes, yes, bring us back the workaround. (Score 1) 85

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.

Comment Re:Why not support the top of the booster (Score 1) 42

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.

Comment Re:On paper, this is a good decision (Score 2) 133

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.

Comment Re:Some "facts" (Score 1) 42

- 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.

Comment Re:Why not support the top of the booster (Score 1) 42

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.

Comment Re:The reasons are far from unknown. (Score 1) 286

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).

Slashdot Top Deals

Politics: A strife of interests masquerading as a contest of principles. The conduct of public affairs for private advantage. -- Ambrose Bierce

Working...