Slashdot Mirror

Quick Note: CPU Hot swapping Lando

Chec out kernel traffic. Writing on NTFS should still be reserved for the more adventurous people.

And it allows us to see clearly that they ARE devils.

If there has ever been a good time to send a letter/make a call/make a visit to your congressman/woman / senator about the DMCA, this is probably it. I'm sure Boucher would be more than delighted to put the bill on the floor if he had our undivided support for it.

Surely it's time for HURD to stop being vapourware and actually get something working.

The HURD is certainly far from "finished" but it is by no means vaporware. Nowadays development is happened under the Debian HURD project. It does boot, it has networking, it's got X11, it's got install disks (Linux based at this time). The last month has seen the first PPP support.

At present there are over 1000 hurd-compiled packages - 25% of the Debian archive. (a full list of packages with statuses here (big page))

For more information, check the afore mentioned Debian HURD pages, Kernel Cousin Debian Hurd (mailing list summaries) and the HURD Documentation Project.

Surely it's time for HURD to stop being vapourware and actually get something working.

The HURD is certainly far from "finished" but it is by no means vaporware. Nowadays development is happened under the Debian HURD project. It does boot, it has networking, it's got X11, it's got install disks (Linux based at this time). The last month has seen the first PPP support.

At present there are over 1000 hurd-compiled packages - 25% of the Debian archive. (a full list of packages with statuses here (big page))

For more information, check the afore mentioned Debian HURD pages, Kernel Cousin Debian Hurd (mailing list summaries) and the HURD Documentation Project.

l fail to see any reason it would not be good financially, "especially for schools"? What makes schools special, since most schools accept hardware donations and need to install an OS in-house? Or, if purchasing systems, can use Dell or one of the few hardware vendors who will install either linux, or a much cheaper old copy of Windows (one that wouldn't be good for educational purposes, but is just right for FDISK'ing).

For school, servers, businesses and anyone doing development, lisencing is a must. You can argue that people will borrow a copy of Widows from a friend and install it on their home PC, but for businesses, it isn't worth the risk

You also seem to have conveniently left out the portion of Microsoft's EULA which gaurantees the right to not use Windows and receive a full refund on the cost of software, if said software came preinstalled on your system...getting a $100 refund and dropping a free copy of linux on your machines is financially sound..

http://zork.net/refund

-but my username really is Anonymous Coward!

You can go to the free-sklyarov mailing list here and do a search (at the bottom of the page) for IEEE. This brings up the messages about the link between the American Association of Publishers (AAP) and IEEE. The problem comes in because the IEEE is on the AAP list of supporting organizations, and the AAP has come out (of course) with a basic "let Sklyarov rot" statement. As a result, free-sklyarov is asking members of IEEE to show concern. It IEEE has been against DMCA actions in general, so the association and whether it actually means something is kind of unclear.

Yup. One point that has been made on the Free-Sklyarov mailing list is that if Elcomsoft's eBookReader is a ``digital lock pick'', well then, lockpicks are legal (in most of the US).

It's breaking and entering that's a crime.

-Renard

i'm talking about this one

personally i've been running 2.4 for a few months now without any crashs. however (coming from freebsd) i really dislike the ipfw/ipchains/iptables crap. i would just like to be presented with one that is the standard.

-Jon

It seems to mee that this meeting is pretty clearly a stalling tactic. Adobe and EFF can schedule all the meetings they want -- I'd even encourage this -- but it seems that this particular meeting (it was "granted" on the precondition that EFF call off the protest) was designed only to thwart the potentially strong movement that is growing around this man's arrest.

So, please continue to join me, and many others, in San Jose or your local planned protest.
--
// mlc, user 16290

Both developments has their good and bad sides.

ActiveX support can be very important in multi-OS work environments and for many on-line banking sites, for example.

On the other hand, sandboxing it and turning it off by default doesn't sound like a bad idea. But don't worry, as long as this requires Wine CVS and as long as the activexproxy is a program in kdenonbeta, it won't be installed by default on your distribution.

Same with the new Ximian developments: embracing and cooperating with SOAP sounds like a good idea.

I _would_ be very careful about .NET development since it is basically Microsoft's proprietary lock-in platform to make sure SOAP will give them _more_ control, not _less_, but cooperation is good. Even so, it is not like we KDE people are totally against SOAP support, some projects already use it.

Furthermore, I like to stress that ActiveX support originated as a proof-of-concept and "cool factor" development. The responses we received at LinuxTag confirmed this.

I've asked this question once on lkml. It seems 3.0 will come when usermode applications have to be relinked (eg. not likely anytime soon).

kernel traffic link.

