Hi,
I m looking for a tool to create simple websites (5-10 pages), only static content (no PHP). Think of the typical small business or sports club website: text + pictures about what they did/do, nothing really complex.
Requirements:
Warning: pg_query_params() [function.pg-query-params]: Query failed: ERROR: column "g_userid" is of type integer but expression is of type text HINT: You will need to rewrite or cast the expression. in /usr/share/php/adodb/drivers/adodb-postgres7.inc.php on line 113
-1: ERROR: column "g_userid" is of type integer but expression is of type text HINT: You will need to rewrite or cast the expression.
ADOConnection._Execute(
INSERT INTO
g2_ImageBlockCacheMap
SELECT DISTINCT
?, ?, g2_Entity.g_creationTimestamp, g2_Entity.g_id, FLOOR(RANDOM()
..., Array[45]) % line 1007, file: adodb.inc.php
ADOConnection.Execute(
INSERT INTO
g2_ImageBlockCacheMap
SELECT DISTINCT
?, ?, g2_Entity.g_creationTimestamp, g2_Entity.g_id, FLOOR(RANDOM()
..., Array[45]) % line 952, file: GalleryStorageExtras.class
GalleryStorageExtras.execute(
INSERT INTO
[ImageBlockCacheMap]
SELECT DISTINCT
?, ?, [GalleryEntity::creationTimestamp], [GalleryEntity::id],
FLOOR(R..., Array[45]) % line 507,
file: GalleryStorage.class
GalleryStorage.execute(
INSERT INTO
[ImageBlockCacheMap]
SELECT DISTINCT
?, ?, [GalleryEntity::creationTimestamp], [GalleryEntity::id],
FLOOR(R..., Array[45]) % line 742,
file: ImageBlockHelper.class
ImageBlockHelper.cacheViewableTree(17) % line 520, file: ImageBlockHelper.class
Error performing imageblock.LoadImageBlock callback realpath(/usr/share/gallery2/modules/core/classes/../../../) realpath(/var/www/net/gallery.windfluechter.net/) Error (ERROR_STORAGE_FAILURE)
in modules/core/classes/GalleryStorage/GalleryStorageExtras.class at line 959 (GalleryCoreApi::error)
in modules/core/classes/GalleryStorage.class at line 507 (GalleryStorageExtras::execute)
in modules/imageblock/classes/ImageBlockHelper.class at line 742 (GalleryStorage::execute)
in modules/imageblock/classes/ImageBlockHelper.class at line 520 (ImageBlockHelper::cacheViewableTree)
in modules/imageblock/classes/ImageBlockHelper.class at line 283 (ImageBlockHelper::fetchViewableData)
in modules/imageblock/classes/ImageBlockHelper.class at line 93 (ImageBlockHelper::_getBlockData)
in modules/imageblock/Callbacks.inc at line 83 (ImageBlockHelper::loadImageBlocks)
in modules/core/classes/GalleryTemplateAdapter.class at line 1052 (ImageBlockCallbacks::callback)
in g2data/smarty/templates_c/%%626616196/matrix/%%A3A3EA3E218EA%%ImageBlock.tpl.php at line 5 (GalleryTemplateAdapter::callback)
in /usr/share/php/smarty/libs/Smarty.class.php at line 1868
in modules/core/classes/GalleryTemplateAdapter.class at line 983 (Smarty::_smarty_include)
in g2data/smarty/templates_c/%%626616196/matrix/%%B4B49B49848CB%%sidebar.tpl.php at line 7 (GalleryTemplateAdapter::block)
in /usr/share/php/smarty/libs/Smarty.class.php at line 1868
in modules/core/classes/GalleryTemplateAdapter.class at line 909 (Smarty::_smarty_include)
in g2data/smarty/templates_c/%%626616196/matrix/%%ADAD7AD74CEE9%%photo.tpl.php at line 12 (GalleryTemplateAdapter::theme)
in /usr/share/php/smarty/libs/Smarty.class.php at line 1868
in modules/core/classes/GalleryTemplateAdapter.class at line 909 (Smarty::_smarty_include)
in g2data/smarty/templates_c/%%626616196/matrix/%%3A3A83A818B59%%theme.tpl.php at line 55 (GalleryTemplateAdapter::theme)
in /usr/share/php/smarty/libs/Smarty.class.php at line 1262
in modules/core/classes/GallerySmarty.class at line 61 (Smarty::fetch)
in modules/core/classes/GalleryTemplate.class at line 219 (GallerySmarty::fetch)
in main.php at line 521 (GalleryTemplate::fetch)
in main.php at line 104
in main.php at line 88
* in main.php at line 3
file_exists(/var/www/net/gallery.windfluechter.net/g2data/cache/module/_all/0/0/GalleryPluginHelper_fetchPluginStatus.inc) getParameter smarty.compile_check for core plugin file_exists(/var/www/net/gallery.windfluechter.net/g2data/cache/module/core/0/0/0.inc) file_exists(/var/www/net/gallery.windfluechter.net/g2data/smarty/templates_c/%%626616196/matrix/%%C7C79C79EEB7F%%ItemInfo.tpl.php) strftime(%x, 1231148074) file_exists(/var/www/net/gallery.windfluechter.net/g2data/smarty/templates_c/%%626616196/matrix/%%F3F3EF3EB483E%%PhotoSizes.tpl.php) file_exists(/var/www/net/gallery.windfluechter.net/g2data/cache/entity/2/1/21143.inc) file_exists(/var/www/net/gallery.windfluechter.net/g2data/cache/entity/2/1/21080.inc) file_exists(/var/www/net/gallery.windfluechter.net/g2data/cache/entity/1/9/19996.inc) file_exists(/var/www/net/gallery.windfluechter.net/g2data/cache/entity/4/4/4457.inc) file_exists(/var/www/net/gallery.windfluechter.net/g2data/cache/entity/0/0/7.inc) file_exists(/var/www/net/gallery.windfluechter.net/g2data/smarty/templates_c/%%626616196/matrix/%%5A5A35A33504B%%Navigator.tpl.php) file_exists(/var/www/net/gallery.windfluechter.net/g2data/cache/entity/2/1/21148.inc) file_exists(/var/www/net/gallery.windfluechter.net/g2data/cache/entity/2/1/21588.inc) file_exists(/var/www/net/gallery.windfluechter.net/g2data/cache/entity/2/1/21127.inc) file_exists(/var/www/net/gallery.windfluechter.net/g2data/cache/entity/2/1/21138.inc) file_exists(/var/www/net/gallery.windfluechter.net/g2data/cache/entity/2/5/25248.inc) file_exists(/var/www/net/gallery.windfluechter.net/g2data/smarty/templates_c/%%626616196/matrix/%%F6F68F68636C4%%ExifInfo.tpl.php) postgres7 error: [-1: ERROR: current transaction is aborted, commands ignored until end of transaction block] in EXECUTE(" SELECT g2_Group.g_id, g2_Group.g_groupName FROM g2_UserGroupMap, g2_Group WHERE g2_Group.g_id = g2_UserGroupMap.g_groupId AND g2_UserGroupMap.g_userId = ? ORDER BY g2_Group.g_groupName ")
While I have most of my albums encoded as Ogg Vorbis files,
the music from my college days (and before) is still only on disc,
either in a big box in storage, or in one of a couple Case
Logic CD wallets I used back then to lug my tunes around the
globe.
I ve long been meaning to encode those and shove the boxes and
cases into storage, but in more than a year, that hasn t happened.
A few weeks ago, my adorable
girlfriend offered the necessary encouragement, suspecting that
I might enjoy going through old music again. Right she was: it s
great fun. I didn t think I was ever going to listen to Drum and Bass
again, and now I am quite enjoying the music I listened to in high
school.
Unfortunately, while encoding all those discs, there s a pattern
emerging: the discs from the box are all processed without any
problems; the discs from the wallets yield many read errors.
Inspecting the physical media, the cause seem to be scratches in
the plastic deep enough to damage the reflective layer.
When CDs came out, they were touted to be rigid and sturdy. The
material quality has noticeably decreased in the years, as the
producers kept cutting their costs. Discs of the past 15 years
aren t good enough anymore to be stored in the Case Logic way. I
wish I had known 15 years ago.
NP:
LTJ Bukem: Logical Progression
I've been converting all my Mercurial repositories to Git. One of the
motivations for this was hg's poor handling of branches and tags:
branches are just another metadata field on a commit, and tags are
entries in a text file called .hgtags that is tracked in the
repository(!). Git has its flaws as well, but I prefer its view that
branches and tags are just refs, which are pointers that exist at the
repository level and are pushed or pulled around in much the same way
as the objects they refer to.
The excellent hg-to-git.py script included in contrib created Git tags
corresponding to my old Mercurial tags, but of course didn't modify
the actual commits. So I still had a .hgtags file in my Git
repository, and a boilerplate commit of the form "Add tag foo for
changeset bar" each time I added to it (recall that .hgtags is just
another file. Thankfully, I never had to deal with two branches where
I added different tags...). I wanted to remove these. Git has a
'filter-branch' command that can totally rewrite or expunge commits;
this is of course a horrible idea for already published code, but
there's no harm in using while initially preparing a repository.
While I appreciate git's object model and speed, I must agree with its
detractors that the user interface is terrible. It took some tinkering
to get git-filter-branch to do what I wanted, so I'm writing this to
save my notes for next time (and in case someone else is searching for
how to do this). Here's the command I arrived at:
git filter-branch \
--tag-name-filter cat \
--index-filter 'git update-index --remove .hgtags'
--commit-filter \
'if [ $# = 3 ] && git diff-tree --quiet $1 $3; then
skip_commit "$@"
else
git commit-tree "$@"
fi' \
HEAD
The tag name filter is always necessary if you want tags to be updated
to point to the corresponding commits on the new, rewritten branch. I
consider this a UI failure -- when a branch is rewritten, the ref is
modified, and the old one moved to refs/original. Tags, on the other
hand, stay where they are, without any indication on the new branch
that this is where you might want to move that old tag and sign it
again or whatever. IMHO they ought to be handled the same as branches.
The index filter is simply an efficient way of removing the unwanted
file from all commits. This and the tag filter are both covered in the
manual page.
Writing a commit filter is a little more obscure. After .hgtags is
removed from the index, we may end up at one of those useless "Added
tag foo" commits and have no changes to record in the commit. By
default, of course, filter-branch still records these -- the commit
message might be useful, or something. But I want to suppress them.
The commit filter is called with a tree -- you're at the point between
write-tree and commit-tree (I recommend Git from the bottom up if
you're confused here.) It gets that tree ($1), and then "-p PARENT"
for each parent, just like commit-tree. So, if this is a normal commit
with one parent, there will be 3 arguments. (If there's only one
argument, there is no parent, i.e., the first commit, and if there are
more, then it's a merge.) This is the only case we want to mess with.
If there are no changes between our tree and the parent's tree, then
it's one of those no-op commits, and we can skip it (skip_commit, a
shell function defined by filter-tree, uses some deep magic to hand us
the original parent again next time).
I think diffing the index and the parent would work as well, but this
seemed clearer. It still feels like a hack, so I'd love to hear from
anyone who can suggest improvements. Since this is a special case,
maybe it's better off being implemented in hg-to-git.py itself.
There's always more than one way to do it.
Update: Teemu Likonen points out that the next version of Git
(1.6.2, not yet in unstable) will have a --prune-empty option which
makes this particular problem totally trivial. I am starting to get
the feeling that the Git developers are all reading our minds... :-)
I have a bit of money invested in stocks and funds, passively
managed by my bank. I ve made a bit with risky speculations, and
I ve lost about the same amount with the markets dive of the last
18 months. Net benefit: zero cash, a bit of experience. Time to
move on
I am not an interesting customer, so I was all the more
surprised to get a call from an employee of the bank the other day.
He identified himself as Crisis Manager or something similarly
ridiculous, mentioned at least 20 times that he was a regular
employee and wouldn t receive provisions, and he also kept assuring
me that he s doing himself what he s suggesting to me: leveraging
the cost-average effect.
I turned him down, probably a bit too briskily. Let s
investigate why.
Banks are good at devising ingenious tricks to fool people; it s
their business after all. One of those tricks is the so-called
cost-average effect. It s awesome, they say, because it is the
first product that adapts to the ever-changing market: when prices
are up, it buys smaller numbers of shares, and in low times, it
stocks up on them by buying larger quantities, automatically.
Fancy, no? It isn t, because the entire idea is to get your
signature on a contract that obliges you to pay a fixed sum each
month, with which shares are then bought. Obviously, when prices
are up, numbers you get for your money are low, and vice versa.
Observe how well the banks manage to turn that basic rule into a
selling point. They are good at that. In fact, that s probably all
they re good at. Obviously , inflation is also factored in, so the
monthly fixed sum actually increases by a projected 5% each year,
which they call inflation protection .
While this strategy investing fixed-sum installments rather
than lump sums certainly has its benefits, and can level out the
risk of throwing a large sum of money at the market, it is commonly
considered a suboptimal strategy, especially when employed over
longer spans of time. For more information, I refer you to the
frequently cited article Nobody gains
from dollar cost averaging analytical, numerical and empirical
results , published in the 1992/1993 issue of the Financial
Services Review journal.
So why would the bank approach me with this offer ? Let s go
hypothetical and check out Ashley s investment practices:
Ashley bought a fund five years ago at 100 per share, and it s
now down to 80 . The loss is thus 20%, a -4% factor (20% / 5 years)
that affects the overall performance of the portfolio.
Ashley doesn t really care much about the percentages. After
all, the only thing that counts is the worth of the shares when
sold right now. Everything else is history and only influences the
size of the tears one weeps in times like this, which is a
psychological malfunction, not a function of the financial markets
crisis.
The bank, however, does not like negative performance
values.
Positive percentages yield happy (blinded?) customers, who get
much more enthusiastic (greedy?) to put more money into the giant
machine that makes the banks tick which is still in the process
of blowing up into their faces.
But negative performance values cause investors to become
conservative and leery. They d rather hold on to their hard-earned
cash for fear of losing more. That s the flip-side of
aforementioned psychological malfunction, and this is the core of
the reason why some of the big investors get bigger even in times
like this they do not succomb to the feeling .
The banks, however, need cash, and loads of it, and while the
state is busy printing notes, they take every chance to get more.
Private clients are wonderful prey, as they are less informed about
the system than investors. So, to get cash from the clients, the
banks have to circumvent the psychological malfunction.
They cannot boost the market value share, but there are two
values that factor into a percentage, and the cost-average effect,
sold as the best thing since sliced bread, is nothing but a way to
affect the other number: the sale price, the divisor.
If the fund stays below the original sale price (100 ), each
time Ashley pumps more cash into the machinery each month, this
divisor decreases, effectively decreasing the percentage value. In
the long run, this yields happier customers, who are willing to put
more money in, especially if the performance turns positive. The
baseline is now lower, so a return to previous heights would
correspond to larger performance values than ever before.
Obviously, a positive market causes the baseline to grow, but
the cost-average deals continues to pay off for the banks. Since
Ashley put that signature on the contract, the bank has a
guaranteed cash flow for the contract s duration, while Ashley
wonders why the percentage remains dampened. Cost-average means
decreasing the percentage, in good as well as in bad times. Just
now, the bank doesn t have to work so hard to get even more money
from you.
It gets worse: usually, those contracts are embedded in some
sort of life insurance deals with grand promises in 40 years to
come, and over all that time, it ll be quite clear who wins and who
loses.
Scary, huh? I was going to end with the advice to stay away from
the cost-average effect, but I think I can just as well make it
more general: if you don t understand a deal, don t sign it. If you
abide by that rule, you would stay away from cost-average effect
deals all by yourself.
Maybe my little writeup has helped, nonetheless.
NP:
DJ Ti sto: Live at Innercity
At some point in the past, when I was still thinking that Glest can be packaged in a sane way, I had a conversation with upstream developer martinho on the Glest forum (they call it board) about them integrating a patch in order to support big endian machines.
I've been a bit surprised by the strong positive response to my previous post. People generally seemed to think it was quite non-ranty; maybe I should clean the rust off my flamethrower. :-) My hope was that I'd be able to persuade people to change some practices, so I guess that's a good thing.
Of course, there are many very smart people doing bug triage very well, and I don't want to impugn their fine work. Like its medical namesake, bug triage is a skilled discipline. While it's often repetitive, and there are lots of people showing up with similar symptoms, a triage nurse can really make a difference by spotting urgent cases, cleaning up some of the initial blood, and referring the patient quickly to a doctor for attention. Or, if a pattern of cases suddenly appears, a triage nurse might be able to warn of an incipient epidemic. [Note: I have no medical experience, so please excuse me if I'm talking crap here. :-)] The bug triagers who do this well are an absolute godsend; especially when they respond to repetitive tasks with tremendously useful pieces of automation like bughelper. The cases I have trouble with are more like somebody showing up untrained, going through everyone in the waiting room, and telling each of them that they just need to go home, get some rest, and stop complaining so much. Sometimes of course they'll be right, but without taking the time to understand the problem they're probably going to do more harm than good.
Ian Jackson reminded me that it's worth mentioning the purpose of bug reports on free software: namely, to improve the software. The GNU Project has some advice to maintainers on this. I think sometimes we stray into regarding bug reports more like support tickets. In that case it would be appropriate to focus on resolving each case as quickly as possible, if necessary by means of a workaround rather than by a software change, and only bother the developers when necessary. This is the wrong way to look at bug reports, though. The reason that we needed to set up a bug triage community in Ubuntu was that we had a relatively low developer-to-package ratio and a very high user-to-developer ratio, and we were getting a lot of bug reports that weren't fleshed out enough for a developer to investigate them without spending a lot of time in back-and-forth with the reporter, so a number of people volunteered to take care of the initial back-and-forth so that good clear bug reports could be handed over to developers. This is all well and good, and indeed I encouraged it because I was personally finding myself unable to keep up with incoming bugs and actually fix anything at the same time. Somewhere along the way, though, some people got the impression that what we wanted was a first-line support firewall to try to defend developers from users, which of course naturally leads to ideas such as closing wishlist bugs containing ideas because obviously those important developers wouldn't want to be bothered by them, and closing old bugs because clearly they must just be getting in developers' way. Let me be clear about this now: I absolutely appreciate help getting bug reports into a state where I can deal with them efficiently, but I do not want to be defended from my users! I don't have a basis from which to state that all developers feel the same way, but my guess is that most do.
Antti-Juhani Kaijanaho said he'd experienced most of these problems in Debian. I hadn't actually intended my post to go to Planet Debian - I'd forgotten that the "ubuntu" category on my blog goes there too, which generally I see as a feature, but if I'd remembered that I would have been a little clearer that I was talking about Ubuntu bug triage. If I had been talking about Debian bug triage I'd probably have emphasised different things. Nevertheless, it's interesting that at least one Debian (and non-Ubuntu) developer had experienced similar problems.
Justin Dugger mentions a practice of marking duplicate bugs invalid that he has problems with. I agree that this is suboptimal and try not to do it myself. That said, this is not something I object to to the same extent. Given that the purpose of bugs is to improve the software, the real goal is to be able to spend more time fixing bugs, not to get bugs into the ideal state when the underlying problem has already been solved. If it's a choice between somebody having to spend time tracking down the exact duplicate bug number versus fixing another bug, I know which I'd take. Obviously, when doing this, it's worth apologising that you weren't able to find the original bug number, and explaining what the user can do if they believe that you're mistaken (particularly if it's a bug that's believed to be fixed); the stock text people often use for this doesn't seem informative enough to me.
Sebastien Bacher commented that preferred bug triage practices differ among teams: for instance, the Ubuntu desktop team deals with packages that are very much to the forefront of users' attention and so get a lot of duplicate bugs. Indeed - and bug triagers who are working closely with the desktop team on this are almost certainly doing things the way the developers on the desktop team prefer, so I have no problem with that. The best advice I can give bug triagers is that their ultimate aim is to help developers, and so they should figure out which developers they need to work with and go and talk to them! That way, rather than duplicating work or being counterproductive, they can tailor their work to be most effective. Everybody wins.
Dear recording industry: I hate almost all of you. One of my
all-time favourite albums, Poland:
The Warsaw Concert by Tangerine
Dream, has been castrated, probably to save cost by squeezing a
double LP onto a single CD. Today, Wikipedia
turned my world upside down. Screw you, money-greedy recording
industry. Please fuck off and leave music to those who care. This
includes smaller labels who know what they are doing.
I now must have the full-length track. Unfortunately, it s
seemingly impossible to come by. I searched the Web, even dreaded
sites like Ebay, but after an hour I gave up without success.
There s a seller on Amazon, but s/he consistently gets negative
feedback, so that s a bit risky for the price asked.
Thus, dear world, please save me: does anyone have the
full-length third track of that album, titled Barbakane , in a
high-quality digital recording and would let me have it? I will
pose with the album and today s newspaper to prove legal ownership.
Heck, go ahead and make a ridiculous request, such as standing on
my head. I m desperate.
NP:
Tangerine Dream: Phaedra
This blog post is long overdue, but like Lenny, it was finally released. Yes, I defended my PhD thesis on December 4th. So I m officially a Doctor from the Universit Joseph Fourier Grenoble.
The general context of my thesis is distributed systems, like peer-to-peer systems and applications running on HPC (High Performance Computing) cluster and grids. More specifically, I worked on methods and tools to study such systems, trying to answer the following questions: take a given application that will run on a distributed system. What can we learn or verify about its performance or its characteristics? Will it scale well, even with 1000 or 10000 nodes? Does this app perform better than this another app? Under which conditions? (that s probably the hardest question, because you need to be able to run both apps under the same conditions if you want a fair comparison!)
My work involved studying basic building blocks that can be used to study distributed systems, like network emulators (Dummynet, Linux s traffic control subsystem, NISTNet). I also designed P2PLab, which allows to emulate network-centric peer-to-peer systems using a cluster, targetting experiments with thousands of emulated instances of the application. For example, it allowed to run experiments with ~15000 emulated BitTorrent nodes using 160 real machines.
So what s next? Well, my first-priority plan is to make use of my PhD to apply to an academic position (maitre de conf rences, i.e assistant professor). If you know an open position where I would be a good fit, don t hesitate to tell me! Of course, this plan might very well fail (I will know around end of June). In that case, I ll probably be looking for a job, likely Free-Software-related. Again, if you hear of something for me, ping me!
Just as a reminder for myself, as I'll probably need this more often in the future (and maybe it's helpful for others):
Per default, if you use a big xterm (232x74 in my case) where you start minicom, the $COLUMNS and $LINES environment variables will be 80x24 nevertheless, and those applications which honor them (vim, for example) will be too small and not use the full xterm size of 232x74.
$ minicom $ echo $COLUMNS; echo $LINES 80 24
You can fix that like this:
$ eval resize $ echo $COLUMNS; echo $LINES 232 74After you do eval resize the variables are updated and vim will use the full xterm size. That's all.
Given the large number of comments I got (26!), I feel obliged to post a summary of what was said.
First, the problem:mkswap it, I don t care about the data that is actually in that file after creating it. The stupid way (but only solution on ext3) to create it is to fill it with zeroes, with is very inefficient.
Theodore Tso provided more information in a comment, which I m copying here:
Yes, it will work on ext4. A convenient which makes this easy to use can be found here at http://sandeen.fedorapeople.org/utilities/fallocate.c. It was written by Eric Sandeen, a former XFS developer who now works for Red Hat, who has been a big help making sure ext4 will be ready for Fedora and Red Hat Enterprise Linux. (Well, I guess I shouldn t call him a former XFS developer since he still contributes patches to XFS now and then, but he s spending rather more time on ext4 these days.) One warning about the program; it calls the fallocate system call directly, and it doesn t quite have the right magic architecture-specific magic for certain architectures which have various restrictions on how arguments need to be passed to system calls. In particular, IIRC, I believe there will be issues on the s390 and powerpc architectures. The real right answer is to get fallocate into glibc; folks with pull into making glibc do the right thing, please talk to me. Glibc does have posix_fallocate(), which implements the POSIX interface. posix_fallocate() is wired to use the fallocate system call, for sufficiently modern versions of glibc. However, posix_fallocate() is probablematic for some applications; the problem is that for filesystems that don t support fallocate(), posix_fallocate() will simulate it by writing all zeros to the file. However, this is not necessarily the right thing to do; there are some applications that want fallocate() for speed reasons, but if the filesystem doesn t support it, they want to receive the ENOSPC error message, so they can try some other fallback which might or might not involve writing all zero s to the file. The other shortcoming with posix_fallocate() is that it doesn t support the FALLOC_FL_KEEP_SIZE flag. What this flag allows you to do is to allocate disk blocks to the file, but not to modify the i_size parameter. This allows you to allocate space for files such as log files and mail spool files so they will be contiguous on disk, but since i_size is not modified, programs that append to file won t get confused, and tail -f will continue to work. For example, if you know that your log files are normally approximately 10 megs a day, you can fallocate 10 megabytes, and then the log file will be contiguous on disk, and the space is guaranteed to be there (since it is already allocated). When you compress the log file at the end of the day, if the log file ended up being slightly smaller than 10 megs, the extra blocks will be discarded when you compress the file, or if you like, you can explicitly trim away the excess using ftruncate().fallocate works fine: creating a 20 GB file is almost immediate. Also, syncing or umounting the filesystem is also immediate, and reading the file returns only zeros. I m not sure how it is implemented, but it looks nice :-). However, it still doesn t solve my initial problem: mkswap works, but not swapon:
:/tmp# touch tmp :/tmp# /root/fallocate -l 10g tmp :/tmp# ls -lh tmp -rw-r--r-- 1 root root 10G Mar 3 11:01 tmp :/tmp# du tmp 10485764 tmp :/tmp# mkswap tmp Setting up swapspace version 1, size = 10737414 kB no label, UUID=a316ce8e-cf33-412b-8dc0-e10d9f2ebdbb :/tmp# strace swapon tmp [...] swapon( /tmp/tmp ) = -1 EINVAL (Invalid argument) write(2, swapon: tmp: Invalid argument\n , 30swapon: tmp: Invalid argument ) = 30 exit_group(-1)(swapon works fine if the file is created normally without using fallocate()). Any other ideas?
So you do computer stuff for work, and what do you do in the weekend?
Right, more computer stuff.
Not that I dislike it, obviously. But, well.
The computer stuff that I did this weekend was situated mainly around
dvswitch. During their
talk at the Debian devroom at FOSDEM, Ben and Holger mentioned that one of the
things they'd still like to see implemented in DVswitch is the ability
to do tally
lights. Such lights are useful, not only for the benefit of those in
front of the camera, but also for the benefit of those behind
the camera allowing them to know when they're free to roam about
in order to find something interesting to show, or when they should keep
the camera somewhat stead because they're live.
Since I was planning on using dvswitch to record the concert
(dutch only) of the choir group that I'm part of, and since a
concert has different requirements than does a talk, I set about
implementing tally light functionality. For now, the actual tally light
is just a laptop screen which turns red when you're live, or green
when you're not but there's nothing stopping anyone from changing
that into, say, a USB-controlled light or some such.
In any case, it works now. It's not entirely pretty (involving two
processes working with the same socket) and not entirely finished yet,
either (it only works for primary sources, not secondary sources), but
it gets the job done.
It did require me to refresh knowledge that I hadn't used in
literally 10 years, however. I had some C++ at school, but haven't used
it since my final exam on that course, and while the code is still
readable, it did require me to refresh my memory at some levels. Oh
my...
Anyway, that was yesterday, for the most part. Today, a friend came
over with a DV camera (since I don't have any), and we ran some tests.
Most of it worked immediately, but there were a few bugs, which I ironed
out today. Right now, it works correctly the parts that are
implemented, at least.
This video stuff is rather fun to play with.
In case you ve been living under a rock these past years, I shouldn t have to tell you what this is about :). Well, just in case.
The Google Summer of Code (GSoC) is an international program that offers student developers stipends to write code for various open source software projects. Debian has participated since 2006, mentoring dozens of students on Debian projects.
The important part of the 2009 edition of the Google Summer of Code is going to start next week with the Organizations application period (March 9th). By that time, we should have listed a reasonable number of ideas on the dedicated wiki page.
We will try this year to improve on the performance of the previous years, starting first with more and more dedicated manpower. If you have some time to spare to help manage our Summer of Code bid this year, we can make it a much better experience for the students and for Debian.
Help is immediately needed in many areas. Some examples:
I hate to say this, but often when somebody does lots of bug triage on a package I work on, I find it to be a net loss for me. I end up having to go through all the things that were changed, correct a bunch of them, occasionally pacify angry bug submitters, and all the rest of it, and often the benefits are minimal at best.
I would very much like this not to be the case. Bug triage is supposed to help developers be more efficient, and I think most people who do bug triage are generally well-intentioned and eager to help. Accordingly, here is a series of mini-rants intended to have educational value.
lp_karma_suffix, which can help you to identify developers without having to spend lots of time clicking around.
Lars wonders
about debhelper's approach of inserting script fragments into package
maintainer scripts.
It's really very interesting to survey debhelper's collection
of fragments, in its autoscripts directory. Of the 55 fragments,
the mean length is 4.5 lines, and the mode (and also shortest[1])
length is 3 lines.
The 32 scripts that are each three lines follow a very simple pattern:
if [ "$1" = something ] && exists some-script; then
some-script some-parameters
fi
some-script some-parameters $@
dh_usrlocal code
is the best example of that.)
The most promising way to improve things seems to be using dpkg triggers,
which is why I was very enthuisiastic when we finally got them, over a year
ago. Triggers let many of these hooks into maintainer scripts go away
completely. Rather than each package having to test for and call
update-menus, menu can simply trigger on the modification of any menu file.
Once menu finishes the conversion to using triggers, debhelper can drop
those fragments entirely.
Triggers seem likely to be able to eliminate well over 90% of the things
we need to put into maintainer scripts, and I hope at least half of
debhelper's script fragments can eventually go away thanks to them. The
others seem more difficult.
You probably cannot, for example, make a trigger that does something sane
when an init script is installed. Debhelper has at least three different
fragements that it can put into postinst scripts to handle init scripts,
and these only cover the most common three cases (start, don't start,
don't restart on upgrade).
Moving even these things into a declarative form has long been a dream
of mine. Maybe it could be done with a control file that specifies which
of the methods for running the package's init script to use for this
package.
But it seems we can't do away with maintainer scripts entirely, no matter
how hard we try. That's because maintainer scripts are our only way to deal
with other crippling bugs in old versions of a package, and with upgrade
issues, and with all the other myriad things that we put custom code in
them to deal with. Pity.
| Operation | with journal | w/o journal | percent change |
| git clone | 367.7 | 353.0 | 4.00% |
| make | 231.1 | 203.4 | 12.0% |
| make clean | 14.6 | 7.7 | 47.3% |
| Operation | with journal | w/o journal | percent change |
| git clone | 367.0 | 353.0 | 3.81% |
| make | 207.6 | 199.4 | 3.95% |
| make clean | 6.45 | 3.73 | 42.17% |
| Operation | with journal | w/o journal | percent change |
| git clone | 366.6 | 353.0 | 3.71% |
| make | 216.8 | 203.7 | 6.04% |
| make clean | 13.34 | 6.97 | 45.75% |
| Operation | ext3 | ext2 | percent change |
| git clone | 374.6 | 357.2 | 4.64% |
| make | 230.9 | 204.4 | 11.48% |
| make clean | 14.56 | 6.54 | 55.08% |
A new maintenance version of Rcpp (now at 0.6.4)
was just pushed to CRAN and has been
uploaded to Debian. Rcpp is a set of
utility classes that provide interfaces for transferring the major R data
types to C++ and back which makes it easier to extend R with dynamically
loadable code written in C or C++.
This version changes how use the std namespace: all usage is now
properly prefixed. Likewise, we now define R_NO_REMAP to not
let R define utility functions as length() or
error() which occassionally creates trouble with other include
files -- so now use the more explicit forms Rf_length(),
Rf_error() etc. Also, starting from this release, C++ class
documentation created by Doxygen is included; it can also be seen from my box
as both browsable
html and a pdf file.
Lastly, this version also adds a minor correction to the Windows build
(spotted by Uwe and Simon).
Next.