Slashdot Mirror

The Bergen Linux User group have actually done this for real (for all of 9 packets though), and it was also discussed here. Or course, that's now old hat as it doesn't implement QoS or IPv6oAC.

http://lxr.linux.no/linux-old+...

Why would anyone use RFC1149, when it's been essentially superseded by RFC2549? I mean, really!

That's news to me. I see almost every graphics device in the kernel: http://lxr.linux.no/#linux+v3.9.2/drivers/video/
Unless you have hardware that doesn't have an opensource driver, of course. Because they can't put closed source into the kernel. You can pin that on specific gpu makers, not linux.

Huh!? Your first assumption is incorrect!
Listening to music while system is checking the email in background and you browse a site IS taking advantage of multicore systems on desktop OR a phone, as long as the OS scheduler is multi-core aware. Phones are multicore to accomplish such parallel tasks.
Applications don't need to be aware of multicore. OS scheduler will take care of that.

But Linux has zero UNIX-sources in it, and hence is not UNIX.

O RLY? ;)

how many projects ship with compiler settings that use -O3 by default? The kernel does as it is going for the ultimate in performance

You are pulling "facts" out of your ass.

The kernel is built by default with O2, or optionally Os as a configure option.

You do not have the slightest clue what you are talking about in this, or any other post I have seen from you.

"Is using code snippets from the internet really an issue?"

It is if you take it from here, for example.

Even modern operating systems are largely written in HLLs

I guess you consider C a High Level Language. I think a LOT of people would seriously disagree with you.

I don't care what OS you are using. Those are written in C and Assembler. Look HERE for yourself.

You are not going to find any php, python, java, perl, ruby etc. etc. there, not a line of it.

Mostly your comments are pointless. Most really "good" HTML is still written by hand. It may get spewed from some content management system, but who do you think wrote all the HTML and CSS for those? Do you think JOOMLA magically coughed it up?

You are seriously clue impaired.

IPoAC support is usually done at the OS level, not the application level.

Try looking through this page on a standards-compliant implementation of IPoAC. Includes a tarball of the source used.

wait, did anyone add DRM to it yet?

Yes.

It would need open source hardware for that too, or at least open source specs. There is way too many issues to make that happen, from hardware vendors wanting to protect their intellectual property and a hostile community to anything closed source. From the programming standpoint this is the kernel developers official stand: http://lxr.linux.no/linux+v2.6.37/Documentation/stable_api_nonsense.txt , or let me put it another way, we don't want your stupid driver cause we have a so much better architecture, so you either include it with our kernel or begone. Funny enough, most companies have chosen the second option. Typical Linux mentality that keeps the desktop system from going forward cause you need to be l33t. Sorry if my post offends a lot of Linux developers but try to take it as constructive criticism to leave politics aside and just provide an alternative to something that works without having to suffer a vendor lock-in (namely nVidia).

That's exactly what I thought too! Good ol' RFC1149.

Sorry, posting error. Should have ended with:

Linux wireless is now pretty good, -after- the api was changed and the drivers refactored. This is pretty much the process happening now with the graphics drivers. Most points most people bring up have been addressed pretty conclusively by the old unstable api doc http://lxr.linux.no/#linux/Documentation/stable_api_nonsense.txt

Sorry about that.

Stable API? Argh, this old argument. Been addressed so many times there is a doc in the trunk.
http://lxr.linux.no/#linux+v2.6.37/Documentation/stable_api_nonsense.txt

Exactly, this file from the kernel docs explains the practical reasoning of not having a stable ABI in detail - http://lxr.linux.no/#linux+v2.6.36/Documentation/stable_api_nonsense.txt

Not only is stability and being able to integrate the drivers better within the kernel a key part of having the source for the drivers. If some poor person gets stuck using a piece of once 'in' hardware that the manufacturer has long since abandoned supporting - the issues can still be fixed. Or will have been fixed before the hardware became obsolete.

It also allows people who can code to help stabilise the drivers. Which essentially means the user has a better impression of the hardware. So the manufacture can benefit significantly from the source for that driver being available.

The reasons are practical - not only for stability but for longevity of support well after the manufacturer has long stopped caring. Having a stable ABI did nothing for Windows XP when the driver ran riot and took down the entire system in an all too common video driver BSOD.

http://lxr.linux.no/linux/Documentation/stable_api_nonsense.txt

