Slashdot Mirror

I have to say that Walther's rant in that thread has significantly diminished my sympathy for the database project. I don't think it warrants comparison to a life and death situation and the suggestion that Mozilla pay restitution to the database project is ridiculous. IMHO the longer this goes on the worse the database people are going to come out of it. To date they've had a good amount of support from most media, but threats of lawsuits, email bombing campaigns, and ad hominem attacks on Mozilla project members will turn people against them.

> RedHat: You either pay or don't (download). It's Linux.

That's fine for your boxes at home, but I have a feeling most legitimate companies are going to pay for support. In fact, I think the fact that it is "free" is one reason some managers are afraid of it. It doesn't cost as much, so it must not be as good.

> Documentation: Windows: None

Yeah right.

Besides, although I admit I only skimmed the article, it appears it was about how Windows Server 2003 offers better performance as a file server than RedHat. It wasn't about which one was all around "better". Anyway, it's just one report - It's been said before.

Oh yeah, and in case you didn't know, Pepsi is still better than Coke.

2003: Linux Desktop Myths (wonder when LWN will post something?)

So while we wait for LWN, here's my best shot:

Myth: Linux Will Be Less Expensive

Real Myth: Using free cross platform apps lowers the cost of Windows, therefore Linux offers no additional savings.

Myth: Linux Is Free

Real Myth: Microsoft includes support for licensed desktop windows. So to compare costs, you simply compare the license fees paid to Microsoft to the "enterprise support" fees paid to a company like Redhat. You can't compare "free" linux to license windows because of the support bundled with very licensed desktop windows.

Myth: Linux Means No Forced Upgrades

Real Myth: You will not be able to pay anyone else for provide support once it is no longer available from the original linux distributor, and you will not be able to support it in-house. The discontinuance of support is a "forced upgrade" as compelling (and legally binding) as a contract which requires upgrades to maintain discounted pricing.

Myth: Linux Management Is Easier

Real Myth: Users will still screw up their systems as they do with windows ('cause they'll all be running as root?)

Myth: Linux Has a Lower TCO

Real Myth: System admins can't manage linux well, because they also manage windows poorly (presumably because the two system are so similar and both similarly lacking built-in remote management)

Myth: Linux Means Longer Hardware Life

Real Myth: Older PCs require "expenditure" for [free] software upgrades at least one. Thus it would be less expensive to simply discard the hardware! (yet still "spend" for the software update). Likewise, keeping PCs longer means more different (all PC compatible) models will be present, which costs more to "support" than simply discaring those older PCs and buying new ones.

Myth: Skills Are Transferable

Real Myth: Your existing desktop support staff are old dogs who can't learn new tricks.

Slashdot is a bit late to this story, actually. Messman pretty much just stuck his foot in his mouth, if he was even quoted correctly. Check out Bruce Peren's comment, and a response from Kristopher Magnusson (chair of Novell's Open Source Review Board) at http://lwn.net/Articles/28988/. Novell does seem to understand that Linux already has value, they just want to bring their value to the table.

I've almost got to believe that Jack Messman was trying to make some kind of joke about the SCO/IBM lawsuit in this comment, and has just been horribly mis-understood.

It's not that funny but people are always leaving the defaults (linksys, tsunami, etc)

Kids please remember to read the WLAN Security FAQ before playing.

A comment at Linux Weekly News links to Matt Wilson's explanation:

In the past we would never have tackled something as massive and invasive as a new threads implementation just after a ".0" release (in this case, 8.0). ... With the introduction of the full family of Red Hat Enterprise Linux product we now have the flexibility to incorporate the best technology ... when they're ready.

I've always viewed Red Hat's extensive patches as a risk. The kernel package, for example, typically includes hundreds of patches. Now that the core distribution is essentially being treated as a perpetual beta, I just can't see myself staying on Red Hat much longer.

Jeepers will you all cut it out already. Let the man try Redhat, and let him hear about the alternatives: here here here here and here.

Ten'll get you one he'll eventually be installing this distro with a 2.6 kernel and either Redhat or Debian based, and he won't give a rat's ass about all this trash you're talking.

We now return you to your regularily schedualled flamewar...

But I hope Bruce and others won't lose time pointing out the implications for people who want to participate in programs like MSFT's "shared source". They open themselves up to later lawsuits if they later develop or distribute anything technologically related, even if it isn't textually derived from the original.

It is an interesting counterpoint in case Microsoft wants to use the lawsuit in any anti-linux campaign ...

Check here, here, and here (I know that ha isn't exactly hot-swapping, but if you can bring up a new server and take down the old one without a hitch, then doesn't it do the same thing?). Also, I would suggest a Google search for "linux cpu hot-swap."

