Slashdot is powered by your submissions, so send in your scoop


Forgot your password?

Comment Re:How is a captive portal site different from AOL (Score 1) 51

That is a bit of a revisionist history summary there... AOL was not an internet service provider or even "AOL" in 1983, it was platform attempting to sell a select set of products. And it did not call itself "the internet", for all intents and purposes "the internet" didn;t really exist before the very late 80's/early 90's outside of a very small community.

Why do you think Facebook calls it "Free Basics" insteac of calling it "The Internet" or "Your Facebook ISP"?

To quote Facebook:

"Free Basics makes the internet accessible to more people by providing them access to a range of free basic services like news, maternal health, travel, local jobs ..."

You want more than basic services? You pay for them.

Comment Re:How is a captive portal site different from AOL (Score 1) 51

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

Because Facebook's intent was to distort the market in ways that may take away that $1/month option and force many more people to rely on only those sites that Facebook approves.

Be realistic: do you really think that Zuckerberg really does anything from a purely altruistic motivation?

They wanted to keep that option, of the people paying extra. In no documentation, literature, or description of the plan is there ever any intent to take away the option to start paying for the otherwise free OTA service in order to get access to the full Internet.

And no, I don't think that Zuckerberg suffers from an overabundance of altruistic motivation...

Why does India believe that he should, and pay for full Internet access for everyone? We don't even have universal Internet access in the U.S..

Comment Re:What should happen but won't (Score 4, Funny) 481

I'm sure (s)he's now totally changed their opinion on the nature of the political right after reading your well thought out and well argued post.

Anyway, can we stop with all of the anger for a minute and remember that a human being just died here? Show some respect. Regardless of whether or not we agree with his positions, there are people out there who loved and cared about this man. My condolences go out to the Koch brothers for their loss.

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

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

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

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

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

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:

And here is a more recent company overview:

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 Re:The Cloud? No thanks. (Score 2) 151

I don't know exactly why Google wants them. Presumably, as a corpus to improve their image processing technologies.

And as a way to improve their facial recognition software, because you'll tag people and then Google will be able to identify the same individuals in other photos. Heck, one feature of Google Glass was to have it upload the photos and Google recognizes everyone on the street. The only way this can happen is if Google has a large corpus of faces so they can identify people in every photo.

Slashdot Top Deals

Just about every computer on the market today runs Unix, except the Mac (and nobody cares about it). -- Bill Joy 6/21/85