I know the feeling—I lucked out and got init/main.c. Check out the text version: it's nothing but includes for the first three minutes.

The "Linux Radio" name should be reserved for something that does, say, interviews with kernel developers, distro maintainers, and summaries of mailing list results. I'm sure there are enough people in the community to garner a worthwhile audience.

The problem is that there's also an implementation.

I wonder if they're going to ban carrier pidgeons as well since they also allow connections to the net.
http://www.blug.linux.no/rfc1149/

They seem to be claiming that it would allow somone to set up an unofficial ISP.

By that kind of logic just about anything at all could be used to connect to the internet.

If I was a big electronics geek I could theoretically set up a pair of toy laser pointers + some light sensors to allow me to relay internet traffic by line of sight (with crappy bandwidth) but that wouldn't be that much more complex than what they seem to be talking about.

Hell you could set up a piece of string with some motors and sensors to relay ip data IPOP (IP Over Pullies)

During a co-op job I worked on a very large multi-platform app (several million lines of code)

the team had an LXR setup to do project wide searching, however it was aging and having problems, and is a bit difficult to work with.
As a side project intended for a report once I was back on campus, I set up OpenGrok, which worked brilliantly, and was reasonably easy to configure, and nicer to use once we got it setup. The team liked it enough that they switched to that permanently.
both are open source, and were built to handle large code bases (LXR was built for the linux kernel, OpenGrok for when Sun open sourced Solaris).

Another one I had tried, which was very easy to setup was Gonzui. It's also open source, but didn't really handle the huge codebase as well as OpenGrok or LXR. For under 100k lines, it's probably fine, and the ease of setup may be worth it.

All three provide a web interface, and do indexing as a separate process from search, so we would re-index the code base nightly. works very well for larger teams, might be overkill for what you need though.

When I'm coding in C, I adopt the best practices from http://lxr.linux.no/

The first example that the author sites as an example of poor programming is "idiomatic" C for traversing a linked list. Also, if the author can't deal with pointers, he should not only avoid C, but also C++ and stick to Java or his beloved PHP and JavaScript. Siting that he found a standards document so flugly as GNU "helpful," doesn't help his argument.

First, learn C as C. Don't be scared, it's just like this "whole nother language" that's different from JavaScript. It can be used quite safely. If it couldn't, your beloved operating system of choice, that is likely written in C, just wouldn't work at all.

Second, draw your learning of the language not from standards documents, but by immersion in books like "The Practice of Programming." You will then find out that code like "for(ss = s->ss; ss; ss = ss->ss);" can be used without fear of misunderstanding because it is "idiomatic." People that know C will fully understand what it is doing. Writing a comment here is pointless and will degrade the readability of the code.

Third, add one further standards document to the list:

http://lxr.linux.no/#linux+v2.6.32/Documentation/CodingStyle

And learn that Coding standards are only as effective as those that use them.

The point you are missing is that "bare-metal code" is assembler, regardless of how much effort is involved.

I again have to point you to Linux or *BSD, these OSes have real time drivers in C. I don't recall seeing *any* peripheral driver in Linux that is not C. Practically all assembly code is under arch/ which means bootstrap, memory initialization and main timers. The rest is C.

Go ahead and write a real time driver in C, let me know how it works for you.

I'm doing this right now, and it is a very usual thing for me to do because I work on firmware for slower microcontrollers that run at clock speeds from 1.8 to 16 MHz. I have tons of peripherals in the MCU, and they must be serviced on time. A typical MCU project is a real time design. Sometimes I profile the code by connecting an oscilloscope to some spare pins and check that I have enough time in critical parts of the code. And *all* the code is C, compiled by avr-gcc 4.3.2. I have maybe 0.1% of the code that is in assembler, and that is stock macros that come with avr-gcc.

To illustrate, here you can see the lowest level of avr32 support, and you can observe how many LOCs are in .S and how many are in .c files. If still not convinced, visit mm/ and see what language the do_page_fault() is implemented in; that is one of most performance-critical pieces of code. C today is the "bare-metal" language of choice, and it works well in that role.

The point you are missing is that "bare-metal code" is assembler, regardless of how much effort is involved.

I again have to point you to Linux or *BSD, these OSes have real time drivers in C. I don't recall seeing *any* peripheral driver in Linux that is not C. Practically all assembly code is under arch/ which means bootstrap, memory initialization and main timers. The rest is C.

Go ahead and write a real time driver in C, let me know how it works for you.

