Slashdot Mirror

So in other words, Linus has decided to deliberately damage the kernel (by introducing unnecessary instability) in order to make it harder for people to write software that uses it.

There are plenty of good reasons not to have a stable internal kernel interface. Also, keep in mind that even though the fact that the kernel API may change inbetween versions may be described as "instability", it doesn't translate to an instability in the OS.

A small addendum to my above comment:

I have now read (yeah, yeah, read before replying -- bite me) this article about why a stable kernel interface is a bad idea. Some very, very good points here that, in essence, I have trouble debating from a technical standpoint. Ok, tough to keep things up-to-date, developers don't want to have to keep the old interfaces in place because it makes a maintenance nightmare, and you possibly sacrifice the stability of the OS as a whole if you do.

Well, that's groovy. I can dig that in ways that shovels can't even begin to contemplate.

The thing that always strikes me, though, is this: The kernel is developed on the F/OSS idealistic system, yet it is striving to break into the mainstream. However, the mainstream simply doesn't work that way. In the Real World(tm), you have to have backwards compatibility, you have to have systems that don't break APIs and standards very often, and you have to have an ease of development for anyone and everyone who wants to contribute to it. Why? Because this is how business works. Business doesn't always have time to stop and, "Do it the right way." Companies can't employ kernel hackers to work 24/7 on keeping a single driver up-to-date because the kernel changes all the time. It's like having a coworker that continually changes the function parameters of the code I'm trying to interface with -- I'd fucking kill him! I don't have time for that shit, and I suspect that's the attitude of many corporations who would otherwise contribute to Linux.

Same old, same old, folks. Idealisms meet reality, big mess ensues. I hate sitting on the fence between the two, but I see good points on both sides. Resolving the conflicts, however, isn't always cut-and-dried.

GKH raises good points about how a stable binary driver interface will open the floodgates to both security problems and to update/maintenance problems. As it stands right now, Linux kernel developers can quickly respond to threats because they are able to fix all instances of a given problem, in all drivers, at the same time. If they do not maintain this flexibility, either some drivers stop working unexpectedly when security fixes are made and the interfaces are forced to change (making Linux appear "unstable") or backwards compatibility must be maintained making the Linux kernel grow over time (whenever a new interface has to be written to address flaws in the old interface).

Yes, abstraction is good...but, in this case, stability, the perception of the user and maintainability (where the *real* costs lie) must win over abstraction. Most of the kernel developers are not being compensated; how often do you think that backwards compatibility is going to be maintained? Its not. Right now, fixes are accomplished because it is easy to accomplish - global search and replace, etc. Make it difficult and it just won't be done.

Manufacturers want binary drivers because they want to play for free - they want all of the benefits of open source without any of the costs. Not cool.

Please read The Linux Kernel Driver Interface (all of your questions answered and then some) by the same author before commenting...

Read lines 44 through 46 of init/calibrate.c.

It sounds like you are unable to build the complete system and run it, since you're missing functionality. This removes the possibility of using runtime tracing tools.

The first thing I would do is run something like Doxygen over it to generate a cross-referenced description of the structures. It won't give you a global view of things, but it will give you a decent browsable view of the code itself. Another response mentioned GNU GLOBAL which may work better for you. Yet another possibility is LXR, though it may not work as well in C++. Regardless, a nice thing about Doxygen is that, when used with GraphViz, you can get useful diagrams generated showing class containment and file inclusion graphs.

After you have that, get out your paper and pencil, and start drawing and manually tracing things. That's how I go about coming up to speed on new code I can't execute and step through. Eventually transfer that knowledge into a text file (or, nowadays, a wiki) so that others can benefit from it.

"If you use the functions from the standard library, you aren't required to comply with the GPL, only if you redistribute and/or modify the library."

Can you point to the part of the MySQL license that says this? If you can't then I think I would prefer to take the word of /usr/share/doc/libmysqlclient12/copyright over yours. ;)

If MySQL were licensed under the GNU LGPL then you would be right... but it's not. If you link against libmysqlclient, then the derivitive work you have created must be licensed under the terms of the GPL.

"It's like saying that if you build your application on top of Linux that you are required to comply with the GPL. Only if you make modifications/distribute/copy the Linux kernel for your project would this requirement hold."

Not at all. I refer you to Linus' statement at the top of the Linux COPYING file:

NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work".

I see no such similar statement in MySQL's copyright file.

This has been written about at length - check Documentation/stable_api_nonsense.txt in the kernel tarball, for example.

I believe we can learn a great deal on how to write good comments by studying the kernel coding style at http://lxr.linux.no/source/

Complaining in Comic Sans is a lot like attempting to network your home office using the standards outlined in RFC 1149. It is indeed possible, but all that you do is make people laugh their heads off in astonishment

Pigeon Packet Transfer Protocol

Carrier Pigeon Internet Protocol

