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


Forgot your password?

Comment Re:How is a captive portal site different from AOL (Score 2) 37

How is a captive portal site different from AOL?

Because AOL was never a captive portal site. AOL was a portal site and used/sold "Keywords" on the portal page as a type of search engine to direct users to prefered endpoints. But there is/was nothing that prevented users from using Yahoo, AltaVista, Jeeves, or any other search engine, or typing destinations URLs in directly.


How about:

(1) AOL was founded in 1983

(2) AOL didn't offer Internet access until 1993, a couple of months after it started to offer Usenet access It spent a decade as a captive portal.

AOL was just like Prodigy, CompuServe, GEnie, and other services of it's day: You connected to a service through the public telephone network, and it was a subset of the information available, compared to what you'd get from an ISP, and advertisers had to pay for keywords.

Given that for about $1/month, an Indian person could convert their "captive portal" experience to a "the full Internet" experience, I'm not seeing a large difference here.

The only thing I'm seeing is not-quite-poor people in India posting online in a way that the actually-poor in India can not possibly post online, as to why all the actually-poor people in India shouldn't have *some* access to the Internet.

Because apparently none-is-preferrable-to-some-which-is-not-all.

Comment How is a captive portal site different from AOL? (Score 1) 37

How is a captive portal site different from AOL?

How, in any way, is a captive portal service in India, any different than America On Line or Compuserve was as captive portals in the U.S.?

They allowed the "Me Too!"'s onto the Internet in the first place, which later expanded to general access.

Comment Re:Why is this news? Tech cos doing worse for deca (Score 1) 321

Microsoft has laid off US workers by the thousands, while simultaneous sitting before congress and insisting more offshore visa workers were needed to make up for "sever shortages" of QUALIFIED US workers.

FTFY. The workers they laid off were not qualified. The positions they were hiring for required different qualifications than those they laid off.

Comment Re:Can someone clarify this? (Score 1) 321

That said, IBM India will have a position for "IT Support Technician" and it will be filled by someone in India who will be moved over here to perform the same task that the former Hertz-employed IT Technician would have done.

No. they will be expected to stay in India.

This isn't an H1-B story, it's an offshoring story.

Too bad the anti-H1-B people got their licks in before the anti-offshoring people, or we'd be talking about the evils of offshoring, rather than the evils of H1-B.

Comment Re:I practically guarantee you... (Score 1) 158

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.

Comment Re:My sister endorsed me for something. (Score 1) 65

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.

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

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

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

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

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?


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

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.

Slashdot Top Deals

Pound for pound, the amoeba is the most vicious animal on earth.