I'm doing this right now, and it is a very usual thing for me to do because I work on firmware for slower microcontrollers that run at clock speeds from 1.8 to 16 MHz. I have tons of peripherals in the MCU, and they must be serviced on time. A typical MCU project is a real time design. Sometimes I profile the code by connecting an oscilloscope to some spare pins and check that I have enough time in critical parts of the code. And *all* the code is C, compiled by avr-gcc 4.3.2. I have maybe 0.1% of the code that is in assembler, and that is stock macros that come with avr-gcc.

To illustrate, here you can see the lowest level of avr32 support, and you can observe how many LOCs are in .S and how many are in .c files. If still not convinced, visit mm/ and see what language the do_page_fault() is implemented in; that is one of most performance-critical pieces of code. C today is the "bare-metal" language of choice, and it works well in that role.

The point you are missing is that "bare-metal code" is assembler, regardless of how much effort is involved.

I again have to point you to Linux or *BSD, these OSes have real time drivers in C. I don't recall seeing *any* peripheral driver in Linux that is not C. Practically all assembly code is under arch/ which means bootstrap, memory initialization and main timers. The rest is C.

Go ahead and write a real time driver in C, let me know how it works for you.

I'm doing this right now, and it is a very usual thing for me to do because I work on firmware for slower microcontrollers that run at clock speeds from 1.8 to 16 MHz. I have tons of peripherals in the MCU, and they must be serviced on time. A typical MCU project is a real time design. Sometimes I profile the code by connecting an oscilloscope to some spare pins and check that I have enough time in critical parts of the code. And *all* the code is C, compiled by avr-gcc 4.3.2. I have maybe 0.1% of the code that is in assembler, and that is stock macros that come with avr-gcc.

To illustrate, here you can see the lowest level of avr32 support, and you can observe how many LOCs are in .S and how many are in .c files. If still not convinced, visit mm/ and see what language the do_page_fault() is implemented in; that is one of most performance-critical pieces of code. C today is the "bare-metal" language of choice, and it works well in that role.

You can search for Google in http://lxr.linux.no/#linux+v2.6.31/

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

In case you were curious.

But I will anyway
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

from http://www.blug.linux.no/rfc1149/pinglogg.txt

If the disk is powered off for many minutes (for example ten minutes) then the savings compared to the cost of spin up will be substantial (it looks like the pay off starts at around 10 seconds after the hard disk has been put to sleep if you read what is written in Extending Battery Life with Laptop Mode). It may even be possible to sleep the disk for longer if everything the user needs is cached (e.g. listening to music sequentially with a big buffer). The killer is that all all those spin ups and spin downs cause increased wear and tear. As such the problem is knowing when it is safe to spin the disk down such that it won't be immediately spun back up again (this may be solvable by forcing a long writeback time at the risk of bigger data loss). See laptop-mode.txt for some examples.

Also, their lawsuit is not going too far, unless they personally are the copyright owners of the code. Just having a violation is not enough. The copyright owner needs to sue them for it. It's not enough for someone who have heard about the work to sue them.

From http://duff.dk/viasat/ (TFA)

August 16th, 2009 - It has been brought to my attention that I do not state which part of the GPL code I am claiming copyright ownership on. I have some patches in the Linux kernel and a direct copyright notice in e.g. therm_adt746x.c. However my patches alone are not going to make a very strong case and it is my hope that big contributors to busybox and uClibc will help out making a bigger group of people who had their copyright violated. I have already contacted several people who have very clear violations of their copyright in the product, and we are looking to sue on their behalf too. But let me please be very clear about the fact that I would rather this case could be settled in a peaceful manner.

Oh, found the code on lxr. It looks like Linux kernels up to 2.6.29.6 are NOT affected, and this is a vulnerability introduced in 2.6.30 due to a fairly significant rewrite of tun.c. Linux 2.6.30 was released in Jun 9, 2009, just a month ago. Funny the tun.c rewrite was not mentioned in the set of changes for 2.6.30.

I think this example actually shows a forte of Linux as open source. New vulnerability is found very quickly after "new" code is released.

Oh, found the code on lxr. It looks like Linux kernels up to 2.6.29.6 are NOT affected, and this is a vulnerability introduced in 2.6.30 due to a fairly significant rewrite of tun.c. Linux 2.6.30 was released in Jun 9, 2009, just a month ago. Funny the tun.c rewrite was not mentioned in the set of changes for 2.6.30.

