Free Software Integralism — Helping or causing trouble?

So today we have two main news that seem to interest the Free Software advocates and, to some lesser extent, developers:

Apple officially decided to shun Java as well as Flash for their own operating system, discontinuing the development of their own JRE for one, and declaring that the latter won’t be available as part of the base operating system install in the next release (10.7 Lion);
the Free Software Foundation published the criteria under which hardware can be endorsed by the FSF itself.

I’ll start with the second point, first pointing directly to the post by Wouter Verhelst of Debian fame; as he points out, basically the FSF is asking for hardware manufacturer to forget that, up to now, Linux is really a niche market, and push only their way. “My way or the highway”.

Now this could make sense for the ideas embedded into the FSF, although it definitely shows a lack of marketing (I’ll wait and see if there will be any serious hardware manufacturer going to take this way, I bet… none). What should really upset users and developers alike is the reason why that is “[other badges] would give an appearance of legitimacy to those products” … what? Are you now arguing that not only proprietary software is not legitimate at all? Well, let’s give a bit of thought on the meaning of the word from Wiktionary:

In accordance with the law or established legal forms and requirements; lawful.

Conforming to known principles, or established or accepted rules or standards; valid.

Authentic, real, genuine.

If you can’t call that integralism, then I don’t even think I can argue with you on anything.

Now on the other issue, Apple has decided that neither Flash or Java suit their need; in particular they are working on a “Mac App Store” that is designed, obviously, to put the spotlight (sorry for the pun) on the applications they find more complacent for their requirements. Is that such a bad thing? I’m pretty sure that Free Software Foundation is doing the same by trying to strive for “100% Free GNU/Linux distributions”. We’re talking of different requirements for acceptance, does one side have to be totally wrong, unethical, unlawful, rapist and homicidal at all? (Yes, I’m forcefully exaggerating here, bear with me).

What I find very upsetting is that instead of simply putting light on the fact that the requirements of the Mac App Store might not be in the best interest of users but in those of Apple, Free Software Advocates seem to be siding with Adobe and Oracle… wha? Are we talking of the same Adobe whose Flash software we all so much despise, the same Oracle who’s blamed for killing OpenSolaris?

But it seems that somehow Apple is a bigger problem than Adobe and Oracle; why’s that? Well, because somehow they are eating in the numbers that, if better handled at many levels, starting from the FSF itself, would have been there for Linux (GNU or not, at this point): the hacky geeks, the tech-savvy average person who’s tired of Windows; the low-budget small office who doesn’t want to spend half their money on Windows licenses…

In-fighting, religious fights for “purity”, elitism, all these things have put Linux and FLOSS in a very bad light for many people. And rather than trying to solve that, we’re blaming the one actor that at the time looked much less palatable, and became instead the most common choice: Apple.

On the other hand, I’d like to point out that when properly managed, Free Software can become much better than proprietaryware: Amarok (of 1.4 apex) took iTunes full on and become something better – although right now it feels like iTunes caught up and hadn’t been cleared up just yet.

MySQL build system

I have to introduce the post stating that I’m not a MySQL user; this site and the xine bugzilla both run on PostgreSQL, and similarly PostgreSQL is what holds the symbol collision database on my box. So if I feel critical of MySQL, well, I am. I’m not really much interested in improving it either, but I don’t want just to shitspread them, so my assessment will be as objective as I can be.

I’ve been looking at the buildsystem of MySQL to help Jorge with the infamous Amarok 2 problem which is making it unavailable on AMD64 and other architecture. I have to say that I do blame a bit the Amarok guys (as much as I love them) because they should probably have pushed MySQL devs to handle the issue before they hit stable; but well, what is done is done, and it’s time to handle it.

The problem is that Amarok tries to use MySQL Embedded in a shared library; shared libraries on AMD64 need to be built with PIC code, and of course MySQL Embeded is not built that way as it only provides static archives to link against. So what is needed is for MySQL to build a shared library copy of MySQL Embedded so that it can be linked in the Amarok engine library.

This is not something tremendously exotic to do, especially for Sound and Video we’ve been converting packages to install shared libraries for quite a while, and not just in Gentoo, but most distributions out there. When libtool is present, this usually gets quite easy since you just have to change some names around to make sure that instead of just building the archives, libtool is used to build the whole library, and there you go. For MySQL is not even vaguely that easy.

