2008-12-15
Posted in PlanetDebian at 13:00 UTC (+0000) by sven
Well, following some other posts on Planet debian, I decided to also publish my vote on the GR regarding Firmware blobs in Debian. Here is my vote:
V: 7112113
In other words, I rank the first option as low as possible (7, below further discussion), ranked all options I think make sense above further discussion (which is at rank 3) and put all other options (except for the one empowering the release team to decide the issue) at the same, highest rank. The option empowering is ranked at the second level.
My priority really is to get Lenny released. While I think we should do as much as we can removing non-free stuff from Debian, I really don’t think it is sensible to delay Lenny because of this. Lenny has far less non-free bits in it than Etch, and I’m also not really sure wether I really want to consider firmware (which doesn’t run on the CPU Debian is for) as software in the sense of the DFSG. The reasoning here is that I don’t see any difference between a hardware manufacturer A who embeds a (non-free) firmware in the hardware (for example in the sense of storing it in a flashable memory) and a hardware manufacturer B who allows us to distribute the firmware blob (and avoids storing it in the hardware). In my opinion, both are equally (non-)free. And following this, I don’t see why we should support hardware created by A natively while not directly supporting hardware made by B.
One could of course argue that we are providing more of a service for B (as we are distributing the firmware for them, while they save some money otherwise spent for the flash memory), but I would like to remind everyone that our foundation documents also include the following:
“Our priorities are our users and free software”
This puts free software and our users at the same level. So to cater for one, we might have to make sacrifices on the other priority. In my opinion, the best compromise here is to not consider firmware blobs as software in the sense of the DFSG, but alternatively, I would accept saying we want to remove all such firmware from Debian, but not to delay Lenny because of this process. Additionally, we should make it easy for users to add all effected drivers/firmwares before/during installation of a system (or even include them on our installation media as some proposed, with a short question to the user wether he wants those firmware blobs to be installed).
Apart from my opinion on the subject itself, I must also mention my concerns about how this vote was written in a very manipulative way. Additionally, those wanting to get Lenny released were proposing too many different options. This is generally a bad idea.
See also The DM GR
See also Debian and Dunc-Tank
Permalink
2008-11-29
Posted in Computers, PlanetDebian at 12:10 UTC (+0000) by sven
In Silly translations, Gintautas Miliauskas wrote about some rather silly translations. This reminded me of a finding by a colleague a few days ago.
He had recently updated his Ubuntu installation to KDE4 (using a german locale). After this, he reassigned a hotkey (to CTRL-SPACE). However, KDE showed: STRG-Weltraum (ctrl-”outer space”) instead of STRG-Leertaste (ctrl-space key) 
UPDATE: Since Frederik (see comments) reminded me of the fact I already knew:
This silly translation is not the fault of the german KDE members, but a bug in the Ubuntu package, which is taking more or less random translations from Rosetta.
See also No related posts
Permalink
2008-10-08
Posted in Personal, PlanetDebian at 12:16 UTC (+0000) by sven
Anand Kumria wrote:
If IBM were to go bankrupt, would the government step in? Unlikely. Investors would lose (money), staff — another word for investors — would lose (jobs), but customers would win (their computers would keep working). Some customers would win more than others (especially those who had the equipment on lease); if no one is collecting, why pay?
I’m wondering here where Anand got the idea that once a company went bankrupt, that you don’t need to pay to that company anymore. When a company goes bankrupt, at least in Germany the following happens: A trustee/liquidator is selected. This liquidator is then collecting the information who owes money to the company and who still needs to get (how much) money from it. The liquidator also has to check the option of selling company assets (which might include the contracts of customers that still have to pay) to fulfill the debts of the bankrupt company. After he turned all assets into money, the money is distributed among those who still have to get money from the bankrupt company.
Anyway, regarding his main argument that the (average) customer of a company (bank in this case) should never have to pay for the failed speculations of that company, I somehow have to agree with him. Someone putting money into a regular bank account or papers with fixed interest rate should never lose his money. But there are also customers buying bank shares with a chance of higher revenue than with fixed interest rate papers. These should suffer from failure of the bank management, as they more or less explicitly wanted to be tied to the success (or failure) of the bank.
However, this is mostly irrelevant, since the failure of so many “investment banks” has side affects that might cost the average inhabitant of the affected countries even more than the discussed rescue plans. One of these effects is that the banks are now much more conservative regarding lease and mortgage plans, effectively leaving many home owners with no option to fulfill previous obligations (remaining debt after a previous mortgage expired can’t be refinanced by a new mortgage), causing them to have to sell their homes to pay the first mortgage. This is in some way stupid because this causes people who were perfectly paying their mortgage rates to loose their house, while the bank which would be giving them a new mortgage could get a new and good customer, improving their income. On the other hand, if the other side effects of the current crisis cause those “good” mortgage customers to loose their jobs, they might turn into bad customers who are unable to pay their rates. All in all, this is a spiral that could cause the whole economy to break down (a small example: The bank is not giving out mortgages, so no one will build new houses so the builders loose their jobs so they don’t pay their mortgage rates anymore,…. – over simplified, but still shows what I mean). Unless the spiral is terminated in time, before too drastic things happen.
All in all, I do understand why the politicians try to rescue those banks (or at least the customers of those banks), though I think that in an economy with slightly higher regulation, there wouldn’t be the need for such a rescue plan. I know there are some german banks affected by the crisis as well (among them Hypo Real Estate and others), but the average private customer of such banks shouldn’t loose money due to the regulations we have in place.
In general, there should be some security fund which makes sure that private customers never loose money put into regular bank accounts or fixed interest papers, vice-versa, banks should calculate mortgages so that they can be pretty sure their customers are actually able to pay off their rates – it doesn’t make sense if someone starts off having to pay 500$/month for their mortgage and has to pay over 1000$ a few years (as in 2-3 years) later, because the bank raised the interest that much. I have no problem with people loosing money from shares of banks or other companies directly or indirectly through investment funds.
See also Migrating aptitudes knowledge about auto-installed packages
Permalink
2008-01-04
Posted in Computers, PlanetDebian at 21:47 UTC (+0000) by sven
Anthony Towns wrote about user configuration (i.e. ~/.foo) and the XDG spec/proposal versus his own (and according to him) simpler version. The main goal of all this is to get rid of all the ~/.foo directories and files in a users home directory. Apart from technically minor differences, I don’t see why AJs proposal would be simpler than the XDG approach. All it does is hardcoding the values which are adjustable in XDG via XDG_*_DIRS.
There is one notable difference though: AJ proposes fallback values which are compatible with existing application paths (i.e. HOME_ETC/XDG_CONFIG_HOME should default to ~/ – resulting in ~/.foo files/dirs). This is a good proposal in a way: If you patch an existing application to strictly follow the proposal made by AJ, it still finds its old configuration (and other files) if the new environment variables are not set. No need to move anything around. However, I think the XDG approach is better since it makes sure that compliant applications don’t clutter ~/ anymore. They do need some mechanism to move existing configurations and data around though if the XDG-compliant stuff isn’t already there, but an old style config exists.
All in all, I think it is worth following the XDG spec, even if it is slightly more complex than AJs proposal. For one, it already exists for a while and I think that some applications already started following that spec. It also makes slightly more sense to me to have the system fully configurable as to where the apps store data as opposed to the hardcoded fallback/default values AJ proposes (even if we would change AJs proposal to use “$HOME-cleaning” default values).
See also Strange MySQL (5.0) issue with authentication
See also Brane Dump — The Thoughts of Matt Palmer
See also About Usability
Permalink
2007-10-22
Posted in Personal, PlanetDebian at 13:56 UTC (+0000) by sven
I really dislike posts like (sorry AJ, you are just one example) AJ Towns blog post
“Some fun”. What I dislike? Well, the post lacks critical information: Which slashdot post inspired him? What data is he talking about? How did he turn the data into those graphics?
Sorry AJ, your post is just the latest example of this style of post, and I really got frustrated over such posts, this is not meant as a personal attack.
Edit:
So to make my wish clear: Please, fellow bloggers, don’t assume that your readers are following your favourite web resources as closely as you do (and with the same specific interests). Explicitly say what you are writing about, reference resources needed to understand what you are doing, at least give readers a chance to find out what you did.
In AJs case, it would probably have been enough to reference the /. article or comment which inspired him.
See also Rescueing files from lost+found
See also Link collection 2009/03
See also Re: Wacky ideas #9: rerun maintainer scripts for changes in related packages
Permalink
2007-10-17
Posted in Computers, Personal, PlanetDebian at 15:03 UTC (+0000) by sven
Since I never really found a nice overview of which CPU flags (see /proc/cpuinfo) mean what, so I gathered some information using the web, with the most notable sources being the BOINC FAQ entry on CPU Register Acronyms at [1] and the output of the nice little (though seemingly mostly unmaintained) cpuid utility. See my results at [2]. Any suggestions for enhancements and completions are highly welcome, just leave a comment to this post.
[1]: href=”http://boincfaq.mundayweb.com/index.php?language=1&view=176
[2]: http://blog.incase.de/index.php/cpu-feature-flags-and-their-meanings/
See also CPU feature flags and their meanings
See also Why is VoIP/SIP so hard?
See also another vote
Permalink
2007-09-18
Posted in Computers, PlanetDebian at 14:20 UTC (+0000) by sven
In “Documentation – the chicken and the egg” [1], Matt Palmer wrote about the problem that noone writes documentation because noone reads it and that noone reads documentation because the few documentation in existence usually isn’t very good. So he, like me hs the habit of searching for help on the net instead of in a projects documentation.
However I disagree with him in the consequences a bit. Because I noticed that on several projects with good documentation (subversion is an example that immediately comes to my mind, but postfix isn’t too bad either), the internet search returns a reference to the docs more often than not. Of course, this means that the documentation needs to be searchable for those webcrawlers. So if you have the task to write documentation, I strongly suggest to make it searchable in some way. For company-internal projects, this obviously means that the documentation must be reachable via an internal search engine. In a project a few years back, we implemented an internal search engine which included company internal information (even with user based access rules so that each user only got those results he could actually access) as well as an external search engines results. It was closed source, but a pretty nice idea. It didn’t, however, index any locally (user’s desktop) stored documents, only what was on some company web page (but including .doc, .rtf, .pdf and the like which where retrievable via http).
[1] http://www.hezmatt.org/~mpalmer/blog/general/documentation_the_chicken_and_the_egg.html
See also IP addresses
See also Init HackFest / New init systems in Debian
See also Strange MySQL (5.0) issue with authentication
Permalink
2007-09-01
Posted in Personal, PlanetDebian, Random links at 14:18 UTC (+0000) by sven
In the recent online article heise online – IFA special – Force-Feedback-Weste mit Kitzelattacke, Heise News (a german IT news site) had a really nice caption under one image showing a new force-feedback vest by Philips. The image looks like this:
The german caption is: “Philips’ Force-Feedback-Weste ermöglicht tödliche Kitzelattacken in PC-Shootern.”
Translation to english is: “Philips Force-Feeback-Vest allows deathly tickling-attacks in PC-Shooters.” (Means First-Person-Shooters).
Nice. That’s at least a pleasant way of dying: Being tickled to death.
Of course, the article itself clears up the misunderstanding: The vest is more tickling than “punching” the player, even if his game-ego is killing most ferociously.
See also Init HackFest / New init systems in Debian
See also The DM GR
Permalink
2007-08-13
Posted in Computers, PlanetDebian at 14:09 UTC (+0000) by blog
Jonathan McDowell wonders how to take aptitude’s knowledge about auto-installed packages from one computer to the other. Well, I looked into the issue for a few minutes and I found a solution though it doesn’t look nice.
for i in
# grep installed package names
`COLUMNS=200 dpkg -l | grep -E '^ii'| awk '{print $2};' `
do
# find package in /var/lib/aptitude/pkgstates
# check for the right state (1 seems to mean
# auto-installed, 3 manually installed)
if
grep-available -s Package,State \
-F Package \
-X $i /var/lib/aptitude/pkgstates \
| grep -q 'State: 1'
then
echo $i
fi
done
Results in a list of auto-installed packages AFAICT. If you change the “State: 1″ into “State: 3″, it seems you get only manually installed packages. So if you take the latter and feed it to “aptitude install”, your database should be right. If you take the former, you feed the list to “aptitude markauto”. A cleaner solution (which works even if /var/lib/aptitude/pkgstates changes formats) would involve checking “aptitude show” output, evaluating the “Automatically installed:” field. However, simply feeding “aptitude show” output to grep-dctrl (or any equivalent) resultes in the rather irritating error message “grep-dctrl: -:14: expected a colon.”, with the 14 changing to a different line in the packages description (usually a line directly following an empty line). So I’m just giving you an idea here.
See also No related posts
Permalink
2007-07-26
Posted in Computers, PlanetDebian at 18:56 UTC (+0000) by sven
Joey, I see a huge difference between voting on the current DM proposal and your virtual (sorry, I can’t remember a better word for it) voting on sponsoring uploads. Debian Developers were always allowed to upload any package they saw as fitting into Debian (though there were no guarantees for these packages to actually being included). Also, NMUs are OK if the maintainer agreed. So all they (seemingly) did was putting a different maintainer address into the control file. However, at least in theory, the sponsors were still responsible for their upload if it turned out fishy.
The DM proposal (don’t get me wrong there, I generally support the idea, I just don’t like the way it is implemented in the proposal) is shifting this responsibility from the sponsor onto the shoulders of the DM, which is a good thing. However I think it doubles some of the work the NM queue already needs done, so my proposal would be not to have it as a completely seperate path for a contributor, but instead see it integrated into the NM process. Wether it would mean adding a new maintainer to the DM keyring after he had an advocate (which is pretty near to the current proposal) or after an AM was assigned and checked some basic things (which I would prefer) doesn’t make a lot of difference to me.
See also The DM GR
Permalink
« Previous Page — « Previous entries « Previous Page · Next Page » Next entries » — Next Page »