I think this example actually shows a forte of Linux as open source. New vulnerability is found very quickly after "new" code is released.

If we ever do get routing by carrier pigeon

We did get routing by carrier pigeon. And yes, sockets did handle it just fine.

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

no one here with a really special and specific task that needed linux?

at least _my_ reason to install a linux on my pc was http://www.blug.linux.no/rfc1149/ - I was really curious and used this later for an university project (unfortunately we had no access to carrier pigeons but everything else worked).

I used some Suse distribution and to be honest: I only stayed after that with linux as I wasn't willing to see the (at this time) inferiority of linux compared to win2k :)

Yes, VLC has a bad habit of only using its own codecs (even when "Use System Codecs" is selected)

Well somebody needs to patch that up, then.

I happen to have an online lxrcross reference of the new VLC 0.9.9 source code here, and you can generate a diff based on editing the code online. Edit the corresponding file, email/check in the .patch generated (from the "edit" link to the right of the file) and bam, bug fixed.

There are a few spots of the kernel that do use hand crafted SSE assembly (a quick glance says RAID calculation is one area (also here) and a particular crypto routine is another) but it is quite rare. Up until SSE4, SSE was really targeted at multimedia applications that contained a lot of floating point arithmetic. Generally floating point is avoided within the kernel so the maintenance pain of crafting an SSE optimised routine along with generic C version would not be worth it. Seemingly when you go to write assembly these days you have to account for the following:

• Are you smarter than your compiler?
• Will you still be smarter than it in a year's time?
• Is it worth the time (both the initial and the maintenance time) to write the routine twice (in assembly and in generic C)?
• Will your assembly still be faster when new processors with different properties come out?

