Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×

Comment Re:Hmm... (Score 1) 839

Aside from the other stupidity already being commented on, this is purely a case of bad design in the LED traffic signals. LEDs are ~4x more efficient than incandescents, but they're still far from perfect, and they still give off a *lot* of heat.

http://en.wikipedia.org/wiki/Luminous_efficacy

I've designed and built many lamps using high power/high brightness LEDs. Any time you design a high power LED lamp you have to heat-sink every single LED otherwise it will burn out. The obvious solution here is to run heatpipes from the sinks at the back of the LEDs to the lamp housing and/or front lens. There's no need to add a separate heater, every electronic device *is* a heater.

Comment And in other news, (Score 2, Funny) 235

this weekend large portions of Spain suffered extended blackouts as a number of the electric company's network routers were overwhelmed by an unexpected surge of traffic. This was apparently the result of an article about Spain's wind-based electrical program being published on slashdot.org, and the ensuing traffic overload from attempts to access the power generation graphs on the public site...

Comment Re:WinCE when you say that (Score 1) 229

Agreed. This was from last December in Kazakhstan, by the way:

http://www.flickr.com/photos/27159137@N08/3186737368/

About the same time frame as those researchers and their discovery. Seems to me that this type of hacking has been going on all over, for a long time already.

And yes, I'd say it's criminally negligent to use any Windows OS on ATMs or anything else where security matters...

Comment Re:don't tread on an ant ... (Score 4, Interesting) 359

It's not so surprising though - it just means that the ants have been able to spread faster than their rate of evolution/mutation. Otherwise, they would have differentiated/speciated first. But because it's so easy for them to hitch rides on passing people, cars, boats, and airplanes, they've spread a lot faster than they would naturally have been able to.

The more interesting thing will be to observe over time and see how long it takes before their super-colony collapses or is torn apart by civil war. Of course that's not likely to occur until their paths of transport and communication are disrupted. If we don't destroy ourselves first, thus giving them a long time to continue to evolve in total connectedness, I guess things will get interesting for them down the road...

The other interesting point this raises is about language and communication in general - biologists frequently talk about animals communicating with each other via whatever their particular mechanisms may be, but they seem to assume that all the members of a species are homogeneous in their communication methods. That's a pretty naive assumption, given all the different vocal and non-vocal mechanisms various human tribes use to communicate. The interesting question here will be whether this super-colony is an example of genocide (the total annihilation of different/competing ant species) or assimilation...

Comment Re:Enterprise directory services (Score 1) 149

Sorry, the eDirectory info is based on personal communication from a Novell engineer. (But it's worth noting that OpenLDAP's libraries are also better tuned than anyone else's, and Novell now ships OpenLDAP's libraries, as do a number of other vendors.) The OID and SunOne results are from benchmarks performed for a customer's RFP, and unfortunately are confidential. But you can find comparable results here:

http://www.connexitor.com/blog/pivot/entry.php?id=130

The FedoraDS codebase is still much the same as SunOne. OpenLDAP is more scalable and higher performing than all others. Since you claim to have worked with all of these it should be no trouble for you to benchmark OpenLDAP against any of your other installations and verify for yourself. Unlike closed-source vendors who use license agreements to prevent you from publishing benchmark results for their products, you have total freedom to bench and publish your results with OpenLDAP...

You may not think it's taking the world by storm; the interesting thing is that it's going into more places than you're aware of. You just don't hear about it much because most companies are too embarrassed to admit they're running free software instead of the crap they spent millions on purchasing in their previous fiscal years.

Comment Re:Enterprise directory services (Score 1) 149

Wrong. OpenLDAP is the number one top performing directory software in the world, and has been since 2003. None of the other directory vendors have been refreshing their technology in recent years, and OpenLDAP is generally 2-3x faster than everyone else. 5x faster than AD typically. If you want performance, eDirectory is pathetic in comparison, and even Novell's engineers have admitted they can't get anywhere close to OpenLDAP's performance.

