Slashdot Mirror

With some quality programming, the web browsers could use a fraction of the CPU power they do now by storing off screen graphics in compressed formats, for instance, especially since ending up with disk caching due to using up the RAM is far more resource intensive than decompressing images.

While the rest of your comment may be sarcastic, this is actually a very good idea. First, it is actually many, many times faster to recompute a value than to pull it from memory:

Jim Gettys: "There seems to be a common fallacy among programmers that using memory is good: on current hardware it is often much faster to recompute values than to have to reference memory to get a precomputed value. A full cache miss can be hundreds of cycles, and hundreds of times the power consumption of an instruction that hits in the first level cache."
http://lwn.net/Articles/188060...

Secondly, even if we're talking about content that isn't already available in compressed form (which most web content is), there are simple compression methods like LZOP, where the extra CPU overhead is still faster than the increased amount of I/O needed to transfer the equivalent amount of uncompressed data.

"lzop is usually IO-bound and not CPU-bound"
http://www.lzop.org/

Frankly, I'd be happy to turn off all Firefox caching if I could... I never open more than 20 tabs, and certainly not with huge images, yet on my 1GB system, Firefox starts causing swapping to disk after every 8 hours or so, and needs to be restarted, and I certainly don't buy the cop-out that my add-ons (Adblock and NoScript) are to blame, while Firefox would be perfect otherwise. And this is with the LTS/ESR version, which is supposed to be the super-stable version.

"Well, malware injection to the linux kernel isn't a mere possibility. The incident that happened back in late 2003 comes to mind."

I don't think you are intentionally trying to misrepresent the facts, but before others take the misrepresentation of the facts and run with it ...

"But this attack never had any chance of corrupting the mainline kernel. The CVS repository is generated from BitKeeper, it is not a path for patches to get into the BitKeeper repositories. So the code in question could only affect users who were working from the CVS repository. Kernels used by distributors probably do not come from that repository, and, as this incident has shown, illicit code can only remain there for so long before being detected."

I think you are confusing a failed attempt with a successful injection. The checks and balances in place stopped it sans two-factor auth. This just makes it even more unlikely.

How do you feel about the fact that Darl McBride said that SCO owns C++?

Source 1
Source 2
Source 3
Source 4

So far we know of exactly one attempt to do that to the linux kernel.

DebConf, the annual Debian conference is always a load of fun. Next one is in Portland OR, very soon.

Check out the LWN calendar for more FLOSS conferences:

https://lwn.net/Calendar/

They certainly sponsor some really neat research from time to time. I particularly liked this one: https://lwn.net/Articles/56894... Then again... that was an IBM researcher who did the actual research and gave the talk, not a government official.

"He is smarter than "the masses" but he's not smarter than people like Stroustrup"

I guess you completely miss his point. If Stroustrop was the only person writing C++ code then your point might be valid. Then again, I doubt Bjarne thinks C++ is a good language for OS development when there will be thousands of developers involved either. Can you show me something that suggests he does?

linux.softpedia.com

osnews.com

Linux Today

Linux Weekly News

OpenSSL is used to add SSL support when compiling PostgreSQL on Windows. It's a constant headache to the developers and packagers of the database. We were all complaining about how much the OpenSSL license sucks, too, before it was cool to rag on OpenSSL.

From http://lwn.net/Articles/552791/.

"This is the latest version of the zswap patchset for compressed swap caching.
This is submitted for merging into linux-next and inclusion in v3.11."

Clipboard? It's a framebuffer with a compositor on top. Clipboards are a client problem (as are many other things).

Well, no, it's not. It's also a keyboard and mouse input system.

It also deals with copy and paste and drag and drop:

http://lwn.net/Articles/491509...