Also don't conclude that just because the kernel doesn't contain many handcrafted SSE routines that no SSE instructions will ever be emitted by the compiler (assuming you've told it that you have a CPU that can cope with them). I believe very new versions of GCC (4.3 and above) have the just gained the ability to emit SSE4 instructions.

There are a few spots of the kernel that do use hand crafted SSE assembly (a quick glance says RAID calculation is one area (also here) and a particular crypto routine is another) but it is quite rare. Up until SSE4, SSE was really targeted at multimedia applications that contained a lot of floating point arithmetic. Generally floating point is avoided within the kernel so the maintenance pain of crafting an SSE optimised routine along with generic C version would not be worth it. Seemingly when you go to write assembly these days you have to account for the following:

• Are you smarter than your compiler?
• Will you still be smarter than it in a year's time?
• Is it worth the time (both the initial and the maintenance time) to write the routine twice (in assembly and in generic C)?
• Will your assembly still be faster when new processors with different properties come out?

Also don't conclude that just because the kernel doesn't contain many handcrafted SSE routines that no SSE instructions will ever be emitted by the compiler (assuming you've told it that you have a CPU that can cope with them). I believe very new versions of GCC (4.3 and above) have the just gained the ability to emit SSE4 instructions.

There are a few spots of the kernel that do use hand crafted SSE assembly (a quick glance says RAID calculation is one area (also here) and a particular crypto routine is another) but it is quite rare. Up until SSE4, SSE was really targeted at multimedia applications that contained a lot of floating point arithmetic. Generally floating point is avoided within the kernel so the maintenance pain of crafting an SSE optimised routine along with generic C version would not be worth it. Seemingly when you go to write assembly these days you have to account for the following:

• Are you smarter than your compiler?
• Will you still be smarter than it in a year's time?
• Is it worth the time (both the initial and the maintenance time) to write the routine twice (in assembly and in generic C)?
• Will your assembly still be faster when new processors with different properties come out?

Also don't conclude that just because the kernel doesn't contain many handcrafted SSE routines that no SSE instructions will ever be emitted by the compiler (assuming you've told it that you have a CPU that can cope with them). I believe very new versions of GCC (4.3 and above) have the just gained the ability to emit SSE4 instructions.

This bit:

echo 0 > /proc/sys/vm/drop_caches

doesn't actually do anything. See the relevent code here.

More importantly, kernel developers believe the drop_caches mechanism to be unsafe. It is a hack to permit easy benchmarking and other testing.

I must agree with the the GP; Linux VM behavior has been and continues to be poor. I particularly dislike the way inactive code pages are removed to buffer IO when there is clearly no reason to do so. You suffer this every time you copy a large file.

They use a European implementation of an American technology.

Note that RFC 1149 has been implemented and publicly demoed.

The ping times were a bit longer than most of us are accustomed to. But there's serious talk of extending the Internet to various space probes, and that will make the avian carrier protocol look speedy in comparison.

One requirement of this, would be to build out driver stubs, so that there would be standardize the communication between the kernel and the drivers.

Read: stable_api_nonsense.txt

C language doesn't do exceptions for example and another one is that in Linux kernel module development they suggest to use goto in their coding style for cases like when you have mutliple exit points in a function and need to do some cleaning before returning. Doing anything else would just add code bloat and then the compiler would have to waste time optimizing it all down to Esentially a goto / jump instruction.

- Coding Style Reference

Sadly, something being in the mainline kernel is no guarantee of avoiding bit-rot. I've been maintaining an elaborately modified version of the Cyclades PC-300 driver for years for precisely that reason. The SMP startup code on sparc64 has a race condition involving a shared buffer for passing params into PROM calls; I know this has been in the current kernel for at least the past year, but I believe it can only occur even in principle on machines with at least three processors. In practice the probability of a conflict rises with the number of processors; I have only been able to demonstrate it using at least five, and the 12-CPU E4500 I originally encountered it on seems to have only a single-digit-percentage chance of booting without a patch to acquire prom_entry_lock at the appropriate point.

Now, it seems hard to imagine ReiserFS will decline to that level of obscurity any time soon, but it certainly is possible for code in the mainline kernel to stay broken for a long time.

Linus Torvald Linux Kernel coding style http://lxr.linux.no/linux/Documentation/CodingStyle

Bjarne Stroustrup C++ Style and Technique FAQ (Trivia and style section) http://www.research.att.com/~bs/bs_faq2.html

The most of so called "Hungarian notations"(including the ones previously recommended by Microsoft) is the wrong interpretation of the original ones. No wonder that Torvald , Stroustrup, Sutter and Alexandrescu don't recommend them. However, the original notation are quit reasonable and can be found here http://msdn.microsoft.com/en-us/library/aa260976(VS.60).aspx

Finally, there is the good book C++ Coding Standards: 101 Rules, Guidelines, and Best Practices By Herb Sutter, Andrei Alexandrescu

The best advice from this book " Don't sweat the small stuff. (Or: Know what not to standardize.)". For example " Don't specify how much to indent, but do indent to show structure" etc.

If Kernighan, Ritchie, and Torvalds does it like that, who am I to do differently.

http://lxr.linux.no/linux/Documentation/stable_api_nonsense.txt

Summary: Being able to improve the API regularly keeps Linux largely free of legacy cruft that slows down the development and runtime performance of other systems like Windows. That's why Linux maxes out hardware that runs like a dog under Windows.

That's why there is zero software that run on linux and we all are forced to use Windows.

Probably that's why Oracle support only Red Hat and SuSe? Because every serious software vendor depends on stable api ..

Good that Solaris and FreeBSD are moving ahead very fast and the shackels of linux insanity will be broken soon.

http://lxr.linux.no/linux/Documentation/stable_api_nonsense.txt

Summary: Being able to improve the API regularly keeps Linux largely free of legacy cruft that slows down the development and runtime performance of other systems like Windows. That's why Linux maxes out hardware that runs like a dog under Windows.

If you distribute changed GPL binaries you have to provide the source (with the changes already in it) with it (or on request). If you distribute unmodified GPL binaries you still have to provide the source code (for the unmodified binary) along with it or on request. Even if you are "just" distributing a Linux kernel/busybox compiled by someone else you have to provide the source for it (or a written offer for it)*.

The whole not having to GPL (and thus distribute the source) for any/every userland programs which are running on the Linux kernel issue is clarified in the license file that comes with the Linux kernel. As someone said - just because the kernel is GPL userland programs do not have to be. That doesn't get you off the hook for providing the source for the kernel if you distribute binaries though. If you are additionally distributing userland programs that have you received under GPL (like busybox) you will have to provide the source for those too (but you would have had to have done the later regardless of which license the kernel was under).

As mentioned in previous posts the GPL FAQ covers this and many issues and it is worth reading the GPL itself too to give yourself firsthand knowledge of it. The issue you seem to be thinking of is probably covered by the GPL FAQ entry about unchanged/unmodified binaries.

* There is a bit more to it than this but it's well explained in in the GPL FAQ if you missed it when reading the GPL itself.