It is unfortunate that most server-packages don't seperate out their init scripts into separate packages:
From http://www.symantec.com/connect/articles/active-directory-and-linux...
An alternative to allowing anonymous searches on your Active Directory is to allow the nss_ldap routines to bind as an administrator DN to your directory and perform searches in privileged mode. To do this, insert the following lines in your /etc/ldap.conf file: binddn cn=Administrator,cn=Users, bindpw You should be used to the "" thing by now. WARNING: The above example shows that the administrator user name and password have been coded in clear text in the /etc/ldap.conf file! Unfortunately, this file must always remain world-readable, because otherwise users logged on to the system will not be able to read data from the directory. You should not do this on a system where any user has shell access to your system, or can in any other way read this file.If you've put the Administrator password in a world-readable file, you've already lost.
Freitag, 9. April 2010 21:45
[Nokia N97]
Changes of Events in writeprotected calendar on this phone are not permitted. These changes were ignored: test, 04/09/2010 23:00
...you want to run many. Everybody told me so. Which is why I was
warned when I ran my first one year ago in Paris, I knew I would run
other.
So, on Sunday will be my fourth one and my second Paris Marathon.
So, after 4h10mins in Paris (april 2009), 4h12 in Rambouillet Forest
(all alone in full autonomy mode) and 4h00'49" in Cologne, my target
this time is 3h50.
Weather is announced to be perfect, my physical condition is AFAIK
good, the motivation is very high....my only fear is that I registred
in the "4h target" group (because, back in November, I wasn't
expecting the results I got in February/March in half-marathons). As many people overestimate their target, I
expect to be passing hundreds of runners during the first 5
kilometers, which is not the best way to start....but, hey, Paris
streets are wide enough (except Place de la Bastille, my nightmare....I hope
organizers solved the jam problem there).
Of course, I kinda hope seeing fellow Paris DD's waving giant Debian
swirls, including our wanabee-DPL.....but let's stop dreaming. And
running in a sunny day all across Paris and along river Seine, will be
great again even without Zack. I'll also be missing Ralf and No l who
ran it last year: Ralf is unfortunately suffering from knee problems
and No l is preparing for Mainz marathon (target: 3h??).
Anyway, more news on Sunday afternoon....and let's enjoy a full rest tomorrow!
A special report on America's economy: Time to rebalance I've been thinking about that for a while too, especially after the dollar's recent weakness, although it has been strengthening some, lately, apparently due to the state of Greece's finances... I think that the computing industry is, in general, well poised to take advantage of that. For instance, what could be easier to export than computing power or "Software as a Service"? All it takes is a few minutes for someone in Europe to sign up to a US-based service with a credit card. For instance, compare Linode's prices and good service with most of their European competitors (gandi.net for instance, who are good people, and you have to love that they put "no bullshit" right on their front page). Not that they don't have good service in Europe, but it's very difficult to compete on price with the dollar being significantly cheaper. With the dollar where it is right now, gandi is almost, but not quite, competitive with Linode. If you don't include taxes. If the dollar weakens again, though, things could easily tilt far in Linode's favor. Besides a weak dollar, I think it will be important for companies in a position to do so in the US to focus on "the rest of the world". The US is a big, populous country where it's very easy to forget about far-off lands. Compare my home town of Eugene, Oregon to where I live in Padova. Google Maps says that it takes 7+ hours to drive to Vancouver, Canada (which, to tell the truth, isn't all that foreign in that they speak English with an accent much closer to mine than say, Alabama or Maine). Going south, Google says it's 15+ hours just to San Diego, although I think that's optimistic myself, given traffic in California. From Padova, I can be in France in 5 hours, according to Google, 3 hours to Switzerland, 4 to Innsbruck, in Austria, less than 3 hours to the capital of Slovenia, Ljubljana, and around 3 hours to Croatia, too. And if you wanted to throw in another country, the Republic of San Marino is also less than 3 hours away, according to Google's driving time estimates. You could probably live your entire life in a place like Eugene and never really deal much with foreigners, whereas here, nearby borders are both a historic and an ever-present fact. The outcome of this is that, to some degree, people in the US have traditionally focused their businesses "inwards" until they got to a certain size. Which is, of course, a natural thing to do when you have such a big, homogenous market to deal with before you even start thinking about foreign languages, different laws, exchange rates and all the hassle those things entail. However, if exchange rates hold steady or favor the US further, and internal spending remains weaker, it appears as if it may be sensible for companies to invest some time and energy to attract clients in "the rest of the world". "Cloud" (anyone got a better term? this one's awfully vague, but I want to encompass both "computing power" like Linode or Amazon's EC2, as well as "software as a service") companies likely will have a much easier time of things: for many services, it's easy to just keep running things in the US for a while, and worry about having physical or legal infrastructure abroad later. Your service might not be quite as snappy as it may be with a local server, but it'll do, if it performs a useful function. Compare that with a more traditional business where you might have to do something like open a factory abroad, or at the very least figure out the details of how to ship physical products abroad and sell them, and do so in a way that you're somewhat insured against the large array of things that could go wrong between sending your products on their merry way, and someone buying them in Oslo, Lisbon or Prague. Since this barrier to entry is lower, it makes more sense to climb over it earlier on. As an example, Linode recently did a deal to provide VPS services from a London data center, to make their service more attractive to European customers. However, they still don't appear have marketing materials translated into various languages, and presumably they don't have support staff capable of speaking languages like Chinese, German or Russian either (well, at least not in an official capacity). This isn't to pick on them; they may have considered those things and found them too much of an expense/distraction/hassle for the time being - they certainly know their business better than I do - and that they simply are content to make do with English. Other businesses, however, may decide that a local touch is important to attracting clients. What do you need to look at to make your service more attractive to people in other countries? In no particular order:
The first production run of TeleMetrum
boards arrived from our assembler today, and overall things are looking good!
Unfortunately, I specified the wrong value for a capacitor associated
with the new and improved 150mA 3.3 volt regulator. The resulting symptom
was interesting to debug... everything seemed to be fine except that the GPS
chip wouldn't talk to us. After some investigation, it became clear that
the 3.3 volt power
supply was taking much longer to stabilize than it should... long enough that
the power-on reset circuit was relaxing before the supply was stable! The
cc1111 apparently handles this just fine, but the GPS chip doesn't. Since
the new cap is optional, just removing it caused everything on the
first test board to
start working! The ultimate solution will probably be to both replace the
new bypass capacitor with one of the correct value, and to swap out the cap
in the reset circuit for a somewhat larger value to ensure we have plenty
of margin in the reset circuit.
I now have 4 of the new boards completed, turned on, and passing initial
tests. Hopefully tomorrow I'll be able to wrap up the rest of the required
functional testing. I then need to focus my attention on a business trip
all of next week... but if all keeps going well, we're very close to
taking our first orders.
Stay tuned!
After being away from home for almost two weeks (and, due to unforseen circumstances, having the longest time away from my mailbox I can recall in almost 15 years), last Monday I met with Pooka and Caro, originally just for lunch, but it evolved into an evening-long work session on the SECO3 project (which I continued long into the night But I'm drifting into offtopicness).
Caro is now living again in Costa Rica, and to prove it, she brought us two delicious-smelling bags of coffee. Now, I know my cats like the smell of coffee, I know specially Santa loves to completely put her head inside my coffee cup and lick what's left of my espresso's foam
But this was really surprising. It was not until today, three days later, I had the heart of bringing my coffee to the office where I'll enjoy it.
It is so aromatic that Chupchic and Santa seemed to be taking turns to keep me from claiming the bag At all times, either (or both!) of them layed on top of my precious. It was not until today, when I gave them their breakfast, I was able to take the (still warm) bag of coffee and bring it to work.
ries kernel: [168074.392016] Northbridge Error, node 0, core: -1 ries kernel: [168074.392186] K8 ECC error.This was first noticed somewhere at the beginning of January. A DSA member then used the usual HP tools to check whats up, none of it reported an error. There wasn t much of an option left besides waiting what happens in the future. No support would do anything here. Until March we did not have any trouble. But at the 14th of March this changed, as the HP tools now found a serious error, reporting Status: DIMM is degraded for the third DIMM module. A support ticket was opened at this point and a replacement DIMM got sent out. Unfortunately the well known Mr. Murphy did look at this issue and so the wrong thing was sent out to the wrong place. Countdown continued and 10 days later the host decided to randomly lockup. And as HP servers have an Automatic Server Reset function in such cases, the whole machine rebooted. Not only once. Guess how much a filesystem likes such things when the machine is active. And for added fun a second DIMM got reported as broken, we now had DIMM #3 and #4 gone off. A certain ping-pong with HP support later we asked the local admins to take out the broken DIMMs and then also to change the order in which the remaining DIMMs are arranged. Unfortunately this did not help, the errors stayed. At this time we already turned off the services running on the machine and it mostly waited in the HP Insight Diagnostics test from HPs SmartStart CD. (And it always locked itself at 97% here). The support asked us to try another round of work on the machine, which our DSA team and the local admins did. But as it already was the 30th of March and nothing helped, our DSA got a little more direct in asking for a working solution. Like replacing the board and sending a technician to look and fix the machine. This was scheduled for the 1st of April, but turned out to not work as hoped. For some reason the technician was not able to find the board that was sent as replacement (no fault of our local admins!), so nothing happened the 1st of April except us getting a little upset. DSA communicated this to HP support, asking for escalation and finally getting this fixed. Our local admins could at last greet a HP technician on the 2nd of April then and he even had the replacement board with him, so he did his work there. He also confirmed that the two DIMMs mentioned above are faulty. For some reason he did not replace them, but left them outside of the machine. He also left the place without telling the Brown CS staff, so it wasn t the best performance he made. Fortunately the machine was in a working state again, only missing 2 of its DIMMs, 4Gb RAM. This has to be replaced by HP in the next days. When the Brown CS staff found out the technician left without notice they enabled our DSA to access the ilo of the machine again, so they could get the machine back up. Of course the first run was the HP SmartStart stuff again, running a full test. It reported no error, pheeew. There had been a few more steps in getting the settings of the ilo correct again and running a full filesystem check on it, but somewhere in the night the machine was back up and ready for us FTPMasters and Release team to get the services back. As the machine was back up in the middle of the night where I was sleeping, I did start my work somewhere this morning. At 10:25 CEST this started with a md5sum check of all files we have in our pool/ structure, ie. the Debian archive. We had 655k files to check, so it naturally took a while. Luckily we only found 32 broken files. Even better a set of them is already fixed, the rest of them is easily fixable with a set of binnmus the buildd people helpfully schedule, so not too much work involved in fixing this issue. Could have been worse. (Actually, when the first reboots happened, before the long downtime, we also had some broken logfiles, unreadable changes files and such things. But those I already fixed back then). More or less in parallel to the md5sum check we also started the queue daemons again, to let our upload queues from the other hosts forward their files to the central queue on ftp-master, tested the triggers to the new buildd peoples machine and the release team did a britney run. This took the first 5 hours (and a bit) of the process. As a second step, and we are still in this, we started the processing of the incoming queue. Turned out we have to process 10gigabytes of new uploads, in a total of 1285 uploads. This process is still running at the time I write this blog post, having processed about 1100 uploads. A good 9 til 10 hours run, but this was expected. I actually thought it will take even longer. When this is done I will go and have a manual dinstall run. That is, I will run every action a dinstall is usually doing by hand. And verify each step. Usually dinstall takes some 2 hours, manually it can take a bit more. Somewhere during this run a mirror push will also be done, a fairly huge one this time, with all those updates. When this all works I will turn on FTPMaster cronjobs after this dinstall, or at latest tomorrow morning, as usual, and service is back as usual. As far as I know the release team plans to turn on their cronjobs tomorrow morning too, so this will all be nice then. Apropos release: Please note what I wrote in my latest d-d-a mail:
As a sidenote from me: If you have a package that might be involved in whatever transition to testing, or simply might get involved, it could really help if you wait a day or two with the next upload, so the release team can sort through all before you give them new trouble. If in doubt, try mailing debian-release@lists.debian.org and ask. :)So, thats it, enough annoyance with all those status bits here and there. I go leave you alone now. :)
As I really liked
saying why I think
Open Game Art is a good project I
decided to start a small serie of well done free (well not only
software) projects. This time SFML got to
be the one.
SFML is, as the name already tells, a
Simple and Fast Multimedia Library written in C++ but
providing bindings for a whole bunch of other languages like
Python, Ruby, C,
D and
others. Debian currently provides the
original library as well as
the C and
Python bindings
maintained by the Games Team and
myself. On
a side remark, SFML also uses my
favourite License, zlib.
What I really like about SFML is the readable
code all through the
project. Every time I was unsure what some function does having a look
at the actual implementation (and some OpenGL
and X11) knowledge turned out to be quite
satisfactory. This is, of course, aided by the fact that SFML's
development is driven by a single Developer, Laurent Gomila.
On the rather weak points I'm still hoping the to-be-released 2.0
Version of SFML will introduce something like a stable API which it
currently lacks (although the API has settled and there are no such
huge changes as from 1.2 to 1.3 in recent updates any more). SFML also
uses hand-made Makefiles for building (now supporting DESTDIR at least
-- in some non-standard way) and has the usual load of embedded
libraries which results in it's current load of patches.
For a nice time burner make sure you take a look at the python
binding's snake-like clone. It clearly misses some important aspects
to form a full game but it's nice nontheless. I have a (not-quite)
small
SFML based Project
myself, a forward ported game from my old DirectX days, however it's
unfortunately not yet playable again und rather stalled at the moment
due to lack of time.
So much for SFML. If you feel like it feel free to join me on writing
about well done pieces of software or just about pieces on how you
think it should be done and tell us where you found it happening.
The additional resources provided by Sun allowed us to make major improvements to Tcl and Tk. Scott Stanton and Ray Johnson ported Tcl and Tk to Windows and the Macintosh, so that Tcl became an outstanding cross-platform development environment; Windows quickly came to be the most common platform. Jacob Levy and Scott Stanton overhauled the I/O system and added socket support, so that Tcl could easily be used for a variety of network applications. Brian Lewis built a bytecode compiler for Tcl scripts, which provided speedups of as much as a factor of 10x. Jacob Levy implemented Safe-Tcl, a powerful security model that allows untrusted scripts to be evaluated safely. Jacob Levy and Laurent Demailly built a Tcl plugin, so that Tcl scripts can be evaluated in a Web browser, and we created Jacl and TclBlend, which allow Tcl and Java to work closely together. We added many other smaller improvements, such as dynamic loading, namespaces, time and date support, binary I/O, additional file manipulation commands, and an improved font mechanism. Unfortunately, after several years, Sun decided that they wanted to promote one and only one language. And that language was Java. So Ousterhout and many people from his team decamped to a startup that Ousterhout founded, called Scriptics, where the Tcl and Tk innovations continued:
In 1998, Scriptics made several patch releases for Tcl 8.0 to fix bugs and add small new features, such as a better support for the [incr Tcl] extension. In April 1999, Scriptics made its first major open source release, Tcl/Tk 8.1. This release added Unicode support (for internationalization), thread safety (for multi-threaded server applications), and an all-new regular expression package by Henry Spencer that included many new features as well as Unicode support.
However, as many a company based around open source was to find later, it's a tough space to be in. Scriptics changed its name to Ajuba, and was eventually sold (at a healthy profit, apparently, making it a relative dot com success story, all in all) to Interwoven, for the "B2B" technology that Ajuba had developed. Interwoven was not interested in Tcl, particularly, so, to create a system for the ongoing development and governance of the language, the "Tcl Core Team" was created.
This was something of a blow to Tcl, but certainly not fatal: Perl, Python, Ruby, PHP, Lua have all had some paid corporate support, but it has by no means been constant, or included large teams.
At the same time in the late 90ies, open source was really starting to take off in general. Programmers were making all kinds of progress, and had begun to make Linux into what is today the world's most widely used server platform, and laying the groundwork for the KDE and Gnome desktops. While these may still not be widely used, they are for the most part very polished systems, and leaps and bounds better than what passed for the 'Unix desktop' experience in the 90ies.
One of the key bits of work that was added to Tk was to make it look pretty good on Microsoft Windows systems. This was in an time when the "enterprisey" folks were turning away from Unix in the form of AIX, Solaris, HPUX, et al. and taking up NT as the platform of choice, so it was in some ways sensible to make Tk work well there, and in any case as a cross platform GUI toolkit, it ought to work well there in any case.
And, on the Unix side, Tk emulated the expensive, professional Motif look and feel that serious Unix programmers used. What could go wrong?
As Gnome and KDE continued to mature, though, what would become one of Tk's major (in my opinion) marketing blunders took root. I have it on good authority, from someone who was there in the office, that the Scriptics guys working on Tcl and Tk viewed Gnome and KDE (and the Gtk and Qt toolkits) as not really worth their while. To be fair, since Tk has always been under a liberal BSD style license, the Qt toolkit has always been "off limits". Still, though, the attitude was that Tk was a standalone system, and since it ran on pretty much any Unix system, it didn't need to bother with Gnome or KDE. Gradually, though, as more and more people used Gnome and KDE exclusively on Linux, the Tk look and feel began to look more and more antiquated, a relic from the 1990ies when Motif (which has since pretty much disappeared) was king. Tk applications started to really stand out by not looking at all like the rest of the operating system. And, while Linux may not be responsible for a vast portion of the world's desktops, it is widely used by developers, who were turned off by the increasingly creaky look of the Tk applications they saw.
Tk is and was actually a fairly flexible system, and it would have been possible to tweak the look and feel to make it look a bit better on Linux, without even doing any major work. Maybe not perfect, but certainly better looking. Nothing happened, though.
Another problem was that Tk and Tcl made it so easy to create GUIs that anyone could, and did, despite, in many cases, a complete lack of design skills. You can't particularly blame the tools for how they're used, but there was certainly a cultural problem: if you read most of the early Tcl and Tk books, and even many of the modern ones, there are hundreds of pages dedicated to exactly how to use Tk, but few to none explaining even basic user interface concepts, or even admonitions to the user to seek out that knowledge prior to attempting a serious GUI program.
The end result is that a lot of Tk programs, besides just looking "old fashioned" had fairly poor user interfaces because they were made by programmers who did not have a UI/design culture.
Contrast that with Gnome and KDE, which have made a point of focusing on how to make a good GUI for their systems, complete with guidelines about how applications should behave. It may have taken them some time to get things right, but they have done a lot to try and instill a culture of creating high quality, well-integrated GUI's that are consistent with the system where they run.
Lately, there has been a lot of work to update the Tk look and feel, and it has finally started to bear fruit. However, in terms of marketing, the damage has already been done: the image of "old, crufty Tk" has been firmly planted in countless developers' minds, and no amount of facts are going to displace it in the near future.
Another problem Tcl faced, as it grew, was the tug-of-war between those wishing to see it small, light, and easy to distribute embedded within some other program, and those wishing it to become a "full-fledged" programming language, with lots of tools for solving every day programs. Unfortunately, that tug of war seems to have left it somewhere in the middle. Lua is probably more popular these days as an embedded language, because it is very small, and very fast, and doesn't have as much "baggage" as Tcl. Meaning, of course, that it doesn't do as much as Tcl either, but for a system where one merely wishes to embed a scripting language, without much 'extra stuff', Tcl's extra functionality is perhaps a burden rather than a bonus. On the other hand, while Perl was happily chugging along with their CPAN system for distributing code, giving users easy access to a huge array of add-on functionality, and Python was building up a "batteries included" distribution, that included a lot of very useful software straight out of the box. Tcl, on the other hand, chose to keep the core distribution smallish, and only lately has got some semblance of a packaging and distribution system, that is, however, run by ActiveState, and is (at least according to a cursory glance at the Tcl'ers wiki), not even fully open source. The lack of a good distribution mechanism, and, in the meantime, eschewing a larger, batteries-included main distribution left Tcl users with a language that, out of the box, did significantly less than the competition. Technically, a Python style "big" distribution would not have been all that difficult, so once again, I think this is a marketing problem: a failure of the Tcl Core Team to observe the "market", assess what users needed, and act on it in a timely manner.
Somewhat related to the large Tcl vs small Tcl issue was one particular extension, or extensions to the language that was noticeably absent: a system for writing "object oriented" code. Tcl, at heart, will never be an OO language through and through, like Ruby or Smalltalk, but that doesn't mean that an OO system for it is not a useful way of organizing larger Tcl systems. Indeed, Tcl's syntax is flexible enough that it's possible to write an OO system in Tcl itself, or, optimizing for speed, utilizing the extensive C API in order to create new commands. Over the years, a number of such systems have arisen, the most well-known being "Incr Tcl" (a play on the incr command, which is akin to += 1 in languages like C). However, none of these extensions was ever included with the standard Tcl distribution or somehow "blessed" as the official OO system for Tcl. This meant that a newcomer to Tcl wishing to organize their code according to OO principles had to pick a system to use from several competing options. And of course, newcomers are the least able to judge a complex feature like that in a language, making it a doubly stressful choice. Furthermore, even experienced Tcl programmers who wanted to share their code could not utilize an OO system if they wanted their code to work with just standard Tcl. Also, if their code had a dependancy on some OO system, it would require the user to download not only the extension in question, but the OO system it was built on, which, naturally, might conflict with whatever OO system the user had already selected! As of Tcl 8.6, thanks to the work of Donal Fellows, Tcl is finally integrating the building blocks of an OO system in the core itself, but this effort is probably something like 10 years too late.
Some other more or less minor things that have taken too long to get integrated in the Tcl or Tk distributions include the PNG format (still not there in a production release of Tcl), a readline-based command line (Tkcon is nice, but not a replacement for simply being able to type "tclsh" and get a nice, functional shell like Python, Ruby and most other languages have. This could easily lead to a bad first experience for someone trying out Tcl). Tcl also took too long to integrate a first-class hash type (accessed with the 'dict' command), which only appeared in 8.5. Its "arrays" aren't bad, but don't quite have the full power of a hash table as dict implements them. Once again, the code to do these things was/is out there, it has just been a matter of integrating it into Tcl and Tk, which has been a slow process.
One actual technical problem that Tcl faces is the concept that all values must be representable as a string. This is more or less ok for things like lists, hash tables or numbers, but is problematic when the user wishes to represent a value that simply isn't a string. A basic example is a file handle, which at the C API level is a FILE*. How does Tcl get around this? It keeps an internal hash table with a Tcl-script accessible string, such as "file5" that points to a FILE * value that is used internally by file commands. This works pretty well, but there is a big "but": since you can compose a string like "file5" at any time, that must be able to access the actual file pointer, you can't do any sort of "garbage collection" to determine when to clean things up automatically. Other languages have explicit references to resources, so the program "knows" when a resource is no longer referenced by the rest of the program, and can clean it up. Therefore, the programmer must explicity free any resources referenced this way. This explanation is simplifying things somewhat, but it is something I view as a technical problem with Tcl.
If you've been following along, you've noticed a lot of "these days" and "recently". That's because Tcl is still very actively developed, with a lot of new ideas going into it. However, if you look at the release dates, it seems that after Ajuba was sold off, and Ousterhout pretty much abandoned an active role in the language for good, placing it in the hands of the Tcl Core Team, there was a lull in the momentum, with Tcl 8.5 taking 5 years to be released.
This is actually, in my opinion, an interesting phenomenon in languages: you risk hitting some kind of local maximum when your language is popular enough to have a lot of users who will be angry if things are changed or accidentally broken in the course of big upheavals. So you have to slow down, go carefully, and not rock the boat too much. On the other hand, there is an opportunity cost in that newer languages with less to lose can race ahead of you, adding all kinds of cool and handy new things, or simply fix and remove "broken" features. Erlang is another system that has, in my opinion, suffered from this problem to some degree, but this article is long enough already! Once again, though, not really a technical issue, but a problem with how the code was managed (and not an easy one to solve, at that).
A Tcl failure that I was personally involved with was the web infrastructure. What went on to become Apache Rivet was one of the first open source Apache/Tcl projects, and was actually quite a nice system: it was significantly faster than PHP, and of course made use of Tcl, which at the time had a large library of existing code, and could be easily repurposed for projects outside the web (or the other way around: non-web code could be brought in to a web-based project). One thing I ought to have done differently with the Apache Rivet project was listen to the wise advice of Damon Courtney, my "partner in crime" on the project, who wanted to see Apache Rivet have a fairly "fat" distribution with lots of useful goodies. Rails and Django, these days, have shown that that's a sensible approach, rather than relying on lots of little extensions that the user has to go around and collect. The code was out there, I should have helped make Rivet do more "out of the box".
A problem that is and it isn't: the syntax. Tcl's syntax is amazingly flexible. Since everything is a command, you can write new commands in Tcl itself - and that goes for control structures, too! For instance, Tcl has a "while" command, but no "do ... while". It's very easy to implement that in Tcl itself. You simply can't do that in most "everyday" languages. However, this comes at something of a "cost". The syntax, for your average programmer who doesn't want to go too far out of their comfort zone, is perhaps a little bit further afield from the C family of languages than they would prefer. Still though, a "human" problem, rather than a technical one. Perhaps, sadly, the message is that you'd better not "scare" people when introducing a new language, by showing people something that doesn't look at least a little bit familiar.
Conclusions? First and foremost, that, gradually, Tcl and Tk continue to be improved. However, if one visits developer forums, there are also a lot of negatives associated with the Tcl and Tk "brands", and I am not sure if it will be possible to rectify that. So what can we learn from the rise and subsequent "stagnation" of Tcl?
At 9, it was still pretty empty and we went into the ticket offices to buy our tickets. By the time we got out a few minutes later, it was packed mostly due to the arrival of innumerable tour groups from all over Europe and, apparently, Japan. We went to the Star kr lovsk pal c (Old Royal Palace) first, since I knew from their website that it would close at noon due to a visit from Prince Charles.
That was a beautiful building, and it s amazing to read about the features of it that are centuries old or even almost a thousand years old. The Vladislavsk s l (Vladislav Hall) and chapel particularly caught my eye. Underneath the palace is a museum, including some 1000-year-old jewelry and flooring, and some clothing that is several hundred years old recoverd from burial plots.
We also went to Bazilika Sv. Ji (St. George s Basilica), which one of the guides described as ancient . It was another wow moment, and it felt like the oldest church we were in yet. I think it probably was, actually; last rebuilt in 1142.
For lunch, we asked for a recommendation from our hotel. They suggested one place, which we walked to. It was a nice easy walk down some Prague side streets, but the restaurant and all the others along our walk were closed on Saturday. We eventually made our way back to the hotel and asked for a new recommendation, which was successful this time. Terah ordered some ribs, while I ordered a more traditional Czech goulash, which happened to be served in a bread bowl. A minute later, the waiter brought Terah a fork and knife. And he brought me a bowl of water with a slice of lemon, and announced wash for you. That was a surprise, and a bit puzzling one at that. Turns out that eating bread that had stew served in it is indeed a bit messy, and having some water to clean up with is indeed helpful.
We met up with Anna from Leipzig and one of her Czech friends for dinner Saturday night. We found a nice local Czech place. I had ham with sauerkraut in a folded potato cake. It was excellent, and the total bill for Terah and me came to 235 Kc or about $12.50. We had a nice walk back to the hotel in the crisp, dark evening.
Sunday morning we had breakfast at our hotel the only time we ate a meal at a hotel this whole trip then got on the tram, the metro, and the bus to the airport. Total cost for that trip for two: 52 Kc, or about $2.75. Far cheaper than a taxi.
One weird thing happened to us in Prague. We were riding the tram towards downtown, and as we would be on it for several stops, Terah was sitting. I was standing as there wasn t an available seat for me. Terah and I were both looking out windows, until Terah was startled because her arm was wet. She looked around and it turned out a middle-aged woman had spit on her, and was glaring at her. We never did figure out why. About all we can think of is maybe someone else, such as a very old person, had gotten aboard but Terah hadn t noticed and therefore didn t offer to give up her seat. That was probably the only real rude gesture towards us on the entire trip. We ran the story by Anna s friend (the native Czech) and she was as surprised and baffled as we were.
As I wrap this up, we re sitting at our gate in Prague waiting for our flight to Munich. In this airport, in an out of the way corner on the very lowest floor, I spotted only the second drinking fountain I ve seen in Europe this entire time and also perhaps the continent s most expensive cup of coffee.
After we get to Munich, it s a flight to Chicago, another to Indianapolis, and finally a drive home Monday.
I ve been eagerly looking forward to the release of Xero Personal which has been heavily promoted by Xero and BNZ (as MoneyMap) for the last few months. Unfortunately my first impressions of the product today are extremely underwhelming. Xero Personal is definitely not worth anywhere close to $5/month for me at this point in time and I m unlikely to even keep using the free trial.
To set the context for that statement, Xero Business set the bar high. I first used the original version of Xero while it was still in beta and even then it was clear that it was an application that took accounting to a new level and would provide an order of magnitude improvement in how I maintained the accounts for our business. That promise held true once we started paying for it, even though the cost of Xero is more than 10% of our annual expenses, the time and hassle it saves makes it a worthwhile investment. By contrast today s release of Xero Personal offers nothing new above existing personal finance websites or desktop packages and would take me extra time to use as it fails to handle many of the basic transactions that a normal household will encounter.
The way Xero Personal works is by having you manually upload your bank statements (the automatic import functionality that is so useful in the business version of Xero has been restricted to BNZ MoneyMap customers only). For each transaction you are asked to provide two pieces of information. The first is a category which serves as a basic form of account to track expenses and income. For each category you can set a spending or saving goal which Xero will help you track progress towards. The second is a name to identify the other party in the transaction. Xero Personal comes pre-loaded with some fairly generic categories. Annoyingly you re restricted to no more than 8 additional custom categories and the names associated with each transaction are are simple strings you can t link a transaction to another account or entity. To represent a transfer you need two separate transactions, one in each account, which you assign to the special category Transfer so that Xero knows to essentially ignore it. Nothing links the transactions together or ensures that the values balance.
In addition to the basic categorisation functionality the application also attempts to track your assets and liabilities (bank accounts and credit cards show up automatically) so that it can compute your net worth. Unfortunately as soon as you try and use this you hit the problem that there is no way to link transactions from your accounts back to your assets and liabilities. This means unless you regularly and manually update your assets and liabilities the net worth calculation only takes into account changes in your cash position and becomes blatantly incorrect.
As an example, take the common case of a household with a weekly mortgage (or other loan) repayment. You want the weekly payment to decrease the balance of your current account, increase the balance of your interest expense category and decrease the value of your mortgage liability. Your net worth should decrease by the value of the interest expense only, as the decrease in the value your mortgage liability offsets the remainder of the decrease in the value of your current account.
Xero Personal doesn t come close to being able to handle this example today. The ability to split payments to different categories has also been left out (even though it s present in Xero Business and therefore presumably in the underlying engine) so your only option is to categorise the entire payment as a mortgage or housing expense, decreasing your net worth by the full value of the payment. Even if you could split the payment between two categories, one for the interest and one for the principal the inability to link the category for the principal to the liability account means the net worth calculation will still be incorrect.
Maybe I m being to hard on this newly released product? It is a SaaS application after all and Xero has an excellent history of releasing regular updates to the business version of Xero. The reason I m so surprised and disappointed by this initial release is that it essentially lacks any double-entry accounting support many of the missing features are core functionality that is already implemented in the accounting platform that supports the business version. Assuming that Xero Personal is built on the same platform (and that would be the obvious choice wouldn t it?) the fact that Xero Personal has been released and is being heavily promoted without these features (compared to the initial version of Xero Business which was fully functional and obviously awesome even in beta) suggests to me that it s a conscious decision to significantly limit the scope and usefulness of the application rather than simply a limit on what could be implemented before the initial release.
I sincerely hope that I m wrong and that the coming months bring significant improvements to the functionality of Xero Personal, but until it can support common transactions like mortgage repayments correctly I won t be using it or recommending it to anyone.
After that, we walked through the old trade fair grounds. Leipzig has a long history as a trade center, and after they built the new trade fair grounds, the old ones were reused for other things except for the old Soviet building, which is now both gaudy and abandoned. We picked up Fritzi, who is a very cute 4 years old, from preschool and returned to their house for supper.
After that, Brad and I went back into town, intending to hear a reading at the old city pool. When we realized it was a different day, we walked around the city center for awhile and then had a beer at a yes combination cafe/laundromat.
Thursday was our day to explore the city. Brad showed us a couple of buildings in the university, including the library, then dropped us off at St. Thomaskirche. That s the church where J. S. Bach was music director for many years, and was buried. Like so many, it was impressive in its height and history.
Next we went to the Stasi museum. The Stasi were the feared and powerful East German secret police during the Communist times. The museum itself was housed in the former Stasi headquarters for Leipzig and was involved with the history of the overthrow of the Communists. The museum covered a lot of the history of the Stasi, including its frantic last days during the 1989 revolution. The level of spying on people was incredible and sophisticated, and they tried to destroy records as the overthrow of the government was imminent.
One of the offices in the inner part of the building was left untouched from the Communist years, right down to the typewriter and coffee machine.
After that, we went to the Altes Rathaus (old city hall or townhouse, built in 1556) to do a bit of shopping. Terah was wanting some souvenirs, and I had spotted a shop I thought she might like when walking through the city with Brad the night before. We had already bought some souvenirs at the Schloss Charlottenburg museum store in Berlin (some East German-style crosswalk fridge magnets, and a decorative egg), but wanted something a bit nicer for us and were on the lookout for gifts for others too. We wound up buying a wood carved church scene with a woven wheat tree for us, and another item for others. The shopkeeper spoke no English, and my German vocabulary is small, but we managed to communicate the question of whether or not she could wrap it up in a box for our trip home and she could, and did. Excellent. (I didn t know how to ask about box, but knew how to say that we were Americans, and with a fair bit of gesturing all around, managed to get the idea across.)
Then we went in the Altes Rathaus itself, which was both a museum and an interesting cultural experience. We bought our tickets at the booth downstairs, then went upstairs to the entrance. We asked for the English audio guide, which is very common at museums in Germany. (They are small digital audio players that contain recorded information; each room or display has a number you can key in to hear about it in your own language.) We got it, and were told in incredible detail how to use it, even though they are quite easy to figure out and we had used them before. The museum employee told us where the audio tour starts, and in what order it usually goes, which was an effort for her given her limited English. But we all understood and went on our way.
It wasn t even 5 minutes later when she had left her desk and came over to us. She was slightly alarmed at two things: one that we didn t have the volume at full blast (which was loud enough for the entire room to hear), and secondly that we weren t looking at the exhibits in the proper order. Never mind that it s easy enough to pull up the audio information about any room just by keying in the number posted in it, I guess. Anyhow, we sort of inwardly shrugged, let her turn the volume up to potentially disturbing the other visitors level, and went through the museum in the order she wanted us to. (Note that this wasn t a museum where there is a one-way flow of traffic or something; you walk into one exhibit, back to the main hall, and then pick your next one.) So we went through the rest of the museum with our English audioguide blaring throughout the large, echoing, wood rooms, feeling a bit rude to the other visitors (maybe 5 of them while we were there) due to its volume.
Anyhow, the Altes Rathaus was beautiful and interesting, covering mainly the pre-industrial history of Leipzig. We learned about some of the guilds, the city treasury (vault), and where the town council/parliament met along with rich merchants. There were about as many museum guards as visitors there, and one or two of them sort of followed us around, pointing out the large and completely obvious signs with audio guide numbers in the rooms for us. They are serious about their audio guides in Leipzig.
I m glad we went, and I m glad we had the experience we did, too. Terah told me later that she felt reprimanded about the audio guide and visiting order. My take on it was a bit different: the museum is impressive and interesting, but obviously not visited by tourists as much as museums in other cities, or even touristy sites like Thomaskirche in Leipzig. I think they they noticed two people, obviously very foreign (speaking only a little German, and with an American accent) with an interest in their city s history, and took pride in making sure we got the most of our visit and learned as much as possible about something they care about.
Here is the main hall of the Altes Rathaus.
We met up with Brad in a cafe near St. Thomaskirche for coffee and cake, then it was on to St. Nikolaikirche (the Church of St. Nicholas), the other large church in town. We stepped out of a passageway to face the large building, and walked in. The interior was decorated in pastels, and was also beautiful and historic. I can t get enough of that sort of building, I think. This building was especially important because it was the site of organizing for the Monday evening protests against the Communist government in 1989. People met at the church, sang a few hymns (to qualify it as a religious service, perhaps), then organized their protest for the evening. Sometimes they would wind through city streets and put flowers at the Stasi headquarters steps, and once the citizens actually overtook the Stasi headquarters.
After awhile we grabbed a bit more for lunch: a pretzel for Terah and a Currywurst for me. (This one wasn t spicy and wasn t all that good.) Then we went to the GDR museum, which was large and interesting, but unfortunately for us, completely in German with no English guide available.
That evening, we went to a Bach concert at the Leipzig Gewandhaus, celebrating Bach s 325th birthday. That was fun, and a neat experience with such good music in a very nice venue. The program included Bach s Suite for Orchestra no. 1 in C Major (BWV 1066), Concerto for Violin no. 2 in E major (BWV 1042), Ich habe genug (BWV 82), and Suite for Orchestra no. 4 in D major (BWV 1069). Sir Roger Norrington was conducting, and was rather fun and atypical to watch. He had the audience chuckling a few times with his minimalist conducting or perhaps his flamboyant gestures. Anyhow, the music was excellent and the tickets included free passage on the public transit system 3 hours before and after the concert a nice touch.
Due to our schedule, we didn t spend much time with Fritzi, but we did get to play with her a bit. She likes to pretend to be a shopkeeper, and had her store all ready to lay out. We would ask her for some items, which she d put in a basket for us, and then of course there would be a child s twist: we d get our items, and she d pay us for them too.
Terah and I brought some books for Fritzi. The particularly enjoyed Goodnight Moon because inside it is an picture of The Runaway Bunny, which she already had. Fritzi chose one of her books to give to Jacob it was a German book (Maulwurf) based on a Czech cartoon mole. That was nice of her, and Jacob really liked it (I ll write about that later).
We had a good time in Leipzig, and I was getting fairly good at navigating downtown and with the trams and then, of course, it was time to move on. So Friday morning we caught our 7:50 train from the Leipzig Hauptbahnhof. We took the ICE train to Dresden, then walked a few feet to get onto the EC to Prague. That was a bit of a funny experience. The ICE trains are all sleek, modern, meticulously maintained, and the passengers tend to be very quiet. Talking is barely above a whisper, and people seem alarmed if their cell phone rings, even outside the quiet car. The EC passenger car appears to have been built, or last renovated, in the 1970s, and may have been Hungarian. The seats and curtains are old and faded; some of the seat backs have rips in the vinyl headrests. People were talking or eating loudly, in a very different setting than on the ICE train.
As we rode along, we were on the right side the river Elbe for many miles. The scenery was beautiful, with small houses in the river valley, and the occasional house up in the hillside. At one point (a bit before we passed through K nigstein on the way to the Bad Schandau stop), we spotted what looked like an old walled city up on the hill. I figured out later that it was Festung K nigstein (K nigstein Fortress).
Update: I forgot to mention a couple of things about Leipzig. One was our walk through a forest yes, a forest in the city. That was a nifty, quiet, and pleasant surprise. Secondly was seeing all the DDR apartment blocks, where the apartments evidently were quite literally blocks. It is interesting to see the Communist architecture.
Ubuntu always gets a lot of coverage in blogs, and the recent This should be fixed ... or I'm gonna .. install .. gentoo. yeah. really.(Similarly you see many comments of the form "I agree", "oh noes", or "Please revert ASAP", rather than technical arguments.) This non-technical nature of the userbase is also readily apparent if you browse through the answers to problems posted in forums for example "Delete this file, I don't know why it works but it fixes it for me!!2!". (I've seen some truly horrific advice upon Ubuntu forums, even so far as chmodding various parts of the system to allow users to write binaries to /bin.) Similarly you'll see that the launchpad is full of generic linux misunderstandings and bugs that aren't "real". The unfortunate fact is that the Ubuntu bug tracker is a wasteland in many places:
Ubuntu as a distribution is interesting, and I'm not trying to be overly critical - A year or two ago had somebody thrown money at me I might have been inclined to accept it. I think most of the perceived problems stem from a single common source, which is largely the issue of scale. (e.g. bug reports to bug handlers. developer numbers to user numbers.)There are many good things to be said about Ubuntu (& Canonical) in addition to the negative ones that we see in the press or that I've perceived and mentioned above. The truth is it works for a lot of people, and the growing pains will continue until it either dies or both its audience and itself matures. Either way I don't hate Ubuntu, in the same way that I don't hate Microsoft, Oracle, Fedora, Gentoo, or other mass-entities. There are pros and cons to be made for most of them, (and of course Debian itself is no different).
However I will say that every time I see people write "If you want a sexy/shiny/easy to use Linux desktop then install Ubuntu" I glance over at my Debian Lenny desktop, marvel at how sexy, shiny and easy to use it is, and get a little bit disappointed at our own marketing failure(s).ObFilm: Day of the Woman
Note: I wrote most of this before Neil Williams' recent comments on the 3.0 family of formats, so despite the timing this isn't really a reaction to that although I do have a couple of responses. On the whole I think I agree that the Lintian message is a bit heavy-handed and I'm not sure I'm thrilled about the idea of the default source format being changed (though I can see why the dpkg maintainers are interested in that). That said, as far as I personally am concerned, there is a vast cognitive benefit to me in having as much as possible be common to all my packages. Once I have more than a couple of packages that require patching and benefit from the 3.0 (quilt) format as a result, I find it in my interest to use it for all my non-native packages even if they're patchless right now, so that for instance if they need patches in the future I can handle them the same way. It's not unheard of for me to apply temporary patches even to packages I actively maintain upstream, so I don't discount those either. I haven't decided what to do with my native packages yet; unless they're big enough for bzip2 compression to be worthwhile, there doesn't seem to be much immediate advantage to 3.0 (native).
Anyway, on to the main body of this post:
I've been one of the holdouts resisting use of patch systems for a long time, on the basis that I felt strongly that dpkg-source -x ought to give you the source that's actually built, rather than having to mess around with debian/rules targets in order to see it. Now that the 3.0 (quilt) format is available to fix this bug, I felt that I ought to revisit my resistance and start trying to use it. Migrating to it from monolithic diffs is of course a bit more work than migrating to it from other patch systems, so it's taken me a little while to get round to it. I'd been thinking about holding off until there was better integration with revision control (e.g. bzr looms), as I feel that patch files really ought to be an export format, but I eventually decided that I shouldn't let the perfect be the enemy of the good. I have enough experience with co-maintaining packages that use build-time patch systems to be able to compare my reactions.
After experimenting with a couple of small packages, I moved over to the deep end and converted openssh a few weekends ago, since quite a few people have requested over the years that the Debian changes to openssh be easier to audit. This was a substantial job - over 6000 lines of upstream patches - but not actually as much work as I expected. I took a fairly simplistic approach: first, I unapplied all the upstream patches from my tree; then I ran bzr di interdiff -q /dev/stdin /dev/null >x, reduced it to a single logically-discrete patch, applied it to a new quilt patch using quilt fold, and repeated until x was empty. This was maybe an hour or two of work, and then I went through and tagged all the patches according to DEP-3, which took another few hours. After the first pass, I ended up with 38 patches and a much clearer idea of what has been forwarded upstream and what hasn't; I currently have 5 patches to forward or eliminate, down from 18.
Good things:
dpkg-source -x gives you, so it's the natural representation in revision control too), bzr blame works just as you'd expect and displays both upstream and Debian changes at once. I rely on tools like blame a lot, and I really hate the way build-time patch systems make it hard to use revision control when the tree is in a built state, so this was a hard requirement for me..pc directory, and the tree checks out in the patched state (as it should), so I needed some way for developers to get quilt working easily after a checkout. This is sort of the reverse of the previous problem, where users had to do something special after dpkg-source -x, and I consider it less serious so I'm willing to put up with it. I ended up with a rune in debian/rules that ought to live somewhere more common.quilt pop -a, force a merge despite the modified working tree, and then quilt push && quilt refresh -pab until I get back to the top of the stack, modulo slight fiddliness when a patch disappears entirely; thus effectively using quilt's conflict resolution rather than bzr's. I suppose this will serve as additional incentive to reduce my patch count. I know that people have been working on making this work nicely with topgit, although I'm certainly not going to put up with the rest of git due to that; I'm happy to wait for looms to become usable and integrated. :-)Next.