I have been reading Kernel Traffic regularly (looks like there's a new one tonight incedentally). Seems like there are some problems they've been having trouble sorting out. To my knowledge (again, limited to KT), they are still pending and in fact the latest kernels would be considered rather unstable for a stable series. In particular, the Virtual Memory subsystem has problems. I don't understand the details but higher memory systems >256MB can run into FS corruption. And last I heard they've written off VIA as an incompetent chipset manufacturer meaning they haven't a clue why VIA machines lock up. Someone *please* flame me for being wrong!

Hi,

I've been generally impressed at the level of support IBM has given to various open source project such as Apache. Other areas however have obviuously been neglected, for example the opening of drivers. Witness this recent thread on the linux kernel mailing list in which one Dan Streetman from IBM states plainly:

But management doesn't listen to me when I say it will never get accepted so I had to make a token effort of submitting it to prove it won't get accepted. And I did try hard to convince them to release the actual driver but it didn't work.

This obviously makes linux developers doubtful about the real motivations behind IBMs open source efforts:

I find it very odd indeed with IBM's big voice of open source praise, yada yada, and what Lou has said in the past, that there would be any question at all of wether it would be open source or not. Isn't big blue behind open source? Or is it just for publicity? Makes me wonder now... -- Mike A. Harris

My question is the following:

Will IBMs open source effort in the future be limited to the obvious areas (net/web related stuff, linux ports to IBM hardware) or are there any plans to educate other IBM departments about the benefits of opening the development process? If yes, are there any practical examples (winmodem drivers for thinkpad laptops, etc.)?

Thanks in advance

"...I know companies like Sun and IBM have come around..."

They have? IBM say the right things (e.g. we're spending a billion on Linux, stenciling little Tux's everywhere etc), but are they really embracing the "open" mentality?

Have a look at the latest Kernel Traffic, item number 7 IBM Lumbering near open source.

Does that sound like a company that has come around to you?

Lando

Uh, you don't need to use kernel space to achive this kind of performance in linux... Check this out...

X15 alpha release: as fast as TUX but in user space.

It's a beginning of a new era alright. An era of putting code that is destined to open us all up to a mess of portability, compatibility and security problems. That has no reason being in the kernel, for those of us that have respect for the basic decency of the UNIX programming model... And in the end, for no real benefit. Hooray! pfft.

The fast webserver is called X-15. Here is a release announcement from the author, Fabio Riccardi.
For a discussion of this webserver on LK, see Kernel Traffic #119

X15, an experimental user-space server written to "compete" with Tux is faster:

http://kt.zork.net/kernel-traffic/kt20010507_117.h tml#3

Frankly, from a security perspective, having a public-facing daemon running in kernel space is utterly frightening.

Apache is meant to have configurability over performance, and does dynamic content. However, I'm sure we'll see better performance from *nix based Web servers over time. Paul

On the other hand, Tux's performance was recently replicated in user space. Linux reall does have kick-ass TCP/IP performance these days.

I'm quite happy at 2.4. Is there any compelling reason why I would need 2.4.4?

YES! Upgrade now! 2.4.2 ate my ext2 filesystem. And I'm far from a unique case, there are weird filesystem bugs (both ext2 and reiserfs) in early 2.4 kernels. Lots of information about this on Kernel Traffic: (1) (2) (3) (4) (5) (6) (7) (8) (9).

Given all these problems, I'd say: don't run 2.4.x on a server yet. Run it on your desktop if you are daring (I do, even after it ate my filesystem.) but make backups of anything really important. Keep up-to-date on them; don't let a fixed bug eat your filesystem.

I'm quite happy at 2.4. Is there any compelling reason why I would need 2.4.4?

YES! Upgrade now! 2.4.2 ate my ext2 filesystem. And I'm far from a unique case, there are weird filesystem bugs (both ext2 and reiserfs) in early 2.4 kernels. Lots of information about this on Kernel Traffic: (1) (2) (3) (4) (5) (6) (7) (8) (9).

Given all these problems, I'd say: don't run 2.4.x on a server yet. Run it on your desktop if you are daring (I do, even after it ate my filesystem.) but make backups of anything really important. Keep up-to-date on them; don't let a fixed bug eat your filesystem.

I'm quite happy at 2.4. Is there any compelling reason why I would need 2.4.4?

YES! Upgrade now! 2.4.2 ate my ext2 filesystem. And I'm far from a unique case, there are weird filesystem bugs (both ext2 and reiserfs) in early 2.4 kernels. Lots of information about this on Kernel Traffic: (1) (2) (3) (4) (5) (6) (7) (8) (9).

Given all these problems, I'd say: don't run 2.4.x on a server yet. Run it on your desktop if you are daring (I do, even after it ate my filesystem.) but make backups of anything really important. Keep up-to-date on them; don't let a fixed bug eat your filesystem.

I'm quite happy at 2.4. Is there any compelling reason why I would need 2.4.4?

YES! Upgrade now! 2.4.2 ate my ext2 filesystem. And I'm far from a unique case, there are weird filesystem bugs (both ext2 and reiserfs) in early 2.4 kernels. Lots of information about this on Kernel Traffic: (1) (2) (3) (4) (5) (6) (7) (8) (9).

Given all these problems, I'd say: don't run 2.4.x on a server yet. Run it on your desktop if you are daring (I do, even after it ate my filesystem.) but make backups of anything really important. Keep up-to-date on them; don't let a fixed bug eat your filesystem.

I'm quite happy at 2.4. Is there any compelling reason why I would need 2.4.4?

YES! Upgrade now! 2.4.2 ate my ext2 filesystem. And I'm far from a unique case, there are weird filesystem bugs (both ext2 and reiserfs) in early 2.4 kernels. Lots of information about this on Kernel Traffic: (1) (2) (3) (4) (5) (6) (7) (8) (9).

Given all these problems, I'd say: don't run 2.4.x on a server yet. Run it on your desktop if you are daring (I do, even after it ate my filesystem.) but make backups of anything really important. Keep up-to-date on them; don't let a fixed bug eat your filesystem.

I'm quite happy at 2.4. Is there any compelling reason why I would need 2.4.4?

YES! Upgrade now! 2.4.2 ate my ext2 filesystem. And I'm far from a unique case, there are weird filesystem bugs (both ext2 and reiserfs) in early 2.4 kernels. Lots of information about this on Kernel Traffic: (1) (2) (3) (4) (5) (6) (7) (8) (9).

Given all these problems, I'd say: don't run 2.4.x on a server yet. Run it on your desktop if you are daring (I do, even after it ate my filesystem.) but make backups of anything really important. Keep up-to-date on them; don't let a fixed bug eat your filesystem.

I'm quite happy at 2.4. Is there any compelling reason why I would need 2.4.4?

YES! Upgrade now! 2.4.2 ate my ext2 filesystem. And I'm far from a unique case, there are weird filesystem bugs (both ext2 and reiserfs) in early 2.4 kernels. Lots of information about this on Kernel Traffic: (1) (2) (3) (4) (5) (6) (7) (8) (9).

Given all these problems, I'd say: don't run 2.4.x on a server yet. Run it on your desktop if you are daring (I do, even after it ate my filesystem.) but make backups of anything really important. Keep up-to-date on them; don't let a fixed bug eat your filesystem.

I'm quite happy at 2.4. Is there any compelling reason why I would need 2.4.4?

YES! Upgrade now! 2.4.2 ate my ext2 filesystem. And I'm far from a unique case, there are weird filesystem bugs (both ext2 and reiserfs) in early 2.4 kernels. Lots of information about this on Kernel Traffic: (1) (2) (3) (4) (5) (6) (7) (8) (9).

Given all these problems, I'd say: don't run 2.4.x on a server yet. Run it on your desktop if you are daring (I do, even after it ate my filesystem.) but make backups of anything really important. Keep up-to-date on them; don't let a fixed bug eat your filesystem.

I'm quite happy at 2.4. Is there any compelling reason why I would need 2.4.4?

YES! Upgrade now! 2.4.2 ate my ext2 filesystem. And I'm far from a unique case, there are weird filesystem bugs (both ext2 and reiserfs) in early 2.4 kernels. Lots of information about this on Kernel Traffic: (1) (2) (3) (4) (5) (6) (7) (8) (9).

Given all these problems, I'd say: don't run 2.4.x on a server yet. Run it on your desktop if you are daring (I do, even after it ate my filesystem.) but make backups of anything really important. Keep up-to-date on them; don't let a fixed bug eat your filesystem.

Ahhh, open source. Its a bit messy, but works out nicely in the end more often than not...

So, I'd extrapolate and give them the benefit of the doubt on the ECN thing. They appear to be quite reasonable when presented with coherent arguments.

Please refer to the bold, red warning prefacing the linux-kernel mailing list FAQ:

Hot off the Presses:

On 22-FEB-2001, vger.kernel.org will enable ECN. You may need to switch ISP in order to receive linux-kernel email. See the section on ECN for more details.

On 25-JAN-2001, David Miller announced that vger.kernel.org will enable ECN in 4 weeks time. This means if your email account is with an ISP which has a buggy router, you will no longer be able to receive linux-kernel mail (as well as other mailing lists hosted on vger). You should check if your ISP is ECN tolerant, and get them to fix their routers or switch to another ISP.

Of course, these are the same people that use the MAPS DUL to block dial-up modem users from posting to the linux-kernel mailing list. Rik van Riel threw a temper tantrum, saying the DUL was class prejudice based on internet connection and that "DUL is an unethical list to use because it assumes guilty by default. Anyway, since linux-kernel has chosen to not receive email from me I won't bother answering VM bugreports or anything here." Alan Cox quickly replied, Thats ok. Andrea will I am sure be happy to take over as maintainer [of the VM subsystem]."

*BSD users (and developers) are all complete jackasses... you'll fit right in. - Linus Torvalds

If you haven't yet -- read kernel traffic if you get a chance. Much of this has been covered there and in detail.

To summarize the comments there, Alan (or Linus, or Theo, or ...) doesn't have to know about the specifics of the chips in the microwave. I doubt any of them would care to know the specifics of most hardware unless they have it.

Good code is highly portable; 'Bits are bits'.

Sure, different chips will execute the same string of binary information differently, but the design in the original code -- if solid -- will be reflected in the binary when compiled for any target device. (Baring, of course, compiler bugs you'd have to deal with anyway.)

Am I over-simplifying? No doubt. Yet, the design defects corrected in the non-hardware-specific code won't have to be fixed for each and every new piece of hardware.

In many cases, defects found working with a specific piece of hardware might point to flaws in the general code.

Very little programming is necessarily hardware-specific. Most code is either OS or interface not hardware.

You don't read Kernel Traffic much, do you? :)

Just off hand, I remember that there are bad WD IDEs, IDE controllers (various companies), let alone odd BIOS and software interactions between the different parts. It can definately be the hardware sometimes! (Remembers problems with an old laptop.)

• No support for EXT2 file systems larger than 1 gig ("HURD cannot handle partitions larger than [about] 1 gig. The reason being, it tries to map the whole thing into virtual memory") !!!??
  
  
• No POSIX threads
  

• No support for EXT2 file systems larger than 1 gig ("HURD cannot handle partitions larger than [about] 1 gig. The reason being, it tries to map the whole thing into virtual memory") !!!??
  
  
• No POSIX threads
  

Okay, I'll bite.

The benefits of linux release methodology over the Microsoft release methodology:

- I can quickly get a sense of what is being improved with each kernel release by looking at the changes notice that is included with each kernel.
- I can find in depth discussion of some changes by following the kernel development list or the major discussion by reading the kernel traffic summaries that are published weekly at http://kt.zork.net/kernel-traffic/latest.html
- I can go read the code in the kernel to try to discern what is going on
- I can try to contact a kernel developer directly to seek information on a particular improvement
- I can offer my own improvements to the code
- I can tell what the benefits or a particular improvement are and who will benefit from this improvement

- I do not have to blindly go forth into the mire of a service pack and hope that it fixes a problem in a correct and well thought out manner and hope that it truly offers a benefit and does not only serve the interests of one entity

Does this mean that some bad ideas don't get brought into kernel releases? No. Does this mean that I have to expend less effort in deciding upon and then executing a update of my system? No. But I do have more tools available and better information to help me to decide if this is the right decision.

Read the Kernel Traffic and find out!

isn't Linux itself under the generic GPL?

No. The Linux kernel is specifically licensed under version 2 of the GPL. See here for more info.

The article talks about things needing to run 'close' to the Linux Kernel in embedded devices.
Well, the GPL 3 is completely irrelevant here, as the Linux Kernel is not available under GPL3. Linus specifically releases the kernel under the GPL 2 licence (not GPL 2 or greater, see Kernel Traffics passim.).

Some would argue the if the GPL3 turns out to be a good thing in the future, then it will be very difficult to relicence the kernel under GPL3 as there are so many contributers who submitted modifications to GPL 2 only code.

Note that this also means that you can't legally take code from the GPL 2 only kernel and place it in a GPL 2+ project, but that's not strictly relevant to the topic at hand.

Please see kt.zork.net, I assume all the kernel cousins have moved too.

Oh, you da man! Yes, indeed, Kernel Traffic and all his cousins are there. Cheers to Zack for providing this excellent service despite being laid off by Linuxcare, cheers to you for letting me know, and fuckings to Linuxcare for leaving the old dead page lying around with no hint as to why it's gone stale.

Please see kt.zork.net, I assume all the kernel cousins have moved too.

KT is no longer on kt.linuxcare.com - It's on kt.zork.net .

Zack Brown was laid off from Linuxcare :-( and as such the kernel cousin lists have moved to kt.zork.net

Alright, so those're pretty cool. But, from someone who's been folding for most of his existance, Joseph Wu's Origami Page still is among the greatest, and has what might be the greatest X-Wing Model (2 notes: 1, it's a .pdf file, 2, it's the "Chi-Wing Fighter" to avoid copyright infringement, no relation to the starship we know). There's no limit to what one can do with a square of paper (and people are pushing that limit (yet another note, warning, adult content) all the time...

But she already won the 1998 Best Stallman magnet in the Bay Area at the [crackmonkey] Stallman Awards.

But Al Gore did invent the Internet!
--

Oh, I see.

I'd suggest we have a contest for Most Creative Means of Accepting the EULA. Meanwhile, I predict that Windows Refund Newsletter Issue #4 is going to have fun with this one!