To the folks saying "ActiveDirectory is best of breed" - yeah right. The AD server is crap; what you guys are seeing as "nice" are the GUI admin tools. Which by the way also work with Samba4/OpenLDAP...

AD design flaws: http://www.mail-archive.com/ldap@umich.edu/msg01464.html

I can't dispute that M$ makes slick GUIs (sometimes). But to call AD best at anything is a far stretch. And no pretty GUI on top is worth anything when the underlying technology is broken.

re: commercial support for OpenLDAP - Symas has customers with production deployments of billions of entries (several hundred million identities plus ancillary objects). OpenLDAP has been run successfully with over 5 billion entries in a single database; no other directory software in the world can make that claim. Oracle OID comes close but again at over an order of magnitude slower performance.

Telcos, cable companies, large financial institutions, petrochemical/energy companies, and governments all around the world are switching to OpenLDAP because it's the only solution that works reliably and performs so well at such large scales. Nothing else touches it.

Comment Re:torrent of rtmpdump 1.6 available (Score 1) 203

Except, downloading copyrighted material isn't inherently wrong, by any definition, let alone illegal.

I was using an earlier version of get_iplayer's hulu support to catch up on TV shows that I'd missed recently. I'm also a cable TV subscriber - I've already paid for the right to receive and view these programs in my home. I've never signed any agreement that dictated how / in what form I can receive those programs, or whether I can record them or watch them later or not. They have my license fee, so now they should shut up and let me watch the material I already paid for.

Downloading for the purpose of unlicensed distribution - that's a separate matter. But that's not what I'm doing, and just trying to discourage people from downloading is misguided.

Comment Re:Don't be so Glib (Score 1) 565

What other use case *is* there for strcat???

"make no difference" try profiling some actual code before you say that. I have, it does. It's the difference between having a poky slow AppleShare server and having the fastest one in the world. (Yes, I wrote that while at Locus Computing.) It's the difference between having a poky slow LDAP server and having the fastest one in the world. (Yes, I wrote that - OpenLDAP today is the world's fastest directory server; in 2000 it was a pig.)

Efficiency *always* matters. People who think "it makes no difference" are the programmers responsible for all the crap bloatware in the world today... Just because they're in the majority doesn't make them right.

Comment Re:Don't be so Glib (Score 2, Informative) 565

You and the vast majority of C programmers, it seems.

Security aside, think of it from an efficiency perspective: it always starts from the beginning of the target string (since it has no other information available to it), iterates to the end, and then begins catenating the second string. This gives you O(n^2) behavior when catenating multiple times to the same string. The str* functions are some of the worst ever designed...

There are two obvious fixes:
  1) always record explicit lengths of your strings, so that you can catenate by just memcpying to the end of a given target string
  2) use my strcopy() function, which returns the pointer to the terminating NUL at the end of the target string.

E.g., this is legal and useful:
strcat(strcat(strcpy(a,b),c),d);

but it's slow because each strcat starts over from the beginning. If strcpy/strcat always returned the pointer to the end of the target string, instead of the pointer to the beginning of the target string (which is what strcopy() does) then you get no efficiency loss, and you only need one function instead of two:

strcopy(strcopy(strcopy(a,b),c),d);

After you fix this basic inefficiency you can of course define strn/strl variants as you see fit...

Comment Re:Don't be so Glib (Score 2, Interesting) 565

Oddly enough, I have to agree with Drepper here, strcat() et al are terrible, and anyone using them *does* deserve to be punished. (Odd because of the many other disagreements I've had with him, on bug 4980 and elsewhere.)

But what do I know, it's not like I ever maintained a C compiler, high performance C library or multitasking kernel before. (Oh wait, I did...)

Slashdot Top Deals

"Look! There! Evil!.. pure and simple, total evil from the Eighth Dimension!" -- Buckaroo Banzai

Working...