As of 2016-02-26, there will be no more posts for this blog. s/blog/pba/
Showing posts with label kernel. Show all posts

There was an incredible idea posted early this month in Linux kernel mailing list by Paul E. McKenney:

Although there have been numerous complaints about the complexity of
parallel programming (especially over the past 5-10 years), the plain
truth is that the incremental complexity of parallel programming over
that of sequential programming is not as large as is commonly believed.
Despite that you might have heard, the mind-numbing complexity of modern
computer systems is not due so much to there being multiple CPUs, but
rather to there being any CPUs at all.  In short, for the ultimate in
computer-system simplicity, the optimal choice is NR_CPUS=0.

This commit therefore limits kernel builds to zero CPUs.  This change
has the beneficial side effect of rendering all kernel bugs harmless.
Furthermore, this commit enables additional beneficial changes, for
example, the removal of those parts of the kernel that are not needed
when there are zero CPUs.

Who would have thought the solution is just that simple, zero CPUs. All problems will be gone as long as you have zero CPUs. No more unexpected bugs and developers wouldn't be stuck in complex of design. Zero is the one.

If you think that's ultimately optimal choice, then you are mistaken. Less than five hours later, Eric Dumazet brought up another concept which makes the entire kernel ascends to completely different and extraordinary level. No one has foreseen it until now:

Hmm... I believe you could go one step forward and allow negative values
as well. Antimatter was proven to exist after all.

Hint : nr_cpu_ids is an "int", not an "unsigned int"

Bonus: Existing bugs become "must have" features.

Of course there is no hurry and this can wait 365 days.

Using opposite to negate the disadvantages of having CPUs. As if matter-antimatter collides, which results the energy generated much more than by options we have today. We may have several orders of magnitude greater than currently most powerful CPU's processing capability.

Lucky for Linux user, this technology doesn't need to wait for long. Less than 365 days to go. Since then, our Linux box will be able to do almost everything in a split of a second, which needs an hour or so at the moment.

No doubt that the major OS developers will try to patent it. Someone with good heart has to prevent such thing from happening and allows everyone to use this new concept freely. This is the future of human beings, not just computing, we can not afford being ruined by corporations.

This just... rickrolls!

Also checkout this one-liner using SystemTap.

I didn't compile the original, so I re-compiled my kernel to add required flags, just get my computer rickrolling! I did slight modification:

sudo stap -g -e 'probe kernel.function("do_filp_open") { p = kernel_string($pathname); l = strlen(p); ext = substr(p, l - 4, l) ; if ( ext == ".mp3" || ext == ".ogg" || ext == ".mp4" ) { $pathname = %{ (long)"/tmp/RickRoll.flv" %}; } }'

sudo stap    -e 'probe kernel.function("do_filp_open") { p = kernel_string($pathname); l = strlen(p); ext = substr(p, l - 4, l) ; if ( ext == ".mp3" || ext == ".ogg" || ext == ".mp4" ) { system("mplayer -fs /tmp/RickRoll.flv") ; } }'

To tell the truth, I don't know where to get the MP3, so I use YouTube video and it gets even better. Video player sure has no problems, MPD has no problem as well.

If you have an empty audio file for the media player and supply -loop 0 to mplayer... full screen + looping, FTW!

I didn't try these: Hijacking normal files like txt when editor opening (Don't really know SystemTap, but I think execname() is right way to check, right?) and replace with lyrics. Images, mehhay! I think this would replace all images you view on web when browser loads from cache.

All my playlists are rickroll'd.

Never gonna say good bye, well sang.