I like your "describing the beach" analogy, but you perhaps give astrophysicists/cosmologists less credit than they deserve. We certainly do have to do a lot of extrapolation to say anything about distant stars, galaxies etc, but we do get some breaks. An obvious example is emission lines: you can take a sample of gas in the lab, pass a current through it, and look at the frequencies of light it gives off. That list of frequencies gives you a 'fingerprint' for the gas you're looking at, and it's well understood in terms of quantum mechanics.
Now, when we look at distant stars or galaxies, we see exactly those same series of lines (modified systematically by redshift as appropriate), which tells us that quantum mechanics works the same in those stars/galaxies as it does here on earth.
At the same time, there is still a huge potential for uncertainty when trying to get more specific information, which is what makes astronomy/astrophysics so hard (and interesting:-). The Hubble constant issue that brought this up is a nice example: The WMAP results constrain H very tightly, and therefore, if there's no dark energy or cosmological constant, the predicted age of the universe (it's just 1/H, although the weird astrophysics units of km/s/Mpc seem designed to make that non-obvious) can be found very precisely - that is, with a small 'statistical' uncertainty - it may not necessarily be very *accurate* - that is, the reported value is close to the true value.
That might seem done and dusted, but as others have pointed out, there are other ways of constraining the age of the universe. An obvious way of getting a lower bound is to look at the oldest things we can find. Globular clusters are believed to be very old, and by modelling the evolution of these galaxies suggests that they're older than the age given by 1/H.
It's further complicated by things like the results of the High z supernova search, which suggests the universe is accelerating in its expansion, and so 1/H isn't a good measure of the age of the universe.
So, given all that, which do we believe, and how do you summarize the "age of the universe" in one number? Answers on a postcard to any well-regarded, peer-reviewed astrophysical journal...
Oh yeah, while I'm idly wondering, what are the odds of this making it into mainstream desktops ( stock gnome/kde )?
Well, to some extent it's already there: KWin uses COMPOSITE to do translucency and shadows, for example.
There are plans to extend use of these features in KDE 4. Zack Rusin from KDE, has been working on this sort of thing (you can see an interview with him from the Summer). There's also the Plasma project, which has beauty and usability as its key aims built in from the start.
And best of all, you can get involved and help make KDE 4 the best ever!
The paper itself suggests that observing the waves from such an event would have to wait until the "second generation" LIGOs. I assume by that it means advanced LIGO, which isn't scheduled to start taking measurements until 2013, so don't hold your breath:-). Even so, LIGO is an amazing project - the sensitivities required are enormous, (to quote the LIGO website: "These changes are minute: just 10-16 centimeters, or one-hundred-millionth the diameter of a hydrogen atom over the 4 kilometer length of the arm"), and the payoffs for theory and astronomy are potentially huge.
As to whether gravity is a wave, that's generally agreed (as someone else pointed out, measurements of binary pulsars show this). However, the exact details of general relativity in the strong field regime - that is, near black holes, neutron stars, etc - hasn't been well tested, and there are potentially modifications of general relativity which would give the same predictions for the weak field case (eg, the solar system), but would differ for strong fields. Physics World has a nice article on it.
While we're on the topic, does anyone know of a use for transparency apart from pretty eye candy? For all the fuss that's made about it (and not to take anything away from the effort of the X.org folks), I can't think of a particular use. Any suggestions?
Heh, yeah. But surely the complete translation of the GUI into British English, along with sizeable portions of the GUI translated into Welsh and Irish Gaelic, there's plenty of opportunity for usage this side of the pond.
Seriously, if you find a feature you like, fire off an email to thank the developer - it can make someone's day, and it's nice to see one's work being used and enjoyed.
You can find the relevant person for any KDE app with Help->"About " in the menus, or you can find plenty of developers on the kde-core-devel@kde.org and kde-devel@kde.org lists. And don't forget the artists, translators, promo team, accessibility team, doc writers, and the many other people who make KDE happen.
I'd like to widen the question that icefox put, to As a member of an open source team, what attitude and methods do you use towards recruitment?
I think this touches on a wider issue relating to open source (free software, peer-directed projects, whatever you want to call it), namely how we deal with the less strictly technical aspects of the software itself. Most of the discussion on, say, OSS mailing lists is directed towards coding, as of course it should be, since it's the software itself that is the object of the exercise. But there are plenty of other important and useful ways of improving software and people's experience of it: documentation, usability considerations, promotion, and so on.
Improving these aspects of software in an open-source model seems to be a very different task to writing code. It requires 'soft' skills - the ability to attract people, help them learn the ropes, and then retain them as contributors. In a business model, of course, you can pay people to do the marketing and the usability testing (say), but in an open project, you can't force people to do what they don't want to.
As a contributor to KDE for a few years now, I think we as a project have perhaps thought too little about these wider things, but what have other projects done about them? Do you rely on companies to sponsor developers (not necessarily coders!) who can work on these less popular areas, or do you require coders to provide, say, documentation or usability testing for their apps?
There's a lot more information about what will be going on at the KDE wiki at http://wiki.kde.org.
There are plenty of opportunities to contribute, too - even if you're not a programmer or 'power user'. Take a look, for example at KDE Community World Summit under "Coding Marathon" for a list of teams that will be present.
As an example, I'm on the documentation team, and we've got plenty planned. Check out KDE Documentation @ aKademy for more details.
On the topic of economics, here's some numbers I just whipped up:
LINX, the London Internet Exchange, deals with around 15Gb/s on average. 60% of that is a little over 1GB/s. Let's be conservative and call it 0.9GB/s. That's 77,000 GB/day (rounding down again), which is all P2P (so they claim).
That amount of data comes to 7,000,000 10MB music tracks, or 77,000 1GB video files. Now, Apple have proven that Joe Public will pay a reasonable amount for media offered legitimately, so let's assume that 10% of this P2P traffic could be converted to legitimate sales of music. So, assuming £0.60 (=$1) for a music track, or £4 (=$6.50) for a movie, that's a potential:
£42,000/day -> £15million/year of music sales
($25m/year)
or
£31,000/day -> £11million/year of movie sales
($18m/year)
And that's just in the UK!
Now, I know this isn't the point of the article, but there's a huge potential for the media companies we all moan about so much to make money, *and* for us to get the content we want (sans 9 tracks of filler for one good track) at the same time, and they're doing almost nothing about it. What am I missing?
(OK, so I guess someone who knows more about bandwidth usage and economics than me can make these figures more realistic, but you get an order of magnitude...)
Nobody seems to have mentioned the great advantages of DocBook here. Having written some bits of documentation for KDE, I've seen some of DocBook's advantages:
First off, it's fully compliant SGML or XML, whichever flavour you prefer. DocBook documents are stored as nice plain ASCII which can be processed with any SGML/XML tool you happen to have lying around.
Output options are virtually unlimited. IIRC, HTML, man, texinfo, plain text, (La)TeX and anything else you care to mention are available as output formats, with XSL providing a way to produce your own custom output.
The Crunch: Text is marked-up for what it is, not what it's meant to look like, so you needn't know a single thing about formatting while writing content and vice versa. You know the advantages of using CSS instead of hard-coding HTML. Well, they count for DocBook too.
Nifty features like creating tables of contents from the source and all that sort of thing that you thought only TeX could do.
I suppose I should mention that it's extensible, hence the XML version.
Slashdot Mirror
I like your "describing the beach" analogy, but you perhaps give astrophysicists/cosmologists less credit than they deserve. We certainly do have to do a lot of extrapolation to say anything about distant stars, galaxies etc, but we do get some breaks. An obvious example is emission lines: you can take a sample of gas in the lab, pass a current through it, and look at the frequencies of light it gives off. That list of frequencies gives you a 'fingerprint' for the gas you're looking at, and it's well understood in terms of quantum mechanics.
Now, when we look at distant stars or galaxies, we see exactly those same series of lines (modified systematically by redshift as appropriate), which tells us that quantum mechanics works the same in those stars/galaxies as it does here on earth.
At the same time, there is still a huge potential for uncertainty when trying to get more specific information, which is what makes astronomy/astrophysics so hard (and interesting :-). The Hubble constant issue that brought this up is a nice example: The WMAP results constrain H very tightly, and therefore, if there's no dark energy or cosmological constant, the predicted age of the universe (it's just 1/H, although the weird astrophysics units of km/s/Mpc seem designed to make that non-obvious) can be found very precisely - that is, with a small 'statistical' uncertainty - it may not necessarily be very *accurate* - that is, the reported value is close to the true value.
That might seem done and dusted, but as others have pointed out, there are other ways of constraining the age of the universe. An obvious way of getting a lower bound is to look at the oldest things we can find. Globular clusters are believed to be very old, and by modelling the evolution of these galaxies suggests that they're older than the age given by 1/H.
It's further complicated by things like the results of the High z supernova search, which suggests the universe is accelerating in its expansion, and so 1/H isn't a good measure of the age of the universe.
So, given all that, which do we believe, and how do you summarize the "age of the universe" in one number? Answers on a postcard to any well-regarded, peer-reviewed astrophysical journal...
Oh yeah, while I'm idly wondering, what are the odds of this making it into mainstream desktops ( stock gnome/kde )?
Well, to some extent it's already there: KWin uses COMPOSITE to do translucency and shadows, for example.
There are plans to extend use of these features in KDE 4. Zack Rusin from KDE, has been working on this sort of thing (you can see an interview with him from the Summer). There's also the Plasma project, which has beauty and usability as its key aims built in from the start.
And best of all, you can get involved and help make KDE 4 the best ever!
The paper itself suggests that observing the waves from such an event would have to wait until the "second generation" LIGOs. I assume by that it means advanced LIGO, which isn't scheduled to start taking measurements until 2013, so don't hold your breath :-). Even so, LIGO is an amazing project - the sensitivities required are enormous, (to quote the LIGO website: "These changes are minute: just 10-16 centimeters, or one-hundred-millionth the diameter of a hydrogen atom over the 4 kilometer length of the arm"), and the payoffs for theory and astronomy are potentially huge.
As to whether gravity is a wave, that's generally agreed (as someone else pointed out, measurements of binary pulsars show this). However, the exact details of general relativity in the strong field regime - that is, near black holes, neutron stars, etc - hasn't been well tested, and there are potentially modifications of general relativity which would give the same predictions for the weak field case (eg, the solar system), but would differ for strong fields. Physics World has a nice article on it.
While we're on the topic, does anyone know of a use for transparency apart from pretty eye candy? For all the fuss that's made about it (and not to take anything away from the effort of the X.org folks), I can't think of a particular use. Any suggestions?
Heh, yeah. But surely the complete translation of the GUI into British English, along with sizeable portions of the GUI translated into Welsh and Irish Gaelic, there's plenty of opportunity for usage this side of the pond.
Seriously, if you find a feature you like, fire off an email to thank the developer - it can make someone's day, and it's nice to see one's work being used and enjoyed.
You can find the relevant person for any KDE app with Help->"About " in the menus, or you can find plenty of developers on the kde-core-devel@kde.org and kde-devel@kde.org lists. And don't forget the artists, translators, promo team, accessibility team, doc writers, and the many other people who make KDE happen.
- Refactoring code
- Fixing bugs that hadn't been reported
- Adding features that hadn't been specifically requested in the bugzilla
- Writing and improving docs
- New translations
- Usability improvements
- New artwork
- ...
Remember, software isn't just code, and a lot more goes into it than just bugfixes and now functionality.As a member of an open source team, what attitude and methods do you use towards recruitment?
I think this touches on a wider issue relating to open source (free software, peer-directed projects, whatever you want to call it), namely how we deal with the less strictly technical aspects of the software itself. Most of the discussion on, say, OSS mailing lists is directed towards coding, as of course it should be, since it's the software itself that is the object of the exercise. But there are plenty of other important and useful ways of improving software and people's experience of it: documentation, usability considerations, promotion, and so on.
Improving these aspects of software in an open-source model seems to be a very different task to writing code. It requires 'soft' skills - the ability to attract people, help them learn the ropes, and then retain them as contributors. In a business model, of course, you can pay people to do the marketing and the usability testing (say), but in an open project, you can't force people to do what they don't want to.
As a contributor to KDE for a few years now, I think we as a project have perhaps thought too little about these wider things, but what have other projects done about them? Do you rely on companies to sponsor developers (not necessarily coders!) who can work on these less popular areas, or do you require coders to provide, say, documentation or usability testing for their apps?
There's a lot more information about what will be going on at the KDE wiki at http://wiki.kde.org. There are plenty of opportunities to contribute, too - even if you're not a programmer or 'power user'. Take a look, for example at KDE Community World Summit under "Coding Marathon" for a list of teams that will be present.
As an example, I'm on the documentation team, and we've got plenty planned. Check out KDE Documentation @ aKademy for more details.
OK, that's enough advertising for one comment...
PhilRod
On the topic of economics, here's some numbers I just whipped up:
LINX, the London Internet Exchange, deals with around 15Gb/s on average. 60% of that is a little over 1GB/s. Let's be conservative and call it 0.9GB/s. That's 77,000 GB/day (rounding down again), which is all P2P (so they claim).
That amount of data comes to 7,000,000 10MB music tracks, or 77,000 1GB video files. Now, Apple have proven that Joe Public will pay a reasonable amount for media offered legitimately, so let's assume that 10% of this P2P traffic could be converted to legitimate sales of music. So, assuming £0.60 (=$1) for a music track, or £4 (=$6.50) for a movie, that's a potential:
£42,000/day -> £15million/year of music sales ($25m/year) or £31,000/day -> £11million/year of movie sales ($18m/year)
And that's just in the UK!
Now, I know this isn't the point of the article, but there's a huge potential for the media companies we all moan about so much to make money, *and* for us to get the content we want (sans 9 tracks of filler for one good track) at the same time, and they're doing almost nothing about it. What am I missing?
(OK, so I guess someone who knows more about bandwidth usage and economics than me can make these figures more realistic, but you get an order of magnitude...)
PhilRod
- First off, it's fully compliant SGML or XML, whichever flavour you prefer. DocBook documents are stored as nice plain ASCII which can be processed with any SGML/XML tool you happen to have lying around.
- Output options are virtually unlimited. IIRC, HTML, man, texinfo, plain text, (La)TeX and anything else you care to mention are available as output formats, with XSL providing a way to produce your own custom output.
- The Crunch: Text is marked-up for what it is, not what it's meant to look like, so you needn't know a single thing about formatting while writing content and vice versa. You know the advantages of using CSS instead of hard-coding HTML. Well, they count for DocBook too.
- Nifty features like creating tables of contents from the source and all that sort of thing that you thought only TeX could do.
- I suppose I should mention that it's extensible, hence the XML version.
--PhilRod