Slashdot Mirror

When's the last time you heard of a bug in Linux forcing a reinstall?

Hey Bright Boy, you must not pay attention to Linux news nor how many different distributions there are. Allow me to enlighten you a bit.

Mandrake 9.2 may kill LG CD-ROM drives | Fedora Core 6 release date pushed back | Kernel Newsflash (Do a quick search for this section of the page and the old production kernels) | ReiserFS and filesystem corruption issues -- how to fix them, etc (Has to do with an old known issue between Gentoo and ReiserFS | ext3 corruption issue in 2.6.18 found by RedHat

Also try running something like Rawhide, Gentoo unstable branch (Which I do), Debian unstable, or any plethora of other systems out there which include software that's not extensively tested. While it is true that it is rare to find incredible bugs that create a big headache for end-users in a Linux distribution release, it's not impossible and there have been many occurrences of these bugs in release Linux kernels themselves. Let's not kid ourselves, shit happens on both sides of the fence, and it's not only unfair but naive to hold Microsoft to some golden standard because they have a large bankroll. Throwing money at a problem is the worst way to solve it, especially when it comes to QA.

P.S. -- Even in the stable branches of distros breakage can happen and it can be difficult or impossible to recover vital data from the system. I'm running reiser4 on my ~amd64 Gentoo and I keep hoping I don't end up with filesystem corruption that would hit me quite often in the past when I was pretty much forced to use a vanilla kernel with reiser4 or the -mm patchset, which is about as unstable as they come. Plenty of other people get hit by random difficult to reproduce bugs for any filesystem, daily. ext3, jfs, xfs, reiserfs, you name it. I dunno about ext2 though, but since they're so closely related (ext2/3), I'd figure most things that ail one ail the other. Also, you were speaking directly on a bug forcing a reinstall of the system, which usually means a gross configuration error or some other form of data loss. The Mandrake link is the only one which diverts from this train of thought, but it most certainly was a big hitter if you can remember when the story hit, as I do.

Another P.S. -- You say they've had all this time to iron Vista out as if they started out with "This is what Vista is going to be, period. Get there and release it." Sorry buddy, that's not how development goes, especially when competitors are around introducing new ideas all the time, never mind your own R&D department.

Actually current (>=2.6.13?) have slowly been reducing this value 250 and now 100 in-order to reduce idle power usage. http://lwn.net/Articles/145973/

Interesting. I hadn't seen that. Is there a sysconf(3)-style way to see what HZ is on the currently-running kernel?

I had seen that really new kernels are eliminating HZ entirely (and good riddance). Umm, google for "tickless Linux".

Here is one (admittedly short) answer: http://lwn.net/Articles/198201/

I guess lanuchd didn't do exactly what the Ubuntu people wanted.

-matthew

Actually current (>=2.6.13?) have slowly been reducing this value 250 and now 100 in-order to reduce idle power usage. http://lwn.net/Articles/145973/

Here is an interesting article from Linux Weekly News: Who maintains RPM? Makes you wonder about the future of that package format. Unfortunately, it would not be an easy thing for Red Hat to switch to apt or anything else, we'll probably have multiple incompatible package formats for a long time to come.

Here's just some of what Linus says about binary modules.

"I'm a complete non-believer in binary modules"

"Basically, I want people to know that when they use binary-only modules, it's THEIR problem. I want people to know that in their bones, and I want it shouted out from the rooftops. I want people to wake up in a cold sweat every once in a while if they use binary-only modules."

I don't want to live in a world where companies like TiVo (although I love their DVRs) can use technological loopholes to build on the community's work while denying their end-users the ability to build on and tinker with the products they paid for. The open-source nature of Linux doesn't count for jack if your computer will only allow you to boot the signed copy of Linux that came preinstalled, and/or signed Linux upgrade CDs that you buy in a box at the store, does it?

Sadly, I can only provide a few tantalising hints. Not because I'm sitting on the information, but because very few people have written about this, and I haven't yet tried it myself.

Wikipedia on xD cards
Instructions to fit an xD card to a Mattel Juicebox
A comment on LWN from Wookey, who knows a lot about flash
xD card pinout

My best advice is to ask people on the linux-mtd mailing list for specific details.

Here's what Jesse Keating, Fedora's Release Engineer, has to say about Firefox and its security updates:

"firefox.org doesn't care about Linux. They produce "updates" that are first Windows precompiled binaries." [...] "They really really suck for trying to work out security updates, especially for Linux where they aren't providing the binaries. They care about what they provide as precompiled clients and nothing else (at least that's how it appears from the outside)."

http://lwn.net/Articles/204543/

This is fixed in the driver nvidia has marked stable.

For those who whine about "open source zealots who whine about open source drivers":

LWN.net (as usual) has a great write-up of the reasons to insist on open source drivers.

There are several good reasons. Open source drivers are *important*. It cannot be said that one truly supports Linux if one only does so with closed drivers.

I'll be in the market for a monster computer early next year. Planned to go AMD, but since there is no PCIe based card with open source drivers, I think I will have to go with Intel just to get their GMA3000 integrated graphics. It's that important.

(Although, the reverse engineered R300 drivers might be good enough by then. If so, AMD might be an option.)

More recent PREEMPT_RT benchmarks from the I-PIPE testing team, via Paul McKenney's earlier RT overview.

ADEOS - the microkernel used in RTAI - is "hard real-time", as is VxWorks. TimeSys' Linux patches are soft real-time.

Small correction: if by "TimeSys' Linux patches" you mean the -rt patchset that i'm maintaining (and to which Thomas is a major contributor), and in particular if you mean the CONFIG_PREEMPT_RT kernel feature, then the answer is a clear "no": it's not "soft real-time", it's intended to be "hard real-time" in the same sense as ADEOS/RTAI is.

The -rt patch-set implements a fully preemptible Linux kernel, which allows a higher-prio event to preempt any lower-prio processing: it can preempt device driver interrupt processing or other "irqs off" critical sections or other normally non-preemptible (for example spin-locked) code within the kernel, immediately. (it does all the necessary hard-real-time things one would expect: it pushes interrupt processing into special kernel threads, it implements priority inheritance for all Linux locking primitives to guarantee processing and to get out of priority inversion scenarios, etc.)

See more about the technology behind the -rt patchset in Paul McKenney's article on LWN.net, and on Kernel.org's RT Wiki. You can also try out an -rt kernel based Linux distribution yourself, grab a Knoppix-based PREEMPT_RT-kernel live-CD from: here.

RT has a pretty big speed penalty.

I can definitely say that unlike some other approaches, the -rt Linux kernel does not introduce a "big speed penalty".

Under normal desktop loads the overhead is very low. You can try it out yourself, grab a Knoppix-based PREEMPT_RT-kernel live-CD from here: http://debian.tu-bs.de/project/tb10alj/osadl-knopp ix.iso.

From early on, one of our major goals with the -rt patchset (which includes the CONFIG_PREEMPT_RT kernel feature that makes the Linux kernel "completely preemptible") was to make the cost to non-RT tasks as small as possible.

One year ago, a competing real-time kernel project (RTAI/ipipe - which adds a real-time microkernel to 'above' Linux) has done a number of performance tests to compare PREEMPT_RT (which has a different, "integrated" real-time design that makes the Linux kernel itself hard-real-time capable) to the RTAI kernel and to the vanilla kernel - to figure out the kind of overhead various real-time kernel design approaches introduce.

(Please keep in mind that these tests were done by a "competing" project, with the goal to uncover the worst-case overhead of real-time kernels like PREEMPT_RT. So it included highly kernel-intensive workloads that run lmbench while the box is also flood-pinged, has heavy block-IO interrupt traffic, etc. It did not include "easy" workloads like mostly userspace processing, which would have shown no runtime overhead at all. Other than the choice of the "battle terrain" the tests were conducted in a completely fair manner, and the tests were conducted with review and feedback from me and other -rt developers.)

The results were:

LMbench running times:

| Kernel............ | plain | IRQ.. | ping-f| IRQ+p | IRQ+hd|

| Vanilla-2.6.12-rc6 | 175 s | 176 s | 185 s | 187 s | 246 s |
| with RT-V0.7.48-25 | 182 s | 184 s | 201 s | 202 s | 278 s |

(Smaller is better. The full test results can be found in this lkml posting.)

I.e. the overhead of PREEMPT_RT, for highly kernel-intensive lmbench workloads, was 4.0%. [this has been a year ago, we further reduced this overhead since then.] In fact, for some lmbench sub-benchmarks such as mmap() and fork(), PREEMPT_RT was faster.

(Note that the comparison of PREEMPT_RT vs. I-pipe/RTAI is apples to oranges in terms of design approach and feature-set: PREEMPT_RT is Linux extended with hard-realtime capabilities (i.e. normal Linux tasks get real-time capabilities and guarantees, so it's an "integrated" approach), while ipipe is a 'layered' design with a completely separate real-time-OS domain "ontop" of Linux - which special, isolated domain has to be programmed via special non-Linux APIs. The "integrated" real-time design approach that we took with -rt is alot more complex and it is alot harder to achieve.)

See more about the technology behind the -rt patchset in Paul McKenney's article on LWN.net, and on Kernel.org's RT Wiki.

Linux has made major progress in the real-time area. But it still doesn't have everything needed.

Many drivers are still doing too much work at interrupt level. There are drivers that have been made safe for real time at the millisecond level, but that's not universal. Load a driver with long interrupt lockouts and your system isn't "real time" any more. This is the biggest problem in practice. There are too many drivers still around with long interrupt lockouts.

That's where my -rt patchset (discussed by Thomas in the article), and in particular the CONFIG_PREEMPT_RT kernel feature helps: it makes all such "interrupt lockout" driver code fully preemptible. Fully, totally, completely, 100% preemptible by a higher-priority task. No compromises.

For example: the IDE driver becomes preemptible in its totality. The -rt kernel can (and does) preempt an interrupt handler that is right in the middle of issuing a complex series of IO commands to the IDE chipset, and which under the vanilla kernel would result in an "interrupt lockout" for several hundreds of microseconds (or even for milliseconds).

Another example: the -rt kernel will preempt the keyboard driver right in the middle of sending a set of IO commands to the keyboard controller - at an arbitrary instruction boundary - instead of waiting for the critical section to finish. The kernel will also preempt any network driver (and the TCP/IP stack itself, including softirqs and system-calls), any SCSI or USB driver - no matter how long of an "interrupt lockout" section the vanilla kernel uses.

Is this hard technologically? Yes, it was very hard to pull this off on a general purpose OS like Linux (the -rt kernel still boots a large distro like Fedora without the user noticing anything) - it's the most complex kernel feature i ever worked on. I think the diffstat of patch-2.6.18-rt5 speaks for itself:

613 files changed, 22401 insertions(+), 7903 deletions(-)

How did we achieve it?

The short answer: it's done via dozens of new kernel features which are integrated into the ~1.4MB -rt patchset :-)

A longer technical answer can be found in Paul McKenney's excellent article on LWN.net.

An even longer answer can be found on Kernel.org's RT Wiki, which is a Wiki created around the -rt patchset.

You just mount your disk under linux or whatever and replace ci.dll with one that always returns "yeah this file hashes OK". Could probably do it with a hex editor.

Counterpoint:

A TPM-equipped system requires support in the BIOS. Before the system boots, the BIOS will "measure" the current hardware state, storing the result in a PCR. The boot loader will also be checksummed, with the result going into another PCR. The boot loader is then run; its job is to stash a checksum of the kernel into yet another register before actually booting that kernel. Once the kernel is up, the "trusted software stack" takes charge of talking to the TPM, providing access to its services and keeping an eye on the state of the system. Systems which provide a TPM typically also include the needed BIOS support; this support could also be added by projects like FreeBIOS and OpenBIOS. There are versions of the Grub bootloader which can handle the next step; LILO patches also exist. Once the kernel is booted, the TPM driver takes over, with the user-space being handled by the TrouSerS TSS stack.

source

Seems like this is possible in Linux today, and is a good idea in my opinion.

Caveat: your Designed For Windows Vista computer may not boot anything else in the near future....

Also note that the linuxppc project seems to have died out as he retired from the project about a years after. There are apparently alternatives that work. So maybe it'll all work out one way or another, no matter what happens to the developer. Dammit, we're all dispensable, people!

I was speaking on the general state of windows computing. Currently under XP this can happen if you're not careful what you check. I had someone ask me about this just yesterday. MS isn't known for admitting they screwed up and backtracking on something like that. If they have, great, but the fact of the matter is they already went down that road. Its just proof that they have no problem testing the waters with highly restrictive DRM.

I'll check that out next time I boot my XP to play The Sims 2 (Currently gives me some minor graphical glitches in Vista RC2 that I haven't bothered investigating). If you would be so gracious as to provide proof positive that Microsoft did make copy protection the default for MP3s in any iteration of Windows Media Player that made it to XP, please let me know since I'm going to be so gracious as to provide links to you that you requested.

and I doubt they form 51% or more of MS customer base.

So we only care about the majority of users with something that's entirely optional. Yeah, that makes a lot of sense to provide all these tools for creating your own music, video, whatever with tools that come with Vista, and instead of making it easy on content creators large or small, we decide to instead tell them that they need to go elsewhere for that when it's trivial to implement? That makes no business sense.

As for your education, here you go oh lazy one:

on DRM in KPDF

Re: DRM-crippled Banshee has no copyleft protection

Torvalds: "DRM is Perfectly OK with Linux

Linux and DRM - succeeding where MS failed?

The RIAA - Hollywood - DRM - Linux Suicide Pact

GStreamer to support DRM

They will probably do what tivo did.

>> it's not a EULA. It's simply a contract

The FSF begs to differ on the latter.

Prof Eben Moglen is the Free Software Foundation's attorney, and of course is strongly involved in framing the GPL's legal content. And in the detailed article "The GPL Is a License, not a Contract", Prof Moglen says very clearly that:

" The GPL, however, is a true copyright license: a unilateral permission, in which no obligations are reciprocally required by the licensor."

It really doesn't get much clearer than that. Read the whole article though for Pamela Jones' typically detailed explanation. Even some lawyers on Slashdot seem to be getting that point wrong.

  The word 'license' has, and has had for hundreds of years, a specific technical meaning in the law of property. A license is a unilateral permission to use someone else's property. [cut]

A contract, on the other hand, is an exchange of obligations, either of promises for promises or of promises of future performance for present performance or payment. [cut]

The GPL, however, is a true copyright license: a unilateral permission, in which no obligations are reciprocally required by the licensor. [EM]

http://lwn.net/1998/0924/

Sorry, I didn't quote the URL in the parent post (so slashdot removed it).

Why are we making life so much easier for crackers?

I pick on Ubuntu in particular as it is by a large margin the most popular desktop Linux distro.

Debian's problem has always been that its handlers place users and the usability of their distribution far below very petty internal arguments intended to frame the distro as some sort of legal pioneer

Debian did not choose this battle. They have been distributing Firefox for years in the same way they distribute other open source software. It was Mozilla who forced the issue by threatening legal action if Debian doesn't change the name or start submitting all patches (even security patches) to Mozilla for permission before they are applied. Mike Conner of Mozilla says "you should consider this, as I previously said, notice that your usage of the trademark is not permitted in this way, and we are expecting a resolution. If your choice is to cease usage of the trademark rather than bend the [Debian Free Software Guidelines] a little, that is your decision to make."

Debian asked "could we at least get a stay of execution? Etch is going into deep freeze in less than a month. Would it be possible to resolve this after the release?" and Mozilla responded that "If we were forced to revoke your permission to use the trademark, freeze state would not matter, you would be required to change all affected packages as soon as possible. Its not a nice thing to do, but we would do it if necessary, and we have done so before."

Many legal squabbles are instigated by Debian, but this isn't one of them. Mozilla has forced the issue. Linux Weekly News wrote a good summary of the situation.

-Fyodor
Insecure.Org

Rich.

The problem with the GPLv3 is that it makes a lot of demands on how end-users should be able to use the software.

For one thing, it demands that the end-users be able to modify the software. A lot of hardware manufacturers don't even have programmable firmware. Are they going to go out of their way, and increase the cost of the product, to give this capability? And what about the liability concerns that this opens up. If they provide a formally supported mechanism to change the software on the device-- which they must, according to the ideals expressed in the GPLv3-- they may be liable for when someone changes this software.

All of these issues are very vague. Is the company acting in bad faith if it ships its embedded Linux with just exactly enough hard disk space to run the software it ships with, but no more? Is the company acting in bad faith if the product needs to interact with another, closed source product in order to usefully function? What if the closed source product isn't even under their control, or contains DRM? What if the product can operating in a degraded mode without DRM, but needs DRM to get full performance?

The whole area is a legal minefield, as Linus and other kernel developers have pointed out time and time again. A lot of these legal issues are more complex than you think. In some cases, new law is being made even as we speak. It's very foolish to claim that any issue related to the GPLv3 is settled until a judge has made a ruling. And even then, that ruling only applies in the relevant country.

On the whole, the whole GPLv3 effort is just a very complicated political game trying to achieve something that can't be achieved by a software license-- the rollback of DRM and the service-based internet economy. It will fragment the open source community and scare away business investment.
Linus understands this and is coming out against it. Good for him.

Well, the BSD license is best for mulching babies.

Jumping in...

...and these guys are preemptively coming out and saying that it wouldn't be a good idea even if it were possible.

So why didn't they just announce that it isn't possible and stop there? Why go further with the value statements about GPLv3? This would certainly have sufficed if their purpose was just to discuss v3 as it relates to the kernel:

"The kernel is at GPLv2 and will stay that way, end of story. For those of you who dearly love GPLv3 for whatever reason, sorry, we can't do it with the Linux kernel. If you really want a full GPLv3 toolchain check out (... list of obscure kernels that are GPLv2 and could go GPLv3 ...) or fork a BSD kernel."

I read the thread at http://lwn.net/Articles/200422/ and I have to agree that it sounds fishy that they went to all this trouble. So they are critical developers, well experienced, etc., but if they are so cool with Tivo DRM (because Tivo does return source code), why do they care if the GNU toolchain goes GPLv3? Someone else on the thread mentioned that embedded consumer devices will likely work from a GPLv2-only fork of the toolchain as if that's a bad thing. If all they care about is the fact Tivo et al return code to the kernel, why should they care if Tivo et al deliberately choose to use an obsolete glibc?

Their fundamental argument seems to be: "We're engineers and we're happy that this high-quality product is both available for end users " (me: who they still seem to think means device manufacturers rather than consumers) " and for us to play with, and so long as the source is available to us under the same terms we made it available to everyone else we are happy."

Yet they are saying in the thread: "Third parties will restrict all users freedom; that is a given. They will select software that enables their business objectives. ... What is going to be the impact of adopting GPLv3? You wont have anyone using your software."

Is this really their beef with GPLv3? If so, it sounds like they're more in it for the notoriety ("my code runs all over!") than any kind of technical achievement.

I'm not dissing their technical merits, but I have to agree with other threads here that their statement about GPLv3 is not well supported factually, seems to (deliberately) misunderstand GPLv3 (especially the DRM and patent clauses), and serves only to provide cover for embedded device manufacturers over the concerns of both distros and end users. It feels very much like a group of people who are defending their lucrative industry niche at the expense of the very factors that helped create that niche in the first place.

he was talking about the statement. you're talking about the poll.

he was talking about the statement. you're talking about the poll.

http://lwn.net/Articles/199838/

ready for a dunking

third picture down

sorry bdale :)

http://lists.freedesktop.org/archives/xdg/2006-Apr il/008012.html
http://lists.freedesktop.org/archives/xdg/2006-Apr il/008025.html
http://lwn.net/Articles/178411/
http://lwn.net/Articles/178409/

http://lists.freedesktop.org/archives/xdg/2006-Apr il/008012.html
http://lists.freedesktop.org/archives/xdg/2006-Apr il/008025.html
http://lwn.net/Articles/178411/
http://lwn.net/Articles/178409/

And here I thought this one was enough to get those damn things pulled.

Of course you lose personalization when you're anonymous. The reporter should change his name to TautologyMan.

Cookies are less of an issue if you use a proxy that rewrites them on the fly to be session-only and encrypted (like anonymizer.com, if they're still running).

Here are some of the real problems.

To provide reasonable anonymity your proxy has to block Java and Javascript. Many sites will stop working.

Given my line of work I researched Tor and out of the first N places I tried to visit, the fraction that blocked Tor exit nodes was 100%. Now that's a real inconvenience.

If you're using a single-stage proxy instead of Tor then the anonymizing proxy might be a honeypot.

A single-stage proxy only protects you from being identified by the destination web site. Your ISP could still have records of where you went and when.

You're still identifiable by the remote site if you've ever visited it before, if it left a cookie, and if you don't have something in place to block cookie transmission. One visit to cheerleadersincombatboots.com you might explain as a slip of the mouse, weekly visits over a year could get you in trouble.

It's hard to get IP-hiding proxies right. Your IP might leak if there's a transparent proxy between you and the anonymous proxy, if you use Internet Explorer, or you could be hit by a bug in the anonymous proxy's Javascript blocking. How many undiscovered, unfixed, or reintroduced bugs are there in whatever anonymous proxy you use?

You do seem to understand my point... but in your original post you implied that dropping NAT would decrease security, which is not the case.

We have to get rid of NAT as soon as possible. In some countries users are already behind as many as five levels of NAT!

It's unfair for the Debian maintainers to criticise Schilling

If you RTFA, you'll see he's talking about Linux, not Windows. He's probably referring to Van Jacobson's network channels. But the momentum is slowing down as implementation issues are uncovered, and the odds are that it's probably not going to happen anytime soon.

If you RTFA, you'll see he's talking about Linux, not Windows. He's probably referring to Van Jacobson's network channels. But the momentum is slowing down as implementation issues are uncovered, and the odds are that it's probably not going to happen anytime soon.

If you RTFA, you'll see he's talking about Linux, not Windows. He's probably referring to Van Jacobson's network channels. But the momentum is slowing down as implementation issues are uncovered, and the odds are that it's probably not going to happen anytime soon.

The problem is that general-purpose cpus grow in power so quickly that the offload-engines get ever-larger problems beating them. And they get the aditional problem that they don't get packet-filtering or anything else that is not custom-written for that particular card (if it's even possible to convince the card to do it!)

It's also nothing new -- these cards have existed for literally decades, and haven't managed to make any kind of inroads, not even in specialized servers.

Have a look at this year-old Lwn-article for an example listing some disadvantages.

You should have stopped with your last comment - you've gone beyond stupid now.

You cannot report bugs to the kernel team if your kernel includes third party code

Dumb. They're not third party drivers they're included in the main kernel tree. The rest of your little rant their is based on that first, incorrect presumption.

It is an absolute fallacy that open source automatically means it is being audited by....

Dumb straw man. I didn't say open source automatically gets audited - I said the linux kernel is audited.

And it is. There's the sparse kernel auditing project, the coverity people are doing a free, ongoing audit, the ongoing LKAP (linux kernel auditting project), I could go on and on.

The openness or closedness of code has no bearing on the capacity for an audit.

Beyond stupid. Open code can be independantly audited. Closed code cannot. Do you even read what you write? Tell me how I can run sparse on the nvidia source code.

And I'll stick with the current best video card and driver combination available for Unix and Unix look-alikes.

I think you meant to say 'fastest' rather than 'best'. And nvidia does not release a driver for UNIX that I'm aware of.

I've never encountered a proprietary format for my data that I couldn't convert into something else.

You must be exceedingly fortunate, an ace programmer, or woefully inexperienced. See the second lesson in A couple of lessons on the hazards of proprietary software, for a recent real life example.

Some people want to impose their definition of "free" onto me and tell me I shouldn't be allowed to choose proprietary software, the opposite of freedom.

That logical fallacy right there isn't even suitable for scaring away crows, it's such an old canard. Please pardon the pun.

IIRC that was the reason why there is no full GNOME in Slackware.

Actually, GNOME was dropped in Slackware because it was taking up so much of Patrick's time that the system as a whole was suffering -- it had nothing to do with X.org 6.9, which by the way didn't even exist at the time. In addition, there were already two whole communities of developers (perhaps three? gware, dropline, and freerock) putting time and effort into making their own GNOME distributions specifically for Slackware. But don't take my word for it...read all about his decision from http://lwn.net/Articles/129282/:

New Entry: gnome/*: Removed from -current, and turned over to community support and
New Entry: distribution. I'm not going to rehash all the reasons behind this, but it's
New Entry: been under consideration for more than four years. There are already good
New Entry: projects in place to provide Slackware GNOME for those who want it, and
New Entry: these are more complete than what Slackware has shipped in the past. So, if
New Entry: you're looking for GNOME for Slackware -current, I would recommend looking at
New Entry: these two projects for well-built packages that follow a policy of minimal
New Entry: interference with the base Slackware system:
New Entry:
New Entry: http://gsb.sf.net/
New Entry: http://gware.sf.net/
New Entry:
New Entry: There is also Dropline, of course, which is quite popular. However, due to
New Entry: their policy of adding PAM and replacing large system packages (like the
New Entry: entire X11 system) with their own versions, I can't give quite the same sort
New Entry: of nod to Dropline. Nevertheless, it remains another choice, and it's _your_
New Entry: system, so I will also mention their project:
New Entry:
New Entry: http://www.dropline.net/gnome/
New Entry:
New Entry: Please do not incorrectly interpret any of this as a slight against GNOME
New Entry: itself, which (although it does usually need to be fixed and polished beyond
New Entry: the way it ships from upstream more so than, say, KDE or XFce) is a decent
New Entry: desktop choice. So are a lot of others, but Slackware does not need to ship
New Entry: every choice. GNOME is and always has been a moving target (even the
New Entry: "stable" releases usually aren't quite ready yet) that really does demand a
New Entry: team to keep up on all the changes (many of which are not always well
New Entry: documented). I fully expect that this move will improve the quality of both
New Entry: Slackware itself, and the quality (and quantity) of the GNOME options
New Entry: available for it.
New Entry:
New Entry: Folks, this is how open source is supposed to work. Enjoy. :-)

If the spammers are now sending round Gutenberg texts, this is entirely appropriate. Project Gutenberg caused probably the first ever spam, when Michael Hart launched the project by trying to mail everyone on ARPANET with the U.S. Declaration of Independence. (source)

* Opinder Bawa has one filing for having sold 15,000 shares, and another for 8,000 shares. He would appear to have sold all the shares he possesses (but he still has a lot of options).

* Robert Bench has three filings: 7000 shares, 5000 shares, and 4100 shares.

* Jeff Hunsaker sold 5000 shares at the beginning of June.

* Darl McBride sold 7000 shares just after the suit was filed.

That's millions of dollars in stock sales. Given that the stock price skyrocketed when they announced the lawsuit, and the executive stock dumping began shortly thereafter, what do you make of this situation?

• The VMI virtualization interface
  
• Linux team tells VMware and Xen to get their acts together

• The VMI virtualization interface
  
• Linux team tells VMware and Xen to get their acts together

You joke, but that was one of the (many, excellent) points of Van Jacobson's recent net channels presentation. From his slides:

Networking gear has gotten fast enough (10Gb/s) and cheap enough ($10 for an 8port Gb switch) that it's changing from a communications technology to a backplane technology.