Every now and again the topic of SELinux arises locally.
I still believe it is:
(including English!)
The string freeze of Debian Installer officially ended at 23:59
yesterday (Sept. 20th). Indeed, this was extended a bit to today, with
agreement by Otavio Salvador who I thank for this.
That allowed Zak to "save" Tagalog and also the Welsh and Latvian
translators to polish their work.
We now have to decide about some of these languages: those that failed
to meet the release criteria but were formerly activated in D-I. There
are four such languages: Amharic, Welsh, Estonian and Northern Sami.
Please find below the mail I just sent to debian-i18n and
debian-boot. I promised that this discussion would happen in
public. It will (but it will be short as we can't delay the release of
the installer for ages....and I think that my proposals are
reasonable!)
First of all, the numbers as of Sunday Sept. 21st 09:32 UTC (date of
the last commit with an l10n update):
Languages meeting the release criteria: 59
------------------------------------------
Already activated and complete for level 1: 51
Arabic, Belarusian, Bulgarian, Bosnian, Catalan, Czech, Danish,
German, Dzongkha, Greek, Esperanto, Spanish, Basque, Finnish, French,
Galician, Gujarati, Hebrew, Hindi, Croatian, Hungarian, Indonesian,
Italian, Japanese, Georgian, Khmer, Korean, Lithuanian, Latvian,
Macedonian, Malayalam, Marathi, Norwegian Bokm l, Nepali, Dutch,
Norwegian Nynorsk, Punjabi, Polish, Portuguese, Brazilian Portuguese,
Romanian, Russian, Slovak, Albabian, Swedish, Tamil, Thai, Turkish,
Vietnamese, Simplified Chinese, Traditional Chinese
Already activated and complete for sublevels 1 and 2: 6
Bengali, Kurdish, Slovenian, Tagalog, Ukrainian, Wolof
Not yet activated languages complete for sublevels 1 and 2: 2
(the mail in -i18n and -boot says 3 but this is an error by me)
Irish, Serbian
Languages failing to meet the release criteria: 15
--------------------------------------------------
Activated languages: 4
Amharic, Welsh, Estonian, Northern Sami
Not yet activated languages: 11
Afrikaans, Persian, Armenian, Icelandic, Kazakh, Kannada,
Malagasy, Malay, Telugu, Urdu, Xhosa
Discussion
----------
(careful people will notice that I moved Welsh down to "failed to meet
the release criteria" as this is what is technically correct)
Nothing to discuss for the 57 already activated languages that meet
the defined criteria. They'll be kept or first activated in the RC1
release of Debian Installer.
Similarly, nothing to discuss for the 11 languages that were not
activated and haven't made it. They will remain unactivated.
Two languages should be activated as they have met the release
criteria for the first time during the string freeze: Irish and Serbian.
This adds more load (and size changes) to D-I but I really don't see
any reason to not follow our own rules there.
The discussion comes for the 4 languages that fail to meet the release
criteria. Here are my proposals with some rationale:
Amharic:
I would really dislike deactivating Amharic because it's highly
symbolic to have the language of Ethiopia activated. We have so few
African languages. Also, the translation is nearly complete and the
translator was well coping with updates until July. The missing
stuff for Amharic in sublevels 1 and 2 are messages about loading
drivers or firmware from removable media, the rescue mode stuff for
the graphical installer and some messages that briefly appear during
finish-install. A little bit more important is the message warning
that the boot partition is not ext2 or ext3, added in August by
tbm. I think this is not enough to drop out one year of efforts for
the translator
As a consequence, I propose to KEEP Amharic.
Welsh:
Only five strings are missing in sublevels 1 and 2 because of the
small experience of PO files by the person who completed the
translation during last week. One will make the regular user login
name screen to be in English and others will make the GRUB password
screen to be in English as well, that's all.
Additionnally, we can safely assume that all potential users of
Welsh have good skills in English...and will therefore very easily
cope with these screens.
As a consequence, I propose to KEEP Welsh.
Estonian:
The translation had NO update since Etch. The last update is dated
back to Feb. 17th 2007. I haven't got any sign of life from the
translator and no Estonian users have volunteered to maintain the
translation.
Missing strings are in many places, including several screens that
appear in default installs. Even though one can assume that the
skills of the average Linux user in Estonia is fairly good, I think
this is not enough to throw users in a big mix of English and
Estonian.
As a consequence, I propose to DROP Estonian.
Northern Sami:
The translation is very incomplete. With about any other language,
that would be a reason to drop the translation.
However, a few reasons make me suggest keeping it:
- Northern Sami is mostly used in Norway and D-I will fall back
to Norwegian Bokm l which is understood by all potentials users
as it is teached in all Norwegian schools.
- Users will be warned, *in Sami*, about this situation
- The choice of Sami will be kept in localechooser even if the
translations are dropped. This is on request of Debian Edu
developers to avoid them to develop a special boot floppy
to offer the choice of Sami (a requirement for Norwegian
schools). I personnally think this is a reward to Debian Edu and
its ancestor Skolelinux for their initial involvement in the
development of D-I
As a consequence, I propose to KEEP Northern Sami.
I understand that these choices may be debatable and some may sound
slightly subjective. I however think this is the best way to be fair
with translators' efforts without compromising the quality of D-I.
Please note that the final word on this will be by D-I release
managers...but advices are very much welcomed.
I thought this meme was a cute idea. Here goes:
It's late notice but Boston area folks should drop by the local Software
Freedom Day events today. It goes from 10:00-16:00 and is located in a
great space in Chinatown. More information in on the wiki.
I'm teaming up with John Sullivan of the FSF to talk about free software
on in your pocket on unexecpted platforms. We'll show off CHDK (for
cameras), the FreeRunner (a phone), and probably also talk about
RockBox, iPodLinux, and more. It should be laid back and fun!
The whole point of SFD (and this SFD event in particular) is create a
space that's appropriate to folks that don't already know about free and
open source software and that aren't necessary technical. If you are a
hacker or an advocate, show up and meet some like minded folks and
introduce new people to the ideas that inspire you. If you are just
curious about this stuff this event is designed for you.
If you're not in Boston, check the SFD webpage. There are hundreds
of events around the world and may even be one near you!
"A license can ruin a perfectly good piece of software"Whenever possible, try to avoid:- Jon Stevens
Email-Reminder - Receive emails for events like birthdays and anniversariesThis helps distributors and contributors by explicitly stating the license version as well as the name and contact details of the copyright holder.
Copyright (C) 2004-2008 by Francois Marier (fmarier@gmail.com)
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see http://www.gnu.org/licenses/.
ghostscript, the bounding box detection is dreadfully slow, anything from one to ten seconds for a single page ! When you have a 60 pages article to print, it can be quite tedious...
Well, I've just discovered that the --trim option of pdfnup can do very similar things too. It removes a given amount of margins on the side, with the syntax 'left bottom right top'. Most of the time, a well-thought pdfnup --trim ... will work as well as pdfcrop while in the meantime being much faster...
Myself and a colleague were both getting Joe-jobbed yesterday. I had an easy time telling Exim to reject mine at SMTP time, but the colleague receives mail on our only Plesk server, so it’s using qmail. I’ve noticed before that qmail admin tools are primitive and incomplete, so I looked for the appropriate rocks to bang together to put this fire out. (I think I just sprained a metaphor.)
My best attempt so far is to edit the user’s .qmail file to start with a pipe to a command that exit 100s if it detects an error for an email which the user obviously didn’t send (wrong email client or whatever). qmail understands code 100 as a hard error, so I think that should generate an SMTP error, but I didn’t figure out from the logs whether it was SMTP-time or later and my testing was inconclusive. I suspect Plesk will remove my pipe when the user next edits their email account, too. How do qmail/Plesk users not drown in spam?
In related news, I’ve started getting “Challenge Response” emails from users of Merak Mail Server Software for emails I never sent. I’m answering the challenges so that challenge-response users get spam if their server spams me. Challenge-response is evil - I don’t want spam from your mailserver just because you accepted spam that said it was from me. If you are using Merak Mail Server Software, change away now!
One of my current anti-spam tactics is to read my email in batches (which Suw suggests is a good idea) and group messages which look “similar”. Very similar messages appear for very few reasons: people resending messages, mailing list threads, stuff from spam-nets and a few others. Apart from spam-nets, most of the others match one of a few keywords. My current method of doing this is part-automatic and part-human. Are there automated anti-spam tools which exploit this local similarity? I think DCC used to include this idea, but then there were software patents and hoo-ha and I stopped paying so much attention.
Finally, a small discussion has broken out in the comments of Is Yahoo Now Even Worse On Spam? about whitelisting and business-critical uses of free webmails.
Why is it that always the seemingly most simple things turn out to be the most annoying? This time I “just” wanted to get rid of one of my last MySQL databases and move it over to PostgreSQL. The Bacula catalog that saves which file I backed up when and to which storage medium. I tried with MySQL’s “mysqldump” and it’s PostgreSQL compatibility option - but apparently MySQL developers know nothing about PostgreSQL. Then I tried with “sqlfairy” - and found myself booting my system hard after it ate 2 GB of swap and died while converting 500 MB of data.
So finally I asked in #bacula and was told to try CSV (comma-seperated values) as an intermediate format. Yuck… that satan-spawned format that reminds me of my dark past? Okay. First dump the catalog from MySQL:
for table in BaseFiles CDImages Client Counters Device File Filename FileSet Job JobMedia Location LocationLog Log Media MediaType Path Pool Status Storage UnsavedFiles Version ; do mysqldump -u root -pmypassword -T. bacula $table; done
(Okay, okay, this is not comma- but tab-seperated. But that’s even better for running the COPY-FROM command later.)
This creates an ‘.sql’ (the schema) and a ‘.txt’ (the rows/records) file for each table in the current directory. Just don’t try to apply the schema to PostgreSQL. Instead better create a new schema. Bacula ships with a script for that purpose.
Unless you have the PostgreSQL database for Bacula ready you should run something like…
/usr/share/bacula-director/make_postgresql_tables -h localhost -U bacula
…and…
/usr/share/bacula-director/grant_postgresql_privileges -h localhost -U bacula
Now on to read the tab-delimited data into PostgreSQL. The importing via the COPY command must be done with administrator privileges! And it’s important to explicitly state which columns correspond to which table columns (see the respective ‘.sql’ files) or otherwise you’ll get chaos. Of course this only has to be done for .txt files larger than 0 bytes. Oh, and the filename has to be absolute. Example:
s/0000-00-00 00:00:00/1970-01-01 00:00:00/g. Clear the table (DELETE FROM job) and import again.
And finally it’s important to get the sequence numbers right as described in the Bacula manual.
Morale: spend two extra-minutes to start with PostgreSQL right away instead of bothering about conversions later. And never assume converting from one database to another would work - just because both have “SQL” in their names.
Last week I wondered how much space a complete git conversion would actually need—and I was quite surprised:
The first line is the regular CVS checkout. The third line is the SVN checkout that's available from alioth. You can see that the size is not really something one would want, especially since the real gain is extremely little: besides offline diff you rather have disadvantages with not being able to do much offline because anything history wise requires you to be online. In CVS you at least knew that revision 1.12 of a file is three commits above revision 1.9 of the same file; while in SVN you have no chance offline to know how many commits to a file happened between revision 512 and 1024, if any at all. The conversion to git took me quite a long time, practically almost three days of (non-constant) running git-cvsimport on my laptop. The time did not completely surprise me, at least when I noticed in the end that it were well over 83 thousand commits in well over 10 years, reaching back to July 1998. My first own commit was in July 2001, which wasn't too hard to find out with git neither, and required no online operation. git gives you complete offline access to the history. This is actually something that the build process can be based on. There propably will be some speed drawback with not being able to do simple-math for revision difference like in CVS, but that actually will have to be checked. I'm still convinced being able to do all the stuff offline without any strange hacks or needing to be online all the time is something worthwhile. Things left to do and which I propably won't find the time in the too near future because of ... erm, you know? Lenny? That we want to release? But anyway, to not have the list of things get lost, here is a (not complete) list of things in case you are bored and want to play around a bit:$ du -hs webwml* 325M webwml 416M webwml.git 819M webwml.svn
git clone ssh://git.debian.org/git/users/alfie/webwml.git" should get you started. Please notice to play around in a seperate branch and not directly in origin to be able to pull further and update from time to time.
(and disregards the rest)
Jonah Lehrer reports the result of a depressing but unsurprising experiment: The Facts Don’t Matter.
Political scientists Brendan Nyhan and Jason Reifler provided two groups of volunteers with the Bush administration’s prewar claims that Iraq had weapons of mass destruction. One group was given a refutation — the comprehensive 2004 Duelfer report that concluded that Iraq did not have weapons of mass destruction before the United States invaded in 2003. Thirty-four percent of conservatives told only about the Bush administration’s claims thought Iraq had hidden or destroyed its weapons before the U.S. invasion, but 64 percent of conservatives who heard both claim and refutation thought that Iraq really did have the weapons. The refutation, in other words, made the misinformation worse. A similar “backfire effect” also influenced conservatives told about Bush administration assertions that tax cuts increase federal revenue. One group was offered a refutation by prominent economists that included current and former Bush administration officials. About 35 percent of conservatives told about the Bush claim believed it; 67 percent of those provided with both assertion and refutation believed that tax cuts increase revenue. In a paper approaching publication, Nyhan, a PhD student at Duke University, and Reifler, at Georgia State University, suggest that Republicans might be especially prone to the backfire effect because conservatives may have more rigid views than liberals: Upon hearing a refutation, conservatives might “argue back” against the refutation in their minds, thereby strengthening their belief in the misinformation. Nyhan and Reifler did not see the same “backfire effect” when liberals were given misinformation and a refutation about the Bush administration’s stance on stem cell research.It’s particularly interesting that the backfire effect is more pronounced with Republicans; this certainly resonates with my admittedly biased view. Better information doesn’t seem to fix the problem, either:
During the first term of Bill Clinton’s presidency, the budget deficit declined by more than 90 percent. However, when Republican voters were asked in 1996 what happened to the deficit under Clinton, more than 55 percent said that it had increased. What’s interesting about this data is that so-called “high-information” voters - these are the Republicans who read the newspaper, watch cable news and can identify their representatives in Congress - weren’t better informed than “low-information” voters.Anyone have a better solution? Or should we just throw in the towel on democracy?
Next.