Donald Trump you magnificent bastard, you did it. You actually did it. What you did is irrelevant and counterproductive but still gold star and a tick for perseverence.
In possibly related news, SETI is closing down their radio telescope array. I don't think I'd want to show this planet off to the neighbors either.
The Linux kernel attempts to protect portions of its memory from unexpected modification (through potential future exploits) by setting areas read-only where the compiler has allowed it (CONFIG_DEBUG_RODATA). This, combined with marking function pointer tables const , reduces the number of easily writable kernel memory targets for attackers.
However, modules (which are almost the bulk of kernel code) were not handled, and remained read-write, regardless of compiler markings. In 2.6.38, thanks to the efforts of many people (especially Siarhei Liakh and Matthieu Castet), CONFIG_DEBUG_SET_MODULE_RONX was created (and CONFIG_DEBUG_RODATA expanded).
To visualize the effects, I patched Arjan van de Ven s arch/x86/mm/dump_pagetables.c to be a loadable module so I could look at /sys/kernel/debug/kernel_page_tables without needing to rebuild my kernel with CONFIG_X86_PTDUMP.
Comparing Lucid (2.6.32), Maverick (2.6.35), and Natty (2.6.38), it s clear to see the effects of the RO/NX improvements, especially in the Modules section which has no NX markings at all before 2.6.38:
lucid-amd64# awk '/Modules/,/End Modules/' /sys/kernel/debug/kernel_page_tables grep NX wc -l 0 maverick-amd64# awk '/Modules/,/End Modules/' /sys/kernel/debug/kernel_page_tables grep NX wc -l 0 natty-amd64# awk '/Modules/,/End Modules/' /sys/kernel/debug/kernel_page_tables grep NX wc -l 762.6.38 s memory region is much more granular, since each module has been chopped up for the various segment permissions:
lucid-amd64# awk '/Modules/,/End Modules/' /sys/kernel/debug/kernel_page_tables wc -l 53 maverick-amd64# awk '/Modules/,/End Modules/' /sys/kernel/debug/kernel_page_tables wc -l 67 natty-amd64# awk '/Modules/,/End Modules/' /sys/kernel/debug/kernel_page_tables wc -l 155For example, here s the large sunrpc module. RW is read-write, ro is read-only, x is executable, and NX is non-executable:
maverick-amd64# awk '/^'$(awk '/^sunrpc/ print $NF ' /proc/modules)'/','!/GLB/' /sys/kernel/debug/kernel_page_tables 0xffffffffa005d000-0xffffffffa0096000 228K RW GLB x pte 0xffffffffa0096000-0xffffffffa0098000 8K pte natty-amd64# awk '/^'$(awk '/^sunrpc/ print $NF ' /proc/modules)'/','!/GLB/' /sys/kernel/debug/kernel_page_tables 0xffffffffa005d000-0xffffffffa007a000 116K ro GLB x pte 0xffffffffa007a000-0xffffffffa0083000 36K ro GLB NX pte 0xffffffffa0083000-0xffffffffa0097000 80K RW GLB NX pte 0xffffffffa0097000-0xffffffffa0099000 8K pteThe latter looks a whole lot more like a proper ELF (text segment is read-only and executable, rodata segment is read-only and non-executable, and data segment is read-write and non-executable). Just another reason to make sure you re using your CPU s NX bit (via 64bit or 32bit-PAE kernels)! (And no, PAE is not slower in any meaningful way.)
At some stage the seminal KDE vs Gnome paper vanished from its original home, and while it's still available in a few places (such as here) it set me thinking. What are the fundamental differences between Gnome and KDE development? There's lots of little differences (2006: Gnome parties on a beach. Akademy has melted ice cream in the rain) but they're both basically communities made up of people who are interested in developing a functional and interesting desktop experience. So why do the end results have so little in common?
Curious about these shiny new things i keep hearing about, i set up a test desktop system using using systemd as the init system (yes, that means using systemd-sysv in place of sysvinit -- so i had to remove an essential package for this to work). A system-crippling bug was naturally the result of living on the bleeding edge, but fortunately it was resolved with a trivial patch. In all, i'm pretty happy with some of the things that systemd seems to get right. For example, native supervision of daemon processes, clean process states, elimination of initscript copy-paste-isms, and socket-based service initiation are all obvious, marked improvements over the existing sysvinit legacy cruft. But i'm a bit concerned about other parts. For example, all the above-mentioned features fit really well within a tightly-tuned, well-managed server. But systemd also appears to rely heavily on complex userland systems like dbus and policykit that would be much more at home on a typical desktop machine. I've never seen a well-managed server installation that warranted either policykit or dbus. Also, given the bug i ran into -- when PID 1 aborts due to a silly assertion, your system is well-and-truly horked. Shouldn't a lot more attention to detail be happening? I'd think that a "recover gracefully from failed assertions" approach would be the first thing to target for a would-be PID 1. I'm also concerned about the Linux-centricism of systemd. I understand that features like cgroups and reliance on the spiffiness of inotify are part of the appeal, but i also really don't want to see us stuck with only One Single Kernel as an option. The kFreeBSD folks (and the HURD folks) have done a lot of work to get us close to having some level of choice at this critical layer of infrastructure. It'd be good to see that possibility realized, to help us avoid the creeping monoculture. I worry that systemd's over-reliance on Linux-specific features is heading in the wrong direction. So my question is: why is this all being presented as a package deal? I'd be pretty happy if i could get just the "server-side" features without incurring the dbus/policykit/etc bloat. I already run servers with runit as pid 1 -- they're lean and quite nice, but runit doesn't have systemd's socket-based initiation (or the level of heavyweight backing that systemd seems to have picked up, for that matter). I understand that Lennart is resistant to UNIX's traditional "do one thing; do it well" philosophy. I can understand some of his reasoning, but i think he might be doing his work and his tools a disservice by taking it this far. Wouldn't systemd be better if it was clearer how to take advantage of parts of it without having to subscribe to the entire thing? Of course, i might be missing some nice ways that systemd can be effectively tuned and pared down. But i've read his blog posts about systemd and i haven't seen how to get some of the nice features without the parts i don't want. I'd love to be pointed to some explanations that show me how i'm wrong :)Tags: systemd
As you might know, I m of one the people who promote the idea of having a Constantly Usable Testing (CUT). I will post a set of articles on this topic to help me clarify my ideas and to get some early feedback of other Debian contributors. I plan to use the result of this process to kickstart a broader discussion on debian-devel (where I hope to get the release team involved).
Let s start by defining my own objectives with Debian CUT. I won t speak of the part of Debian CUT that plans to make regular snapshots of testing with installable media because that s not where I will invest my time. I do hope other people will do it though. Instead I will concentrate on changes that would improve Debian testing for end-users. I consider that testing (in its current form) is largely usable already but there are two main obstacles to overcome.
Testing without freezes = rolling
The first one is that testing is no longer testing during freezes. The regular flow of new upstream versions that makes testing so interesting for many users is stalled because we re using testing to finalize the next stable version. That s why I d like to introduce a new suite called rolling that would work like the current testing except that it never freezes. Testing would no longer be a permanent suite, it would only exist during the freeze and it would be branched off from rolling.
Rolling should be a supported distribution
The second obstacle is not really technical. We must advertise rolling as a distribution that ordinary people can use but we should make it clear that it s never going to have the same level of polish that a stable release can have. And to back up this assertion, we must empower Debian developers to be able to provide good support of their software in rolling, this probably means using rolling-proposed-updates more often to push fixes and security updates when the natural flow of updates is blocked by transitions or other problems. Some maintainers won t have the time required to provide the same level of support as they currently do for a stable release and that s okay, it s not worse than the current testing. The goal is to treat it on a best-effort basis and to try to gradually improve the situation.
My goal for wheezy
This is the the minimal implementation of CUT that I would like to target in the wheezy timeframe. Having testing as a temporary branch of rolling is not a strict requirement, although I d argue that it s important to not waste resources towards maintaining two separate yet very similar distributions.
Should Debian embrace those goals?
Ignoring all possible problems that will surface while trying to implement those goals, can we agree that Debian should embrace those goals because it means providing a better service to a class of users that is not satisfied by the current stable release?
I will come back to the expected problems in a subsequent post and we will have the opportunity to discuss them. Here I just want to see whether we can have broad buy-in on the principles behind Debian rolling and CUT.
23 comments Liked this article? Click here. My blog is Flattr-enabled.
xorg.conf are now ignored... Wait, wait, don't go flaming the Xorg maintainers, but keep on looking rather. This is where I found out about xinput, the new way to customize/parametrize input devices for the X server. And, lets face it, it beats any customization that could have been done in xorg.conf ! Here's how to use it.
First, you'll have to install it from its own package (xinput), as it doesn't come bundled with standard X clients. Second, you can find out about the devices connected to your X server using:
~ xinput --list
Virtual core pointer id=2 [master pointer (3)]
Virtual core XTEST pointer id=4 [slave pointer (2)]
SynPS/2 Synaptics TouchPad id=12 [slave pointer (2)]
It is easy to find the device you're interested in (here, say the touchpad entry). Then, you list the properties you can set/get using:
~ xinput --list-props "SynPS/2 Synaptics TouchPad"
[...]
Synaptics Edge Scrolling (269): 0, 0, 0
The list is quite impressive, so I have only shown the one I'm interested in. You see here everything is 0, which probably explains why edge scrolling is disable (I don't have a clue what the actual numbers mean). You can finally change the properties this way:
xinput --set-prop "SynPS/2 Synaptics TouchPad" "Synaptics Edge Scrolling" 6 6 6This gave me back edge scrolling. I used a similar approach to enable again the third button emulation... What is neat here is that the property names are readable enough, and there's a lot of them to play with. Great !
i can haz understanding?I m trying to rebuild a package with gcc-4.6 instead of (default) gcc-4.5. Sounds easy, huh?Not today, not with qmake :(Setting CC=gcc-4.6 CXX=g++-4.6 on the command-line does not help. Neither does exporting these in debian/rules. Let s fire up Google, I think I remember qmake tends to prepend EVERYTHING with QMAKE_ Right, official documentation says it s QMAKE_CC and QMAKE_CXX. Setting those on the command-line does not help. debian/rules? Nope!Okay, let s do it the qmake-way, set it in the main .pro file which basically just calls a bunch of other .pro files (one for each component of the project). Guess what? It does not help. You have to set these in each and every .pro file! Rly? Is this what I have a build-system for?</rant>Now, seriously, what s the proper way to override stuff like this in qmake? Any pointers appreciated.
Since my latest announcement of the Lua workshop, I received a couple of emails asking why I discourage the use of Lua. Actually, I already wrote out many of the things I dislike about Lua. I won't come back on this technical issues here, but since Lua 5.2 is not yet released (it's still at alpha stage), they are still relevant nowadays. Stack based API is harder
The ease of integration of Lua into a C program is one of the point of Lua. They claim it's very easy to integrate Lua into your C application, because it does not use pointer, nor reference counting, nor anything that requires a minimum amount of skills to be used. It uses a virtual stack based approach. You push or pop things on a stack, and refers to them using a relative or absolute index. In order to people who never wrote Lua code to understand, here's a quick example on how this work. The L pointer is a Lua environment.
/* Create a table on the stack: index 1 */ lua_newtable(L); /* Push a string on the stack: index 2 */ lua_pushstring(L, "hello"); /* Push a number on the stack: index 3 */ lua_pushnumber(L, 123); /* Set newtable["hello"] = 123 */ lua_settable(L, -3);You first push a table (in Lua, a table is almost equivalent to what you'd call a hash table in other language), then push the key, the value, and do the assignment operation. In the settable, we use -3 as index, meaning the "3rd item on the stack counting from top". We could also have written lua_settable(L, 1), since the table is also the first item on the stack from the bottom. So far, so good. Problems arise when you do more complicated stuff. My previous example is what you would typically find in a tutorial, but of course, real life is different, and usually more complex. If you cut the things in different parts, it can start to be more complicated. Let's take a look at the following:
/* Create a table on the stack: index 1 */ lua_newtable(L); /* Push a string on the stack: index 2 */ lua_pushstring(L, "hello"); /* Push a number on the stack: index 3 */ lua_pushnumbe(L, mycomputingfunction()); /* Set newtable["hello"] = 123 */ lua_settable(L, -3);Here, we do exactly the same thing, but we do not push 123 directly: we compute it. And here's the trick: if your computing function is also using the Lua stack, things can become very messy. As long as your computing function use the stack cleanly by pushing and poping all its item, and returning the stack in the same state it was before, you're safe. The problem is that in a complex program, you also write bugs. You do not chose to, but you do. And sometimes, you forget to pop one of the item you fetched from a table. Imagine that mycomputingfunction is:
int mycomputingfunctiong(void) /* Just push the table we want to fetch the number from on the stack */ pushatableonstack(L); lua_pushstring(L, "mykey"); lua_gettable(L, -2); return lua_tonumber(L, -1);This function works perfectly. It pushes a table, then a key ("mykey"), then fetches mytable["mykey"] and pops the key (lua_gettable does push value/pop key itself), and then returns the numeric value of the last item (the fetched one) of the stack. However, this function has a bug: it does not pop the table! This does not prevent the function to work. It does not raise a segmentation fault. It does not show any problem under gdb. It does not show any leak under Valgrind. It does now show any problem under any standard C debugging tool. But when you'll start using it, your program will start to do weird things, and you'll have to spend a huge amount of time debugging it manually, dumping the stack content at each step of your program to watch out what's wrong. Another bad thing, that can happen, is some code poping accidentally an item from the stack, or worst, from an empty stack. This does not raise any error on the Lua side, but will break your program in very unfunny way. Even if I've been very meticulous writing awesome, but we hit that problem regularly. The easiest workaround is to use lua_settop(L, 0) to reset the stack to 0 element. Doing this regularly (like after each program event or treatment) can remove left-over items and avoid the never ending stack grow you may experience if your left-over items continue to pile up. Did I tell you I dislike work-around? You could also use lua_call(), which would avoid such an error, but this would require a huge amount of indirection, and would make write more (useless) code. This kind of problem does not exists with pointer based API. If you screw things up, the problem will cause a segmentation fault or leak memory, or cause things you can (easily) debug with standard tools like gdb or Valgrind. No reference counting is a pain in the ass
Userdata objects are variable Lua size objects embedding a C struct you define. It's the equivalent of an object in object oriented language. Lua does not provide any reference counting for the userdata objects. That means you can push this objects on the stack, use them, but they cannot directly reference each others. If you have a "car" userdata and a "wheel" one, the car cannot hold directly a reference to the wheel. This is not possible because userdata are allocated and garbage collected by Lua, and there's no way to increase the reference counting yourself. So the common hack is to store the wheel into a table as a value, and store the table index as an integer into the car data structure. This obviously makes memory leaks tracking harder, add huge level of reference indirection in usage (still more code), and does not make the whole process less error prone (at least in my opinion). No paradigm makes you lose time
Lua is proud to come with no paradigm and to provide metatables. I already showed 3 years ago that it has big flaws. To me, this ain't no good. Lua is not functional, nor it is object oriented. Most people, including me, want one of this paradigm, or any else. Plain old imperative is not enough. So you'll start to build more, or to use something like LOOP, which implements an object model. You'll implement your paradigm. I say life is too short to (re)write a paradigm. In awesome we wanted to have an object oriented approach (this is kind of typical in such a graphical application context), so we tried to build one. To me, this started to be a show stopper when I realized that I've ended writing Python object model into Lua while developing awesome (which aims to be a window manager, not a language). This is one of the reason I stopped hacking on Lua things. I liked Python object model and wanted to have it in Lua, and spending time rewriting Python is just not worth it. I probably should have chose Python, not Lua. YMMV. Embedding may not be a good choice
This is not Lua related, but I want to mention it. Googling for "embedding vs extending" will probably tell you more about why you should double check that you really need to embed Lua rather than to extend it. Being small is not an excuse
One common argument to choose Lua is that it has a small footprint. Yeah, that's true, but that's useless. Bummer! When I program, I don't have any resource usage pressure. People who have such pressure are either paranoids or playing in the world of embedded computers. This is also a no more existing conception since quad core processors equiped phones are coming into the market. I'm rather confident that what we used to call embedded devices are just dead and are now plain computers. But as usual, YMMV. So start to forget about it, run in your underpants and yelling "yay we killed that shit!", and then use real computers stuff. :-) Even if benchmarks show how Lua is damn fast, remember what a benchmark proves: that you can do useless things very fast. Too few extension modules
This is not directly Lua's fault, but there's too few extension modules for Lua. The community is quite small compared to other big languages' ones. So think twice
before you choose Lua (or any other language). My recommendations these days
would be not to embed, but to extend. If you really have no choice and need
to embed a language into your application, GNU Guile is probably worth
considering, because it's a Scheme and therefore a functional language :-),
and because it can provides also different languages.
Including Lua.
I was trying to build the curl hackage package on Debian unstable with ghc 7.0.3, and one of its modules were failing to build. I searched for the error message and found this GHC ticket. As mentioned in the ticket, I had to downgrade binutils to 2.20. The version of binutils in sid is 2.21.
Another possibility would be to change curl to avoid using -fvia-C, but I didn't want to modify the package.
I'd like to buy most of my books as e-books, particularly novels.
I'd like buy to all of my movies and TV shows as downloads.
I'd like to buy maps for my Garmin GPS device as a download.
I can do none of these things, unless I consent to restrict my
freedoms in essential ways. For example, I can buy books, but only
if I read them on a Kindle or Nook or similar restricted device.
I can buy TV shows on iTunes, but I can't watch them on my Linux
laptop. I can buy the maps, but only if I get a Windows (or maybe
Mac) computer so I can run Garmin's proprietary software to download
the maps and put them on the device.
There are ways to circumvent these restrictions. Doing that is
illegal in various countries I would like to live in. If I'm going
to be breaking the law, the easier route would be to copy thing
illegally.
I can choose to succumb to corporate enslavement, where
they get to decide what I watch, and how. Even when
I try do this, I fail: I installed Amazon's Kindle software for
the Android, but it would still not let me buy anthing, saying
that each title is not available in my country. It said this even
for stuff long past copyright, while giving pointers to the same thing
in Project Gutenberg.
Alternatively, I can choose to reject doing things digitally,
and relying on paper for books and maps, and rental DVDs for
video stuff.
I've heard rumors that there is a lot of good stuff legally
downloadable for free. Maybe I should go find some more.
I have a short list already,
but finding the stuff that actually interests me is not easy.
As Evgeni Golov already blogged, there is going to be the next round of a IRC meeting of the Debian/Ubuntu Games Team on the upcoming Saturday. This time it will be held at April 30th at 12:00 UTC in #debian-games on irc.oftc.net, so if you are interested in bringing the Games Team up to pace again, want to join and wonder how you could help, please attend. The agenda contains a fair amount of leftovers from the first meeting, please see Meeting Page about it.
This year we will have two more projects is GSoC comparing to last year, the chosen ones being:
Filed under: English Phpmyadmin 0 comments Flattr this!
I d like to extend a warm welcome to our new batch of students selected for the 2011 Debian Google Summer of Code!
They should soon be posting on Debian Planet and you re welcome to come talk to them on #debian-soc on irc.debian.org
Further details will be posted in the coming days to our wiki: http://wiki.debian.org/gsoc
Automated Multi-Arch Cross-Building and Bootstrapping
aka autocrossbuild , by Gustavo Prado Alkmim, mentored by Wookey
In the
announcement of availability of D-I in Uyghur, I made a mistake :
Xinjiang is also known (indeed named by the Uyghur people) as "East
Turkestan" and not Eastern Turkmenistan.
These things can be sensitive, so apologies to Uyghur people for
misnaming their region.
After several months, it was time for a new release 0.2.4 of
RInside which is now
on CRAN. RInside is a set of
convenience classes which facilitate embedding of R
inside of C++ applications and programs, using the classes and functions provided by the
Rcpp R and C++
integration package.
This new release contains a few small internal changes to the initialization
code, as well as a number of slightly improved examples employing more of the
simplifications which Rcpp offers.
Also included is a brand new example embedding R
inside of the Qt framework; an
earlier blog post
had already discussed this example. Two more examples were added to the
standard/examples directory which now contains fourteen plus two tests.
We also added a NEWS file, the entry for this release is below.
0.2.4 2011-04-24
o Minor code cleanups in initialization code
o New example embedding R inside a Qt application, along with pro file
for Qt's qmake providing a complete simple C++ GUI application
o New examples rinside_sample 10,11 based on questions on the
r-help and r-devel mailing list
o Some improvements and simplifications throughout examples/standard
as well as examples/mpi/
o Added this NEWS files -- with entries below summarised from ChangeLog
and the corresponding blog posts
And courtesy of
CRANberries, here are
the
changes from the previous release.
More information is on the RInside page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.RInside-0.2.3/RInside/inst/ChangeLog only RInside-0.2.3/RInside/libRInside.a only RInside-0.2.4/RInside/ChangeLog only RInside-0.2.4/RInside/DESCRIPTION 24 ++++-- RInside-0.2.4/RInside/R/RInsidePaths.R 4 - RInside-0.2.4/RInside/doxyfile 8 +- RInside-0.2.4/RInside/inst/NEWS only RInside-0.2.4/RInside/inst/THANKS 1 RInside-0.2.4/RInside/inst/examples/mpi/rinside_mpi_sample0.cpp 10 +- RInside-0.2.4/RInside/inst/examples/mpi/rinside_mpi_sample1.cpp 11 +-- RInside-0.2.4/RInside/inst/examples/mpi/rinside_mpi_sample2.cpp 10 +- RInside-0.2.4/RInside/inst/examples/mpi/rinside_mpi_sample3.cpp 9 -- RInside-0.2.4/RInside/inst/examples/qt only RInside-0.2.4/RInside/inst/examples/standard/rinside_sample1.cpp 30 ++++---- RInside-0.2.4/RInside/inst/examples/standard/rinside_sample10.cpp only RInside-0.2.4/RInside/inst/examples/standard/rinside_sample11.cpp only RInside-0.2.4/RInside/inst/examples/standard/rinside_sample2.cpp 15 +--- RInside-0.2.4/RInside/inst/examples/standard/rinside_sample3.cpp 6 - RInside-0.2.4/RInside/inst/examples/standard/rinside_sample5.cpp 10 +- RInside-0.2.4/RInside/inst/examples/standard/rinside_sample6.cpp 12 +-- RInside-0.2.4/RInside/inst/examples/standard/rinside_sample7.cpp 9 -- RInside-0.2.4/RInside/inst/examples/standard/rinside_sample9.cpp 2 RInside-0.2.4/RInside/inst/include/RInsideAutoloads.h 35 ++++++++-- RInside-0.2.4/RInside/inst/include/RInsideEnvVars.h 13 +-- RInside-0.2.4/RInside/src/Makevars 2 RInside-0.2.4/RInside/src/RInside.cpp 21 +++--- 26 files changed, 121 insertions(+), 111 deletions(-)
Last night I wanted to buy an album on Amazon and I couldn't do the
checkout as the site required me to install the Amazon MP3 Downloader to make
the purchase and download of the album. The downloader is not needed for a
single song though, but buying each song separately would be more expensive and
more work. The good news is that it automatically offered me packages for
different Linux distros: Ubuntu, Debian, Fedora and OpenSUSE instead of telling
me off for using Linux and leaving me behind with a Windows only download.
But here comes the catch, all offered packages are only for the Intel 32-bit
architecture.
Now this is a showstopper for me, as I am running an AMD64 Debian which is a
64-bit architecture. I first tried to download and run the 32-bit debian
package nonetheless as there was some hope with the ia32-libs and ia32-libs-gtk
package. But this was not working as the application needs gtkmm libraries like
libglademm and bailed when I tried to run it. So I filed
a wishlist bug report against ia32-libs-gtk for inclusion of gtkmm
and possibly other needed libraries to run the Amazon MP3 downloader on AMD64.
So I bought the album using MusicLoad instead which simply puts all songs in
a single archive on-the-fly and let me download that archive.
When I tweeted my frustration on Twitter I was hinted by Jo Shields
and also by Gabriel Burt that there would have been a much simpler solution to
this issue by using Banshee which includes an Amazon MP3 Store plugin:
This plugin allows you to log into your Amazon account browse their store like
the regular Amazon store, plays the song samples directly, purchase songs,
downloads the songs and imports them into Banshee's database so you can play
them right away. And as if this wasn't good enough yet, with the the purchase
of MP3 songs on Amazon using Banshee automatically makes a donation to
the GNOME foundation.
As I am the only one who forgot or wasn't aware of this awesome solution
this deserved some blogging.
Update: some people pointed out that clamz is also available to make MP3
purchases on Amazon.
Since Debian is in GNOME3 transition period, after last dist-upgrade I lived on bare minimum of GNOME DE and its apps. basically all I had working right was Chromium and Terminal, instead of Rhythmbox I used mpg321, instead of Gedit it was Vim and so on, which is all fine except the fact it had me living in 2000 again.
It was all due to python-gtk2 version that was missing in Sid repositories. Furthermore, as I was unable to restart X and had my notebook on suspend after every login I had to retype my wifi passphrase due to a bug in gnome-keyring. I believe I did my part, reported the bugs and waited maintainers responsible for those packages to do something. But this situation went on for 8 days.
I remember the times when you couldn t fire up X for weeks, but after those days Unstable has gained reputation that it s not like that anymore, but after having a situation like this one, it makes me wonder.
Please, don t take this the wrong way, I mean no harm but the ultimate question that is brought up here is is this the price of bleeding edge?
*Update
As many of you came down on me with anger, let me say couple of things. First of all, when I first wrote this post I was kind of using it for venting. Second of all original title was Price of freedom as it sounds too confrontational and for some misleading I had it changed to Price of bleeding edge . What happened above could ve been avoided if I used safe-upgrade instead of dist-upgrade, as at the time I was just too tired and wasn t paying enough attention to the list of all the packages that are going to be removed.
I use Sid for few years now, and am of a opinion if used with attention it is the the best bleeding edge/devel distro out there. I wasn t ranting and am still of opinion that things like this need to be discussed among us, of course we can just stick to the line debian is the best and we re not going anywhere. Maybe I did go over the line with this attempt of positive criticism, but I really don t see nothing wrong with what I did here, as one of items from Debian Social Contract is We Won t Hide Problems thus let s talk about it.
Again, I apologize if I offended anyone, as point of this whole post wasn t of such nature.
Next.