And they're coming to take you away ha-haaa
They're coming to take you away ho ho hee hee ha haaa
To the Redmond farm
Where life is beautiful all the time
And you'll be happy to see those nice young men
In their - see? Sharp coats
And they're coming to take you away ha haaa
We thought it was a joke
And so we laughed
We laughed when you had said
That you could leave the FLOSS and work for Bill
Right? You know we laughed
You heard us laugh. We laughed
We laughed and laughed but still you left
But now we know you're utterly mad
And they're coming to take you away ha haaa
They're coming to take you away ho ho hee hee ha haaa
To the happy home with bugs and Vista and viruses
Security "fixes" which patch and patch and open new hacks and holes
And they're coming to take you away ha haaa
We've read your blogs
And used your code
And this is how you pay us back
For all our kind unselfish, loving deeds?
Ha! Well you just wait
They'll find you yet and when they do
They'll make you write with ASP.net
You well-dressed geek
And they're coming to take you away ha haaa
They're coming to take you away ha haaa ho ho hee hee
To Camp Microserf where life is beautiful all the time
And you'll be happy to drink that nice Kool-Aid
In their clean white cups
And they're coming to take you away
Wednesday I went off on a bit of a G'n'R-fueled rant about metadata, documentation, and the shotgun blues. Today, I'd like to focus on something more positive.
As Pascal blogged the other day, the new p2 is almost done and is ready for tire-kicking.
Some new features I personally like include:
a new p2.repo2runnable ant task, used to convert an update site zip to the old-school unpacked "runnable" features/plugins format so that one day we will be able to throw away all those extra zips.
UPDATE, 2009-06-02: repo2runnable now works as a commandline application too, thanks to Andrew's fix. Wiki updated.
I'm also impressed that there is new, current documentation regarding the above tasks, as well on the new Publisher which replaces the Metadata Generator.
Well, I'm split on the new default behaviour in the update UI, such that when you add a new update site p2 won't by default search ALL your other listed sites. This is a great performance gain if you're installing a new self-contained feature, but a pain if you're installing something like VE which depends on EMF and GEF, and you don't already have those deps installed. Simple workaround is to just pick the "all sites" entry in the dropdown.
But other than these minor concerns, I'd say YES. With lots more commandline and ant toys available, p2 is certainly maturing. And with more people adopting its use and spinning p2 repo zips, more testing is being done, and more use cases are being covered.
So... get in the ring, and go a few rounds with p2. It's worth the battle. :)
It's been a bad week for update sites and Galileo contribution from Modeling... and I confess I'm partly to blame. That and the fact that despite documenting processes, workarounds, tips, tricks, and advice... no one Reads The Fine Mediawiki (Category:Releng or Modeling Project Releng).
Highlights:
The mysterious appearance of a new version of org.eclipse.osgi_*.jar in releng.basebuilder's R35_M5 tag, which caused an ant <copy/> used to rename a file to fail because copy can't merge two jars into one file. Still no idea why an old basebuilder tag would magically grow a new jars, but I've worked around the now-faulty assumption w/ smarter Ant code.
A change to the way our sites are created, in an attempt to workaround what I believe (but can't yet prove) is a flaw in the way content.xml is produced - namely, if the xml file is > 21M, it gets truncated or corrupted. We used to cache 2 or 3 releases of a given project (eg., M5 and M6) on the same site, in order to give people a way to "back up" to the previous release; now, you only get the latest (bug 271486). I confess I screwed up here and instead of replacing a folder with new contents, I was copying INTO that folder - `cp -r one two` resulted in folder one/two/ instead of two/. I fixed that by changing to a move instead of a copy, but a downstream process failed because of the assumption that both one/ and two/ would exist. The lessons here are: a) shotgun debugging sucks, and b) don't change the way stuff is created after M7.
People publishing two updates to a site at the same time, resulting in the appearance of two </site> tags in a site.xml file, causing p2 metadata generation to be incomplete or fail entirely; unfortunately, no error is logged when this happens so it's rather difficult to decipher the tea leaves. This may be the real source of the metadata corruption, if not the "file is too big" issue above.
Observations about obsolete jars corrupting metadata, but no one taking it upon themselves to clean up the site or do some troubleshooting
People inconsistently naming their milestones (it's 2.0.0M7, not just M7!) and corrupting our Release Notes database. This one amazes me the most since it takes seconds to see what was done last time (check any of the following: RSS feeds, release notes, downloads pages, update sites) and follow suit. And, of course, the conventions are documented, along with the rationale (consistent patterns == simpler code).
Or, to put it another way...
Sick of this life
Not that you'd care
I'm not the only one with
whom these feelings I share
Nobody understands
Quite why we're here
We're searchin' for answers
That never appear
But maybe if I looked real hard I'd
I'd see your tryin' too
To understand this life,
That we're all goin' through
Sometimes I feel like I'm beatin' a dead horse
And I don't know why you'd be bringin' me down
I'd like to think that your love's
Worth a tad more
It may sound funny but you'd think by now
I'd be smilin'
I guess some things never change
Never change
So, please, can we stop opening bugs (277172, 277105, 277034, 276928, 276641) and just use the tools and docs already available?
Yesterday I set about learning how to convert a Xvid-encoded .avi to DVD so that my more technically challenged relatives can watch an HBO movie that's not available in video stores.
Here's the process, with approximate elapsed times. Thanks go entirely to linuxquestions.org for the solution.
Hardware used: Thinkpad R51 (Pentium M 1.6GHz, 1.2G RAM) + Samsung USB DVD-DL burner (16.4x1352KBps).
Acquire your .avi file source. For a 1.1G .torrent, this took 2 hours.
Copy the source onto a drive with sufficient space to re-encode it. 20 - 25 minutes for USB-to-USB copy between drives.
Verify installed software requirements. I still have an old copy of xubuntu on the R51, so I needed to install these tools. Under 2 minutes.
Split the 16:9 NTSC widescreen .avi into movie.m2v (video) and movie.ac3 (audio). Create an MPEG from the audio and video pieces. Generate DVD/AUDIO_TS/ and DVD/VIDEO_TS/ dirs in the current dir using the dvdauthor.xml to add chapters every 15 minutes. All three steps back-to-back, 6 hours.
It's been said for many a year that *this* will be the year Linux breaks through into the desktop space. Clearly we're still a long way off, but it's nice to see that over the past two years, both Linux and BSD-based Mac OS X have taken share away from Redmond.
Next Thursday, May 21 is the Toronto Demo Camp from 6:30-8:30 with refreshments thereafter. We haven't nailed down all the details yet (like the order of presentations or what food will be served), but I can safely say that barring any Canada Post mixups, there will be Eclipse golf shirts available to be won by those in attendance.
How do you win? Well, by presenting, of course! Sign up now!
The presentation format is flexible, and this is an informal event... so if you have 5 mins, 15 mins, or 30 mins of material, great! We'll provide the conference room, projector, whiteboards, and even a laptop if you provide the demo materials. The rest is up to you.
When signing up, please identify your name, topic & expected duration. Looking to strut your funky stuff and get some early adopters as you get close to the June release? Here's your chance.
Have you ever wanted to fetch a whole stack of Eclipse project runtimes so you can build against them? For example, say you want all the Galileo M7 builds from Platform, TPTP, BIRT, DTP, WTP, and dependencies (EMF, GEF, XSD). You can find the URLs for each zip you want on the projects' pages, and download them one-by-one from the closest mirror, but that's time- and bandwidth-consuming, esp. if you want these on a remote server, not your local box.
Enter the "&r=1" option on http://www.eclipse.org/downloads/download.php, which will fetch from the closest mirror automatically.
So, now, you can script the M7 stack fetch like this:
for u in $*; do
if [[ ! ${u##*file=*} ]]; then # add the r=1 suffix
u=${u}"&r=1"
fi
echo "wget $u ..."
wget --no-clobber "$u"
done
Am I the only person that finds this inconsistency annoying? Is it time for a more consistent UI? I'm exploring what to do for Athena-based builds, and welcome suggestions in bug 275682. What pages do you like best? Worst? Which are easiest to use? Hardest? Do you prefer the old blue-and-white pages? The purple Phoenix pages? The grey Nova pages? Any UI designers want to contribute?
Or, really, are downloads obsolete? If we could collect statistics on p2 jar downloads, I'm sure we'd see that most people prefer that approach, and I for one would certainly prefer to just build against a p2 repo (or 7) than a pile of zips. I suppose the hybrid solution for now is to provide zipped p2 repos for download, many projects do today (Modeling, GEF, PDT, VE ...).
Just a quick note to let people know that I've updated the Eclipse Hudson instance (and you can too, if you're in the Hudson admin group!)
As part of this update, I've installed a plugin to make Hudson look more consistent with other CI tools:
I know it's generally not advisable to do potentially breaking changes like this on a Friday evening, but after a number of ups and downs this week, the Galileo BuckyBuilder is actually green (blue) ...
... and it's my last weekend as a 25 year old, so out with a bang we go.
If I broke anyone's Hudson job w/ this update, let me know - I'll be checking mail over the weekend, just in case.
Last week I fired the Fox and switched to using Opera 9.6. Today, I'm back to Firefox 3.0 because while Opera has a few nice features, it ultimately lags behind FF (for me, anyway) in usability and functionality.
Here's how they stack up:
Opera 9.6's Pros
Sidebar notepad feature
Speed dial homepage
Minimalist UI with sidebar (incl. a handy notepad app and the usual suspects (transfers/downloads, history, bookmarks). For web dev, there's some handy extras like Links (a list of all the links in a page) & Info (page metadata)... but then FF also provides these via a different UI
Ability to do "g keyword keyword2" to search Google for those keyword(s) (Firefox just does this without the "g")
Mouse gestures
Single "Wand" password manager login for entire session (rather than per-window - see Firefox Cons below)
Location bar only works with URLs and sometimes page names. Way more typing needed than in FF
No ability to undo the closing of a tab
Cannot reproduce FF extensions in Opera; Delicious and Twitter integration are not nearly as good; no tab colouration, single view of downloads, no Tasktop support.
Cannot store username/password pairs for in-page login forms (only browser-level ones). Repeatedly having to log in to JBoss Hudson every few hours is a royal pain.
Crashes unexpectedly but previous session can be recovered.
Lame icon with a dropshadow. Retro, sure, but c'mon, they've had that for AGES, and it's just lame.
Firefox Cons
Memory bloat
Crashes unexpectedly but previous session can be recovered.
When reloading a saved/crashed session, every single page requiring access to the password manager pops a login dialog; sometimes I get to enter my password 7 or 8 times, or hit ESC repeatedly to lose those tabs.
I also briefly tried Firefox 3.1beta4, but as none of my extensions work there yet, it's not much better than Opera at this point. It's supposed to be better on memory, and has new bells and whistles being added to the Awesomebar. It's also supposed to be implementing a lot of functionality I get now from the above extensions, such as better tab management.
Implementing a common build infrastructure would also be complicated by additional code repositories as well.
Not true; the Athena system already supports CVS and SVN, plus a "build from local sources" mode which works w/ a cvs/svn tree dump, a workspace w/ checked out projects, or (TBD, we haven't tested this yet) with a git repo. And we have an open bug to make repo tree structure irrelevant to the local checkout mode. Party on. There is even a Git plugin for Hudson so you can use Hudson to watch your repo for changes, like it does with CVS and SVN.
Can't use unapproved or non-EPL code at Eclipse.org
Not true; from discussions w/ legal@eclipse.org, I've been told at least twice that as long as you're not SHIPPING code that falls under a non-EPL or non-approved-CQ you're entirely fine to USE that code as server-based infrastructure. Rock on.
Cannot include tooling in a release train or host its project at Eclipse.org
Not true; since eGit is EPL and jGit is BSD, I don't see a problem with distributing the tooling that would connect to a Git repo hosted at Eclipse.org. We worked around the license woes for SVN tooling support. We can do it again. (Of course IANAL, TINLA.)
Conclusion:
No legal concerns with use of Git as hosted server infrastructure. Dash Athena (Common Builder) will support Git. Tooling is safe for inclusion in release trains (either fully like CVS is or partially like SVN is).
Only remaining issue is therefore to get it installed and allocate resources to support/manage it. With all the erosion going on lately, this need should not be trivialized.
Before the thaw this spring, this tree was on top of the bluff. With nothing to support it, it was dropped like an unchampioned feature request.
However, in the spirit of open source, several people on the above bug have offered to help w/ setup, testing, support, etc. So the burden here will be shared, like many things at Eclipse (eg., Babel, Hudson). Erosion continues, but we can all help to shore up the loss.
As most people prolly already know, Sourceforge supports the whole spectrum of VCS and DVCS options. If we don't want people to host projects there, Eclipse has to at least offer something from the DVCS world to encourage participation here. Keep the barrier to entry high, and people will go elsewhere. Lower the barrier, and people will come here to party instead.
With everyone feeling the economic- and time-pinch these days, can we really afford to discourage contributions at Eclipse simply because, as the silverbacks say, "why, back in my day, we only had CVS, vi, and notepad, and dangit, that was good enough!" ?
