Become a fan of Slashdot on Facebook


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Re:In this economy? (Score 1) 562

CDs should be better in every aspect than an LP/Cassette...but they producers typically cut out a bunch of stuff that ultimately makes them inferior. And there are ways around each of the issues you mentioned - hiss was essentially dead space when the volume was turned up too loud.

Personally, I've got a bunch of LPs and Cassettes I want to digitize, and they'll all be better than any CD I could buy.

Comment Re:In this economy? (Score 2) 562

Neither do MP3s. And the quality's better. But, I guess they're not "tangible."

Well...let's see an uncompressed, unfiltered, band-unlimited, DRM-less analog audio stream from a cassette, or a compressed, filtered, band-limited CD or MP3?

Yeah...LPs and Cassettes are coming back b/c of how the CDs and MP3s are getting cut.
- Frequency bands deemed to high or low are cut off - removing high pitches and low pitches that while you may not be able to *hear* you can feel in some senses.
- Filters take this to another level and can often degrade it; sometimes these are used to keep people from copying them as extracting from the CD may add pops, glitches, etc (yes, I have a CD that way - no matter how good I rip it it sill has pops, etc b/c of the watermarks due to the filters applied).
- Compression is also applied, and usually is lossy. AAC, IIRC, was better than MP3 b/c it was lossless, but even then - CDs are compressed typically with lossy compressions.

Do yeah - digital tracks could be better than LP and Cassette but often aren't b/c of everything done by the studios. Yes, you can skip a lot of that stuff but then you get a lot less audio on CDs or the MP3s/AACs get to be a lot larger.

Comment Re:Poor Qualty (Score 1) 147

Most of all that is FOSS, with the exception of Adobe (of course).

Exactly, and by organizations that have a well defined CVE policy so they generate a lot more CVEs than proprietary companies (like MSFT, Apple, Oracle, etc).

Oh, and don't forget that probably all those Linux Kernel CVEs also had a Debian/Ubuntu/Red Hat CVE filed too - so multiple countings - since CVEs are a form of notification; often by the time the CVE is filed for a FOSS project it has also already been fixed; unlike non-FOSS organizations...

Comment Re:NoSQL all the way down (Score 1) 332

Postgres / HSTORE could have probably solved pretty much the entire set of persistence use cases

Hey, but PostgreSQL is buzzword compliant with the new hipness... you want a JSON-based document store? CREATE TABLE docstore ( docid SERIAL PRIMARY KEY, userid INTEGER REFERENCES users, document JSON );

OK, don't code-review that off-the-cuff doodle too seriously, but implementing NoSQL features in a decent RDBMS is easy, implementing RDBMS features in NoSQL is hard...

Yep. I've worked two projects now that include Cassandra. Why? Replication. All the queries are SQL/Relational oriented. The one project supported Sqlite (for dev testing), Mongo, and Cassandra but they wanted to deploy with Cassandra; the project got canned after it was nearly complete and they started looking at the operational costs to meet our required throughput (requests/second) because of how massive the Cassandra cluster needed to be (in terms of node count and the type of server needed to support it); though we were officially told it was canned for other reasons, the timing was just too close to not have been a major factor in the decision.

Comment Re:What Hollande says (Score 1) 328

"theoretical ways to deal with the waste products" = "no actual ways to deal with the waste products"

Actually there are very simple ways to take care of the waste products, but either (a) environmentalists and the EPA get in the way, or (b) we've removed them as options via International Treaty.

The simplest way to deal with waste products is ship into space - and we ship usable nuclear material - working nuclear reactors - into space regularly for use by satellites, etc. So yes, it is a perfectly viable to method to get rid of it - sent into a dedicated orbit around the solar system or to be consumed by the Sun at some point (months) in the future. However, this is banned by International Treaty - one of several treaties signed during the Cold War, primarily to keep nations from sending Nuclear Missiles into space for use (f.e see the movie Space Cowboys - yeah, not doable by Treaty).

So yes, there are ways to deal with it if we decided we really wanted to actually deal with the waste products.

Comment Re:Good ol' fun (Score 1) 302

They have 1.2 million users. That's big enough to have an "email server admin." In fact, it's big enough to have two. They should get some. Not having any hasn't worked out too well for them.

