Posts Tagged ‘breakage’

brilliant fools – hackers update

Monday, March 1st, 2010

cracks are on the rise. so are hacks, and I haven’t posted a thing since December. So what’s up with you?

Good news is that Con Kolivas might have managed to defeat his carpal tunnel and swallow his spite for kernel dev elitism, and is again churning out solid kernel code to improve desktop usability – which the kernel devs aren’t too interested in – something he is quite right to say!

Hopefully ubuntu will pick up CK’s scheduling patches, because they are uber and with ubuntu’s momentum they might topple the stack. Too bad their kernel team can’t follow the churn. Wish I had time to compile it for you or even post some interbench stats with pretty graphs, but there is a BFQ PPA available already so you can test it out on your ubuntu or debian machine. Bonus? Some random dudes wrote a simple IO scheduler which is included there. Ain’t that reasonable?

All that at least until we have time to write our own OS which gets rid of all suckage, is super flexible and of course incorporates all our favorite patches.

Valgrind is pretty neat, and with that we have working stray acks in PRADS, the stealthy host and service detection system. More features and even a new release might come soon, which is to say – when it’s ready. In the mean time I welcome you to try breaking it in any and every way possible.

Also, if everything you do is motivated by monetary gains then you sir are a shame to the human race. Go back to step 1 and have a good day now.

Lame things that suck

Saturday, December 5th, 2009

The world is a difficult place, we know.
Here’s a list of things that suck unnecessarily much:

  • Fink for OSX needs Xcode dev tools.
    Why not provide a gcc/libc-dev package? No idea. General lameness from the fink developers forces you to register at the Apple Developer Connection and download 700MB of apple crap just to install and compile source packaged software in fink. LAME.
  • Fink is not Cydia on the iPhone.
    Both are based on apt and dpkg. Both run on OSX. Pooling of efforts, everyone.
  • The very fact that you have to jailbreak an iPhone is ridiculous. Goes doubletime for Xbox and PlayStation chipping, Wii softmods and DS carding. This is vendor lockdown and should be lotted with the criminally insane – vendors don’t need to take responsibility for user-created apps, but vendoirs must not stand in the way of the software evolution.
  • Tar sands. Corruption.
  • There ain’t enough time to read all the cool web comics. Games? Don’t get me started.
  • to quote a friend and collegue, “every operating system in the world. Pick one and I will tell you how much it sucks.”

HOWTO avoid pains with NetCom 3g USB on jaunty

Sunday, September 6th, 2009

Internet anywhere, ain’t it great?

If you have one of those 3g netcome HSDPA USB dongles you might hve noticed how they don’t really work so well out of the box.

After I had spent 4 hours trying to get the thing working Martin smugly told me these things should be plug’n'play and proceeded to… fail to get it working. oW hELL…

Cutting to the chase and sparing you the gritty details I have a recipie for getting 3g working with the Netcom ZTE-MF636 USB dongle. This recipie should work in ubuntu jaunty and similar recent distros, and most of the instructions apply to other USB dongles too. Included are also all the tips you need to avoid spending 4 hours hammering your head against the wall…

never ask for root again

Monday, August 17th, 2009

just a short note to all of you:

linux is not secure. Passwordless root is here :-*

Yes, it has been published elsewhere, but I’ll do mine to push this meme to you: there can be no “untrusted local users” nor do I believe that your services aren’t exploitable.

Two seconds later I have root on your box.

Despite LSM. Despite SELinux. Despite jails and virtualization. Despite all your assumptions.

You will need some very fine security gents and a little of your own smarts to secure your nets. Call us :-)

The best link on this issue so far has been:

cr0: bypassing linux with null pointer

Do you want security? Go run carpal-tunnel-inducing OpenBSD, swell swell if only it smelled well FreeBSD, or, *drum rolls*

drop-in up-to-date secure and invulnerable grsec kernel for ubuntu and debian

Only disadvantage I can see is that they don’t provide amd64 and desktop builds.