The problem is that the MySQL Embedded code seems like it was put there on a customer’s request, and as long as it worked for them, the whole thing was fine as it was; it shares part of the code with MySQL proper but not all of it, and the shared sub-modules (which are installed as separated static archives by MySQL right now), are not self-sufficient, as they require cyclic linking of dependencies.

The result is that to actually have the thing working, it’s likely that there will be some change in both the buildsystem’s interface, as well as some changes in the number and type of installed files; while this will likely also solve part of the code duplication problem that I found some time ago, it’s very unlikely that upstream would accept that for their main sources right away.

While MySQL is using autoconf and automake for the base of their build system, they are not only using lots of custom rules for the makefiles, they are also using some “strange” methods to add source files to target in particular cases (rather than using AM_CONDITIONAL) and also making use of knowledge against discovery which makes it a bit more difficult to find what is asking for what.

So where is this post going? Well, it’s just a way to ask users to understand why we haven’t fixed the problem yet; as for why we cannot just hack it around like it seems other distributions have done, the answer is that we do prefer to avoid those hacks since they are, well, nasty. And our users expect better from us, even when that means that it takes months to get a package in an architecture because the only way to build it there is to use a nasty hack.

On patching and security issues

Jeff, I think your concerns are pretty well real. The problem here though is not that Debian users should not be suggested not to file bugs upstream, the problem is that Debian should not go out of their way to patch stuff around.

Of course this is not entirely Debian’s fault, there are a few projects for which dealing with upstream is a tremendous waste of time of cosmic proportions, as they ignore distributors, think that their needs are totally bogus and stuff like that. Now, not all projects are like that of course. Projects like Amarok are quite friendly with downstream (to the point all the patches that are in Gentoo, added by me at least, were committed at the same time on the SVN), and most of the projects that you can find not suiting any distribution are most likely not knowing what the distributors need.

I did write about this in the past, and you can find my ideas on the “Distribution-friendly Projects” article, published on LWN (part 1, part 2 and part 3). I do suggest the read of that to anybody who has an upstream project, and would like to know what distributors need.

But the problem here is that Debian is known for patching the blood out of a project to adapt it to their needs. Sometimes this is good, as they take a totally distribution-unfriendly package into a decent one, sometimes it’s very bad.

You can find a few good uses of Debian’s patches in Portage, it’s not uncommon for a patched project to be used. On the other hand, you can think of at least two failures that, at least for me, shown the way Debian can easily fail:

a not-so-commonly known failure in autotoolising metamail, a dependency of hylafax that I tried to run on FreeBSD before. They did use autoconf and automake, but they made them so that they only work under Linux, proving they don’t know autotools that well;
the EPIC FAIL of the OpenSSL security bug; where people wanted to fix a problem with Valgrind, not knowing valgrind (if you have ever looked at valgrind docs, there is a good reference about suppression files, rather than patching code you don’t understand either).

Now this of course means nothing, of course even in Gentoo there has been good patches and bad patches; I have yet to see an EPIC FAIL like the OpenSSL debacle, but you never know.

The problem lies in the fact that Debian also seem to keep an “holier than thou” attitude toward any kind of collaboration, as you can easily notice in Marco d’Itri’s statements regarding udev rules (see this LWN article). I know a few Debian developers who are really nice guys whom I love to work with (like Reinhard Tartler who packages xine and Russel Coker whose blog I love to follow, for both technical posts and “green” posts; but not limited to), but for other Debian developers to behave like d’Itri is far from unheard of, and actually not uncommon either.

I’m afraid that the good in Debian is being contaminated by people like these, and by the attitude of trusting no one but themselves in every issue. And I’m sorry to see that because Debian was my distribution of choice when I started using Linux seriously.

Migrating from iPhoto to DigiKam

For my photos I’ve been using, up to now, iPhoto. The reason for this is that the big part of my photo collection is actually composed of my sister’s photos, which I downloaded directly with the MacBookPro when she asked me.

On the other hand, I use way more often my Linux box, and while iPhoto is a nice tool, DigiKam is not bad either, so I’d gladly move everything on Enterprise, as the mobility option for the photos is lost already once I moved everything on the external harddrive (as I now have more than 10GB of photos).

Unfortunately this migration is not going to be painless I’m afraid, especially because there are a few features I might be losing, unless I can spend some time writing stuff on my own.