Check here, here, and here (I know that ha isn't exactly hot-swapping, but if you can bring up a new server and take down the old one without a hitch, then doesn't it do the same thing?). Also, I would suggest a Google search for "linux cpu hot-swap."

...of course, LWN readers knew about the anticipatory scheduler back in January. We also looked at the SFQ and CFQ I/O schedulers two weeks ago.

...of course, LWN readers knew about the anticipatory scheduler back in January. We also looked at the SFQ and CFQ I/O schedulers two weeks ago.

slashdot.org
newsforge.com
theregister.co.uk
my university's daily newspaper (no link!)
fark.com
the smirking chimp
dr. fun
the daily vault (although i review there once in a while)
google news
daily rotten
lwn.net
crackmonkey archives
the dot
kde-look.org
corona's coming attractions
snopes' update page
doc's weblog

And I think that's about it for a daily basis.

If I believe you and use only free software, will you pay my legal fees and damages if any of them infringe on a patent? After all, you appear to be guaranteeing that all free software authors obey patent laws.

Linus Torvalds, for example, implied that Linux may be infringing. It's sensible and practical not to care, as he suggests, but that only lowers the damage (willful versus negligent infringement), not remove it.

The question is, if Linux in fact infringes on a patent (and its main author doesn't know it doesn't), who pays? It's a very good question, if this sort of lawsuits become more popular. It's possible that one day you'll be choosing between commercial software that explicitly protect against patent lawsuits, and free software with a third-party patent insurance.

Why has Slashdot not mentioned the recent Debian trojan horse? Open Source is not impervious to bugs or trojan horses.

The trojaning of mICQ :

The story, it seems, is this: Rüdiger Kuhlmann, the maintainer of mICQ, had a disagreement with Martin Loschwitz, the maintainer of the Debian mICQ package, on how that package should be built. Mr. Kuhlmann complained that an old version of mICQ was shipped, that it contained bugs which had been fixed upstream, and that his name had been removed from the copyright file. The disagreement had apparently been going on for a while.

Mr. Kuhlmann decided that enough was enough, and he was going to take some action. As of mICQ 0.4.10.1, the code will, when built for the Debian distribution, print out a message which says some unflattering things about Mr. Loschwitz and encourages use of a different version; the program then exits. In other words, when built for Debian, mICQ thumbs its nose at the user and refuses to run. To help ensure that this code got into the official Debian version, it was written in an obfuscated manner, set to trigger only after February 11, and only if it was not being run by Mr. Loschwitz.

Two key points are that (1) most of the bugs Reasoning found are false alarms (which is an occupational hazard for this kind of analysis), and (2) one reason Linux does so well is that those lunatics at Stanford have been doing just this kind of analysis for quite some time, so most of the easily-found bugs were found long ago.

This doesn't invalidate any of their conclusions, of course: the Stanford lunatics haven't been analyzing NT, they've been analyzing Linux, and for sound academic reasons.

The Secure Attention Key (SAK) is there for just this purpose. Although according to this it has had issues.

I've read that that the ext2 filesystem can support ACLs but not many have implemented them.

A quick Google search brought me to this patch for ACL for ext2 with mention of POSIX ACLs, so I'm not crazy.

I've worked with Novell and WinNT in a production environment and find that fine grained access controls are an incredible pain in the ass. If I can maintain a tiered inherited simple structure then my life is much simpler than if this group wants to share one file in their folder with person A in city X but this file is for person B in city Y but they shouldn't see the rest.

Then later on a stupid coworker gives person C read access (or worse yet full access) to the root volume because of rights confusion. That happens too frequently: a lazy or hurried admin just gives full access to get the production issues smoothed out at great risk to security. (No one's deleted anything, but has a worker noticed at some point that he was able to view his senior manager's sensitive documents before I caught the error? I hope not.)

I avoid the convoluted ACL situation where possible and keep separate folders for separate ACLs/permissions and try not to subtract from inheritence.

"More recently, the NUMA scheduler patch has been reworked (by Martin Bligh, Erich Focht, Michael Hohnbaum, and others) around a simple observation: most of the NUMA problems can be solved by simply restricting the current scheduler's balancing code to processors within a single node. If the rebalancer - which moves processes across CPUs in order to keep them all busy - only balances inside a node, the worst processor imbalances will be addressed without moving processes into a foreign-node slow zone. A simple (three-line) patch which did nothing but add the within-node restriction yielded most of the benefits of the full NUMA scheduler; indeed, it performed better on some benchmarks. Real-world loads, however, will require a scheduler which can distribute processes evenly across nodes. Occasionally it is necessary, even, to move processes to a slower node; a lot of CPU time on a lightly-loaded node will give better performance than waiting in the run queue on a heavily-loaded node. So a bit of complexity had to be added back into the new scheduler to complete the job."

