Slashdot Mirror

Not true.

http://www.kerneltraffic.org/kernel-traffic/kt2002 0708_174.html#5
http://www.ussg.iu.edu/hypermail/linux/kernel/0405 .2/1273.html

There are also some ABI implications, which is why most distros avoid 386 support. Can't be bothered to do any more googling.

"Are you being stupid on purpose, or were you born that way?"

Apparently so!

http://www.kerneltraffic.org/wine/wn20050304_264.h tml#6

but it seems to not be gaining much attention.

It is fair enough that Ubuntu gets a lot of respect for the distro, I've found it to be of excellent quality. I look forward to seeing how these other tools help development.

Even though I'm not a contributor (other than occasional bug reports and financial contributions) to Free/Open Source Software one of the things that attracts me to it is that I can see the development taking place. I can read Kernel Traffic or various planets and see developers working together to produce something great.

So even thought they might not effect me directly, it's always exciting to read about new tools etc that might help the developers do their thing.

Shut the fuck up you peecee clown.

The reaction in the console world to has been hilarious. Some guy who used to work at Microsoft and hitches his company completely to that technological nightmare that is Visual Studio/DirectX/Windows/x86 is crying over the fact that he is now screwed technologically in his ability to compete in the lucrative console market.

Well boo-fucking-hoo Gabe.

You made your choice and no you have to live with it. Just like you made your, idiotic, choice to use Outlook...

Those of us with a fucking clue who actually work in the console biz have been working our way to the promised land for years now. And with the PS3 we have arrived. You guys haven't seen anything yet with what we are doing and will be doing with the PS3/Cell/RSX hardware. It is a game/graphics programmers dream system.

Not only is the PS3 a dream system, the unlimited scalability of the internal bus architecture of Cell chips means our code bases are ready to scale to unbelievable heights of performance in future media devices that use multi-Cell systems or Cell chips with more SPUs.

So, yeah, it must suck to be stuck in x86 directx land.

BTW, all you crazy Linux cats are going to get to have fun with your very own Cell systems soon:

http://kerneltraffic.org/kernel-traffic/kt20050905 _326.html

Enjoy! I know I am...

...is a pretty savvy fellow; he's a frequent LKML poster and has gotten some mentions on Kernel Traffic.

A while back, I had looked into what would be involved in setting up a X.Org traffic weekly/monthly/whatever. If anyone is interested in doing this, I have some info from Zack Brown who does Kernel Traffic about how he makes it all happen. Something like that for the various X.Org lists (DRI-devel, and the X.Org lists themselves) would be very helpful I think. I wish I had the time and patience to make it happen myself. :(

I think it would be very helpful for attracting new developers if people could easily keep tabs on what is going on under the hood.

IBM doesn't tend to release code to the public until it's been through a long approval process ;-)

I'd have to agree -- I was more than willing to recommend that my partners and I check out BitMover for source control in-house, until he started mouthing off on the kernel list.

Guess what McVoy, lots of us read the Kernel Traffic summaries who aren't necessarily involved. I don't like companies with bad attitudes, period.

I was just reading the latest Kernel Traffic and it hit me how much of a flux the driver model seems to be in. Constantly.

Microsoft Windows seems to have had a stable driver interface since at least Win2K (probably NT4 too). The weird thing is that eschewing binary compatibility, like Linus likes to do, really ought to make it easier to stabilize a model? I mean, they have all the upsides with none of the downsides.

I really don't care personally -- I don't write drivers -- but isn't it a bit odd that the system is constantly rewritten (or at least majorly tweaked)? New month -- New driver model. New locking mechanism. New everything. What's not new is broken hardware sleep/resume!

Drivers aren't sexy, and it seems a lot of time is spent just spinning in place (no phun intended)