The first problem would be having a way to save the photos from risks of losing data; the quick way would be to put them in raid. At the moment the photos are backed up by TimeMachine too, so I don’t risk losing them. I don’t think putting them in my /home directory will be a good idea: it’s just 14GB and the photos will soon be over that quota. I wonder if LVM can mirror partitions easily.

Then there’s the cleanness of storing the photos on the iPod, I don’t think Amarok can load them, can it? I have to check that out. And having them on the AppleTV too.

On the Wiki there are instructions on how to set up a DPAP (Digital Photo Access Protocol, I suppose it’s a relative of DAAP) server to share the photos with iPhoto, and AppleTV. I have to check that out, maybe writing an ebuild.

Of course the easiest way to handle this would be to have DigiKam actually providing DPAP support ;)

Another point I’d like to address is Flickr uploading. To upload to Flickr at the moment I’m using the FlickrUploadr, as the only plugin to allow that in iPhoto is proprietary commercial software. kFlickr is better than FlickrUploadr, but still isn’t well integrated (can’t just select an Album and say “upload to Flickr”).

Probably some of these concerns will be addressed with the KDE 4 version of DigiKam, I expect that to happen, but now I’m wondering if I should migrate already or wait for those to be done…

On the other hand, I wonder if there is anybody working on reverse engineering the protocol with which iTunes talks to AppleTV, it would be nice to be able to just command it through Amarok or DigiKam.

/me adds stuff to his TODO, which is probably way too big for this to ever happen.

But I certainly hope someone will write this stuff for me :) After all we all do our parts in the greater Free Software plan!

Another change over all the xine’s plugins

I wasn’t happy enough with the new format of plugins’ structures, using direct literals rather than having to define functions to return them. As I said before, it makes more sense to set the identifier, the description and the textdomain directly on the plugin_info_t, so that the plugin does not need to be initialised at all to have its name and the description.

So I started doing this now, and the result up to now seems quite interesting: there are a few extra dereferences in a couple of points, but the functions that load the description of the plugins are quite smaller now, as they don’t have to open the plugin anymore).

What is the problem now? The problem is that there are a bit more than 150 plugins in xine that needs to be modified to comform to the new interface, it’s not a quick task, and it’s actually quite boring. And everytime I do something like that I start to wonder why am I doing that, considering that I’m not paid to do this, and I receive very little feedback about xine…

Once all the plugins are converted, I should be able to assess the improvement and make sure that I didn’t break anything in the plugin loader.

After that, I’ll have to put hands on the catalog generator so that I can save the description on the plugins cache, which should improve even more the loading of descriptions.

And finally, when this is done, I’ll have to take care of all the demuxer plugins again trying to move extensions and mimetype information again directly on the structure exported by the plugin.

That is a prerequisite for having mimetype demuxer detection, which in turn is a requirement for Shoutcast to always work properly, one of the nastiest bugs in Amarok.

Now, I don’t want to appear a pusher, but as I actually know how I’m feeling, I can tell you that if you really want to see xine-lib 1.2 released someday next year, an appreciation sign is certainly useful ;) That can be a “thank you” mail or comment, something from my wishlist or at least the bug reports going directly on the tracker…

And still VirtualBox does not allow to run Solaris with networking

I tried again, just to test, even if I knew it was unlikely, and even if I certainly don’t enjoy working on Solaris (well, not like I tried before, but whatever). The result is just the same: Solaris cannot get the network interface working.

I have to say, though, that there is something new in Solaris Express Developer Edition 09/7: the Developer version has a new installer that seems to be in GTK rather than Java, it also seems quite faster, but… it didn’t work for me. If I filled in the user information to create a ‘flame’ user, the result was that the shadow file couldn’t be opened, without that, it stalled after a couple of minutes reporting a failure in installation process.

The old installer of the non-Developer edition, in Java, is still slow as hell, especially to install the packages, but it worked quite fine. Although I still think that asking more than 8GB for the system is way too much: a server chroot of Gentoo takes up about half a gigabyte.

Anyway this does mean that I can’t test xine-lib-1.2-ac on Solaris yet, and thus I cannot merge it on main branch yet. This is good news for Amarok users as once the branches are merged Amarok 1.4 will stop working, unless I can force someone from the Amarok team to focus a bit on that xine branch ;)