Extracted from:
http://lwn.net/Articles/20741/

You are correct. The LWN article on this just became available to non-subscribers and you can read it here:http://lwn.net/Articles/20741/

(BTW. Everyone should subscribe to LWN. It's an exceptional value)

See the good discussion in the LWN article on this topic.

Way back in December LWN covered this and I think Alan Cox voiced his thought that people (not RedHat) may try and make a business out of support 6.2. Now there's an idea...

It's 2GB, but yes, it is true, HURD is the pinnacle of what happens when you just let people do what the hell they like without any management whatsoever. All you programmers might hate your managers, but honestly, without them, you'd end up with HURD-like projects -- a decade late, and still half a decade to go.

perhaps submitters could either take the trouble to write things in their own words, or save space on slashdot and simply link to the word-for-word-identical original news item. Or at the very least, credit the source.

See BeroLinux on SF which was then integrated to Linux Mandrake PR

Actually, that reminds me of a quote from Linus Torvalds:

Quite frankly, I don't _want_ people using Linux for ideological reasons. I think ideology sucks. This world would be a much better place if people had less ideology, and a whole lot more I do this because it's FUN and because others might find it useful, not because I got religion.

Some companies have adopted a hybrid business model where proprietary software products are used to help fund free software development. In your view, is this an appropriate way to raise the money to pay for free software projects?

Yes, I could really use a debugger that runs backward for a problem I'm having recently. I wrote about it here last month:

Shaver pointed out this message. Apparently Michael Chastain wrote the very program I'm looking for, back in 1995. Nobody cared, the kernel APIs kept changing underneath it, and it died on the vine.

[...] The replayer is the cool part. It takes control whenever the target process executes a system call, annuls the original system call, and overwrites the target process registers and address space with the values that I want to be in there.

[...] If I put memory-access rule checking in at replay time, I can do better than e-fence, on stock binaries with no recompilation. Hell, I can do better than Purify on stock binaries and without tangling with their object-code-insertion patents.

I have enough information available in the proxy ptrace filter to implement PTRACE_SINGLESTEP_BACKWARDS. How would you like to have that capability in gdb? "Execute backwards until this data watchpoint changes." Imagine a graphical debugger with a scrollbar for time, where the top is "beginning of execution" and the bottom is "end of execution."

Yay progress.

Ok, the rest of his message reads as a ``why does my genius go unappreciated'' whine, but still, I want this program! The code is still available, but I'm sure not feeling motivated to try and port it to run on a modern kernel (it doesn't even support ELF binaries...)

It looks like after this message was sent to the linux-kernel list in 1999, there was a whole lot of talk, then three years of zilch. I mailed to ask if any progress was ever made. The answer was no: nobody ever made it work on modern systems.

Yes, I could really use a debugger that runs backward for a problem I'm having recently. I wrote about it here last month:

Shaver pointed out this message. Apparently Michael Chastain wrote the very program I'm looking for, back in 1995. Nobody cared, the kernel APIs kept changing underneath it, and it died on the vine.

[...] The replayer is the cool part. It takes control whenever the target process executes a system call, annuls the original system call, and overwrites the target process registers and address space with the values that I want to be in there.

[...] If I put memory-access rule checking in at replay time, I can do better than e-fence, on stock binaries with no recompilation. Hell, I can do better than Purify on stock binaries and without tangling with their object-code-insertion patents.

I have enough information available in the proxy ptrace filter to implement PTRACE_SINGLESTEP_BACKWARDS. How would you like to have that capability in gdb? "Execute backwards until this data watchpoint changes." Imagine a graphical debugger with a scrollbar for time, where the top is "beginning of execution" and the bottom is "end of execution."

Yay progress.

Ok, the rest of his message reads as a ``why does my genius go unappreciated'' whine, but still, I want this program! The code is still available, but I'm sure not feeling motivated to try and port it to run on a modern kernel (it doesn't even support ELF binaries...)

It looks like after this message was sent to the linux-kernel list in 1999, there was a whole lot of talk, then three years of zilch. I mailed to ask if any progress was ever made. The answer was no: nobody ever made it work on modern systems.

I haven't used a debugger in almost two years. I think the solution to diagnosing problems is to have in place a good logging framework (such as Log4J), which allows you to specify the verbosity of logging per subsystem. (Most people's complaints about using logging is that the noise/signal ratio is often too high to be useful.)

