Slashdot Mirror

I've mirrored the Galeon 2 web page and screenshots here.
I sure hope Mozilla gets ported to gtk2 quickly, and maybe even Garnome features Galeon2 soon.

What an idiot. Firstly, there's the false impliction that since a guy at CERN wrote the first specs for the WWW that this means the internet was made by Europeans. (First off, it was the university of illinois that was communicating with CERN that worked on actually making mosaic and httpd to implement the spec, and secondly there's the fact that "the internet" != "the WWW".)

Yeah, yeah, we know. Just because the original graphical web client was written at CERN (in Switzerland, not the United States) by Tim Berners Lee (an Englishman, not an American), and the original HTTPD was written at CERN, isn't important because it's the first American implementation that goes in the history books. The American history books can comfortably ignore the fact that the University of Manchester (that's Manchester, England) had a programmable computer before anywhere in the United States, because, hey, England's a long long way away and probably doesn't really exist anyway. I could go on.

Bill Thompsons article is over the top and fundamentally wrong headed, but this is exactly the sort of blind, ignorant, narrow, uneducated US arrogance which makes you so disliked in the rest of the world, and which irritates people like Bill enough to make them go over the top.

For the record: no, you didn't invent the Internet. You didn't invent packet switched networking. You did build ARPAnet, at about the same time as the UK built JANET (and other European countries developed similar initiatives); and later, ARPAnet, JANET and several other networks were linked together to form the Internet. For the record, my first email address was @uk.ac.lancs.csvax, because the UK equivalent of DNS ordered name segments from the most general to the most particular.

Not when you're using a browser that doesn't come with flash...

gprof is maybe not the most impressive tool to use, but it's quite useful. At a IA64 course at university [German, sorry] we used gprof to identify the bottlenecks in the c-code of the xvid-codec. Then we assembler-optimized like mad and got quite a nice speed-up.

Result can be found in our wiki:

gprof is maybe not the most impressive tool to use, but it's quite useful. At a IA64 course at university [German, sorry] we used gprof to identify the bottlenecks in the c-code of the xvid-codec. Then we assembler-optimized like mad and got quite a nice speed-up.

Result can be found in our wiki:

gprof is maybe not the most impressive tool to use, but it's quite useful. At a IA64 course at university [German, sorry] we used gprof to identify the bottlenecks in the c-code of the xvid-codec. Then we assembler-optimized like mad and got quite a nice speed-up.

Result can be found in our wiki:

The Spanish Talgo is in the works and will do 350 kph (218 mph).

Currently Spain has AVE from Madrid to Seville. Madrid - Barcelona and others are scheduled.

info in english

If you want an example of how slow Opera renders a simple page, have a look at this page.

let's see. 1 GB in 10 ms works out to 100 GB per second. how recently did GB ethernet come about? and what would the average bandwidth of users be? i would guess much less, but let us assume 100KB per second.

Well 100 GB per second is the raw data rate, as read out (heavily parallel) from the detector, i.e. the data rate the DAQ (Data AQuisition) system has to keep up with. That's pretty difficult really, but done completely in hardware: the readout chips have relatively large on-chip buffers for each read-out channel. NOST OF THIS DATA IS DISCARDED RIGHT AWAY from the so-called Level 1 Trigger, whose purpose is to throw away the most obviously uninteresting collisions.

Since the data rate after L1 is still WAY too large to be all stored, another trigger, unimaginatively called Level 2 Trigger, sorts out even more crap. Since the data rate is lower than for L1, L2 can use more sophisticated algorithms to figure out which event is crap and which is an ever-famous Higgs decay :-)

One more trigger, Level 3 (you guessed it), is used to even further reduce the amount of data, again with more sophisticated means.

Still, the required bandwidth is quite impressive. At CDF II, the data rate after Level 3 will be about 75 events per second, at half a meg each, summing up to 30-40 MB per second (well enough to saturate Gbit ethernet), which are all reconstructed right away.Note that for the LHC experiments (CMS, ATLAS) the amount of data is more than an order of magnitude larger than for CDF and D0 (at Fermilab).

The LHC data will be spread all over the world, using a multi-tier architecture with CERN being Tier 0, and national computing centers as Tier 1 centers, universities being Tier 2, etc. No national computing center will be able to store ALL data, so the idea is that e.g. your Higgs search will be conducted on the U.S. Tier 1 center, B physics on the German Tier 1 center and so on. Obviously not only US scientists will search for the Higgs, so others will also submit analysis jobs on the US Tier 1 and vice versa. To get this working, the GRID is designed. A current implementation is GLOBUS.

Having said this, it is important to note that right now, the GRID is nowhere near this goal. To submit jobs in this "fire and forget" way is not possible yet. There is a shitload of problems to yet solve, the most important ones: trust and horsepower.

Trust: you must allow complete strangers to utilize your multi-million dollar cluster, and they haven't even signed a term-of-use form.