Pictures from the worlds first rfc 1149 implementation.

Pigeon Packet Transfer Protocol

Carrier Pigeon Internet Protocol

Pictures from the worlds first rfc 1149 implementation.

Of course, there are a lot of things that programmers can do to make code easy to read, but I'm quite interested in the things that computers can do to make code easy to read.

For example lxr.linux.no is great but it would be even better if it was integrated into the editor. They say etags is the same, but I've never been able to make it work.

Another thing that would be great would be color coding for bugginess. There are a bunch of different static analysis tools that could generate a bugginess value for each line of code. Also really picky indent color coding would be nice.

Another thing would be better integration with the CVS. Something like this perhaps. It would be handy to know if a bug only affected 2.6 or if it went back to 2.4 as well.

Those are some ideas. Gotto run.

Which was implemented by Bergen Linux User Group in 2001 :)

http://www.blug.linux.no/rfc1149/

That's strange. I thought that issue would have been worked out by RFC 1149 or CPIP. You would think that 40 minute transit times would be a quick ping when using the Carrier Pigeon Internet Protocol (CPIP).

if you have any more doubts - look at the configuration screen. Also peek at the commented code - looks familiar ?. (linux, etc..)

By Norwegians, no less.

The problem is that not all Linux kernel sources are licensed in the way that you have (with the any later version addendum). In fact, not all kernel sources are even under the GPL; here is an example of a file that's under the MPL (Mozilla Public License) and GPLv2 (only). Then there are the files (example provided) that simply state the license as GPLv2 without the "or later".

In other words, the Linux kernel has many, many copyright holders, and many, many different variations of the license language in the source files. If Linus had only accepted files with a certain license language, that would be one thing, but I think he was more worried about the technical aspects than the religious war aspects of the kernel.

In short, you can't just promote the kernel to GPLv3, and I, for one, don't really see what the outcome is really going to be...

The problem is that not all Linux kernel sources are licensed in the way that you have (with the any later version addendum). In fact, not all kernel sources are even under the GPL; here is an example of a file that's under the MPL (Mozilla Public License) and GPLv2 (only). Then there are the files (example provided) that simply state the license as GPLv2 without the "or later".

In other words, the Linux kernel has many, many copyright holders, and many, many different variations of the license language in the source files. If Linus had only accepted files with a certain license language, that would be one thing, but I think he was more worried about the technical aspects than the religious war aspects of the kernel.

In short, you can't just promote the kernel to GPLv3, and I, for one, don't really see what the outcome is really going to be...

This clause was added in the 2.4.18 version of the file It did not exist prior to that. This seems that this would create a problem. If I submitted my work into the Linux kernel prior to 2.4.18 I would have submitted my work under the generic GPL and applied the license allowing for future versions of the GPL to be used. For Linus to make a blanket change to the licensing would violate the copyright holders intention and would be essentialy a violation of the GPL. Linus may have avoided this by securing certain rights from the copyright holder when the code was submitted. I doubt that happened. Also, any derivitive works that changed the licensing of the code to be more restrictive would seem to violate the copyright holders license.

The problem gets worse, I think, because if I submitted code after the 2.4.18 release I would have submitted my code under a license that restricted my code to be license under GPL v2 only. Which would mean there is code in the kernel that is licensed under two different sets of restrictions.

Actually, yes. Try browsing the source online and you'll see that the "make functions that do one thing only and do it well" and "keep functions small and break them up if they get large" rules make even the most complex concepts (for example the NUMA stuff) quite understandable.

I have never seen as complex a system - in any language - as easy to understand.

how about LXR?

I've been using it to browse linux source code lately: here

from the site:
A general purpose source code indexer and cross-referencer that provides web-based browsing of source code with links to the definition and usage of any identifier. Supports multiple languages.

except for lack of syntax hilighting, it works well.

-metric

LXR (or linux cross reference) was originally designed to cross reference the Linux kernel, but does C code in general. Check it out at their website.

