debian.org · Domains · Slashdot Mirror

Re:GIT? by macshit · 2008-06-04 12:24 · Score: 1 · on FreeBSD Begins Switch to Subversion

in short, Git has already won and expect it to be the biggest source code versioning system in less than two years from now.

Indeed. Hg had an early boost from large organizations (e.g. sun), apparently because of it's better windows support at the time, but it seems clear that git has the majority of mindshare these days, especially in the FOSS world.

Here's a graph of scm system on usage on debian which made the rounds recently (note this is based on "popcon" statistics, which measure use of each tool). The top two descending lines are CVS and SVN; the third-from-the-top ascending line is git; the rest of the lines inclucde hg, bzr, darcs, etc. This data obviously isn't perfect, but it seems pretty much reflect the trends that I've observed.

Re:GIT? by AKAImBatman · 2008-06-04 08:07 · Score: 2, Interesting · on FreeBSD Begins Switch to Subversion

If you go by Debian's popcon, Subversion has already kicked both our asses and we should all go home:

http://people.debian.org/~igloo/popcon-graphs/index.php?packages=darcs%2Cgit-core%2Cmercurial%2Cbzr%2Csubversion%2C+cvs&show_installed=on&want_legend=on&want_ticks=on&from_date=2003-10-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1

Re:It's the algorithm, stupid by Just+Some+Guy · 2008-06-03 04:08 · Score: 2, Interesting · on Twitter Not Rocket Science, but Still a Work in Progress

This observation is why the choice of language doesn't matter. If a language implementation is slow, all it does is add a constant factor to any algorithms written in that language.

That's the crappiest, most long-winded apology for poor performance I've seen. Yes, everything you said about O() notation is more or less correct. No, you can't wish it to be applicable just by squinting really hard and hoping.

At some point, that constant does start to matter. Suppose your O(n) algorithm written in $fast_language can support the world's population logged in simultaneously. Further suppose that you wrote prototype #1 in $spiffy_language that can support about 100 users on the same hardware as the $fast_language version. Sure, both are O(n), but that doesn't magically make them equally good solutions.

No, I don't think Ruby is 60 million times slower than the fastest language, but it very well might be 100 times slower for their algorithms. Do you honestly think that wouldn't make any difference?

Surfraw by bugnotme · 2008-06-02 12:50 · Score: 1 · on goosh, the Unofficial Google Shell

There is also surfraw http://surfraw.alioth.debian.org/ which is a great idea but somehow does not aspire greatly enough.

Re:Totally geeky by martin-boundary · 2008-06-02 12:15 · Score: 5, Informative · on goosh, the Unofficial Google Shell

There's already a better choice for command line integration: try surfraw. This lets you stay within a real command shell such as bash, and just type

$ google what I want to know

You'll get the results directly in a browser of your choice. If you're like me, you have the browser set up as w3m, so that the google results simply appear in the same terminal where you can click on them. Since w3m is a pager like more and less, you can postprocess the google output, eg

$ google hello | grep Cached
www.hello.com/ - 2k - Cached - Similar pages
www.hellomagazine.com/ - 32k - Cached - Similar pages
www.hellomagazine.com/royalty/ - 27k - Cached - Similar pages
en.wikipedia.org/wiki/Hello - 39k - Cached - Similar pages
en.wikipedia.org/wiki/Hello_world_program - 32k - Cached - Similar pages
www.elite.net/~runner/jennifers/hello.htm - 157k - Cached - Similar pages
www.ipl.org/div/hello/ - 20k - Cached - Similar pages
www.mylalaland.com/hello/ - 6k - Cached - Similar pages
publicaddress.typepad.com/ - 58k - Cached - Similar pages
www.sanrio.com/ - 10k - Cached - Similar pages

Best of all , surfraw is not just limited to google, so you can have a complete shell browsing experience for a lot of different sites.

surfraw by poopie · 2008-06-02 12:13 · Score: 1 · on goosh, the Unofficial Google Shell

*years* ago, most of us were doing this same type of thing from a commandline with lynx/links.

If you like this, you'll probably like surfraw too

http://surfraw.alioth.debian.org/

All the goodness of goosh without the need for X or a browser

I actually added some of the handlers years ago, but I found that eventually Google searchbox was able to do many of them for me directly - like "quote intc" , "ufo site=cnn.com", etc.

I created my own handlers (elvii) for internal intranet use to do all sorts of mundane queries from the commandline with ease. Its amazing how excited people get when you give them a commandline way to do really quick web queries and get results with minimal CSS/ads/formatting junk.

Re:Server/customer ratio? by gnuman99 · 2008-06-01 16:40 · Score: 2, Informative · on Explosion At ThePlanet Datacenter Drops 9,000 Servers

How about catching on fire and burning down??

http://lists.debian.org/debian-devel/2002/11/msg01926.html

Re:Talk really did wow the conference by dkf · 2008-06-01 06:17 · Score: 1 · on MagLev, Ruby VM on Gemstone OODB, Wows RailsConf

This talk was one of the highlights of the conference. At the talk, they showed performance benchmarks that included running several things as much as 117x as fast as the default Ruby interpreter that is in use by most Rails installations today. The fact that it's built on this commercial-grade Gemstone platform that has been used for years for high-performance production Smalltalk applications just adds to its credibility. Well, without in any way detracting from the technical prowess of the Gemstone folks - sounds like they know their stuff with OODBs - beating the default implementation Ruby on the performance front isn't that hard. Certainly traditionally, Ruby was slow by all independent measures such as the Language Shootout.

I suppose this does beg the questions: does the Gemstone-based system do better in the shootout benchmarks? If so, by how much? And since there's often tradeoffs between optimizations and (frequently obscure) parts of language semantics, what features of Ruby get lost along the way? What proportion of Ruby scripts are likely to run unchanged? What proportion of those are going to get a good performance boost?

Just the things that go through my head on first glance...

Re:Ruby Shootout by cryptoluddite · 2008-05-31 21:40 · Score: 3, Interesting · on MagLev, Ruby VM on Gemstone OODB, Wows RailsConf

I took a look at some more of the benchmarks and they are pretty much universally meaningless once you throw in a good optimizing VM. For instance translating the method benchmark into Java and having it loop 2^31 times instead of 6 million times and Java is 29,000 times faster than Ruby 2.8.

Adding a simple global+=1 to the method body makes Java only 16,000 times faster than Ruby 2.8.

Replacing the +1 with global*=5 makes the Java version only 536 times faster than Ruby 2.8.

These are the kinds of optimizations MagLev is doing, and they don't translate into anywhere near the gains in actual code. So you see, you really need to rethink your tests. Even for something seemingly ok like modifying a global can depend on how it is modified and what the VM can optimize (+1 vs *5). Frankly I would just test these different Ruby implementations using the regular shootout code, since these have been designed not to be optimized out.