Stuff Michael Meeks is doing |
Older items: 2008: ( J F M A M J J A ), 2007: ( J F M A M J J A S O N D ), 2006, 2005, 2004, 2003, 2002, 2001, 2000, 1999, legacy html
/lib/modules/`uname -r`/build, and so on. Finally found
the bug is fixed in HEAD systemtap anyway, filed a SUSE issue, sent
off a trivial patch. Sadly when it runs, it does something -so- strange
to my system that it terrifies me; will come back later.
Icecream is
a sharp tool, it lets other people build software on your machine,
needs you turn off your firewall, and it requires a working
LAN. The wiki page is your friend. [update]: Martin Vidner
points out that if you don't like to disable your firewall,
it's easy to use some built-in rules; as root:
echo 'FW_CONFIGURATIONS_EXT += "iceccd icecream-scheduler"' >> /etc/sysconfig/SuSEfirewall2
/sbin/SuSEfirewall2 start
sudo zypper in -y icecream icecream-monitor # install the package < 5 secs
sudo /sbin/chkconfig --level 345 icecream on # enable icecream startup on boot
Next - decide if this is going to be the scheduler machine ?
if so:
sudo sed -i 's/ICECREAM_RUN_SCHEDULER="no"/ICECREAM_RUN_SCHEDULER="yes"/' /etc/sysconfig/icecream
Then - start the daemon everywhere:
sudo /etc/init.d/icecream start # start the daemon ...
Finally - fix your path:
export PATH="/opt/icecream/bin:$PATH";
make -j8 # and run a parallel make
But I use different distros & versions on each machine - icecream pushes enough of your compiler and toolchain across to the remote host that this shouldn't be a problem.
But I like to turn the scheduler off / unplug my laptop - fine, icecream will handle your use-case perfectly: don't fret.
My mega-server is a 64bit machine, but my laptop is 32bit - fine, icecream will handle your use-case perfectly by default. It can even do cross compiling with more tweaking.
How do I know it's working - for those burned by the
psychosomatic Gentoo experience, running 'icemon' can help overcome your
fears (albeit at the cost of too much of your CPU):

But I run SLED ... - package here.
make %{?jobs:-j%jobs} is
best handled with some rpmbuild --eval '%define jobs 8' -ba foo.spec
than otherwise, sadly much googling, manual and code reading didn't
make this at all obvious.
We chose LiMo because it's a collaborative effort. It's not just one company runs the place. We like that. We like a collegial and collaborative effort, where there is no barrier to entry on the part of developers and, at the end of the day, there is no one entity that can say 'OK, here's how we were playing now. The rules are changed.' LiMo will be our preferred OS because of this openness.Whether sincere or not, I couldn't agree more. Give me a genuine, open, plural community any day over a single vendor dominated one.
$ ls -lR ~/.thumbnails | wc -l
12798 hmm. Apparently we shove all those into a
hash_table in the slab too gnome-thumbnail.c (read_md5_dir)
The company must learn to let go a little bit and let the open source ecology proceed naturally. In the short term, Sun might lose a little bit of advantage in the market, but long term, it is has a better shot at success.Start with OO.o: give us real, meritocratic governance and real (instead of sham) compromise on code ownership (as we have outlined & requested) - instead of trying mightily to avoid both issues while feigning 'Open'ness.
echo "Unpacking OO.o build tree - [ go and have some $DRINK ] ..."
with a fully configurable:
AC_ARG_WITH(drink, [ --with-drink The parameter is a favourite drink that unpack should advice you to take. Example: --with-drink=coffee], ,)- the joys of community; tweaked the spelling: 'advise' - thank goodness the default is still tea (for the UK), and not Coca-Cola. Chat with Rene.
echo t > /proc/sysrq-trigger a little but got no-where in the end.
Well pleased with X / drm / radeonhd stability - in comparison with the proprietary
drivers, I spent an hour SIGKILL'ing X, switching consoles, modprobe -r'ing,
starting and killing compiz and so on, and the machine is still alive.
R500 support requires a newer
drm. - I actually read the drm readme, and discovered make
install needs running in linux-core as well as the
top-level (obviously).

I conjecture that most multi-threaded general-purpose applications are, in fact, so full of concurrency bugs that as multi-core architectures become commonplace, these bugs will begin to show up as system failures. This scenario is bleak for computer vendors: their next generation of machines will become widely known as the ones on which many programs crash.The solution is of course obvious: to give staggering amounts of highly parallel beefy hardware to an infinite number of free-software hackers. Failing that, CPU vendors could do a lot worse than invest a fortune in Julian's helgrind thread checker.

ftw glibc call - I wonder how efficient it's I/O is.

