Slashdot Mirror

Linux really doesn't have very high standards. The core Windows OS has higher standards.

Fix buggy pwrite(). There's a reason pwrite() to a file opened in append mode is supposed to go to the offset specified in the pwrite() call and not be appended to the end of the file like Linux does: so you have the option of doing atomic writes to a file that are either at the end or at the offset you specify.

Make fork() async-signal-safe like POSIX requires. Don't try to lobby the POSIX committee to remove fork() from the list of async-signal-safe functions because unthinking glibc developers added pthread_atfork() handlers to glibc itself, thus breaking fork(). Other OSes treat failure to meet POSIX as a bug, not a reason to try to lower the standards you have to meet.

Fix the God-awfully broken AUTH_SYS implementation that randomly picks which of your groups up to the max specified in RFC 5531 get used for authentication. If you're in more groups than the 16 that the RFC allows, Linux just silently truncates the list. Today you can access your files, tomorrow you can't! What a shithead implementation.

Why wouldn't he simply codify his preferences?

https://www.kernel.org/doc/Doc...

Chapter 8: Commenting
....
When commenting the kernel API functions, please use the kernel-doc format.
See the files Documentation/kernel-doc-nano-HOWTO.txt and scripts/kernel-doc for details.

Here's the safe driver, in the form of source code so you could check it yourself if you want to.

http://lxr.free-electrons.com/...

This driver does require a non-crap operating system, of course. Linux, FreeBSD, OpenBSD, etc probably OSX will work too.

they plan on moving to something unsupported all the time

Pretty sure Linux isn't unsupported. If you're so inclined, you can pay for support if you want it

Unlike with Windows, you get your pick of providers (and yes, that includes big-name, management-friendly corporations), for any particular aspect/application of Linux.

They didn't "port the driver", they copied two functions, radeon_suspend_kms() and radeon_resume_kms() across:

"I have ported radeon_suspend_kms() and radeon_resume_kms() functions from linux to CE. Actually I have validated that the evergreen_suspend() and evergreen_resume() work already on CE. But when the resume work is done and the screen is shown up, I found the 3D engine works wrong."

Since these two could well be little more than mov %radeon_register, $magic_value, the entire "ported driver" could consist of little more than a dozen bytes of code. Even SCO's lawsuit was built around more evidence of copying than this...

Well, they're not huge, but they're a bit bigger than that - radeon_suspend_kms is 67 lines, radeon_resume_kms is 38 lines. http://lxr.free-electrons.com/source/drivers/gpu/drm/radeon/radeon_device.c

You misunderstand. You appear to think I am talking about drivers, but I am really not. The BSP (board support package) is a much lower-level entity than that. While it does contain drivers, they are drivers for things that the OS needs immediately and cannot load at a later stage, such as the interrupt controller and the timer. The location and size of usable RAM come from the BSP, which will also specify the interrupt mapping and the locations of peripheral controllers such as the PCI configuration register. Clearly, without these critical details, the OS cannot do anything at all.

The x86 BSP for Linux is here. There is one basic BSP, and a few special cases for improved support of unusual sorts of PC.

The ARM BSPs for Linux are here. There are more than 40, and this does not account for every ARM platform.

You are surely right that one kernel could include multiple BSPs and pick one after identifying the host architecture somehow. Tricky, but possible. However, even once achieved, this has practical problems. It is much better to standardise on one platform, because standardising means less compiling, less testing, fewer things to go wrong, and lower support costs. This is good for software vendors, OEMs, and users. It would be much easier to produce Ubuntu for ARM if ARM meant "one platform" rather than "every platform is different and very low-level parts of the kernel must support all of them".

Compatibility and interoperability also mean choice. If your manufacturer stops producing updates for your netbook, then it doesn't matter. You can use the same updates as everyone else.

Finally, the problems that prevent Windows booting on motherboard X when installed on motherboard Y are nothing to do with the BSP and everything to do with drivers that are loaded at a later stage.

You misunderstand. You appear to think I am talking about drivers, but I am really not. The BSP (board support package) is a much lower-level entity than that. While it does contain drivers, they are drivers for things that the OS needs immediately and cannot load at a later stage, such as the interrupt controller and the timer. The location and size of usable RAM come from the BSP, which will also specify the interrupt mapping and the locations of peripheral controllers such as the PCI configuration register. Clearly, without these critical details, the OS cannot do anything at all.

The x86 BSP for Linux is here. There is one basic BSP, and a few special cases for improved support of unusual sorts of PC.

The ARM BSPs for Linux are here. There are more than 40, and this does not account for every ARM platform.

You are surely right that one kernel could include multiple BSPs and pick one after identifying the host architecture somehow. Tricky, but possible. However, even once achieved, this has practical problems. It is much better to standardise on one platform, because standardising means less compiling, less testing, fewer things to go wrong, and lower support costs. This is good for software vendors, OEMs, and users. It would be much easier to produce Ubuntu for ARM if ARM meant "one platform" rather than "every platform is different and very low-level parts of the kernel must support all of them".

Compatibility and interoperability also mean choice. If your manufacturer stops producing updates for your netbook, then it doesn't matter. You can use the same updates as everyone else.

Finally, the problems that prevent Windows booting on motherboard X when installed on motherboard Y are nothing to do with the BSP and everything to do with drivers that are loaded at a later stage.

Last year Rob Landley was working on getting the Tiny C Compiler to build the kernel unmodified (again by adding gccisms to tcc) - here's an OLS video of the Landley talking about changing tcc to compile the kernel. Alas, from what I gather this effort has stalled for now.

It is unlikely that you will see the kernel adopting anything that makes the build process much more complicated. Operating system glue layers (e.g. abstractions in code for drivers that are supposed to run on other platforms) are already already frowned upon in drivers. Any new dependencies on tools like autoconf or cmake would most likely be rejected with a "what are we gaining?" complaint. My understanding is that patches that convert gccisms to their C99 equivalents are generally accepted but people are not willing to maintain glue for other compilers because it makes the default case painful. That's their choice - there are always other OSes like NetBSD that can be "compiler portable".

There was a story about the new linux kernel, and that was a point upgrade.

Then again, the P in LAMP has always been about the scripting language, not the database.

Yesterday I was watching Jeff Waugh's presentation at FOSDEM. It was pretty interesting and included his take on LAMP:

-L-inux
-A-pache
-M-ost of our scripting languages start with P
-P-ostgreSQL

A lot of people get interested in technologies when they hear it examplained and can ask the developer - and face to face is much easier than by email.

To really get the value out of it, try to have your presentation recorded (like these from FOSDEM and other conferences). And if you really want to get picked up by search engines and be accessible to deaf users and others with particular needs, event transcripts make for greppable copies of talks and presentations.

Another group have now published other videos from FOSDEM 2006 and their collection includes Stallman's software patents speech: http://free-electrons.com/community/videos/confere nces

Looking forward to reading their other guides, pretty nice of them to publish them online :)

It's indeed nice of them, lots of info, although not complete.
If you look at the Java in embedded Linux systems slides they only mention java's strengths in embedded device and 'forgot' its weaknesses.