Dilligence and perseverence is the path to victory,
and although paranoia may not be the path to safety
noone should leave their front door open.

In other news, and probably a little lame for those of you coming thru the planet feed, security.vcl is here – properly used, understood and abused it could save you some worries, making sure no “untrusted user” went “local” in the first place.

Also, tell your friends: there is a Facebook virus about. It sends links to you from your friends accounts. If you click on the link, you too will be sending your friends links.

Yeah, I know, that sounds like what I do on facebook all day. Except the difference is you don’t know you’re sending links.

So watch out.

And tell your less savvy friends.

how to break your head : try linux compilination

Wednesday, July 29th, 2009

I’ve recently started compiling my own kernels again. Some people ask me why I’d ever want to do this – a valid question, since anyone who’s done it knows a time-consuming hassle best left to the distro packagers and really nerdy people with too much time on their hands. Other people will give a blank face and ask “What is a Conpiling?” To these other people: this article is not for you, it will only serve to confuse that pretty little head of yours. If you know what ‘a compiling’ is, you may proceed. I don’t provide references; I banter them. Google your friend, pluckum.
Still, I am not here to discuss the reasons for compiling your own kernel – these are all too obvious to the initiated and completely uninteresting to anyone else. I’m more interested in the reasons why my friends, collegues and I have *stopped* compiling our own kernels – despite some of us enjoying at least a compile a day (or ten!) for periods of time in the past. Only the gentoo rice boys remain, steadfastly compiling everything in sight despite snide comments about mean time between upgrades and ridicule about their USE_FLAGS selector GUIs.
Why don’t we compile anymore?
There is no stable upstream branch. In my own experience this has had direct consequences for the stability and quality of point releases.
Years after Linus’ bitkeeper schism, the SCO slimeballing and the death of the stable branch, we can look back and say that aye, we have a better audit trail and development has scaled through the roof. We have more kernel features than ever, and an astounding rate of patches make it into mainline every day.
These amazing developments are a long shot away from the linux dev process back in the days of 2.2 and 2.4, but there is a dark side to these developments.
Regressions are no longer the domain of the bleeding edge, the -mm or -ac trees, -alpha and -rc releases for the adventurous, masochistic or desperate. Common things. Getting bitten by that local sexploit and being too embarassed to tell your friends about it. Software suspend used to work fine. The graphics card did not crap itself on the last point release, but at least my NIC doesn’t get bricked in this one. The wifi keeps screwing with you, but you don’t know if you should blame Ubuntu, Intel or Linus. On the internet noone can hear you scream.


Elitism is rife on the LKML, and more pointedly, in the mainline patch process. Who knew NIH would be such a big problem in an open source project? Admittedly, it is the largest and perhaps the most ambitious open source project of all, with all eyes on target, a million uses and powerful market forces pulling the project this way and that. Linux has long ago outgrown the boy’s room, the hacker dungeon and its academic roots. Most kernel patches that get into mainline are pushed there by large hardware and software vendors. Many kernel hackers hack the kernel on their day job, earning an engineer’s living.
Linux has reached the Enterprise in a big way. The system runs and is optimized for Big Iron. The desktop is “good enough”, say the kernel hackers. Latency is fine for our uses, and those squeaky audiophiles should shut up and fork. Indeed they did, as embedded, realtime and audio people have all collectively decided to jump off the wagon.
Out-of-tree kernel hackers already know where the lay is at. After years of pushing the same genious useful patchsets they are sick of cleaning up, splitting out, documenting, backporting, forward porting only to discover that noone read their patch. Maybe they will be lucky, their ideas bastardized overnight into someone else’s pet project, far more likely to succeed once it is Invented Here(tm).
It’s not all bad: we want and need to trust the people that push stuff into the kernel. Who are you to think that you can do it better than them? They are doing their job, they do it well, so what if they all meet for beer and virgin sacrifice after hours, so what if there is no free seating in their society? Fork your own.
Weiging in at 800MB uncompressed, the Linux source is a behemoth. Counting only source, headers and assembly, there are 35,000 files in the linux kernel, with 10,667,648 lines of source code. This code is metriculously organized, not only into systems, subsystems and modules, but into domains of responsibility. Hey, if you’ve ever managed a large software project you would know how annoying, how encroaching it is when someone start fiddling with your private bits.
On the other hand, linux has lost a lot of great contributions and spurned a lot of marvelous people because of this elitism. OpenMosix israeli clustering, reiser4 the murderous file system, software suspend 2 the ‘it just works’ approach, page-in-from-swap, CK’s desktop efforts, the two kernel monty carlo and process snapshotting are only few of the projects that failed to sufficiently influence the core developers, some of them even year after year.
It can be argued that despite the patches not making it to mainline some of these ideas did find their way into the minds of the gitmasters and found other implementations on technical merit alone. To me this defeats the whole purpose of the open source model which drives technology by sheer speed. We’ve had a working, cleaned up, documented version of the patch for two years – and the feature doesn’t make the cut. This is too little too late.