Well....if they're using MS Exchange they'd need a team of 4 or 5 at least. So yes, someone should have known how to set the groups properly so that this could not happen. Of course, that's assuming it went to "Everyone" or a similar all-encompassing group. It could just as easily been a single email that contains a bunch of groups TFA to find out (I would assume).

Comment Re:yes they should (Score 1) 1081


No, we do not.

A Democracy means that there is direct elections - every vote directly influences the voter outcome.

What we have is a Representative Democracy in the form of a Republic where elections are for representatives that are tasked with making the real choices - there is no required direct election of the representatives. Yes, some representatives are directly elected; others are not. Voter influence is by design indirect.

Comment Re:It's not surprising... (Score 1) 176

In an enterprise there are two big costs... licensing, and support.

Linux the cost of support is pretty high -- for models like Red Hat the cost often is higher than Windows because you don't get as high a per-seat discount. Then there are the other ancillary costs like productivity, accessibility, data governance, etc... which are harder to materialize but also make an impact.

So here's the thing:

With Linux - you *might* have a support cost (e.g RHEL/SuSE/Canonical Enterprise support agreements), infrastructure to run, a few engineers to maintain your specific packages, and your normal support staff.

With Windows, you still actually have all of that, plus you have to the licensing for Windows itself, the servers, etc. Windows Server requires licenses for clients to access it - so you pay twice for each user (WIndows Desktop License + CAL on the server).

The enterprise support agreement costs between RHEL/SuSE/Canonical and Microsoft are actually pretty comparable. So ultimately you *do* save money.

However, most organizations that deploy Linux don't heavily customize it like Munich did with making LiMux. Most will just use what's provided via one of those Enterprise distros, use their support, and infra, etc. They might deploy a local mirror (to reduce bandwidth charges and be friendly), and may be a repo for their software additions - but not likely.

So ultimately arguing that people and infrastructure makes Linux more expensive to deploy than Windows is also inherently false. Aside from the licensing (not support, but actual licenses) cost everything runs generally the same; if anything you'll need *more* people to operate the Windows systems simply b/c one Windows administrator has a lot more work to do to maintain a Windows environment than 1 Linux/Unix administrator ever has - which is why you typically see a 1:50 to 1:100 admin to system ratio with Windows (and I'm being generous) while you normally will see a 1:500, 1:1000, or even 1:10,000 with Linux/Unix.

Comment Re:No surprise (Score 1) 167

Well, let me see how really detached I am from technical work: At start of project: My estimate: 490 Story points, +2 senior developers, +1 senior QA, 3rd party cost $20k, GA in 9 months The team estimate: 305 Story points, no new headcount needed, 3rd party cost 15k, GA in 8 months

It's a matter of how much dev work you are doing versus management work. The more time you spend doing solely management, the less you'll be in touch with real dev estimates, etc as it's impossible to keep up both skill sets without actually using them.

I constantly have to tell the team their estimates are low and unrealistic, as I hear them not discussing corner cases, they take it as an insult to their pride that their estimates are accurate, yet 5 releases down the line they consistently underestimate by as much as 80% and miss release dates by as much as 9 months. Where we were supposed to have a team if 16 senior people, now we have an ever growing team that lastly counted 40 junior people. Every 2-3 months RND management see that they are behind, go out and find some guy fresh out of college, 2 or 3 other developers take 2 months to train the new hire, and as a result we are getting even farther behind, while the new guy is only interested in refactoring to the latest technology buzzword instead of writing new functionality. Refactoring is important, but I generally prefer to have the most senior guys do it, and only after they have been tasked by the Architect to do so.

Sounds like (a) you need some good lessons learned taught among the team, and (b) you need to be applying the standard practice of PM Estimate = ((Dev Estimate * 2) + 20%). Devs are extremely bad at and are not taught how to estimate effort; spend the time to teach them how instead of complaining about them.

Comment Re:No surprise (Score 1) 167

Most devs have no clue about project management from a business perspective; your more seasoned devs will (or at least should). "No" will rarely mean "No, that can't be done"; they have to learn how to speak your lingo as much as you need to learn how to speak theirs, and a good PM will help both sides do that.

That's the wrong way around. If you're the project manager, you got hired partly for your people skills. Developers get hired primarily for their technical skills. It would be easier for a good project manager to learn to speak geek than for developers to speak business.

Devs still need to learn the language of management. Even if they don't go into management it will significantly help with (a) understanding management, and (b) communicating with management; thereby making life a lot nicer. It helps when talking to the PM too; but the PM should be able to talk with the Devs in their lingo - IOW, Dev-Dev is pure dev speak; Dev-PM is mixed dev speak and management speak; PM-Management is pure management speak.