1211970599.543457 poll({snip fd details}], 14, 186) = 1
1211970599.543928 gettimeofday({1211970599, 544334}, NULL) = 0
ie. we ask to sleep for 186us, and we get control back to call
gettimeofday 471us later. Of course, quite why we are waking up -so-
frequently, and reading ~20 bytes of samples, and going back to sleep
for such a short time is unclear to me; 260 poll / recvmsg's per
second - just to play a mp3; odd. Could it be that
this is the solution ? Unfortunately esd works (apparently)
perfectly on the same machine at a much more sedate 14 2k reads
per second instead.
http://www.go-oo.org/~michael/blog/index.atom.
(gdb) bt #0 0xffffe430 in __kernel_vsyscall () #1 0xb6eb21d7 in *__GI___poll (fds=0x8641990, nfds=6, timeout=599) at ../sysdeps/unix/sysv/linux/poll.c:87 #2 0xb554f6f2 in ?? () from /usr/lib/libglib-2.0.so.0 #3 0x08641990 in ?? () #4 0x00000006 in ?? () #5 0x00000257 in ?? () #6 0x08641990 in ?? () #7 0x00000006 in ?? () #8 0x00000000 in ?? ()And afterwards:
(gdb) bt #0 0xffffe430 in __kernel_vsyscall () #1 0xb6eb21d7 in *__GI___poll (fds=0x8641990, nfds=6, timeout=599) at ../sysdeps/unix/sysv/linux/poll.c:87 #2 0xb554f6f2 in ?? () from /usr/lib/libglib-2.0.so.0 #3 0xb554f9d8 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #4 0xb5b3d68d in ?? () from /usr/lib/ooo-2.0/program/libvclplug_gtk680li.so #5 0xb54f4751 in X11SalInstance::Yield () from /usr/lib/ooo-2.0/program/libvclplug_gen680li.so #6 0xb7e06cf1 in Application::Yield () from /usr/lib/ooo-2.0/program/libvcl680li.so #7 0xb7e06d3f in Application::Execute () from /usr/lib/ooo-2.0/program/libvcl680li.so #8 0x08071c53 in desktop::Desktop::Main () #9 0xb7e0a27e in ?? () from /usr/lib/ooo-2.0/program/libvcl680li.so #10 0xb7e0a41a in SVMain () from /usr/lib/ooo-2.0/program/libvcl680li.so #11 0x08066c60 in main ()Save your download bandwidth quota (and the planet too) by grabbing a new gdb for your OpenSUSE 11.0 from here.
"MS should build the extensions they need for interop on top of ODF"were actually sincere, or whether they now switch to an equally shrill albeit contradictory:
"They are evily embracing and extending our standard"Given the feature sub-set problem in ODF, can you have the embrace without the extend ? Of course, it is possible that MS (unlike Novell) have no real interest in improving the serious inadequacies around interop. in ODF, in which case their customers will just get upset:
"why does my document look different when I save as ODF, and re-load it in Word"Can you imagine the synthetic outrage that either of these will generate ? Then again, perhaps they will want to improve interop. in the standard, at which point we will inevitably quickly hit the:
or even
"Why, when I select ODF mode, do so many features disappear in the UI"
"This can't go into the standard because there is no implementation in OO.o [or perhaps the more sophisticated 'multiple implementations']"type argument, or will that be waived - in which case we will hit the:
"OO.o can't load & render it's native file format"chestnut - which of course has always been true of KOffice's ODF use and which we keep hearing re-iterated in various forms about Office 12 and OpenXML. Anyway - at the end of whatever "pick your own fight" session we're in for, when all the dazed, confused and exhausted pundits grind to a halt there are perhaps two lessons that will become obvious here:
www.gnome.org
answers replies to queries rather differently depending on where
they come from (apparently) - some people just get ECONNRESET almost
immediately (perhaps a firewall issue). Of course, wget works from
everywhere - here is the query it does:
GET /~michael/blog/index.atom HTTP/1.0 User-Agent: Wget/1.11.1 Accept: */* Host: www.gnome.org Connection: Keep-Alivevs. the query the uber-powerful (etc.) feedparser code does (apparently due to some fun charset love:
GET /~michael/blog/index.atom HTTP/1.0 Host: www.gnome.org A-im: feed Accept-encoding: gzip, deflate Accept: application/atom+xml,application/rdf+xml,application/rss+xml,application/x-netcdf,application/xml;q=0.9,text/xml;q=0.2,*/*;q=0.1 User-agent: Planet go-oo +http://planet.go-oo.org/ Planet/2.0 +http://www.planetplanet.org UniversalFeedParser/4.1 +http://feedparser.org/Presumably the latter looks like a DDOS attack, but only from some IPs (perhaps go-oo.org has a dodgy 2nd hand Russian-Mafia-style IP address).
/usr/src/packages/BUILD
and then unpacked SOURCES/*.tar.bz2 poked Stefan & Petr.
javaldx. The purpose of javaldx is to
(cunningly) grope your system - to look for performance-enhancing
java goodness: here are some stats:
| syscalls | 182000 |
|---|---|
| of which lstat64's | 161000 |
| normal (warm) start | 0.74 secs |
| under strace | 11.7 secs |
| strace log size | 17Mb |
/usr, 14k of /usr/lib, 13k of
/home etc. sigh. Perhaps the frenzy is just revenge for
not having any java on the live-CD system.
sudo; su - prompts
for a non-obvious password; interestingly vs. openSUSE's 11.0' LiveCD
there is no OpenOffice included; odd. Interesting to poke at baobab
to see the size breakdown of the live-cd - odd to have 130Mb of
fonts included, and nothing much to use them; Solaris suffers from
the gconf.xml.defaults malaise too - of ramming tons of translations
into a single file: when will the world stop doing this: 50Mb of
irrelevance ?