Well, not everyone takes an interest in kernel politicking even if they follow the LKML or kerneltrap, and some people even like hitting bugs and fixing issues in their compiles, and trolling in epic flame wars. They too have left kernel compiling to other, more patient and masochistic people.
Maybe it’s because even grepping a single point release changelog is a major chore. The distro folks have gotten fairly good at kernel compiles; ubuntu ships a one-size-fits-all Just Works(tm) kernel, RedHat’s patchset has grown less offensive over the years and debian is and always was debian. Upgrades are relatively painless and usually somebody else already did the dirty work.
Linus Thorvald’s initial plan succeeded: by axing the stable/unstable tree he told the world that the responsibility for stability rests on the distributor. He also axed many hobbyists’ will to stay and play with new releases. I’d rather go play on milw0rm.


There are other compelling reasons not to roll one’s own: the number of configuration options has doubled over the past years, and most of these new options are not relevant to the hobbyist use case. Development not only in the kernel source but in the toolchain (gcc) has caused compile times to soar. I remember proudly compiling 2.4 kernels on my K7 within 10 minutes back in 2001. Today it might take longer to compile the tree on my Centrino dual-core.
And there it is: we’ve suffered feature creep and bloat. After a long download, an hour or more of configuring, and many failed initial make runs, a generic compiled bzImage weighs in at about 3412 kB. This is a modular kernel, mind you. What happened to lean and mean 800 kB kernels?

Memory is cheap you say.
But minds are not cheap!


I’m announcing a contest: what’s the smallest stable useful kernel you can make for your platform? Remember, it should run on other machines and be useful, and the compile reproducible. Choose your own definition of useful, but do find a concrete definition. Use any tree and patchsets that turn you on. Bonus points for packaging so others can plug your kernel into their system. I’ll make your package available.
As a side contest I’ll take compile times along with bogomips numbers and your .config file for reference.


PS. Yahoo! internal IT sucks. Where’s the wifi? Running our own cables, canned XP images in a linux lab, packet loss. This aint no funky party. I guess they are too busy. Paranoia maybe. Things aren’t wonderful.

LDAP and its many uses

Friday, June 19th, 2009

There is a nice article on Single-Sign-On and LDAP in the Journal and although it is not new the man writing it has clearly spent some time finding novel (read: whack) uses for catalogue services.

Myself, on the other hand, I’ve been finding novel ways to break OpenLDAP. My 35-hour stint on Thursday set up more Active Directory-integrating workaround setups of the Slap Daemon than you can shake a bloody large stick at, including but not limited to The Inverted Translucent Reverse Meta Tree, where we do a slapo-translucent overlay in one slapd and a plain slapd database in the second slapd, then slapd-meta the sAMAccountName into uid and remap the suffixes in a third slapd process. Yep, that’s four separate catalogues to solve one application problem.

Don’t. Ask. Why.