Horsepower: everybody expects to get more CPU cycles out of the GRID than he/she contributes. Obviously, this will not work. (Albeit the load levveling might improve the overall performance.)

In many present and (not so far) future experiments in HEP we deal with this kind of data rate. A nice overview can be found here here.

On page 14 you can find the data valume. It is at about 100 TB for present experiments (I am with BaBar).

page 25 gives some overview on the hardware we use at BaBar/SLAC (e.g. farms of STK Powderhorn tape silos with 6000 tapes each, etc..).

page 95 gives an overview on data rates. ATLAS records at 100Hz and 1MB per event, i.e. 100MB/s

Page 99 gives overview of the (estimated) costs of hardware and tapes for LHC experiments. They are in the order of 20 MCHF (Mega Swiss Franks ~ 0.8 Mega Dollar) initial + 10 MCHF per year. We use a mixture of large RAID farms and tape silos. Everything is managed by HPSS (High Performance Storage System). From my experience at BaBar I can tell you that these numbers are underestimated by at least a factor of 2.

The languages you mentioned were all OO or procedural languages. Take a look at functional, logic, stack-based, vector languages or multi-paradigm ones.

Have a look at: http://www.uni-karlsruhe.de/~uu9r/lang/html/lang.e n.html. I put up this page to make it myself easier to get a feeling for or to remeber a language. Interesting languages (my opinion) and different ones are listed below:

Vector-based:

• APL
• J: "APL without ASCII character set" (*)
• K

Stack-based:

• Forth (*)
• Postscript

Functional:

• OCaml: Very fast, nearly as fast as C; OO and imperative features (*)
• Haskell, Gofer: pure, lazy functional language (*)
• Concurrent Clean: (*)
• Pliant: dynamic extensible parser (a bit Lisp-style)
• Aleph: Scheme-like language; used in the operating system Plan9 for many tasks
• FISh: "Functional = Imperative + Shape", very fast

Funny/Strange/Useless:

• Befunge
• BrainF*ck

OO:

• Beta: Pattern-concept (*)
• Sather: Eiffel-dialect with many additional concepts, like closures (*)
• Dylan
• Simula: As background for C++ and other languages
• C-Talk: Mixture of C++, Smalltalk, Lisp and CLU
• Brain: Smalltalk-ish scripting language
• Tom: Mixture of Objective-C + Smalltalk

Multiparadigm:

• Leda: Imperative, OO, functional and logic
• Mercury: Functional + Logic

Logic/Declarative:

• Prolog: for knowledge bases etc.. (*)

Distributed:

• Oz/Mozart: dynamic typed language applicable for mobile agents etc.. (*)
• JoCaml: OCaml dialect extended for Join-Pattern (Thread synchronization) and networking (*)

I've put a (*) to the languages I find very interesting. Those should be worth for a short look at it.

OT:
I've seen and leaned many languages, most of them were not usable for Real-World applications. I go on to look for new languages, but for now, my language of choice is Ruby.

I worked with Perl, wrote several thousands lines of code, but I found it too complicated and hard to learn and error-prone (for my programs). I am sure if you have spend some time with Perl, and you have become a "Perl hacker" you can code very efficient and write good code. But with Ruby or Python you don't have to learn that much.

As I first came across Python (~ 1.5) I was really happy - it was my first interpreted language, since GFA BASIC on the Atari - and impressed about it. It took me serveral days to read through the Python manual. Then one night, I found a link to Ruby at http://www.cetus-links.org (this was Ruby 1.3 - today 1.7). I read the Ruby Users Guide by GOTO Kentaro and was able to code little program in Ruby in the same night. In my opinion it was a lot easier than Python but equal powerful. (I don't know much about the features of Python today.

Now some years ago I still love Ruby and it's nice community, but I am open for all the other nice languages around there.

Regards, Michael

the performance variability due to different programmers... is on average as large or even larger than the variability due to different languages

In other words, if engineers spent more time studying best practices and efficient algorithm design, that might well improve performance more than spending time in religious wars about the merits of pet languages.

In my experience, basic performance tuning can easily create an order of magnitude improvement regardless of the language. And in my experience, most engineers don't know how to do basic performance tuning. That's got to be more important than language selection in the average case.

Tim

While waiting for Doug's server to be unslashdotted, you can also check out an earlier effort, Lutz Prechelt's PhoneCode Project in which competitive implementations of the same problem in different languages were measured on several criteria.
Doug's project is much more ambitious, but since he wrote most of the code it may not be as competitively written.

unfortunately, there don't seem to be many comparing perl with visual basic. However, there are many comparing perl to other things. Maybe you can figure out what you think based on how simmilar you think visual basic is to java, tcl, or one of the others featured...

http://www.google.com/search?q=cache:wwwipd.ira.uk a.de/~prechelt/Biblio/jccpprtTR.pdf+comparison+per l+java+c&hl=en