"The better SCM initiative was established to encourage improved OSS/FS SCM systems, by discussing and comparing them. Among other things, see their comparison file. Zooko has written a short review of OSS/FS SCM tools. Shlomi Fish's OnLamp.com article compares various CM systems as does his Evolution of a Revision Control User. The arch folks have developed a comparison of arch with Subversion and CVS (obviously, they like arch). Another pro-arch discussion is Why the Future is Distributed. A pro-subversion discussion is available at Dispelling Subversion FUD. Slashdot had a discussion when Subversion 1.0 was announced. Kernel traffic posted a summary of a technical discussion about BitKeeper. Brad Appleton has collected lots of interesting SCM links. jemfinch has some interesting essays about SCMs (he uses the term VCS), including why he thinks the approach to branches used by Darcs, Arch, and Bazaar-ng is a poor one. A brief overview of SCM systems that can run on Linux is available."

There are lots of OSS/FS software configuration management (SCM) tools. CVS, Subversion (SVN), and GNU arch get lots of press, but there are many others such as Aegis, CVSNT, Darcs, FastCST, OpenCM, Vesta, Codeville, Bazaar and Bazaar-NG.

You might also take a peek at my paper Software Configuration Management (SCM) Security.

FSF also has a relevant answer in the GPL FAQ here.

While the issue is unclear and only courts could give a definitive answer on it (lawyers could give an educated guess and I assume the companies writing binary modules have asked them for it) it is definitely against the spirit of the GPL to write a module for a GPLed program and then keep it closed.

In my opinion even if binary-only modules happen to be legal they still aren't morally right.

"Anybody who tells me I can't use a program because it's not open source, go suck on rms. I'm not interested. 99% of that I run tends to be open source, but that's _my_ choice, dammit." (Linus Torvalds, October 26, 2004)

Apparently, he actually said that:

http://www.kerneltraffic.org/kernel-traffic/kt2004 1117_284.html#2

(I was surprised.)

If it didn't, wouldn't that technically be a violation of the GPL?

We're about to find out. That's what iRiver is accused of

http://www.kerneltraffic.org/kernel-traffic/kt2005 0102_288.html#8

Kernel Traffic has a pretty lengthy summary of some discussion on the Linux Kernel Mailing List about the state of Real Time capability in the kernel as well that I found pretty interesting.

I'm only really replying to give your comment a bit more weight -- that writer is as dense as lead.

I'm not sure he's ever actually followed kernel development before.

For all those wanting to know whats going on without reading the linux-kernel mailing list, just run over to Kernel Traffic -- a summary of the week's happenings on the list.

Furthermore, the question of "wtf is up with the version names?" is not hard to answer; it's been discussed in public. see Kernel Traffic for example.

Name one feature of C++ that is compelling and useful for the kernel that can't be accomplished in C in a maintainable fashion?

It's a simple question, one I posed before. Are you going to answer it or call me a troll for pointing that until the last 2 years, there wasn't a decent C++ compiler. The 2.4 kernel series still lits in it's documentation, that egcs-1.1.2 (which I believe corresponds to gcc-2.91), is still being supported. So it's not a completely irrelavent point.

http://linux.bkbits.net:8080/linux-2.5/hist/Docume ntation/Changes?nav=index.html%7Csrc/%7Csrc/Docume ntation

Look for the entry that says "Enforce gcc 2.95 compiler as the minimum". Hey, look at that, right next to it that says, 19 months ago that was the minimum. So as off 19 months ago, it sorta follows that they had to support the what you seem to reguard as a substandard C++ compiler. I believe that 2.91 is still used as the compiler of choice for older Sparcs. That's during the 2.5 development kernel.

http://linux.bkbits.net:8080/linux-2.5/anno/Docume ntation/Changes@1.33?nav=index.html%7Csrc/%7Csrc/D ocumentation%7Chist/Documentation/Changes%7Cdiffs/ Documentation/Changes@1.33

Hey, look at that, in the 2.6.0 Documentation/Changes, the required version is still 2.95.X (x>=3). So which version of the C++ compiler did you want to you?

So while you might think they are 4 years old, and unsupported, it is still the version that Linus says is the correct version of the compiler to use. You might think I'm a troll, but at least I know the details of the projects I use. *sigh*, I wish people paid attention to details once in a while. The kernel is very sensitive to the version of GCC it is compiled with. As a general rule that means they are very reluctant to require newer versions, or even support newer versions.