The upshot is that you should stay the hell away from the slapd rewrite module as it will core, that the translucent overlay is magnificent at making very plain ldapsearches (objectclass=*) return no objects or fail, that slapd-meta is a very cool backend to do remapping suffixes, attributes and your mom, that your application should never have to write to a read-only Active Directory tree, and that simplicity is instrumental in not going mental.

Unfortunately, simple solutions to complicated problems are rather hard to come by.

PS. The problems I was trying to fix all came out of one single application bug and my attempts to work around it :-P

Xorg is a steaming pile of gonzales so turn on your UXA

Sunday, June 7th, 2009

Hei folks,

if you have a newer Intel or ATI gfx card, and you’re running a suitably dishy distribution (Ubuntu Jaunty maybe, xorg 7.4, kernels 2.6.27 and up perhaps?) maybe you’ve noticed how sluggish and slow Xorg is. Sometimes it’ll be a dick and eat heaps of your RAM, and maybe hog 98% of your CPU time for no damn raisins.

Furthermore, that sleek graphics card seems to be causing loads of garbage rendering – what gives? I wish I could show you some screenshots but honestly, I don’t really wanna see that shit again, so here’s to not reproducing it. Instead, why don’t you do like I do and enable UXA? Edit your /etc/X11/xorg.conf file and add
Option "AccelMethod" "uxa" to your acting Device section like so:

Section "Device"
   Identifier    "integrated"
   Driver "intel"
      Option "AccelMethod" "uxa"
      Option "RenderAccel" "on"
      Option "PageFlip" "on"

Now logout and back into X again, restart GDM, KDM or whatever and whoop de doo your /var/log/Xorg.0.log should say something like:

(**) intel(0): Using UXA for acceleration
[... snip irrelevant shit ...]
(II) intel(0): [DRI2] Setup complete
[... more irrelevant crap ...]
(II) UXA(0): Driver registered support for the following operations:
(II)         solid
(II)         copy
(II)         composite (RENDER acceleration)
[... further noise ...]
(II) intel(0): direct rendering: DRI2 Enabled

Also, windows should draw/move/resize snappier and there should be much rejoicing. If everything went all right that is.

Note that my glxgears performance dropped from 1300fps (w/xcompmgr) down to 660fps (xcompmgr) and 994fps (no composition manager) so there seems to be a tradeoff here, but I really really prefer my gooey windows snappy, artifact-free and less crash-prone. maybe.

K out

politiet sliter

Tuesday, March 17th, 2009

Politiet sliter med datasystemene sine. En kollega har allerede nevnt saken. Det er skremmende men slett ikke overraskende. Det tar nok mer enn to uker før de får kontroll på viruset, spør du meg.

Jeg lurer på om vi på Redpill-Linpro ikke kunne hjulpet dem litt.
Gode forslag flyr rundt på kontoret:

Vi kunne brannvegget de så viruset ikke sprer seg. Vi kunne satt dem opp med tynnklienter og MultiFrame. Vi kunne fått orden på deres skrivbare shares med litt samba-magi. Vi kunne fått deres applikasjoner over på wine, eller virtualisert dem. Vi kunne stuntmigrert dem ved hjelp av noen usbnøkler og/eller litt PXE-foo – og så, ikke mere virus.

En ting er bra sikkert: det kommer til å ta dem ukesvis bare å få kontroll hvis de fortsetter med det nåværende systemet.. og de utsetter seg for at noe lignende skjer igjen og igjen og igjen.

Bonusen er at våre løsninger er åpen kildekode, så klart!

how to break your debian: mix and match packages

Friday, March 6th, 2009

Let us say that you are, like me, a debian (or ubuntu) user with special needs. You have a kick-ass new laptop and you need the latest linux kernel to get all the fancy gadgets working – like your ethernet adapter.

Your computer is your work environment, so you gave up on sid / jaunty because spending a couple hours a week figuring out why apt is barfing is not an option when clients are breathing down your neck. Also, when update-manager tells you “There are 277 updates” every other day you’ll get sick of booting into the New World just to find out that the New World smells kinda funny and has no pizza. Figuratively speaking.

How to get the best of both worlds?