Because it's a windowing system and it turns out that just a compositor alone isn't enough (who knew, eh?). It's also interesting. Apparently Wayland implements passing of data by just passing a file descriptor, apparently instead of reimplementing 10 pages of ICCCM grot. The thing about the 10 pages of ICCCM grot is it's really REALLY well specified and a random person from the internet can come along, read the ICCCM, grok it (yes, I have actually implemented copy/paste and XDnD from the specs) and get it working. It's not that hard.

The wayland one seems poorly specified by comparison. For example they don't specify teeny-tiny details liekl whether the FD must be seekable, for example. So, do you have to write a local file, or can you pass a socket? Who knows! It's really easy to have a short, simple spec when it's full of ambiguity and people haven't had 26 years to beat it into a definitive, unambiguous state. Anyway, I digress.

Now do you get why the "X sux" stuff from Wayland fanboys is annoying?

Yes, but it's more annoying when it comes from the Wayland author FUDmonsters who understand X11 and yet still make silly claims about it. For example, from the link above, Packard claims:

X was created before there was MIME or Unicode, so there are many pages expended in the X specifications to do things that are more easily handled with MIME types and UTF-8 these days. For cut-and-paste and drag-and-drop, Wayland uses MIME-labeled UTF-8 encoded objects.

Well, that sounds all like OMG X sucks we need MIME and UTF-8. Well the thing is, in order to list types from a copy/paste transfer, applications exchange a string (i.e. atom) with the type name(s) available. And guess what? Almost everything these days except for plain text is exchanged using MIME types. If the MIME-type specifies UTF-8, then the data will be in UTF-8 format. So basically, X names types with a string, just like MIME, and MIME works *perfectly* without modifying or respecifying anything.

You can verify this easily: download and install a copy/paste debugger/sniffer and look at the list of types available that programs offer.

The ICCCM also specifies a few (non-MIME) types that you might like to support, such as TEXT, which maps perfectly on to text/plain and is all of 1/2 a line to implement (if(typeAtom == TEXT || typeAtom == textPlainAtom)...). And X11 sends arbitrary data (including NULs) because it represents data as data+length not a string, so you can exchange anything, such as UTF8.

Anyway, KP implies that that doesn't work with X11 copy and paste, whereas in truth it works perfectly and without any faff or hacking.

Wayland is designed to be something different to X with different goals.

Not so much. It's designed to replace X wholesale. It does windowing, compositing, input, copy/paste/DnD, and a bit opf inter client communication.

Those of us that "want to run software from 1996" are made fun of in Wayland presentations,

Yeah us with our legacy programs. From stroustrup:

"Legacy code" often differs from its suggested alternative by actually working and scaling.

Meanwhile, I shall keep using legacy programs productively. XTerm works amazingly well, still. gvim works great---though I find I sometimes have to compile it with GTK disabled and with XAW (seriously WTF??) support because GTK can't seem to get its shit in order with fonts and everytime ubuntu updates itself/reboots, the font size changes. Xfig is old but works really well within its domain for producing simple, effective figures.

etc etc blah blah.

I also use some more modern programs too. And they all w

No, it's OCZ. ext4 is the most popular filesystem that expects good behavior from drive write caches, so of course it also has the most problem reports. The way write barriers work in ext4, the filesystem struggles when hardware lies about data being flushed to disk. See ext4 and data loss for an introduction.

As outlined there, ext3 gets lucky in some situations ext4 just doesn't tolerate so some people see that as a bug in ext4. But the reason for the change is improved performance. You just can't get a fast filesystem and rugged behavior in the face of drives lying at the same time. You have to pick a side there. In the classic "good-fast-cheap--pick two" trio of trade-offs, OCZ always picks cheap and fast.

Bad drives aren't tolerated by zfs or btrfs either. It's just the case that ext4 is deployed on far more servers than they are.

This is one of those questions that's going to keep being asked... Perhaps one day I'll be fast enough to get a first post on this that people actually read...

Link summary from last time:

• Stack Overflow's books every programmer must read question (locked since 2012).
• Top Programming Books a more diverse list.
• Top 100 Programming Books by sales stats.
• Top Programming Books a more diverse list than the above.
• Reddit has a Must Read Programming books thread.
• In this Stifflog 2006 interview with Yegge, Torvalds, Hansson, Norvig, Thomas, Van Rossum, Gosling, Stroustrup and Bray.
• One of the Kernel Hacker Bookshelf series on LWN recommends Unix Internals.
• Joel Spolsky's list of books programmers need to read.
• Your Favorite Tech / Eng. / CS Books Slashdot thread from 2008, my comment listing my favourite books.

General comments

• A few people have volumes of Knuth's Art of Programming on their shelves (but it's harder to find people who have read all of them).
• One of the consultants who taught at my University said that the Mythical Man Month and Peopleware were good. I've read these too and can also recommended them (although they are more about managing programmers rather than programming per se). The consultant also recommended Design Patterns (although he said not to read the book cover to cover but rather to just be aware of them so you could refer to them later).
• I've heard the "Dragon Book" (Compilers: Principles, Techniques, and Tools I think is the 2nd edition) being talked of favourably.
• Many people seem to recommend reading Godel, Escher, Bach (I'd say it's about mathematical thinking)...

I've noticed which book answers tend to fall a bunch of categories:

• Books that talk about software engineering/management/teams.
• Books that talk about programming languages.
• Books that talk about Computer Science.
• Books that improve your mathematical thinking.
• Books that programmers like but aren't programming/maths at all.

If you're going to ask someone "which book?" try limit the categories they should give you an answer for...

The problem was well discussed in 2009 here : A tempest in a tty pot https://lwn.net/Articles/34382... The result was that after a heated debate, Alan Cox was blamed for allowing old code to stay because emacs would loose terminal output and Greg KH was simmoned to stepup as the TTY maintainer. The new TTY/PTY guys became James Simmons, the Frame-buffer guy and C. Scott Ananian, the former jack-of-all-trades for the One Laptop per Child Foundation. Curious enough it were not Linux server systems like RedHat Enterprise who have been vulnerable for almost 5 years, but the popular Linux desktop distro's like Ubuntu.

Those interested may look at LWN's report for a saner, more balanced view: http://lwn.net/Articles/593676/

See Daemon Managing Daemon. It was written in the early-00s for the Hurd, languished for the better part of a decade, and has been picked up again. It has a model kind of like systemd, only without the Windows braindamage (I mean come on, ini files as a programming language?). Development on DMD is pretty active now, and it's written in Scheme instead of C so mere mortals can hack on it. The design is pretty interesting, and makes extending things easy. E.g. imagine you run an openafs cell and need a service to grab Kerberos tickets and afs tokens at start. You can just register interest in the service in another service and have it Just Work (tm). From the looks of it, you may even be able to just write a single "Kerberize all the services" service. Better than sysvinit (oh joy, forking an init script) and better than systemd (oh joy, forking an ini-file-pretending-its-not-a-program)..

There are significant numbers of people who understand it just perfectly and have valid criticisms that are not bugs.

http://ewontfix.com/14/

The systemd team has pissed of Torvalds:
https://lwn.net/Articles/59368...

Additionally, they repeatedly deny that anyone should have a text log for any reason, dismissing criticisms as 'just hook in syslog *too* as an *optional* thing'. Basically systemd discards decades of sensibilities ecosystem to 'do it better', while throwing out the baby with the bathwater (ditching modularity and portable log data and such).

It's not just that 'if you don't like it, fix it'. People don't like the very fundamental aspects of the design that the systemd did *on purpose*.

This all sounds very very similar to the whole BitKeeper fiasco, where Andrew Tridgell watched the traffic between a real BitKeeper client and the server in order to determine the procotol used

Not really, according to this article, Tridg connected to the Bitkeeper server using telnet, then typed "help" and got most of the information required.

It's not "simply" though. The interfaces in OpenSSL and GnuTLS are not swappable APIs. We went over this a few years ago for PostgreSQL, and one of the major issues was having too many OpenSSL-isms in our code to swap easily.