Actually, assembly is syntactical sugar, do in in machine code (or if your into Turing machine, with punched paper tape). It's nice of you to call me a troll, but you still have yet to state a compelling reason why C++ is a good idea to have in the Linux kernel. C++ and Objective C (I've programmed in both professionally), are very slick ways of accomplishing things that can be done in straight up C (especially Objective C). C++ is much nicer to program in then C if only because it means I never have to null terminate a string again. Given a choice, I'd never ever write a line of C again in my life.

The subset of C++ that is actually hard to do a good job of in C is nearly identically the subset that wouldn't be useable in the Linux kernel. Most of the best ideas for using C++ in the kernel are type checking and virtual functions. Type checking is already a problem (Linus points out that GCC emits spurious warnings about code that is obviously correct to anyone who takes a cursory look at the code w/ the 3.X series of GCC, it would only get worse with G++). He's writting his own set of tools to do type-checking that is tailor made for the Linux kernel.

http://www.kerneltraffic.org/kernel-traffic/kt2004 1019_278.html#5

Virtual functions are nothing but a table of function pointers. They do this all the time in the Linux kernel. I'm asking a simple question, name something besides those two features of C++ that are a tool that needs to be used in the Linux kernel that would be impossible to maintainably implement in C.

I wish they had namespaces, but that's not something that is impossible to do in

Who since Jan 1999 has produced a weekly summary of the discussions on the linux-kernel mailing list. Thank you Zack!

Here's a link to an older KT entry; "Status And Discussion Of EFI (Extensible Firmware Interface) Support"

Explains some history, rationale and technical details.

• Loop-back encryption is kinda clunky. dm-crypt looks to be a cleaner way to do encrypted devices. And pam_mount can mount encrypted home directories on login.
• As for doing encryption in the filsystem, several people are at working at it.
• Your notion that OpenSSH only creates a tunnel while the "console" is open, is little more than FUD. Oh no! The console!. That's the whole point. SSH is largely interactive by its very nature.
• It's quite easy to setup OpenSSL in inetd mode for SSL'd services.
• Encrypted executables? Are you joking? WTF would that achieve? If someone has physical access to your machine, you're screwed anyway. And if someone has broken into your machine remotely then your executables are probably the last thing to worry about. On Unix/Linux systems you need root access to write to system executables. If an intruder has root access, they can do anything and don't need to modify your executable to screw around. This is a straw-man argument.
• Linux is very good as a VPN router. Not only do we have IPsec/IPV6 from the KAME project, there's also the (abandoned) FreeS/WAN project and the spin-off Openswan. But don't forget OpenVPN (available for quite a few platforms, not just Unix/Linux). If you're really desperate, you can always combine SSH and PPP to make a VPN.
• Tokens? You have heard of Kerberos haven't you?
  BTW, here's a good LDAPv3+SASL+KerberosV HowTo

My god you are a troll. Oh, and as others have pointed out, encryption does not instantly make something secure.

--Here you go:

Kernel Traffic

Linux Weekly News

Linux Kernel Mailing List Digest (from google, not tested by me)

--Try and find a site that details the inner workings of the NT kernel, on a weekly or any regular basis -- really -- I dare ya. If you can *find* the date on the NT kernel file, compare it with the downloadable kernels that you can find here:

Kernel.Org

The discoverer of the practicability of the RST attack was Paul A. Watson ..

The re-discoverer rather - clicky clicky

As it is written: "There are no good excuses for binary modules. Some of them may be technically legal (by virtue of not being derived works) and allowed, but even when they are legal they are a major pain in the ass, and always horribly buggy."

You know, there's a reason Linux doesn't work well with binary-only drivers. And that's because binary-only drivers are a bad idea for Linux.

--grendel drago

I love the speed increases that the 2.6 kernel has achieved on the desktop (and for things like media: mplayer never bugs out with that charming "YOUR COMPUTER IS TOO SLOW" message anymore). However, I don't know if it can be considered even remotely stable. Since switching, my uptime has been a Windows like joke.