lxr (http://lxr.linux.no/) was dveloped with the kernel in mind, but now it works with any C, C++, python, perl and other laguajes (those supported by exuberant-ctags). I used it in several projects and, in conjunction with tabbed browsing, I think it's all I need. Dependencies are: mysql, perl, apache, exuberant-ctags.

Indeed, http://lxr.linux.no/source/drivers/char/drm/drm.h :)

Wow, hey, you're right...

Configure was originally written by Raymond Chen...

Interesting....

Wow, hey, you're right...

Configure was originally written by Raymond Chen...

Interesting....

It wouldn't be the first time somebody implemented an April fools RFC.

Please explain how Linux software and transmit data via a wireless network without any hardware.

There: RFC1149/CPIP

By the way, WAN has nothing to do with wireless, it means "wide area network". I seem to recall the official wireless acronym/hip term is "WiFi" (which is a bitch because it always reminds me of my divorce. That's why I call them "802.11b", or *gasp* "wireless" cards).

RFC2529 updates RFC1149. Anybody tried it out yet?

> Isn't that what "real" programmers would do?

Or what about keeping the code blocks small and concise? See Linux kernel coding style Chapter 4.
If you have to scroll some pages to find the corresponding closing tag, something has gone wrong.

But I've to admit, that I use code folding myself, which shows, I'm not a real programmer. But I also prefer Emacs to vi, which only confirms the fact I'm a quiche eater.

still held by Norway

Don't say that, somebody will do it, like the crazy norwegians that actually implemented the April Fools RFC 1149 - Standard for the transmission of IP datagrams on avian carriers.

Actually you almost already can. There are programming environments where you can write programs on a Pocket PC, and those have handwriting recognition. It would scratch and stain the touch-sensitive display if you used a fountain pen instead of a plastic stylus though.

#define RED_HAT_LINUX_KERNEL 1

"black for ones, white for zeros"? You are aware that you just outed your crypto key here? And why not upgrade to RFC1149 compliance while you're at it.

You can browse the 'old' source Here but it doesn't have up to the 2.6.5.

The highest it goes is 2.6.1. But it has all the architectures.

Yes, but RFC 1149 was eventually implemented.

but this one is for real 100%

They compare it to the implementation of RFC1149 in Bergen by BLUG,however this is clearly a breach of 1149.

From RFC1149:

[snip]
Frame Format

The IP datagram is printed, on a small scroll of paper, in hexadecimal, with each octet separated by whitestuff and blackstuff. The scroll of paper is wrapped around one leg of the avian carrier. A band of duct tape is used to secure the datagram's edges. The bandwidth is limited to the leg length.
[/snip]
See. One IP datagram, one scroll of paper. The community demands interoperability tests if CPIP is ever to become a standard


*sigh*

Wohooooo, now that we have two independent implementations, perhaps we can get RFC 1149 on the standards track?!?!

And here's the implementation by the Bergen LUG.

Here's the output (NOTE THOSE PING TIMES):

vegard@gyversalen:~$ ping -i 900 10.0.3.1
PING 10.0.3.1 (10.0.3.1): 56 data bytes
64 bytes from 10.0.3.1: icmp_seq=0 ttl=255 time=6165731.1 ms
64 bytes from 10.0.3.1: icmp_seq=4 ttl=255 time=3211900.8 ms
64 bytes from 10.0.3.1: icmp_seq=2 ttl=255 time=5124922.8 ms
64 bytes from 10.0.3.1: icmp_seq=1 ttl=255 time=6388671.9 ms

--- 10.0.3.1 ping statistics ---
9 packets transmitted, 4 packets received, 55% packet loss
round-trip min/avg/max = 3211900.8/5222806.6/6388671.9 ms

I can't paste in the logs, but that was a link to them, and here is the info re: the implementation.

But, to answer your question, avg time was 5222806.6ms.

I can't paste in the logs, but that was a link to them, and here is the info re: the implementation.

But, to answer your question, avg time was 5222806.6ms.

Ooh - one more neat OS feature that lots of people forget. AmigaDOS always had a ram disk - and it was dynamic. It was called RAM: and you could put anything you liked in there (as long as you had memory) - if there was nothing in there it didn't use any system memory. Thats something even the most modern release of OSX or Linux don't have.

Linux has tmpfs.

My bad %-) For the benefit of those who don't RTFRFCs, RFC1149 - Standard for the transmission of IP datagrams on avian carriers. Laugh, if you must, but RFC1149 has been successfully implemented. Need QOS? No problem - RFC2549.

I wanted to provide a "sample implementation" link as a supplement to your post, but I can only find the first implementation of the more primitive predecessor, rfc1149.

Well, I guess if they were ICMP packets complying with RFC 1149, they probably would hurt if thrown hard...

Way to go MS - stifle creativity, advancement, technology.

I'm choosing to reply instead of moderate, because this is a *huge* pet peeve of mine. I've always thought NT-the-kernel was pretty elegant (especially compared to some *cough* Unix clones).

Actually, the actual Nt_ interfaces *are* documented, but (afaik) incompletely, and without source it's really of very limited utility.

In their quest for One True API (Win32 and now WinFX) they do seem to have killed off all innovation on top of one of their most technically impressive assets.

I had hoped the MSDN academic alliance and shared source licensing would encourage some work, but as long as MS adopts a more liberal download-from-website model for source licenses, innovation on top of the NT kernel is likely to remain a pipe-dream. (When the competition (Linux) is available nicely cross-referenced, you'd have to be crazy to fill out the paperwork for an NT source license.)

I'd love to browse around sources without having to download a tarball using only my web browser.

That is possible. The best place I know is The Linux Cross-Reference.

Pigeons were used instead of email in India until 2002.

Avian carriers are used commercially even today to deliver digital photographs.