Those of us who dislike bad open source licenses have been trying to kick OpenSSL out of projects for years now, and it hasn't gone anywhere but upward in adoption. I've been amazed at how often I see its advertising clause in the credits of video games I play.

Just found an example of what I mean;

In GTK+3.x a lot of work is going on to allow themes to make use of CSS. Thereby breaking the themes a lot, but eventually it will quiet down.

• write a test case
• implement the feature
• if the test case doesn't work then never release the software ever again until it does
• if you want to implement software without the feature give it a different name or at least major version number and allow both to be installed at the same time

This is fundamental. This is simple. This will get donations out of me.

As for us, asshole Feinstein look at us as if we are peons, slaves for the elites, that we do not have any right to enjoy the protection granted by the Constitution and the Bill of Rights, and that we ought to be stripped of everything, and kow-tow to her and her kinds.

I sometimes wonder how monsters like Feinstein get any votes at all while the likes of Feingold can lose to a climate change denier. We have only ourselves to blame.

I didn't vote for her. I voted for somebody else. Yet Feinstein was just, in 2012, reelected with the most votes any senator has ever received, ever.

I think humans are defective. Democracy works fine for small governments, like a village. It's problematic for a political unit so big that you can't travel from one end to another without special arrangements, like California, the 12th largest economy in the world. Democracy is a terrible idea for a country as large as the United States. It's better than any other idea we've tried so far, but there are just too many voices demanding too much attention for it to work well.

So, humans simplify. Most people stick to the 2 parties that they hear about the most. The media talk about the 2 parties that pay them the most. The major party candidates listen to the donors who donate the most. Larry Lessig hopes that campaign finance reform will fix democracy, but humans still need simplified choices.

I think humans can't reasonably manage something as large as the United States. The federal government needs to be scaled way down, or the United States split up, so more local decisions can be made about local issues. But, again, humans are defective, and for example people in New York are personally offended at the local education decisions made in Texas, so the federal government just keeps growing.

http://lwn.net/Articles/419822...

Startup speed is simply not an issue anymore. Your typical server is supposed to be up most of the time, your typical desktop or mobile device is sleeping or suspended when it's not running, and your embedded device only has very few services that it needs to start, to the point where even SysV init is overkill and you're better off with rc.conf or something similar.

That's incorrect.

The big excitement in servers is Elastic Compute. There, you do want servers that can boot up and shut down as quickly as possible, to handle varying demands. It seems that even Linux is considered to take too long, so some Linux kernel maintainers are making their own cloud OS that boots up even faster.

Desktops and mobiles do reboot sometimes. Fast booting was a major selling point for Unix during the age of The UNIX-HATERS Handbook. A bigger benefit for modern PCs is how systemd uses sockets and cgroups to control program state. And I thought the thread was about embedded.

There is more than one type of embedded device. In particular, I am annoyed at how home routers have progressed from, for example, the Netgear WGT624 which took about 15 seconds to boot, to now the Netgear R6300 which takes over a minute to respond to PING, and I'm not sure how much longer until it's fully functional. Sure, once it's configured and running, it's nice, but a typical setup could take several reboots and cause a lot of wasted time.

The R6300 has 128MB of flash and at least 128MB of RAM. That's a lot. Surely it can hold systemd.

The small and simple tools just don't mesh well enough for the more complicated problems.

http://lwn.net/Articles/576078/

Jolla Sailfish OS use systemd

I didn't think it was really strange, but a while back I saw some desktop computers running Firefox on Ubuntu in a coffee shop. This was the old GNOME 2 desktop, so it worked almost exactly like Windows, and the customers in the coffee shop just used the computers and it wasn't any big deal.

I have set up multiple family members, including both of my parents, with Linux computers. I seem to be the guy who gets called when a computer melts down with malware, so I'm motivated to get people off of Windows and onto something else.