Besides, developers tend to be worse negotiators, and if they're talking a foreign language they'll be even more at a disadvantage. One defense a bad negotiator has is to take a position and stick to it.

Experienced developers are sometimes gun-shy. If you're trying to do a job, and say "We can do it if we get X and Y", and find that you're expected to do it just fine without X and Y, and your complaints get stonewalled, it's going to be much easier for you to say "No, can't do it" next time.

It's possible to wind up in a situation where developers and managers are on the same side, but that usually requires management to understand developers and keep promises.

Consider that many senior devs will eventually do some level of management; it helps to learn the lingo. You may not be good at negotiating right away, but building up the toolset is a good thing nonetheless.

Comment Re:No surprise (Score 1) 167

What I have found out, there are some cultures that say "No" when in fact they mean that they won't be able to do it with current resources. Which is absolutely fine to disclose, but for some reason, they don't do it. They just say "no".

Most devs have no clue about project management from a business perspective; your more seasoned devs will (or at least should). "No" will rarely mean "No, that can't be done"; they have to learn how to speak your lingo as much as you need to learn how to speak theirs, and a good PM will help both sides do that.

Often PMs aren't unreasonable and don't expect that features are for free. It is perfectly reasonable for a Dev team to present cost estimate which is not only story points but also headcounts, equipment needed, account for decreased productivity and opportunity cost.

Aside from the MBA speak you have in are obviously detached from the team in any meaningful manner. You might have had a technical background at some point, but you've lost it due to going down the PM/MBA path, and have forgotten how hard it is for developers to do any kind of estimates. That is why you have senior developers and software architects that are in charge of the project as a whole and its general road map. You as the PM need to be working with those people - 1 or 2 people that will really know the product, its source, and customer base really well - to get the estimates, etc you need. They should in turn be training the lower devs to be able to do the same (though that almost never happens) while they collaborate to get the estimate figured out.

Then it is up to the PM to present and defend that cost to execs in a cost/value analysis and if numbers work out the PM can actually help the team get funded and get the job done. But if the team only says "no" instead of "yes, but ..." by providing a complete analysis for a means to make it a "yes" sometimes it just doesn't get to a "yes" and the whole product gets scrapped.

Wrong. The PM is but one part of the team in deciding on the estimate. Their job is to help identify what is valuable to go after and work with the team to build up an estimate and make the case. Their job is to run the financials for the team, ensure there's enough developers and resources, etc. Their job is to be the voice of the team to fight for the product in the organization, to ensure it get appropriately marketed and arrange for all the other non-technical stuff that goes into the product while working with the team to get the technical stuff completed.

Sadly, this is where the MBA/PM courses fail. They focus too much on looking at this in an unbiased manner based on balanced sheets; team work is against other CxO's, and the people that do the real work are turned into "resources" that can be "allocated" without any information or regard for what those "resources" really are. That's not to say that there is not a place for that kind of perspective (there is) but it's not how you should be looking at it the vast majority of the time.

Comment Re:Never can though (Score 2) 167

Even if you can reproduce all of the hardware exactly, you are never going to get the same kinds of results that putting software in the hands of real users will get you.

There's different kinds of buys, which is why you have different kinds of systems and testing environments.

A dev should be able to have an isolated environment in which to be able to test the various parts. Each part should be able to have a sufficient emulation of external parts to be able to have its own unit and functional testing. From there, several parts should be integrated at a time to do functional and integration testing, eventually building up to the entire system being fully integrated and using emulated externals (e.g external auth emulation) so the system can itself run in isolation. This gets to 95% of the issues.

From here is scalability - for which the operations team should be providing environments sufficient to do the scaling testing so stuff can be tested at sufficient scale before it hits production.

Now, that doesn't mean you won't end up with issues in production, but that it should be a rare thing for that to happen. In those rare cases you may have to test in production, but that should be the exception, not the rule.

Too often we don't invest in all the different levels of testing b/c (a) devs are lazy, and (b) management cheaps out. However, doing all the layers of testing will be cheaper in the end since things will be caught earlier where it's cheaper and faster to fix.

Slashdot Top Deals

Usage: fortune -P [-f] -a [xsz] Q: file [rKe9] -v6[+] file1 ...