[...]

- Firewire and sbp2 support is completely broken. Ironically this has, I believe, more from "experimental" in 2.4 to a normal feature, yet it worked fine before and now doesn't work at all (the linux1394 forums forums reflect that I am not alone in this). Trying to copy data to sbp2 drives segfaults, hangs, and worse. Beware of connecting to 2.6 if you have a firewire drive with data you hold dear...

It's important to keep some perspective. Usually whenever anyone says something is full of bugs, they mean that they keep running into the same bug over and over. If you're having problems with Firewire, very likely you're running into one bug in your driver repeatedly. The other people complaining may have the same chipset and the same problem.

My point is that you can't make any generalizations to the entire kernel series (or even subsystem, like 1394) being more or less stable just because you encounter a single bug that you didn't used to. Look more closely at the oopses and your system logs, see where it's happening, file a good bug report. They'll probably have it fixed in a couple releases.

People use "stable" or "unstable" to mean a lot of different things:

1. If they're changing the APIs constantly or not.
2. If the core of the system doesn't crash and performs well under a variety of loads
3. If their system doesn't crash and performs well under their load

...and #3 really needs to be qualified with "for me" or "with this exact hardware, doing this". Because otherwise, you're saying the whole series sucks because of a single bug. And very likely, a bug in a driver. When I read kernel traffic, lwn, or kernel trap, I frequently see mention of fixing some unsafe coding practice...in the core kernel. Drivers are left for their maintainers to update. Some do so quickly and well. Some don't.

Ideally, a system would be so rock-solid that you would never run into even one stability or performance bug. But I don't think that's much more realistic for Linux 2.4 than it is for 2.6.

(This message is not just aimed at you. I see this a lot.)

There's a discussion about it here.

1. A nice unbiased article about how Linux is superior...from a Linux magazine. Perhaps we'll be posting the article from Windows Insider about how Windows is better? No? Didn't think so.

Note that he generally talks about Unix and when being specific most of the time Solaris is mentioned. When he talks about *BSD and Linux it is along the lines of 'oh, and other Unix-like systems such as ...'.