These days my go-to distro is Linux Mint with MATE. I might switch back to Ubuntu once MATEbuntu is available... on the other hand, I have hopes for Cinnamon, so maybe in the future I'll be using Linux Mint with Cinnamon.

But for non-geek users, I definitely don't want a poor rip-off of Mac OS X (i.e. Unity) and I definitely don't want the desktop that is just different from anything else ever made (GNOME Shell).

The MATE desktop has the smooth polish of man person-years of work and the input of usability studies, and it's IMHO the best choice for non-geek users.

Newer versions of Linux can already do this. Using the integrity measurement architecture, module signing, and Secure Boot it's possible to have a system where almost any change is detected. I'm currently trying to get it all working on my machine right now, but it's slow going. Here's hoping that distros start shipping with this set up by default. http://lwn.net/Articles/488906...

A shorter term security measure that more users/Distributions should take is making the root partition read only. I know Android already does this, but it really does help. Something that I would really like to see is an easy to use per application firewall. Cgroups mean that I don't even have to worry about it just spawning a child process. Yes, I want to play this game in wine. No, I don't want it to access the internet. No, wine refuses to run it as a different user, much less one with lower privileges.

Take it from a former Solaris admin, difficult to maintain over-engineering is not the answer. It will fail, and users will hate you.

Question of the day: Why are single user smartphone OSs better at segregating processes than server OSs in the first place? Even while using basic UNIX features to do it?

These classic UNIX systems kind of need to roll over and fall into their graves already. I mean look at what you get with VMWare ESX, then look at iOS/Android, then look at say.. a RHEL-type classic UNIX server.

Where is a modern datacenter OS with the flexibility, availability, resource accounting, process separation of ESX, and the developer friendly frameworks and "It's The Apps Stupid" focus like iOS or Android?

Well, it's not with Linux...

Newer versions of Linux can already do this. Using the integrity measurement architecture, module signing, and Secure Boot it's possible to have a system where almost any change is detected. I'm currently trying to get it all working on my machine right now, but it's slow going. Here's hoping that distros start shipping with this set up by default. http://lwn.net/Articles/488906...

A shorter term security measure that more users/Distributions should take is making the root partition read only. I know Android already does this, but it really does help. Something that I would really like to see is an easy to use per application firewall. Cgroups mean that I don't even have to worry about it just spawning a child process. Yes, I want to play this game in wine. No, I don't want it to access the internet. No, wine refuses to run it as a different user, much less one with lower privileges.

And go where?

• Digg
• Reddit
• The Register
• Linux Weekly News

I've been here a long time as well.

http://lwn.net/ is the only news source I'm paying for.

http://lwn.net/Articles/564095/
Absolute best technical read on the Internet. Subscribe early, subscribe often.

I don't have any evidence that GCC was deliberately architected to prevent any functionality from being implemented - do you? I don't believe projects like this are ever designed to impose such kinds of restrictions - it's not Microsoft, it's GNU.

A great deal of thought goes into the GCC license and GCC APIs that are exposed to third parties. Have a look at this and this. It is true that GCC has been designed and licensed to prevent integration with proprietary tools; Stallman et al. will not tolerate having GCC wired into some proprietary, closed source IDE and that fact guides their decisions about what APIs GCC provides and how GCC is licensed.

The `proprietary' part was left out by the GP and others that make the claim that GCC is designed to prevent third party integration.

I don't have any evidence that GCC was deliberately architected to prevent any functionality from being implemented - do you? I don't believe projects like this are ever designed to impose such kinds of restrictions - it's not Microsoft, it's GNU.

A great deal of thought goes into the GCC license and GCC APIs that are exposed to third parties. Have a look at this and this. It is true that GCC has been designed and licensed to prevent integration with proprietary tools; Stallman et al. will not tolerate having GCC wired into some proprietary, closed source IDE and that fact guides their decisions about what APIs GCC provides and how GCC is licensed.

The `proprietary' part was left out by the GP and others that make the claim that GCC is designed to prevent third party integration.