Usually, with a complicated program, it's fairly difficult (in an IDE) to trace the execution flow without stepping into the wrong subroutine or accidentally stepping over the routine you're really interested in. In a lot of cases, it will take more time setting up your IDE or debugger to do what you want, than it is to simply set up useful log statements that capture what you're really interested in. If you set up all your objects in Java to return useful debug strings from the "Object.toString()" method, you don't really need to use an IDE for inspectors or watches: You can customize debug information, avoiding information overload, and allows you to present just the critical data.

For memory profiling (leaks), disassemly, and performance analysis, a proper tool is very worthwhile. And I think that getting a stack trace from a core dump file useful. For everything else, I agree with Linus that debuggers don't really help you be more careful.

Linux Weekly News is a great example. They need cash but are only offering subscriptions.

Most of their stuff I don't want to pay for: just the weekly digest which I'd be happy to pay (say) $0.05 or $0.10 for. Other people might like to look at some of their deep-level kernel explanation articles.

The deployment never happened, and that was reported pretty widely (e.g., here). This wasn't a problem with Linux, it was a problem with politics and funding. And, frankly, in that kind of situation, I think Linux is better deployed through an incremental grass-roots effort anyway. The Danish approach seems better.

Also have a look at this comment from Bruce Perens and this comment from Eric S. Raymond from when the same thing happened in USA nearly two years ago.

-Filik.

Anarchy Online uses QT.

Perhaps you are also interested in reading this press release/article on Linux Weekly News.
Just FYI :-)

Poorly organized. Lynx-optimized website (with only two pages), only two months to write papers, an overly broad topic, and being held in a pseudo-third world country, away from the main countries where most research is being done, don't exactly add up to success. I'll be surprised if they register more than 500 attendees.

Everyone so far has said "slashcode". I don't think that's a good idea. I doubt the kind of "peer review features" offered here will help, and I doubt it's easy to extend to what you want. The same goes for PHP-Nuke and others.

Here's a slightly less obvious answer. LWN is doing something a little closer to what you're talking about. They have subscription and delayed release for non-subscribers. They are planning to release their code, which is based on Quixote.

You have given very little information, so perhaps you can expect only answers like "slashcode" and "LWN". It depends on many things including the subject matter of the journal, what sort of mark-up and formatting is involved, and how much special typesetting you want in the printed editions. If it's not-for-profit, how about staying out of dead trees altogether?

I wish journals -- and websites -- would keep it simple.

Actually, a challenge to the law's validity is brought at the outset. Elcomsoft did so and lost.

I just didn't want people going off on what a terrible law it is, or that it violated free speech.

Sorry guess again. He/She did have a valid point. Check it out.

To all of those worried about LVM: 2.6 will include a LVM implementation. The EVMS won't make it though.

The story is that 2.4 included LVM1 (I am running it right now on my RH8 box) which had some restrictions and were generally regarded as a kludge. For the 2.6 kernel two competing replacements arised: LVM2 and EVMS. LVM2 is basicly a rewrite of LVM1 while EVMS is an entirely different beast aimed at the BIG IRON in the datacenters. After some (heated) discussion on LKML Linus decided to include LVM2 and scrap EVMS.

The reaction from the EVMS team (sponsered by IBM) was noble: They decided to remove their kernel-land code and rewrite their user-land utilities to use the winning LVM2 kernel interface and create a win-win situation for everyone. Kernel traffic covered the story here and Linux Weekly News made a mention of it here.

I suggest keeping tabs on LWN's weekly kernel page for good explanations of what's going on...you can also read Kernel Traffic, which, although it is usually fairly technical, tends to give you the gist of what is going on in the world of the kernel devs. Good luck-

OK, Here I go again, tilting at /. windmills, but it needs to be said again: PATENTS ARE GOOD, and they **PROTECT** the ability of individual inventors to pursue real innovation. Good patents in no way inhibit the pace of innovation, but rather they are the strongest protection possible to allow the inventor to be able to bring his invention succesfully to market so you and I can buy it.

Here's what I had to say about it in a letter to LWN a while back:

http://lwn.net/2000/0420/backpage.phtml#backpage

And perhaps more importantly, here's what James Dyson has to say, which is essentially the same thing: (Dyson is the famous inventor of the phenominally successful and innovative Dyson vacuum cleaners that have vacuumed up the competition virtually everywhere but the US, where they are just now becoming available.) http://www.dyson.co.uk/invent/default.asp

I know too many of you have fallen for the FSF's party line of patent demonization, but eliminating Patents would only ensure that the likes of Microsoft would roll completely unopposed over any potential competition.