Now, anyone who has read the Linux kernel list or at a minimum Kernel Traffic will recognize that what he says does indeed apply to Linux as well. Without that knowledge, though, it looks like the reasons why Solaris is better and Linux just happens to be like Solaris. (As someone who has admined solaris boxen and owns a few ancient ones -- I'll take Solaris though I want Linux if at all possible.)

For the record though, the important point was that the stock 2.6 kernels do not yet handle HT in an ideal manner. The article doesn't mention if the Gentoo kernel used for the benchmarks is HT patched or not.

And with special thanks to Zack Brown, those interested can read summaries of HT issues here:

http://www.kerneltraffic.org/kernel-traffic/topics /Hyperthreading.html

oopses while rmmoding

I thought rmmmod support was removed or at least deprecated in the latest kernel? Any kernel hackers care to clear this up?

but beginners think "cool, a new stable kernel", try it and are disappointed, giving a bad name to an otherwise great kernel.

Why would beginners be installing a new kernel? The distros would have the latest features patched into their supported kernels. In any case, if you are installing kernels, you should at least read kernel traffic.

So, earlier someone posted a link to a summrary of a discussion on the Linux kernel list. An Intel guy pointed out some issues with the Openfirmware model that make some sense.

The way I read it is, hardware manufacturers want cheap products, and nobody wants to get locked in to supporting just one system architecture for an expansion card.

With something like openfirmware, apparently you have to have a ROM big enough to contain valid code that can run on both IA-32 and IA-64 and PPC, etc., or you end up with things like PC-only and Mac-only cards, which isn't cheap, either. So as nasty as ACPI has been from an implementation point of view, it seems like it does some stuff that open firmware can't do. Same can be said for EFI. Seems like a hell of a problem to me - damned if you do, damned if you don't.

Now, that said, no arguments about the other fringe benefits Intel gets from pushing the standard.

P.S. To my mind, Linus' post on the issue in the thread seems like something that your average software dude (self included) might come up with. Come up with simple hardware specs that don't need ROM code, and standardize on THAT. I'd kill for that kind of utopia in my line of work. I don't work in PCs, I work in embedded systems. All the hardware guys talk about gaining a competitive edge by locking people into their proprietary hardware via a software interface that they control. Same thing going on here - it's not the software dudes in the industry that need convincing - it's the hardware and business dudes who aren't looking to the future, but to the next product.

EFI sucks. Even Linus says so.

2.4.x was better because it thinned out use of the BKL

Yeah, OK. I've only been following Kernel Traffic for a while, so I didn't recognize this either.

googling.... sourceforging....

BKL = Big Kernel Lock. Here's a nice paper on global locking The Linux Scalability Effort seems to have coordinated some of the effort to remove it and also introduce other features which help SMP. Not too surprising that a lot of contributions come from IBM & SGI folk.

Read Kernel Traffic, the periodical summary of conversations on the Linux Kernel Mailing List (LKML). In article #240, you will find your answer. If in doubt, email the authors directly.

Read Kernel Traffic, the periodical summary of conversations on the Linux Kernel Mailing List (LKML). In article #240, you will find your answer. If in doubt, email the authors directly.

Linksys And The GPL: The Saga Continues

Possible Linksys GPL Violations: The Saga Continues

more on kernel mailing list

*cough*

Er, ACPI is a bad example because ACPI has NOT yet been migrated into 2.4. The ACPI guys have been trying to get it in for a long time and finally threw a tantrum on LKML about it when Marcelo said he was planning on releasing 2.4.22 without it. They changed his mind and Marcelo now plans to include it, but it's not actually in there yet.

As you can see, not only does Linux support HT out of the box (as any SMP-aware OS would, really), it's also working to handle HT in the most effective way possible.

Take a real good look at AMD's roadmaps:

Dual Cla-whammers are GONE.

AMD evidently decided to force the enthusiast/mini-server market to choose to buy-up ( dual sledge-hammers, and at the prices involved .. NBL ), or

buy-down ( Dual Athlons

Mean ( well, not really mean, but .. wahh!! . . ), but effective ( for their bottom-line ).

Mind you, there are 2 other significant concerns in replacing my system ( I'm in the segment they .. decided to ignore ):

1. Silent System: .. those Cla-whammer HSFs look huge/possibly-noisy, or, if the chips really are low-wattage, then they'll be really silent under a copper HS with a Verax.de fan on it, and

2. as someone else mentioned, HD CPU usage, but the solution for that ( waitaminit, we dissolve stuff to fix our PC's? ) is to use Serial-ATA ( non-blocking, and non-redundancy-of-commands ).
And with Linux, the Silicon Image chip based S-ATA controllers are supported in 2.6, so grab these, then, rather than the non-open-source HighPoint, or the outright opposed-to-open-source Promise.

Lost Circuits Benchmarks ( stunning ), and CyberCPU.net ( it's the low-CPU, 8% vs 44%, that puts S-ATA into the phenomenosphere ), and .. I'd heard that Seagate is implementing out-of-order-execution for its upcoming S-ATA drives, which oughta make 'em punchier..

( for the TLA-challenged, the CLA in Cla-whammer, the new AMD desktop chip, stands for the Canadian Luge Association, and if these chips are able to flatten luge , they're damn capable, and..
the above usage of NBL stands for Not Bloody Likely, as rememberers of the film-version of Pygmalion may remember.. My Bloody Fair Lady, I think it were callethed.. hmmm.. )

1. don't buy an Itanic, if you're going with Opteron for its ultra-fast RAM ( compared with Itanic ) and drastic cost-effectiveness ( ditto ), an Itanic won't show you whether Opteron'd be a good match: the architectures are totally different.

2. RAID storage: don't buy Promise 'raid' cards ( and DON'T do 'raid' 0/1, do RAID-5 ).

Why? ..
1. it ISN'T possible to use S.M.A.R.T. diagnostics in your drives with the Promise ones, at least ( you'll crash the PCI-bus, hanging, fatally, the machine, using Promise chips .. don't know about Highpoint or Adaptec ), and...
2. they oppose Open Source drivers, and coders, for their own products.

Highpoint has only SuSE 7.3-8.0/Redhat-whatever ( IIRC ) drivers for their fast 1520 cards, but if you want compute performance, you want Gentoo... ( and SuSE's been at 8.1 for ages, now... )

Adaptec? I don't know if their cards have the same issues as the Promise/Highpoint, but their cards compete with Promise's, and so probably cut corners in similar ways ( I'd love to see hard data on that point, though )...

3ware are the only cheap ( compared with SCSI ) RAID controllers I know-of, that offer bootable, real, actual, S.M.A.R.T.able RAID on ATA drives.

( I'd stick scads of 120GB IBM 180GXPs on 'em, because they're cooler-running than the 180GB versions, and better than most other drives: fast, quiet, reliable-looking, etc .. quiet means, to me, that wear&tear isn't happening as much, though I wonder-at the No-Seagate rule expressed earlier... is it that fluid-bearings fail soon? or that Seagate has worthless support from our perspective? )

3. SuSE or Gentoo are really your only choice, that I can see.

Why? .. 1. Redhat's trying to microsoft linux, by ignoring standards and making its way law, and Mandrake's .. a flaky ( though fast ) variant originally based on Redhat... I'm fed-up with both, but YKMV ( metric, here )..
2. SuSE includes damn-near every program-capability one could imagine, and has excellent hardware support ( beyond any others' )..
3. Gentoo's compiled specifically for the hardware you are running, and with --buildpkg you get to build on one, then copy all the tbz2's built, to all of the other ( identical ) machines, and just install 'em, and voilá: ultra-performance.

Misc Links:

Chassis, suitable for lots-of-drives NAS type thing.. or this one for well-cooled system ( thick aluminum's a good conductor of heat, and that makes for a longer-living, less-downtime machine )

I'd use Athlons, but that's just me ( Intel's murdered/crippled WAY too many CPUs, and chipsets, for me to be loyal to them ), and would use these HSFs with Verax.de ( or Panasonic Panaflo ) fans on 'em, just because the noise machines make increase sick-time and reduce health/sanity/productivity so damn much.

Consider using P/Ss like these, remembering that 1. they're REALLY quiet only when running at about 50% load, and 2. the UPS-VA-rating you need for each one is DOUBLE the delivered-watts rating of the P/S.
Also, you want LINE-INTERACTIVE UPSs on all machines. ( NO data-corruption due to brown-outs or other glitches ).

I'd consider dual-CPU machines standard for the desktop, simply because even if a CPU was saturated, on that machine, the machine'd still respond, and I'd stuff as much quick RAM into it as I possibly could ( 3GB/desktop, for engineers ), and I'd ALWAYS use ECC RAM.

Consider this board as something to compare against, with Something Like This KVR266X72C25/1G or this times 3 of 'em, per motherboard.

Like the Marines: Capability-based, not capability-choked, right?

The best advice I've seen on this page is

1. get a GOOD admin ( character, more than anything, values, sanity, cultural-harmony-with-you: you CAN change someone's skillset, you CANNOT change their nature ), and

2. metrics, understanding precisely what 'success' means, what the context is, etc...

3. do it one unit at-a-time

Oh, yeah, here's an Opteron-board news link... ( I'm waiting for lots-of-SATAs-on-board )...

Finally, change the ferro-resonant ballasts in your flourescent lighting to RF ballasts, and switch to Phillips TL-930 4' fluorescent tubes ( Colour Rendition Index of 95, rather than the cheap-cool-white CRI 50!! ), and your health will improve, significantly ( you can then ask for a raise, for your increased effectiveness, see )... if you find the warm-white of the TL-930s ( 3000K ) not brilliant/awakening enough, then mix-in a couple of TL-950s ( 5000K, mid-day-sunshine/sky colour ), to punch-up your alertness.

More info here