More improvements for Amarok (in Gentoo) and xine

So, while I don’t have enough time to blog lately, I’ve been able to squeeze in a few changes to Amarok ebuilds and a few changes to xine-lib too. Let me try to get a little status update.

For what concerns Amarok users in Gentoo, the Live Subversion ebuild is now named with version being 1.4.9999 rather than 9999. This change is to make it clearer which version the Live ebuild is going to build (got a few people asking me lately if the 9999 version was going to install Amarok 2 or Amarok 1.4), and to free the space that should (and maybe will) be of Amarok 2’s live ebuild.

I also added an hard dependency over SQLite 3. Now, I know there are people that will now bitch about this being an extra dependency on Amarok and so on, this always happens. But I have a reason to add such a dependency, let me try to explain.

First of all, even if Amarok has optional support for MySQL and PostgreSQL, the SQLite support is not optional. The idea is that Amarok works out of the box, and neither MySQL nor PostgreSQL allow that, SQLite is the only choice that can be enabled out of the box.

Up to now Amarok built the bundled SQLite, which was the safe solution (even if it caused 1.4.5 to fail on G/FBSD); the reason why I decided for the safe solution before was that SQLite had a bad fame of breaking stuff between releases, and this happened once or twice on other distributions at least; lately the library started being less troublesome though, so the option of using the system copy started to be more interesting.

Another good reason to use the system copy of SQLite, beside policy and security, is the ability to share it between processes using it, saving memory. And one of the most common packages that might be used together with Amarok using SQLite3 is DigiKam. It might sound a bit Apple-istic, but if one of the most common combinations on OSX is iTunes and iPhoto, it might as well be Amarok and DigiKam on KDE, no?

Anyway, this decision was taken together with Markey, so you shouldn’t really start crying, it’s not going to hurt you, you’re not going to build more code (actually, you’ll build less when you update Amarok), and you’re not going to waste more memory (actually you’ll waste way less).