sPh

Gee, maybe all that's why people are going to things like multiple cores on one die, hyperthreading, etc. Programming-wise, these present the same interface as multiple physical CPUs, but they also ameliorate many of the problems you mention...

...everything you're presenting as a "killer" for multithreading is even worse for your multi-process model.

Getting rather far afield here, aren't you?

Most serious programs outside of the scientific community are I/O bound anyway and the whole point of multithreading is to increase parallelism.

You're forgetting that an operation's effect on performance is a product of its cost and frequency.

What about those that can't?

That's a lot of applications, including important ones like databases which must preserve operation ordering across however many threads/processes/nodes are in use.

I wonder if databases will be that hard, though. Good ones already provide on-line replication and failover, multi-version concurrency, and transactions that automatically roll-back if a collision is detected.

You can't just point to some exceptional cases that are amenable to a particular approach, and then wave your hands about the others. Well, you can - you just did - but it doesn't convince anyone.

Since you're practically an AC I can't be sure, but odds are pretty good that I know more about what the Linux kernel is doing and excellent that I know more about what kernels in general are doing.

Your appeal to (anonymous) authority won't get you anywhere.

But since you can't be arsed to do it, here's a link to search Google for "Linux per-cpu". See? Tens of thousands of hits. If you add "allocator" to the search criteria, this is the first hit. It assumes background knowledge, but should make sense.

The real point that we started with is your claim that any multithreaded application will "suck". That statement only has meaning relative to other approaches that accomplish the same goals.

The statement was "If you have a few million tasks to do, pretty much any threading system is going to suck."

The context makes it clear that "tasks" means "things that make the threads talk to each other". And it will, indeed, truly and royally suck.

has a nice article about the state of threading on Linux. See the Sept. 27th Weekly Edition.

If you remember back in September 1999 they announced the biggest purchase yet of linux stations for Retail. This event is on the LinuxTimeline

This and the telia win in Sweden was one of the first major linux wins. Anyone knows how the latter is doing? From the Datamation article article.

"We (Burlington)have been very aggressive about moving toward Linux, mostly on small servers or combination server/desktops," says Prince. "The stores all use Linux."

"There is NOTHING in the kernel license that allows modules to be non-GPL'd....

The module interface has NEVER been documented or meant to be a GPL barrier. The COPYING clearly states that the system call layer is such a barrier, so if you do your work in user land you're not in any way beholden to the GPL. The module interfaces are not system calls: there are system calls used to _install_ them, but the actual interfaces are not."

More detailed article: Oct 24 LWN. I believe your lawyer is right. You either do userspace driver, GPL driver, or open yourself up to threat of lawsuit. I think the threat is very real; we tolorated binary-only kernel modules when we needed them because we were small. Now we're big enough that if you don't support Linux well in your network hardware, it will significantly cut down on your business. We don't need to tolarate them anymore, and it's plausible that in the not too distant future, we won't.

"There is NOTHING in the kernel license that allows modules to be non-GPL'd....

The module interface has NEVER been documented or meant to be a GPL barrier. The COPYING clearly states that the system call layer is such a barrier, so if you do your work in user land you're not in any way beholden to the GPL. The module interfaces are not system calls: there are system calls used to _install_ them, but the actual interfaces are not."

More detailed article: Oct 24 LWN. I believe your lawyer is right. You either do userspace driver, GPL driver, or open yourself up to threat of lawsuit. I think the threat is very real; we tolorated binary-only kernel modules when we needed them because we were small. Now we're big enough that if you don't support Linux well in your network hardware, it will significantly cut down on your business. We don't need to tolarate them anymore, and it's plausible that in the not too distant future, we won't.

Linus Torvalds himself has said that he will allow binary-only drivers, as long as they're loadable modules, to be distributed.

That's been a long standing supposition. However, lwn recently ran an article in which Linus' view on this matter doesn't seem to support this point of view:

There is NOTHING in the kernel license that allows modules to be non-GPL'd. The _only_ thing that allows for non-GPL modules is copyright law, and in particular the "derived work" issue. A vendor who distributes non-GPL modules is _not_ protected by the module interface per se, and should feel very confident that they can show in a court of law that the code is not derived.

and also

The original binary-only modules were for things that were pre-existing works of code, ie drivers and filesystems ported from other operating systems, which thus could clearly be argued to not be derived works, and the original limited export table also acted somewhat as a barrier to show a level of distance.

Then LISTEN TO YOUR LAWYER, S/HE IS RIGHT!

Then consider something like NetBSD or eCOS if the GPL is not acceptable to your needs.