i've read both papers and footnote 11 in the original paper speaks directly to the criticism. the claimed discontinuity is an artifact of the chosen coordinate system, not the metric. redefine the coordinates and the problem goes away, but the math becomes much more hairy. my problem with the original paper is that they fit rotation curves with less than 30 data points with a model with 20 free parameters. of course it's going to fit.........
at our observatory we run several computers (and countless other digital devices) in the telescope chamber 24/7/365. we need to keep the chamber as close to nighttime ambient temperature as possible so this time of year those systems deal with temps down to -10 C or colder for extended periods of time. the temperature is never a problem in my experience, however. static electricity can be when it's really dry and lightning can be a big issue in the summer, though good UPSes and a big metal building help in that regard.
right now it's 5 C in the chamber and one of our shuttle SB51G boxes is reporting the following from lm_sensors:
M/B Temp: +25 C CPU Temp: +22 C Temp3: +19 C
quite reasonable and even if it were 10 C colder, it would still be close to or above freezing within the case. one key difference with our environment is that we take great care to maintain a chamber temp that's above the dewpoint and close the chamber when outside humidity is >90%. condensation can wreak havoc in hurry with optics, though i think computers are pretty safe as long as you keep them running.
at any rate, if i were a computer, i would be much happier in a minnesota garage in the winter than in an arizona garage in the summer:)
here's my experience with setting up a HP Color LaserJet 4600:
win 2k/XP - find way to add printer->select local printer->turn off probe for PnP printers->create new port->select standard tcp/ip port->enter printer ip number->click custom device type and then settings->click raw protocol and enter port 9100->enter printer driver info->click a few more next/finish buttons->print test page
linux (RH9 & FC1) - go to system settings->go to printing->enter root password->click forward->enter desired name and description->select networked jetdirect->type in printer hostname->click on printer manufacturer and then model->click finish and then print test page
OS X - go to the printer configuration utility and find the printer already detected, configured, and set to be the default
sure, the linux config could be worded somewhat more intuitively, but windows is a complete disaster for any non-SMB networked printer. the whole having to select 'local printer' to do it is just hysterical. at least linux refers to it as networked.... my only real niggle so far with the RH/fedora printer config tool is that the sharing properties are hidden under the Actions menu and it doesn't let you configure sharing on a per queue basis.
that all said, the rendezvous support in the HP printer is pretty damn sexy. any mac on the network sees it automatically and understands everything it can do. that's the way it's supposed to be. once i enabled the printer's CUPS support, then the linux boxes were almost there, too. poor windows users still need to go through that long drill, though....
i had the opposite experience with qwest. i called them up to order DSL and they said i couldn't get it even though i can almost hit their local switching office with a rock from my front door. didn't say why i couldn't get it, just that it wasn't possible. so i go to speakeasy.net and their on-line thingie said i could get it and the person i called confirmed that. went and ordered from them and the day before they were supposed to activate me, the qwest guys came by to twiddle something in the phone box outside my house. the covad guy came the next day, plugged stuff in, and DSL worked and i used it for a year. the only problems during that time were speakeasy related. i'm now on a cable modem with cox.net because it's $15/month cheaper than DSL, >=5 times faster, and way more reliable (speakeasy averaged at least 12 hours/month of downtime, often more). it was just too ironic and funny that qwest was too dumb to fix their own equipment to give me DSL, but happily made the fix so some other company could. no wonder their financial situation is such a mess...
they have boxes that sync off of either gps or cdma (for those places where you can't get a good view of the sky). the gps model with the stock oscillator can go several hours without satellites before it drifts too far and only needs a single satellite rather than a full multi-sat lock to sync its clock. upgraded oscillators are available for better and longer term stability. we use the gps version at our observatory to provide ~1 ms time over the network via ntp and ~10 us or better time via the PPS and kPPS outputs. we looked into hooking external gps receivers to PCs running ntpd via serial and PPS, but these praecis boxes are a much easier to configure and maintain solution to the problem and likely more robust as well.
even though it was a personal mess-up on the part of an employee, i'm really damn glad i found out about this exploit today. we've had several linux machines here get hacked into this week (older mandrake, RH 6.1, 6.2, and 7.1). the common denominator in all cases is that they were running wu-ftpd and it was open to the outside world. we'd been scratching our heads real hard since monday and now it all makes perfect sense. now everything's either updated or closed off. had we not known until dec 3, how many more machines would we have to clean up while not knowing what it was we needed to fix? i understand wanting to coordinate announcements and patches while minimizing advertising of exploits, but if something is actively being exploited, admins _need_ to know and need to know _as_soon_as_possible_. even if we can't fix wu-ftpd, we'd at least know we need to make sure it's turned off.
http://mindbright.se makes a really cool java-based ssh terminal client that works great either standalone or as a web applet. it's very full-featured, too, and is actually one of the better terminal emulators i've come across (i like it better than kvt/konsole, way way better than rxvt, xterm, color-xterm, but not quite as much as gnome-terminal; YMMV). it supports full ANSI color as well as at least some xterm control sequences (i have my prompt display host and path in the titlebar and it works in mindterm).
i keep a mindterm page on my linux box so that i can ssh in and do stuff from any relatively modern java-enabled browser (IE >= 4, NS > 4.06). handy for checking mail from cyber-cafes while traveling. if you have a JVM installed, it'd also be a great way to get a full-on terminal window under mac or winXX. way better than the lame telnet clients that are usually available. the license is GPL, but there are some restrictions due to the RSA algorithm that's used:(
while ground-based instruments don't have quite as good spatial resolution as hubble, they can have much greater light gathering power and, most importantly in this case, _much_ bigger fields of view. modern ground-based CCD mosaic systems can cover hundreds of times more sky in a single exposure than hubble's WFPC camera can. if you want to find rare objects like z>5 quasars, you need to cover a lot of square degrees on the sky and it's a lot easier to cover that on the ground with a big mosaic camera.
perhaps it is, but sun, HP, SGI, and i believe IBM put it in their unix kernels so to compete performance-wise, linux has to as well. the nice thing with linux is that you don't _have_ to. just compile a kernel without it and use the user-space nfs implementation, if you prefer.
however, once you see the performance diff, you'll likely want to stick with knfs. in my testing at home with a 10 MB network and at work at 100 MB i find that knfs is just about limited by wire/disk speed while user-nfs is several times slower. knfs is even faster than ftp by quite a bit, especially for reads. writes are generally 20-30% or so slower than reads due to using nfsv2.
tim
good book, but not great
on
The Sparrow
·
· Score: 1
the part that almost made me put the book down and quit reading was when they used arecibo to detect a signal from alpha cen. being a some-times radio astronomer, that just bugged the hell out of me. arecibo only points straight up and can't view anything more than 10-15 deg from being straight overhead while alpha cen only barely gets above the horizon in puerto rico. ok, ok, ok, i'm being a picky astronomer, but it's such a basic blunder in the author's research on the subject.
also, the part of how the church could cobble the money and technology to build a starcraft that powerful stretched credibility. how that particular cast of characters got chosen for the mission stretched it even more. of course, it had to so you'd get people that could make the series of boneheaded mistakes they made which comprise the story.
the 2nd book, children of god, goes more into the alien POV, but contains some really big contrivances of its own (now the mafia is building big-ass starships!). and the aliens aren't all that alien, anyway.
if you can suspend disbelief and ignore those numerous contrivances, the books are a pretty powerful character study. the switching of the story back and forth between rakhat and italy is effective in how it reveals the main characters layer by layer. it worked for me, anyway. however, the sci fi part of things seemed to me to be somewhat feebly cobbled together to set up the character study. as some other poster mentioned, dan simmons covered similar territory much more effectively in the hyperion series.
i give the sparrow a 6/10 and children of god a 7/10.
i've picked up three deskstars in the past year (two 10.1 GB 5400 rpm drives and a 14.4 GB 7200 rpm one). so far they haven't given me any probs and give good performance (12-15 MB/sec). i think the 13 GB one will be even faster since it's newer and has higher density platters.
the only drive make i've personally had problems with is western digital. i had a 2.1 GB drive from them that was flaky from day 1 and several friends and coworkers have had WD drives go south on them. even recently they had a bad batch of drives that had to be recalled.
every drive maker has a non-zero failure rate, though, so it's a matter of how low it is and how well they'll treat you if something goes wrong. in my experience and from what i've read elsewhere, IBM is as good or better than anyone else in both regards.
i recently splurged and got their jerker (sounds better in swedish:) computer desk and it totally rocks! it actually wasn't too expensive, about US$200 including the extra top shelf, side platforms, and document trays. here's a pic of it before it was buried under clutter:
unfortunately, the US website doesn't appear to list it so i'm not sure if one can get it there ( i got mine in NL). if you can find it, it's worth it. it's one of the coolest (IMHO) computer tables i've seen anywhere.
yeah, sitting down and rewriting IDL from scratch would be a huge effort and not bloody likely, but some free things like perl/PDL are coming close to providing near equivalent functionality for data manipulation and plotting.
i think it's rather elitist for big, money-rich centers like ESA or NASA to choose to standardize on expensive solutions like IDL. the $1500 or so per license is a very big chunk of the computing budget for many small departments.
for you perl-headed number crunchers out there, check out the PDL package from CPAN or from http://grimbergen.astro.rug.nl/~tim/PDL/ if you want rpms. it's not yet a full-on replacement for IDL, but it does plots well, is reasonably fast, and is a helluva a lot more fun to program. it has some slick opengl plotting capabilities, too. for general purpose data manipulation and plotting PDL is pretty powerful and i wouldn't dream of moving from it to IDL. i'm forced to use IDL for one of my projects and i _really_ dislike it.
for python users, there's the NumPy package that's roughly analogous to PDL as well as a python interface to the pgplot graphics library. i don't have much personal experience with python, though.
IDL is kind of the exception since most major software packages used in astronomy are free if not open source. heck, aips is even GPL'ed.
if i hear the words "linux fragmenting" once more i'm gonna scream! people miss the _very_ important point that unix fragmentation was as much, if not more, HARDware fragmentation as SOFTware. the software fragmentation followed because the unix players wanted to differentiate their products to help sell more hardware and protect their markets.
sure, linux dists differ in flavour somewhat, but they are all binary compatible within a given arch which is an important distinction. heck, most other x86 unices can run linux binaries as well. with widespread binary compatibility like that, i just don't see how linux could fragment that deeply.
and problems with things breaking between releases is hardly specific to linux. pretty much every OS i've ever used has caused headaches when upgrading to new releases. or, in the case of NT, even between service packs.
i think it'll help having something like the LSB which will state in writing what "linux" is and what it includes, but even without it there's enough of a base and momentum that code forking of the level of the old unices or even the various *BSD species on x86 is very unlikely. and if M$ ever came out with a linux dist, that would be a clear sign that they're admitting defeat to linux's world domination.
i don't know if it was the same brand, but i saw a similar camera that was put up at the LBT so people could grab pseudo-realtime pix of the construction of the observatory while it happened. pretty slick thingie. just plug 10base-T into the back and you could browse it directly, though i think they just set up a cron job on the nearby sparc to grab pix every min or so. i also don't remember the cost, but it would save a _LOT_ of time and headaches spent playing with drivers and stuff.
sounds like someone read gregory benford's recent book, cosm, and got scared. in cosm, they didn't make a black hole with RHIC, though, but a mini-universe. the only person who got fragged was a grad student who stood too close when the mini-universe underwent recombination.
yeah, i had pretty decent luck with 5.0, but i certainly recall all the griping about it which is why the griping about 6.0 feels like deja vu. and we know that by 5.2, most of the kinks were ironed out and they ended up with a solid distro. the x.0 releases of RH (and many other things) should really be treated as pseudo-betas (gammas?). yeah, it sucks that they aren't completely bug-free, but it takes eyes to see and fix bugs and the best way to get more eyes is to release early and often. that said, though, there were a couple boners in 6.0 that could have been avoided with just a little testing.
as far as bugzilla, i've had pretty good luck with responses post-6.0, even within the first week or two of release (the apmd thing, for example). i think they were also kind of swamped with people wanting breaks after the release plus the linux expo they were hosting.
every x.0 redhat release since 2.0 (which i started with) has caused people grief. i've had my share of problems with 6.0 (install not mounting/home or/usr properly, apmd messing up TZ info, latex getting hosed, scientific apps like IDL and IRAF not working with glibc2.1, etc.), but i certainly had problems with earlier x.0 releases as well. 4.0 was an even bigger mess than 6.0. 5.0 didn't seem as bad, though i did have to spend several evenings rebuilding stuff to work with glibc. now that i have 6.0 running, it runs fine and i don't have any stability problems with either KDE or gnome/E.
redhat really tries to push the latest technology into their x.0 releases, sometimes perhaps before they're ready (glibc in 5.0, gnome in 6.0). they did at least make betas available for 5.0 and 6.0, but how many people really tried them out? and how many other current dists are running glibc2.1 even though it's been clearly stated that it will be a key part of the LSB? i for one appreciate redhat taking the risks of staying out on the bleeding edge. it would be really easy for them to be safe and corporate and let others innovate and take the heat.
redhat also has a good bug tracking system in the form of bugzilla.redhat.com that i encourage all redhat users to take advantage of when they find a bug or a problem. the more people take advantage of it, the better redhat 6.1, 6.2, and later will be.
the 12 billion year age they give is misleading because it makes assumptions about the parameters other than the hubble constant that are used in determining it. it really should be treated as a lower limit. a fairer age estimate based on what we currently know or don't know about the hubble constant, density of the universe, and existence of a cosmological constant would be something like 20 +/- 10 billion years.
observations of certain species of stars called "Cepheid" variables were used to obtain these results. these kinds of stars have a well-defined relation between their period and luminosity. so if you can measure how fast they vary, you can derive fairly accurately how intrinsically bright they are. once you know how intrinsically bright they are, you can use that together with how bright you observe them to be to get their distances. do this for a bunch of these stars in a galaxy and you can get a fairly accurate distance to that galaxy. this team did just that for a bunch of galaxies out to much greater distances than was possible from the ground before HST and thus derived the Hubble constant.
so, the Hubble constant was the end and Cepheids were the means.
when they say "expanding universe", they mean that indeed space itself is expanding. the matter in the universe is just being carried along for the ride. expanding/contracting space is one of the profound predictions of einstein's theory of general relativity, though he didn't believe it at first and added a constant to cancel it out. a few years later when edwin hubble discovered observationally that the universe was expanding, einstein regretted adding the constant and dubbed it his "greatest mistake".
however, there is now evidence that some form of that constant is needed so al might have been right in the first place.
the hubble constant is only one of the parameters you need to calculate the age of the universe. the overall mass density (commonly expressed as q_0 = mass density/critical density for collapse) and the cosmological constant (if any) are also needed. the 12 billion years is derived assuming the mass density is equal to the critical density for eventual collapse (a flat universe; q_0 = 1) and no cosmological constant. however, we don't really yet know what the values for these other parameters are, even to within a factor of two. current best estimates favor q_0 less than 1 and a nonzero cosmological constant which can result in ages of 15-20 billion years or more for the universe.
the hubble constant is a hard thing to measure right and it's taken decades of work to get it to within 10%. measuring q_0 and the cosmological constant to a similar precision is decades more away, i think.
tim (i'm not a cosmologist, but i play one at work)
actually, things like rdist, cron, rpm, autorpm, logwatch, etc. are the biggest advantages to running linux over NT. with linux it's really easy using these free tools to keep a network of boxen synced up and admin'd remotely and automatically. you don't even really need NFS or NIS if you're clever, though they can simplify things. with NT, there's always stuff that needs registry diddling or local installation which makes admin'ing remotely or for a large number of machines problematic. with linux, once you know how to handle 5 machines, say, handling 50 or 500 isn't that much harder if you do it right.
back where i used to work, we had one guy handle over 150 solaris boxes plus dozens of xterms and network printers by himself (using mostly cron, scripts, rdist, and NFS with no NIS or NIS+; pretty much everything he does could be applied to linux and probably simplified). in contrast, they have 3 people full-time for a smaller number of NT/95/98 boxes and they still have trouble keeping up.
Slashdot Mirror
i've read both papers and footnote 11 in the original paper speaks directly to the criticism. the claimed discontinuity is an artifact of the chosen coordinate system, not the metric. redefine the coordinates and the problem goes away, but the math becomes much more hairy. my problem with the original paper is that they fit rotation curves with less than 30 data points with a model with 20 free parameters. of course it's going to fit.........
at our observatory we run several computers (and countless other digital devices) in the telescope chamber 24/7/365. we need to keep the chamber as close to nighttime ambient temperature as possible so this time of year those systems deal with temps down to -10 C or colder for extended periods of time. the temperature is never a problem in my experience, however. static electricity can be when it's really dry and lightning can be a big issue in the summer, though good UPSes and a big metal building help in that regard.
:)
right now it's 5 C in the chamber and one of our shuttle SB51G boxes is reporting the following from lm_sensors:
M/B Temp: +25 C
CPU Temp: +22 C
Temp3: +19 C
quite reasonable and even if it were 10 C colder, it would still be close to or above freezing within the case. one key difference with our environment is that we take great care to maintain a chamber temp that's above the dewpoint and close the chamber when outside humidity is >90%. condensation can wreak havoc in hurry with optics, though i think computers are pretty safe as long as you keep them running.
at any rate, if i were a computer, i would be much happier in a minnesota garage in the winter than in an arizona garage in the summer
tim
here's my experience with setting up a HP Color LaserJet 4600:
win 2k/XP - find way to add printer->select local printer->turn off probe for PnP printers->create new port->select standard tcp/ip port->enter printer ip number->click custom device type and then settings->click raw protocol and enter port 9100->enter printer driver info->click a few more next/finish buttons->print test page
linux (RH9 & FC1) - go to system settings->go to printing->enter root password->click forward->enter desired name and description->select networked jetdirect->type in printer hostname->click on printer manufacturer and then model->click finish and then print test page
OS X - go to the printer configuration utility and find the printer already detected, configured, and set to be the default
sure, the linux config could be worded somewhat more intuitively, but windows is a complete disaster for any non-SMB networked printer. the whole having to select 'local printer' to do it is just hysterical. at least linux refers to it as networked.... my only real niggle so far with the RH/fedora printer config tool is that the sharing properties are hidden under the Actions menu and it doesn't let you configure sharing on a per queue basis.
that all said, the rendezvous support in the HP printer is pretty damn sexy. any mac on the network sees it automatically and understands everything it can do. that's the way it's supposed to be. once i enabled the printer's CUPS support, then the linux boxes were almost there, too. poor windows users still need to go through that long drill, though....
tim
i had the opposite experience with qwest. i called them up to order DSL and they said i couldn't get it even though i can almost hit their local switching office with a rock from my front door. didn't say why i couldn't get it, just that it wasn't possible. so i go to speakeasy.net and their on-line thingie said i could get it and the person i called confirmed that. went and ordered from them and the day before they were supposed to activate me, the qwest guys came by to twiddle something in the phone box outside my house. the covad guy came the next day, plugged stuff in, and DSL worked and i used it for a year. the only problems during that time were speakeasy related. i'm now on a cable modem with cox.net because it's $15/month cheaper than DSL, >=5 times faster, and way more reliable (speakeasy averaged at least 12 hours/month of downtime, often more). it was just too ironic and funny that qwest was too dumb to fix their own equipment to give me DSL, but happily made the fix so some other company could. no wonder their financial situation is such a mess...
tim
http://www.endruntechnologies.com/
they have boxes that sync off of either gps or cdma (for those places where you can't get a good view of the sky). the gps model with the stock oscillator can go several hours without satellites before it drifts too far and only needs a single satellite rather than a full multi-sat lock to sync its clock. upgraded oscillators are available for better and longer term stability. we use the gps version at our observatory to provide ~1 ms time over the network via ntp and ~10 us or better time via the PPS and kPPS outputs. we looked into hooking external gps receivers to PCs running ntpd via serial and PPS, but these praecis boxes are a much easier to configure and maintain solution to the problem and likely more robust as well.
tim
even though it was a personal mess-up on the part of an employee, i'm really damn glad i found out about this exploit today. we've had several linux machines here get hacked into this week (older mandrake, RH 6.1, 6.2, and 7.1). the common denominator in all cases is that they were running wu-ftpd and it was open to the outside world. we'd been scratching our heads real hard since monday and now it all makes perfect sense. now everything's either updated or closed off. had we not known until dec 3, how many more machines would we have to clean up while not knowing what it was we needed to fix? i understand wanting to coordinate announcements and patches while minimizing advertising of exploits, but if something is actively being exploited, admins _need_ to know and need to know _as_soon_as_possible_. even if we can't fix wu-ftpd, we'd at least know we need to make sure it's turned off.
tim
i keep a mindterm page on my linux box so that i can ssh in and do stuff from any relatively modern java-enabled browser (IE >= 4, NS > 4.06). handy for checking mail from cyber-cafes while traveling. if you have a JVM installed, it'd also be a great way to get a full-on terminal window under mac or winXX. way better than the lame telnet clients that are usually available. the license is GPL, but there are some restrictions due to the RSA algorithm that's used :(
tim
while ground-based instruments don't have quite as good spatial resolution as hubble, they can have much greater light gathering power and, most importantly in this case, _much_ bigger fields of view. modern ground-based CCD mosaic systems can cover hundreds of times more sky in a single exposure than hubble's WFPC camera can. if you want to find rare objects like z>5 quasars, you need to cover a lot of square degrees on the sky and it's a lot easier to cover that on the ground with a big mosaic camera.
tim
perhaps it is, but sun, HP, SGI, and i believe IBM put it in their unix kernels so to compete performance-wise, linux has to as well. the nice thing with linux is that you don't _have_ to. just compile a kernel without it and use the user-space nfs implementation, if you prefer.
however, once you see the performance diff, you'll likely want to stick with knfs. in my testing at home with a 10 MB network and at work at 100 MB i find that knfs is just about limited by wire/disk speed while user-nfs is several times slower. knfs is even faster than ftp by quite a bit, especially for reads. writes are generally 20-30% or so slower than reads due to using nfsv2.
tim
the part that almost made me put the book down and quit reading was when they used arecibo to detect a signal from alpha cen. being a some-times radio astronomer, that just bugged the hell out of me. arecibo only points straight up and can't view anything more than 10-15 deg from being straight overhead while alpha cen only barely gets above the horizon in puerto rico. ok, ok, ok, i'm being a picky astronomer, but it's such a basic blunder in the author's research on the subject.
also, the part of how the church could cobble the money and technology to build a starcraft that powerful stretched credibility. how that particular cast of characters got chosen for the mission stretched it even more. of course, it had to so you'd get people that could make the series of boneheaded mistakes they made which comprise the story.
the 2nd book, children of god, goes more into the alien POV, but contains some really big contrivances of its own (now the mafia is building big-ass starships!). and the aliens aren't all that alien, anyway.
if you can suspend disbelief and ignore those numerous contrivances, the books are a pretty powerful character study. the switching of the story back and forth between rakhat and italy is effective in how it reveals the main characters layer by layer. it worked for me, anyway. however, the sci fi part of things seemed to me to be somewhat feebly cobbled together to set up the character study. as some other poster mentioned, dan simmons covered similar territory much more effectively in the hyperion series.
i give the sparrow a 6/10 and children of god a 7/10.
tim
i've picked up three deskstars in the past year (two 10.1 GB 5400 rpm drives and a 14.4 GB 7200 rpm one). so far they haven't given me any probs and give good performance (12-15 MB/sec). i think the 13 GB one will be even faster since it's newer and has higher density platters.
the only drive make i've personally had problems with is western digital. i had a 2.1 GB drive from them that was flaky from day 1 and several friends and coworkers have had WD drives go south on them. even recently they had a bad batch of drives that had to be recalled.
every drive maker has a non-zero failure rate, though, so it's a matter of how low it is and how well they'll treat you if something goes wrong. in my experience and from what i've read elsewhere, IBM is as good or better than anyone else in both regards.
tim
http://www.astro.rug.nl/~tim/desk.jpg
unfortunately, the US website doesn't appear to list it so i'm not sure if one can get it there ( i got mine in NL). if you can find it, it's worth it. it's one of the coolest (IMHO) computer tables i've seen anywhere.
tim
yeah, sitting down and rewriting IDL from scratch would be a huge effort and not bloody likely, but some free things like perl/PDL are coming close to providing near equivalent functionality for data manipulation and plotting.
i think it's rather elitist for big, money-rich centers like ESA or NASA to choose to standardize on expensive solutions like IDL. the $1500 or so per license is a very big chunk of the computing budget for many small departments.
tim
for you perl-headed number crunchers out there, check out the PDL package from CPAN or from http://grimbergen.astro.rug.nl/~tim/PDL/ if you want rpms. it's not yet a full-on replacement for IDL, but it does plots well, is reasonably fast, and is a helluva a lot more fun to program. it has some slick opengl plotting capabilities, too. for general purpose data manipulation and plotting PDL is pretty powerful and i wouldn't dream of moving from it to IDL. i'm forced to use IDL for one of my projects and i _really_ dislike it.
for python users, there's the NumPy package that's roughly analogous to PDL as well as a python interface to the pgplot graphics library. i don't have much personal experience with python, though.
IDL is kind of the exception since most major software packages used in astronomy are free if not open source. heck, aips is even GPL'ed.
tim
if i hear the words "linux fragmenting" once more i'm gonna scream! people miss the _very_ important point that unix fragmentation was as much, if not more, HARDware fragmentation as SOFTware. the software fragmentation followed because the unix players wanted to differentiate their products to help sell more hardware and protect their markets.
sure, linux dists differ in flavour somewhat, but they are all binary compatible within a given arch which is an important distinction. heck, most other x86 unices can run linux binaries as well. with widespread binary compatibility like that, i just don't see how linux could fragment that deeply.
and problems with things breaking between releases is hardly specific to linux. pretty much every OS i've ever used has caused headaches when upgrading to new releases. or, in the case of NT, even between service packs.
i think it'll help having something like the LSB which will state in writing what "linux" is and what it includes, but even without it there's enough of a base and momentum that code forking of the level of the old unices or even the various *BSD species on x86 is very unlikely. and if M$ ever came out with a linux dist, that would be a clear sign that they're admitting defeat to linux's world domination.
tim
i don't know if it was the same brand, but i saw a similar camera that was put up at the LBT so people could grab pseudo-realtime pix of the construction of the observatory while it happened. pretty slick thingie. just plug 10base-T into the back and you could browse it directly, though i think they just set up a cron job on the nearby sparc to grab pix every min or so. i also don't remember the cost, but it would save a _LOT_ of time and headaches spent playing with drivers and stuff.
tim
sounds like someone read gregory benford's recent book, cosm, and got scared. in cosm, they didn't make a black hole with RHIC, though, but a mini-universe. the only person who got fragged was a grad student who stood too close when the mini-universe underwent recombination.
tim
yeah, i had pretty decent luck with 5.0, but i certainly recall all the griping about it which is why the griping about 6.0 feels like deja vu. and we know that by 5.2, most of the kinks were ironed out and they ended up with a solid distro. the x.0 releases of RH (and many other things) should really be treated as pseudo-betas (gammas?). yeah, it sucks that they aren't completely bug-free, but it takes eyes to see and fix bugs and the best way to get more eyes is to release early and often. that said, though, there were a couple boners in 6.0 that could have been avoided with just a little testing.
as far as bugzilla, i've had pretty good luck with responses post-6.0, even within the first week or two of release (the apmd thing, for example). i think they were also kind of swamped with people wanting breaks after the release plus the linux expo they were hosting.
tim
every x.0 redhat release since 2.0 (which i started with) has caused people grief. i've had my share of problems with 6.0 (install not mounting /home or /usr properly, apmd messing up TZ info, latex getting hosed, scientific apps like IDL and IRAF not working with glibc2.1, etc.), but i certainly had problems with earlier x.0 releases as well. 4.0 was an even bigger mess than 6.0. 5.0 didn't seem as bad, though i did have to spend several evenings rebuilding stuff to work with glibc. now that i have 6.0 running, it runs fine and i don't have any stability problems with either KDE or gnome/E.
redhat really tries to push the latest technology into their x.0 releases, sometimes perhaps before they're ready (glibc in 5.0, gnome in 6.0). they did at least make betas available for 5.0 and 6.0, but how many people really tried them out? and how many other current dists are running glibc2.1 even though it's been clearly stated that it will be a key part of the LSB? i for one appreciate redhat taking the risks of staying out on the bleeding edge. it would be really easy for them to be safe and corporate and let others innovate and take the heat.
redhat also has a good bug tracking system in the form of bugzilla.redhat.com that i encourage all redhat users to take advantage of when they find a bug or a problem. the more people take advantage of it, the better redhat 6.1, 6.2, and later will be.
tim
that's what i get for leaving my brain at home. when i said q_0, i really meant Omega. Omega = 2*q_0, anyway, so i was only off by a factor of two.
:)
at least i said i wasn't a cosmologist
tim
the 12 billion year age they give is misleading because it makes assumptions about the parameters other than the hubble constant that are used in determining it. it really should be treated as a lower limit. a fairer age estimate based on what we currently know or don't know about the hubble constant, density of the universe, and existence of a cosmological constant would be something like 20 +/- 10 billion years.
tim
observations of certain species of stars called "Cepheid" variables were used to obtain these results. these kinds of stars have a well-defined relation between their period and luminosity. so if you can measure how fast they vary, you can derive fairly accurately how intrinsically bright they are. once you know how intrinsically bright they are, you can use that together with how bright you observe them to be to get their distances. do this for a bunch of these stars in a galaxy and you can get a fairly accurate distance to that galaxy. this team did just that for a bunch of galaxies out to much greater distances than was possible from the ground before HST and thus derived the Hubble constant.
so, the Hubble constant was the end and Cepheids were the means.
tim
yeah, the theory of general relativity :)
when they say "expanding universe", they mean that indeed space itself is expanding. the matter in the universe is just being carried along for the ride. expanding/contracting space is one of the profound predictions of einstein's theory of general relativity, though he didn't believe it at first and added a constant to cancel it out. a few years later when edwin hubble discovered observationally that the universe was expanding, einstein regretted adding the constant and dubbed it his "greatest mistake".
however, there is now evidence that some form of that constant is needed so al might have been right in the first place.
tim
the hubble constant is only one of the parameters you need to calculate the age of the universe. the overall mass density (commonly expressed as q_0 = mass density/critical density for collapse) and the cosmological constant (if any) are also needed. the 12 billion years is derived assuming the mass density is equal to the critical density for eventual collapse (a flat universe; q_0 = 1) and no cosmological constant. however, we don't really yet know what the values for these other parameters are, even to within a factor of two. current best estimates favor q_0 less than 1 and a nonzero cosmological constant which can result in ages of 15-20 billion years or more for the universe.
the hubble constant is a hard thing to measure right and it's taken decades of work to get it to within 10%. measuring q_0 and the cosmological constant to a similar precision is decades more away, i think.
tim (i'm not a cosmologist, but i play one at work)
actually, things like rdist, cron, rpm, autorpm, logwatch, etc. are the biggest advantages to running linux over NT. with linux it's really easy using these free tools to keep a network of boxen synced up and admin'd remotely and automatically. you don't even really need NFS or NIS if you're clever, though they can simplify things. with NT, there's always stuff that needs registry diddling or local installation which makes admin'ing remotely or for a large number of machines problematic. with linux, once you know how to handle 5 machines, say, handling 50 or 500 isn't that much harder if you do it right.
back where i used to work, we had one guy handle over 150 solaris boxes plus dozens of xterms and network printers by himself (using mostly cron, scripts, rdist, and NFS with no NIS or NIS+; pretty much everything he does could be applied to linux and probably simplified). in contrast, they have 3 people full-time for a smaller number of NT/95/98 boxes and they still have trouble keeping up.
tim