For those interested in x32, I wrote an article for Linux Weekly News last May. x32 ABI support by distributions may have some information on x32 you might not have been aware of.

In short, I found it easy to use the experimental x32 architecture for Debian, and there are certain scientific apps out there that might get significant benefit from it. Web application accelerators like Varnish might also have something to gain by using x32.

One problem here is that the "multiple parties" are looking for holes to take advantage of, not to fix.
Another problem is that for example Linux is generating more holes per week than it is fixing, and the attitude sucks (https://lwn.net/Articles/538600/, https://lwn.net/Articles/313621/, etc).

If OSS were serious about security they would immediately use grsecurity and managed runtimes (JVM and like). I don't expect either happening anytime soon.

During the Automotive Linux Summit Greg Kroah-Hartman talked about the progress of kdbus.

He did a really poor job justifying the need for kdbus since he talked about QNX type messaging on Linux and how that was already provided by the SIMPL API in which Greg said "works well". Within that same article it is mentioned that the speed increase to D-BUS could be accomplished without moving it to the kernel. He did say that being in the kernel allowed for the order of messages to be guaranteed but it's debatable if message ordering is justification enough.

I don't really see this as something to get too upset about. Like most experimental things within the kernel, you can simply choose to recompile the kernel without kdbus. If Red Hat can live with the additional overhead within kernel space (even with the use of bloom filters to help with message classification and delivery) and support it then it probably won't make much of a negative impact. Red Hat is Gnome based and their architectural decisions are biased towards it anyways.

Sorry but your "finding" really don't match with the reality: http://lwn.net/Articles/551969/

Binder is "weird", Kroah-Hartman said. It came from BeOS and its developers were from academia. It was developed and used on systems without the System V IPC APIs available and, via Palm and Danger, came to Android. It is "kind of like D-Bus", and some (including him) would argue that Android should have used D-Bus, but it didn't. It has a large user-space library that must be used to perform IPC with binder.

Binder has a number of serious security issues when used outside of an Android environment, he said, so he stressed that it should never be used by other Linux-based systems.

http://lwn.net/Articles/551969/

What does he know anyway. If he knew more about kernel development he would be more offensive like Linus :)

hHe short version: http://lwn.net/Articles/551969/

At first, this sounds like the kernel developers have raided LP's "private stash", but it turns out the reason for kdbus is preceeds it - in fact in even preceeds d-bus itself. Specifcally, kdbus is intended to be a alternative version of Android's binder. Android doesn't use d-bus, because it didn't exist (or was too immature) back when it was concieved. While binder is in the staging tree, it'll never be part of the kernel proper for various - some fixable, other unfixable. Binder is not just a hard pill to swallow for the kernel developer, its a spiked ball the size of a fist in a bottle labelled "NOT TO BE TAKEN ORALLY".

There's a NEED for something like kdbus independt of systemd. We needs a new IPC type, like domain sockets, except with reliable multicast and filtering. Linux domain sockets do not support multicast, much elss reliable multicast. Approaches to add this have been tried: Both by directly adding multicast to domain sockets or by adding an ew address family (AF_DBUS), but patches adding that to unix domain sockets have been rejected, as has AF_DBUS.

No one suggesting putting the entire dbus-daemonm and protocol in the kernel with kernel XML parser (and so dbus-daemon will still be needed for authentication and the inital connection setup, but then steps out of the way after that), kdbus is "just enough" to implement an accelerated and robust message bus.

http://lwn.net/Articles/551969/

Linus is okay with it. Have to worry about Al Viro. :-)

Here is an updated talk by Greg K-H that he gave on KDbus, he posted this about 3 days ago. https://github.com/gregkh/presentation-kdbus

Let's stop all the FUD, and educate yourself on the reasons behind on this.

Why do you think that single process has anything to do with this ? The Mozilla developers clearly want to do this, it just is a massive effort to change their code to suite the model.