http://ncstrl.ubka.uni-karlsruhe.de:8080/Dienst/UI /2.0/Describe/ncstrl.ubka_cs%2Firatr-2000-5 note: slashdot preview function revealed that the port 8080 in my post is being stripped out of the HREF by slash. So, the URL is as you see in text. The link will take you to that URL without the :8080. Just add the :8080 and you're back in business.

http://www-106.ibm.com/developerworks/web/library/ wa-sssl.html

http://www.pixeldate.com/dev/comparison/index.shtm l (see the refs section at end of article)

-matt

A friend of mine told me that computers at my uni library, or even the whole uni domain, can get access to the standars for free.. I can't confirm that, but of course he had in front of him a thick bundle of papers entitled "802.11". Yes it was the ISO standard. Is this the same in universities elsewhere? Well, they even give every student about 1000 sheets free for printing from the uni printer every semester, the beauty of German education system.

Um, this is on the server, where Microsoft dosen't have a monopoly, not even a plurality. According to netcraft, that title belongs to Apache.

So what's microsoft's problem?

There are a number of them, as I see it:

• Microsoft dosen't have a good mechenisim for staying up to date on the latest patches. For example, I can put security.debian.org in my /etc/apt/sources.list, and set cron to run apt-get upgrade nightly. This will automagically install any security patches with no user intervention. Even non-debian distributions have mechenisims like manually-installable packages and quick (and honest) reporting of security issues, which make it easy to stay up to date.
• Their closed-source and propietory systems extend the time between an exploit being found, and a usable patch being produced. For a classic example, look at the Ping of Death. Linux had a patch out in (exactly) 2 hours, 35 minutes, and 10 seconds. Microsoft took almost a month.
• This is the most important: Microsoft administraters tend not to be as good at network administration as Unix administraters. I'm not trying to insult any softies out there, and I'm sure there are some really good Microsoft admins and poor Unix admins, but with Microsoft handing out MCSE's to any dipshit who can memorize a questions book (but probably has no experence or training with security), it's bound to happen. Unix administraters have (generally) taught themselves, which means they have many years of practical experence with their OS, or learned Unix at a real academic instution, which means that they got more than just the crash course.

Bruce Schneier once called security a "process, not a product". Microsoft has tried to pretend that they are selling a product. That you go to the store, buy Microsoft Foo 2000, pull the disks out of the shrink wrap, and use it like you'd use a television or a vacume cleaner. An Operating System is too complex of a beast for that to be the case, and no amount of Wizards or flying folders is going to change that simple fact.

I haven't heard much mention of the change from ipchains to iptables. I have been waiting for the production 2.4 kernel release to update my firewall from 2.2.17 and would like to know how it works from someone who has taken the plunge already.

Whenever I read about these incredibly complex theories, like 11 dimensional superstrings, the M-theory, "sparticles", and what have you, it just reminds me of the "theories of planetary motion" that people used to come up with before they realized the earth goes around the sun.

Actually, SUSY (supersymmetry, that's where the sparticles come from) would simplify a great deal of things! For instance, it would unify the strong, weak, and electromagnetic forces. It would also explain dark matter. SUSY is really pretty elegant. The big drawback, however, is that it hasn't been observed yet... But due to the nature of the theory, SUSY is very hard to rule out by current experiments.

You might want to check the web page of one of our professors, he's got some talks on SUSY there.

I don't know much about string theories, but we had a speaker here for a seminar lately and from what I understand, string theories aren't fully understood yet.

Since the early days of relativity and quantum mechanics, physics in general has the problem that it's no longer "intuitive" as it was in Newton's days. Our everyday experience doesn't help us in understanding quantum phenomena. But just because it's no longer "graphic" it's far from being unsatisfactory.

Tetris Tetris Tetris Pacman Asteroids Centipede

And for you people that grew up on the kaypro, cloned Ladder! (Shameless self plug)

I'm sure you can any of the most popular games just with a quick search on google. :

can be found here. It is, however, in German legalese and may be hard to understand.

Big Brother System and Network Monitor NetSaint Network Monitor Network Monitor, Network Sniffer, Sniffer, IP Sniffer The Angel Network Monitor IPTraf - An IP Network Monitor Chesapeake's Network Monitor BigBen: Network Monitor Utility LG #28 ATM Network Monitor >> Brought to you by Google!

Here's another mirror...

Enjoy!

http://www.uni-karlsruhe.de/~ig25/ssh-faq/

As it points out, this will leave the data connection open to sniffing/hijacking. If you only care about the integrity of the files you transfer, then verifying against (securely obtained) md5 checksums should do the trick. If you want to encrypt the datastream, you'll need to be a bit more fancy.

If it's possible, consider the use of 'scp' instead of ftp; you'll get protection of both control and data, since it's built into ssh.

Another option (if you control the clients as well) is to use ssh2's "sftp" client. Beware the licensing issues with ssh2, however.

If you really trust the clients, it's also quite easy to set up a VPN between the client and server, and then FTP directly. The ways to go about this depend on the OS you're using, so I'll leave it as an exercise to the reader.