No, it didn't. Spam was a big issue for a while but server side spam filters like cleanfeed and distributed systems like nocem became very sophisticated and effective. Unlike email filters, Usenet filters have the advantage in being able to see *all* the destinations. If an article that appeared in more than a handful of groups was quickly squashed. Spam never entirely went away but it well under control long before the decline of Usenet.

There were also efforts like Usenet2 that created a network of trusted servers who would keep spam out. It worked fairly well but interest waned initially because the spam problem was effectively controlled in regular Usenet but even more so as total volume declined and the Usenet2 corner became too thinly populated to be of much use.

Now there is still the problem of idiots posting things in inappropriate places but that's a problem of moderation, something Usenet never did well. (Usenet *did* have moderated groups but it drastically slowed conversation and did not scale well)

I still run a small news server. Spam is only a "problem" is groups where the posting volume has dropped near zero and spam is all that is left. A bigger problem is that I keep losing peers as people give up and shutdown thier servers.

But doesn't call. Maybe she knows better. Maybe it's the two hour time difference. Maybe it is because she comes from a generation where long distance calls were expensive.

I live in Silicon Valley so most of my friends are either technically savvy themselves or have others they prefer to call on.

I think he's right. Have you noticed that phones are getting bigger and tablets are getting smaller? I think phones are about to eat tablets in the same way they ate other stand along devices. People don't want two devices. They want one.

Personally, I hate the idea.

Probably the kind where the parents can not entirely dismiss the notion that their child may be doing something quite serious that they don't know about. In other words: virtually every parent of a teenager who is honest with themselves.

I guess it's for fickle people. My path is essentially: DOS -> AmigaOS -> Solaris -> Linux, with the qualification that the old systems never entirely went away, it is just a change of focus for my desktop usage. I've never gone backwards or done the same migration twice.

Now if it was about data migration between OS's that would make a lot more sense. I move data between Solaris, Windows, and Linux all the time.

Have their been any updates at all since you submitted your patch? If not and the time period is long enough to believe there never will be, then your best course of action is to fork. As one with enough vested in the project to pay for further development, you are probably in a better position to steward the project than the original developers, who likely have no more use for the program.

If there have been updates, then you have a more sticky position. Most likely, the maintainers considered your patches to be too narrowly applicable at least relative the difficulty required to integrate and maintain them. At that point, you are pretty much stuck re-integrating your patches with each release.

Windows COTS wouldn't necessarily solve your problem either. It just takes away the option to patch your own. If the company is not interested in making the changes you request, there isn't much you can do about it. The exception would be of the commercial software is more popular and better maintained but that's true in the open source world too. If you have a choice between two projects, both of which an do the job with adjustments, you are most likely better off contributing the one that is actively maintained than the one that isn't, even if the required changes are more extensive.

Unfortunately, making an estimate to half-day granularity takes a great deal of time. So much, in fact, that you will likely need to give an estimate for the time to complete the estimate because it will be significant part of the total project time.

And you will still likely be wrong because what you are really doing is a sketch implementation without the feedback that prevents small errors from exploding into total nonsense. A course estimate may actually be better since it forces you to factor in unknowns rather than assuming unknowns don't exist because "look at all the detail!"

I've worked for several startups. Four years is long enough to expect some turnover if the headcount is non-trivial. The pointed questions to ask are:

1) How many employees?
2) What kind of roles to they serve?
3) Is the company obscuring turnover by keeping traditionally high-turnover roles like sales as contractor?

That seems the most plausible path. All it takes is a hole in the sewer pipe and a hole in the water pipe and there's your path. Once in the water pipes it doesn't sound impossible for pathogens to move backwards into the aquifer. I admit the pressure gradient should work against this but it sounds more plausible than quickly transiting a "a thick layer of clay or shale" separating the sewer pipes from the aquifer.

Not necessarily. If you improve benefits in such a way that the job becomes more appealing to women, more qualified women will apply. Child care, for instance. It would be a benefit for any employee that has children but, statistically, women are more likely to be single parents and take greater responsibility for children in a two parent family.

Absolutely... as long as you are the copyright holder for all of the code. Otherwise you need to track down everyone else who contributed and get them to agree to the new terms. Or rewrite the bits that you don't own.

Indeed, there is a whole movement pushing for GMO food labeling consisting almost entirely of people ignorant that "GMO" doesn't tell anything about the health effects of a food item.

Perversely, there is no movement to label the chemicals applied to food even though many of the chemicals (like pesticides and herbicides) are toxins.

Unfortunately, like many interviewing methods, this doesn't test what you think it tests. It actually tests a candidate's ability to quickly produce low to moderate effort results under stress and to think out loud. It is a good skill to learn but mostly because it comes up a lot in interviews. Actual development is seldom done this way. Quiet contemplation and low stress collaborative banter is how problems usually get solved. Unfortunately, though effective, neither method prepares a candidate for being given a problem they have never seen before and then having every movement watched as time ticks down.

Come out to the Newtech Meetup and similar regular events. Specifically watch for the "Shout Outs" but also just talk to people. Backend database is actually in more demand than front end app development but both come up.

By "CA" you must mean Canada because in California, specifically the San Francisco Bay Area (including Silicon Valley) this is not remotely true. Engineerig jobs that don't require experience are nearly myth. Listings are few and require quite specific experience.