Also Mozilla has been working on multi-process again this year. First for Firefox OS (where every Firefox OS phone that shipped is using it) and recently for normal Firefox.

http://lwn.net/Articles/576564/

Anyway I've seen Chrome UI lock up as well with a busy tab. So I don't know why people keep bringing it up (other than security of course).

The advantage of asm.js is, it runs in a browser you already have. It is just about skipping the type inference code (a form of guessing) and having the JIT part of the Javascript engine not having to deal with dynamic types.

That means asm.js can eventually be as fast as Java or .Net. Which for certain things can be close to or even faster (because of runtime optimizations) than compiled native code.

Really, usually the slowest parts of Javascript tend to be: the DOM and time to download.

Nope - that'd be Secure Boot. There's nothing inherently wrong with UEFI.

Au contraire. See e.g. the rants of people who have to implement UEFI support in Linux: http://lwn.net/Articles/444666/

This patch allocates the boot services regions during EFI init and makes sure that they're executable. Then, after SetVirtualAddressMap(), it discards them and everyone lives happily ever after. Except for the ones who have to work on EFI, who live sad lives haunted by the knowledge that someone's eventually going to write yet another firmware specification.

http://lwn.net/Articles/570558/

They should just contribute their articles to Linux Weekly News so we don't need to setup another subscription.

You should look at LWN. It's a news site maintained by Jonathan Corbet, who co-authored the popular 'Linux Device Drivers' books for 2.4 and 2.6 kernels, and maintains a weekly newsletter about what currently happens in the Linux community. It also maintains archives, which gives it an index covering the widest range of topics in the Linux kernel.

You can read the 2.6 driver book on LWN as a starter, as there is no radical departure between Linux 3.x and the 2.6.x series. You can even grab an older copy/branch of the kernel like 2.6.32 and run it in a VM, as then there will be no difference between the source you use and what the existing books contain.

You should look at LWN. It's a news site maintained by Jonathan Corbet, who co-authored the popular 'Linux Device Drivers' books for 2.4 and 2.6 kernels, and maintains a weekly newsletter about what currently happens in the Linux community. It also maintains archives, which gives it an index covering the widest range of topics in the Linux kernel.

You can read the 2.6 driver book on LWN as a starter, as there is no radical departure between Linux 3.x and the 2.6.x series. You can even grab an older copy/branch of the kernel like 2.6.32 and run it in a VM, as then there will be no difference between the source you use and what the existing books contain.

looks like this is what i was thikning of http://lwn.net/Articles/542642/ http://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01

No joke; I meant http://lwn.net/Articles/45019/, after SCO had claimed every Linux user in the world owed them US$ 699, and had started to remove all evidence of their fraud from their own website in 2003; it was still in the IA Wayback Machine, but then SCO demanded that the IA remove those copies as well, because it would be detrimental to their court cases if copies of proof that they were liars and frauds still existed on the 'Net :-(

Yes it leads to real bugs - Brad Spengler uncovered one of these issues in the Linux kernel in 2009 and it led to the kernel using the -fno-delete-null-pointer-checks gcc flag to disable the spec correct "optimisation".

html5 can replace flash, check this link on how firefox can replace flash

still not perfect, but getting better. it will replace flash, just like PDF.js can replace PDF plugins in browsers

For those who don't know, PDF.js is the "built in PDF viewer" in recent Firefox builds. It's not an Adobe-provided thing. It's a new Firefox feature to convert PDF to HTML5 using Javascript using a mozilla foundation "community driven" javascript project.

I gleefully support the goals of the project.

And yet I regret to report that from my work-related test cases, PDF.js is badly broken with long technical documents with diagrams. :-(

For those who don't know, you can disable it!
1. Type about:config in the address bar and press Enter.
2. Press the big button to bypass the warning.
3. In the Filter bar, paste pdfjs.disabled
4. In the search results, double-click pdfjs.disabled to set its value to true
5. Restart Firefox for the changes to take effect.