On xine-lib front instead, thanks to Albert Lee, Ben Taylor and Jonathan Wheeler, Solaris support is improving, and I’m trying to get a virtual machine running now (through Virtual Box, like Bernard said too — although I still need vmware-server installed with USB support to eventually update my phone :( ). The virtual machine I need to finish the audio conversion branch by adding support for the new formats to the Sun Audio output.

I’ll also be trying to clean up a few warnings in the code, so that the build is as clean as possible, without going to rewrite all of it. Unfortunately to get xine-lib to build correctly on Solaris, we need to rename BE_ and LE_ macros to something different (like X_BE), which is a nasty thing to commit.

Anyway, time to work.

A possible solution out of Farragut’s trouble

Yesterday I tried to fix a few of the issues with ~sparc-fbsd lagging behind (expected, considering that only me and Roy are handling it); unfortunately the PSU seems to be running quite hot, so when I started it again today to try a patch Ulrich gave me to try fixing emacs-cvs-23, it started making bad smell.

So a possible solution out of this mess for me would be to take Klothos to an undefined break, taking out its Promise SATA controller and putting it into Farragut, so I can connect the 160GB SATA spare drive I have; I actually need a noise dampener, but those are cheap, and I’ll make an order for them soon anyway.

For Klothos to come back up, I’ll have to wait so I can buy a new PSU for it, with active PFC and possibly less noisy.. not sure how much time will that take. In the mean time Roy (who’s currently on his honeymoon) is the only reference for ~sparc-fbsd keywording.

Anyway for those interested, yesterday it was quite a spree of keywording for ~x86-fbsd and somewhat for ~sparc-fbsd (fixed the most prominent problems with the latter, not everything though :( ).

Today I should probably update the Amarok’s maintainer guide, since although nothing changed since I left till I returned, I changed some stuff myself already (and that’s why the live version is now 9999-r2), and on that note I should test PyQt on G/FBSD to fix the new .badindev on Amarok.

So much stuff to do! And this is just a fraction of what I used to do, by the way.

Synergy of frontend and backend

Sometimes, it’s easy to forget how helpful is for frontends and backends (or in case of xine-lib we should more properly speak of middleend) developers to work together, back to back to provide users new features.

I wrote before that I wanted to see what would it take to implement Last.FM support directly in xine itself; thanks to eean (Ian Monroe) and Alex, I’ve been able to actually understand why it’s not a good idea to actually implement the whole last.fm protocol in xine-lib.

But, what I can do is making it easier to xine frontends to implement last.FM playback. The SYNC string is sent on the HTTP stream every time the track changes, it’s usually skipped over, as it doesn’t disrupt the mp3 stream; what I can do instead is looking for that string, and then inform the frontend that the metadata has to be re-read. Other input plugins do similar things to inform the frontend that the channel, the chapter, or other stuff, in this case, the metadata, so the event was already present and required me no interface addition.

Implementing this xine side was quite easy, it was an about five lines change, the result was quite good. I just needed to add a memmem() replacement for systems where it’s not present (I know there are a few).

Ian then started working on making Amarok use the new feature (that will be available in 1.1.8 version and in 1.2 series); by using this, it’s possible to skip over the whole Ruby proxy script, first connection is faster, and the metadata is updated when the track changes, rather than some time before the track changes.

This is a perfect example of synergy in development. Through this changed, applied to a real world need of one frontend (Amarok) who wants to play Last.FM, is now possible to implement Last.FM playback much easily in any xine-lib frontend.

On a different note, thanks to Kostya (and then to Peter Lemenkov), I now know there is a really Free implementation of Monkey’s Audio decoding (for the last revision of the format) at http://www.rockbox.org/tracker/task/7256. Unfortunately it’s designed for embedded usage so it’s not much use of xine out of the box, I’ll need to fix it to be at least reentrant (right now it’s using static buffers for everything). Maybe there is some hope to get Monkey’s Audio support in xine (and thus Amarok) :)

Anger, and xine-lib’s mov support (plus a lot more xine stuff!)

*If there is something that makes me very angry is the Summer; I shut down Enterprise during the night because it’s noisy and my mother whines about the noise; I usually could work with Intrepid (the laptop) from my room, but there I don’t have a desk, and the mattress is latice and it doesn’t seem to be a good heat sink, so it overheats, and I can’t even type on the keyboard; this was one of the reasons I bought a 32” LCD TV, which I can connect to the laptop, leaving the laptop on a chair or on the drawer, where it doesn’t overheat, but then I can’t type on it. I should have bought a bluetooth keyboard too, but they are so damn expensive! Plus, standing on the bed trying to sleep doesn’t work well for me when I have my brain going on its own path, and I get angry, angry, so angry that I could smash the laptop over the chair entirely for being unhelpful in this situation. So here I am, in my home office, at Enterprise’s keyboard, trying to relax myself, with bad results.*

Today, I wanted to get started on my plan to improve xine’s support for m4a files; looking at xine playing a generic file, I understood that the metadata wasn’t being loaded at all; on the other hand, there seemed to be a function that was supposed to load it; luckily, it never worked.

Why do I say luckily? Well, most of the code in the qt/mov demuxer does not give problem, but does not even try to parse correctly all of the possible variants. The first example is that most likely the 64-bit offset specifiers will drive xine crazy and get it to crash; luckily there don’t seem to be many 64-bit mov files out there, so it shouldn’t be an issue (please don’t confuse this issue with 64-bit timebases, like the ones generated by FFmpeg, that causes QuickTime to skip over the file; those works fine since 1.1.7 as I fixed their loading). Also, the function that supposedly parsed the metadata increased the pointer on the file by increments of the byte, which is quite wrong, and nasty too.

So then, why do I say it never worked? Well, the code tried to look for a meta atom (an atom is an element of a qt/mov file) inside the main moov atom; but the metadata is actually stored inside /moov/udta/meta atom (consider the path like an XPath applied to qt/mov atoms; yeah the atoms are usually nested).

Now in xine-lib-1.2 the code is fixed to actually load the metadata correctly, and I’ve also improved the code to use switches instead of multiple if cases, this should improve the runtime speed to parse the qt/mov files, and at the same time makes the code more readable. While the first change is totally useless to Amarok users (Amarok uses a TagLib plugin to get the metadata out of m4a files, so it gets it right already), the latter might be appreciated.

My next step would be to try making use of the coverart metadata, to display the cover while playing the audio track and no video is present; it might be a bit of an issue as it should be possible to switch between the cover and the visualisation plugins, but that’s a long story.

I’ve also been thinking about the «Digital Booklet» that iTunes offers with some albums, which I suppose contains the album art; I’m not sure which format it uses, but I’d suppose it’s still a qt/mov file with image data in it (yes, the format also allows still images to be loaded there); it could be quite nice to support that in xine, too, and Amarok could use such a feature to display the booklet data, as in Amarok 2 there should be at least some video playing capabilities. Unfortunately I couldn’t find an album that I’d spend money on without too much regret that had such a digital booklet to get to test.

This work let me consider about the way xine loads the metadata; right now just a subset of the possible information is recovered from the files; it might be nicer to actually provide all the metadata loaded as possible, trying to map it into standard values, or providing string-mapped values for extended metadata as found in qt/mov/mp4 files. Unfortunately there are two things to consider against such an idea: the first is that the API has to be changed to be able to get the extended metadata, the second is that the metadata loading might be time and memory consuming, and a few xine frontends, like Amarok, might not care about it at all, and as such it would require to add an option (at runtime) to load or not the metadata when opening streams (it cannot be global, as Amarok uses xine’s metadata load to get information about the streams that are being played through http and other protocols where TagLib is useless).

Another thing that might be useful to implement, although Amarok wouldn’t likely make use of it, would be last.fm playback, directly in xine. Unfortunately I never looked up the protocol used, so I can’t assess how much work it’s needed to send the messages and receive the additional metadata; the datastream is actually HTTP-based, at least that’s how Amarok’s proxy mangle it, so it shouldn’t be impossible to implement; there is probably the need of adding an option with username and password to use to connect to last.fm.

Again, optimisations that xine-lib might take is an option to enable/disable the visualisation plugins; this is helpful because most users will likely not use them at all, so why build them? They take up space and time without reason; and it’s also the place where a TEXTREL is found, at the moment, so it might be a good idea to make them optional for security reasons too.

I hoped to make use of exmap to actually track down some of the memory usage in xine, but the current version doesn’t work for me on a current kernel on AMD64, so I gave up for now. If somebody has a clue how to make it work, I’d be happy to know.

To give an update about the current works in progress, then, I’ll try to summary most of what I talked about for 1.2 series:

the audio conversion branch is happy that aRTs output has been removed from 1.2 series of xine; unfortunately it requires still porting for ESounD (can do it on Enterprise), JACK, FusionAudio (these two are Linux’s so they are somewhat doable if I have a lot of time) and SunAudio (Solaris or NetBSD, I don’t have either available to test with); if I can’t find anybody to help me out with this, it might require quite a lot of time before the port is done;
the XDG compliancy work is half done, half because Matt Messier reported some problems when building for a prefix that is not in the default XDG_DATA_DIRS path; in theory we should be changing the code to look first in the prefix for which we built, and then check into the rest of XDG paths; I still have to find time to do this, and that’s why xine-ui isn’t ported yet;
the new libdvdnav copy requires some testing with non-encrypted ISO9660 DVDs, that should work fine with the current internal copy of libdvdnav, albeit with a very nasty hack that we’re lucky is working; I have to find such a DVD myself first hand to be able to test if the new libdvdnav can be fixed without the same hack, before merging it into mainline;
the new DocBook guide got me a bit stuck; I’ve converted the documentation to DocBook 4.4 XML, and then converted the fig images to SVG (which is quite more modern, and probably easier to deal with), and I got the rules in place to build them; unfortunately there doesn’t seem to be a nice and little SVG rendering program for OS X, so I can’t make the dependency over xmlto and rsvg (or any other rendering program) mandatory (for installing from Hg), which means I have to return to the previous nasty hacks;
what else? Well there are a lot of things to work on in xine, unfortunately we need waaay more man power; Thibaut started working on the new plugin loading code, but he’s gone MIA again.

Anyway, if you want to help in any way with these tasks, it’s certainly appreciated; development is the best thing, but if you cannot, maybe you can find someone who can actually grok xine-lib, and convince her/him to help, we do need people. On the other hand, if you know of a decent album of Metal, J-Pop or Jazz music, available on iTunes Plus (note the Plus, it has to be DRM-free) that contains a digital booklet, please let me know – or even better send a gift card to me with the name of it ;) – so that I can try to work on that particular issue.

Now I should really try to sleep, if I can without wanting again to smash something. I don’t think I live well enough if just thinking of what to do about my life gets me to this point, do I?