Slashdot Mirror

To clarify, yes, I know that I can order one from Linuxcare ... But, I'm still looking for more of an automated e-commerce approach, instead of just having to email someone and such ;).

Alex Bischoff
---

-=-=-=-=-

-=-=-=-=-

-=-=-=-=-

Well, the issue is, the APM specification does not cover multiple cpu systems.

As Alan Cox said, "If making that APM call reformats your disk and plays tetris on an SMP box the bios vendor is within spec (if a little peculiar). No APM call of any kind is SMP safe."

Streamripper

Streamripper

A non-profit organization funded by IBM, et. al... Nobody wants their feet held to the fire. If IBM wants to make a release, then they have every right under the GPL to do so. I think that the linux community would encourage them as well, just as NSA's, rtlinux, etc. have been encouraged. Why don't they make their own Linux? Because Linux=Linus? Yes, well no, maybe, not.

The truth is that there are a lot of design innovations in linux. Between it and the tools that come with any normal distro there are a wealth of features you don't find on most commercial unixes. To me Linux is like taking off the back cover of a watch and seeing the pieces move.

In a production environment it's sooo nice to be able to make changes sans reboot and get helpful dmesg output, and not have to jump through hoops to get a strace or struss installed. These debugging tools for the developer are the joy of the administrator.

Anyway, the point is that Linux is a gift from the people who write it. They are going to do what they like-- and they're going to do it in an open forum. If you don't like it, PICK UP THE GPL and WRITE YOUR OWN. Everyone will benefit.

Besides, I always get a kick out of these release announcements. I thought it was pretty funny.

A speed issue would be a delay loop overflow, but anyone still using counter-based delay loops should sit down with a game developer and learn about more robust throttling methods. Every decent computer architecture has a system clock that can be used to accurately measure time in tiny increments.

You've seen the BogoMIPS reported in a Linux kernel boot? That measure is reported when the kernel calibrates a certain timing loop which it uses for microsecond delays. There are some *very* good reasons why the kernel still uses timing loops not the least of which is that the gettimeofday() syscall is much too slow for the kernel to use for this purpose.

Believe me, the kernel developers know what they are doing. If you doubt that, spend some time reading the archives of the kernel development list or the weekly Kernel Traffic summary.

My boss cares about two things: - price - support He loves linux for the price, but is always nervous about the support issue

You mean something like this.

First, you assume that Linus' work and decisions are not subjected to criticism. Read the kernel mailing list (or at least Kernel Traffic), and you'll see that people are constantly butting heads with Linus, to everyone's benefit.


Second, you assume that Linux is "supposed to be a democracy". Since when? It started as Linus' project, and the way things tend to work in an open development community, whoever starts the project generally retains the lead and the power to rule by fiat if necessary. If you don't like it, fork.


Which brings us to your (not sequentially) third assumption, which is that such a system will inevitably lead to major forks. This is not the case, especially when the project lead is as respected (and with good reason) as Linus, or when the project is as identified with its leader as Linux is with Linus. It would *not* be a healthy decision for a Linux distributor to fork the kernel, and everyone knows it, and nobody really wants to anyway.

Kudos to Zack Brown for creating a readable abstract from the discussions on linux-kernel!

Kudos to Zack Brown for creating a readable abstract from the discussions on linux-kernel!

Don't beleive me? Check what Linus himself had to say on the Linux Kernel Mailing List

Here is a tasty sample:

Quite frankly, anybody who uses RedHat 7.0 and their broken compiler for _anything_ is going to have trouble.

I don't know why RH decided to do their idiotic gcc-2.96 release (it certainly wasn't approved by any technical gcc people - the gcc people were upset about it too), and I find it even more surprising that they apparently KNEW that the compiler they were using was completely broken. They included another (non-broken) compiler, and called it "kgcc".

It claims (without proof) to be a lot faster than Java: 1.5 - 3 times slower than C (according to this document, the source of much of the following information).

It's all tooled up with both the bad bways of Garbage Collection. Yes, let's hear it, folks, for Mark and Sweep and his old sparring partner Reference Counting. Still doesn't stop it churning perceptibly in the ticker applet. (They claim RT scheduling but that's no good when you're sitting inside IE with JavaScript turned on in a force 9 pr0n gale.) The polyhedra demo is fast and smoothe and reasonably svelte.

'array of array of vector of arse'. Gak! Neither I nor the compiler are amused that dcl is now compulsory.

It can run Limbo source or binaries, not just bytecode.

Dennis Ritchie encourages the development of a C compiler, and maybe the one bundled with Plan 9 has a few tricks up its sleeve. With a gcj-style Dis backend you could install signed X and Gnome/GTK/KDE/Qt (or the unbelievably cool Ion Window Manager) applets to replace the embarrassingly retro interface. How about writing DHTML in Perl or Python instead of JavaScript? Can you say .GNET?

The site's 3 years old and the guy may be talking out of his arse. I'll give him this, though: he sure knows how to diss up C++ with a zeal for hellfire and damnation truly worthy of his dear OS's name:

C++ objects and their complexities are happily left out. There is no polymorphism or tricky exception handling (the difficulty of understanding exception handling caused the explosion of the Ariane 5 rocket).

It's not every day you download and install an operating system in a couple of seconds (ADSL). Didn't even have to powercycle IE let alone reboot its other OS plugin, Windows. If they don't open the source I'm sure there's someone somewhere who's looking at his/her 1 floppy Linux distro and hatching a cunning plan. What a shame Theo de Raadt's so down on a pocket OpenBSD (reminds me of Guido's antipathy to a Python shared object, Linus's allergy to a kernel debugger). That fireproof sonofabitch would be a perfect fit for plug-in World Domination.

Let's see. Depending on who you want to sell on the issue, we certainly have the big boys. IBM , HP and quite likely Compaq (the TrueUnix/VMS folks, not the crappy box assemblers) can quite likely deliver expensive support and professional Linux services. Of course it's up to you to determine the quality. But you also have to do that when EDS is shipping 10 of their clones with bad haircuts to you.

Then there are specialized companies whose most prominent representation is probably Linuxcare.

Finally and - in my experience most importantly there are the distributers who base their business model basically on services. I had outstanding experiences with SuSE (American site) which guided me through struggles getting X up on my notebook. They made a very idealistic, determined and goal oriented impression and delivered far better support then what I've seen with companies that charge $1/4 million a year (and that was the free issue installation support). They run a professional services department and they have various support plans including 24/7 - and dedicated resource plans. Pricing looks quite reasonable.

I can't vouch for Red Hat, Mandrake , or Caldera, but at least Red Hat has a good reputation.

So, here we go. There's a lot around to chose from and compare. If the gentlemen in the suits insist on an IBMHPSUNDEC rubber stamp, here you go and you probably pay for it through your nose. Not that the distributers quite give away theire services, but from what I've seen there seems to be excellent value there.

I suspect it has something to do with silly linuxthreads which, of course, Linus will never change because he wrote them and they are therefore ...


Exactly, and I remember this thread in l-k 2 months ago where he showed what a prick he can be in those circumstances...

Here's an excerpt that after which I wondered if Linus isn't going a little insane at times:

"Personal opinion, and it has nothing to do with "15 years ago" vs "today":

The pthreads approach never got to a real framework for threads as real entities. To pthreads, a thread is a braindamaged stepchild of a process, and cannot do anything on its own. It's this drooling messy thing that has no life without the parent process that wipes up after it. It has no spine.

In short, threads are not proper citizens. They are guest workers. Expendable. Worthless. They don't have a life of their own.

Now, the notion of rfork/clone/sproc "variable-weight processes" is not new per se. But it's an important _notion_. It basically says that threads are _not_ the ugly drooling stepson that you really wouldn't want to see at family re-unions.

Suddenly, with rfork/clone/sproc, a thread is not just something that you can prod in the right direction with the cattle prod of a random collection of POSIX routines. A thread is an Idea. A Notion. Something worthy of a capital letter. Something you can discuss in mixed company.

It's the difference between being useful and being Right.

It's hard to explain. If you have a bent toward physics, it's the difference between a practical experiment and the Unified Teory of Everything. It's the difference between Galileo saying "everything falls at the same speed" and Newton's "F = mMG/r?".

If you're religious, it's the difference between "It was a dark and stormy night.." vs "Let there be Light!".

If you're into computers, it's the difference between Windows ("sure, it works much of the time, and it looks pretty") and Unix ("everything is a process or a file").

It's like an idea: there are mundane ideas ("hey, let's go out for pizza and a beer") and there are big ideas ("I have a dream..").

The difference? The big idea leads to something larger than itself. It makes people think about what the meaning of life is. It gives a _direction_ for where things are supposed to go.

In contrast, a small idea leads to other small ideas (fifteen beers later: "I know, let's drive past the police station and moon every cop in the city!").

Ok. I'm overdoing it. But think of rfork/clone/sproc as a way to try to come to grips with what it really means to be a thread. Be one with the thread. Grok the threadedness - so that you can understand what is wrong and what is right _without_ having to count every comma in a standards draft that is 473 pages long.

In short, "pthreads" is a rough approximation of the theory of magnetism. While rfork/clone/sproc is Maxwell's equations. One can tell you how much force a magnet excerts on a charged particle in motion. The other one tries to explain how the universe works. "

(Emphasis mine)

He's trolling, right?

read the Debian Hurd mailing list online at: http://kt.linuxcare.com/debian-hurd/latest.epl

You can follow the action on the Debian Hurd mailing list (which is slow but nowhere near dead) at the Debian Hurd Kernel Cousin.

Bottom line is that people are getting things like X and PPP going, so there's definite progress toward a system you could use every day.

On kernel-traffic you can see a recent discussion about select and poll on Linux. They just don't scale well AT ALL.

Last week's Kernel-Traffic summary, Linus actually says the opposite:

what you're showing is that Linux actually is _closer_ to the perfect scaling (Linux is off by a factor of 5, while Solaris is off by a factor of 15 from the perfect scaling line, and scales down really badly).

Now, that factor of 5 (or 3, for 2.4.0) is still bad. I'd love to see Linux scale perfectly (which in this case means that 10000 fd's should take exactly 100 times as long to poll() as 100 entries take). But I suspect that there are a few things going on, one of the main ones probably being that the kernel data working set for 100 entries fits in the cache or something like that.

Either

1. Solaris has solved the faster-than-light problem, and Sun engineers should get a Nobel price in physics or something.
2. Solaris "scales" by being optimized for 10000 entries, and not speeding up sufficiently for a small number of entries.

• 3D user interfaces / window managers
• Artificial Intelligence (e.g. agents) tied to ...
• Voice recognition

Something more realistic: I would like to be able to renice a process' disk activity and disk buffer cache usage, for example when the updatedb process trawls my hard disk to update the (s)locate database. I used to run this every hour until I got sick of just about everything grinding to a halt (I have plenty of RAM and MHz).

I did a search on Google and found that this was discussed recently on Kernel Traffic.

If you really want ACLs (I know I do, but maybe that's just because I *like* ACLs due to tons of experience with it on NT), why not support the poor guys doing the NTFS-for- Linux driver?

The arguments about ACLs being too difficult is IMHO crap. They aren't. I've done a lot of stuff directly manipulating ACLs, and the only difficult part was finding out where the docs for the pertinent parts of the Win32 API were. Doing ACL stuff at API level requires that you know what you're doing, but show me a serious API that doesn't. I mean, come on - everything looks difficult until you've tried. Speaking from experience, ACLs were no harder to learn than sockets programming.

--

Nailer asks:
With kernel 2.4 in the final stages of bug hunting, and on track for a December release, I thought it might be pertinent to discuss the future of Linux. What now?

If you are truly interested in Linux kernel development and the future of the OS, why not just just subscribe to the Linux Kernel mailing list, browse the archive or read the digests on Kernel traffic?

Slashdot is comprised primarily of Linux users not Linux developers. Questions like this are better sent to mailing lists frequented by the people who make these decisions than to a bunch of armchair critics. This article is similar to asking a bunch of random Windows users where Windows&#153 development should go and expecting a coherrent answer.

Second Law of Blissful Ignorance

Easy - Linus is Uncovinced. Once again, check out Kernel-Traffic for the details. Basically, it's the old user-space versus kernel-space argument, with lots of good arguments from either side.

It would be nice to have in 2.5 a kqueue/kevent interface similar to FreeBSD 4.x Maybe something like Schedular Activations

There's been some discussion along these lines in Kernel Traffic that might be of interest. I'm no kernel hacker, but it's a fine way to expand the frontiers of my ignorance!

Even though I personally haven't really compared any MTAs, you might want to check out this comparison table which has users' ratings and comments for exim, postfix, qmail, sendmail, etc

Even though I personally haven't really compared any MTAs, you might want to check out this which has users' ratings and comments for exim, postfix, qmail, sendmail, etc.

Linus does not like version control systems -- do a search on kernel traffic regarding that issue.

Perhaps Linus finally grew a spine?

(as referenced in a recent issue of kernel traffic)

(personally I just took the site as a humour thing though I feel the kernel is a bit overdue. but as i'm no k-hacker and just sit on the sidelines and bitch, what do I matter? :)

Since HURD is a mutually recursive acronym, it's quite hard to say the entire phrase. :)

It's the GNU kernel, which has been in development for well over a decade, based on the Mach microkernel. And yeah, it's still not ready for prime-time, although you can install Debian's unstable distribution for it. The Kernel Cousin project has a section for its Debian mailing list.

My understanding of Hurd is rather limited (basically what I have read in the Kernel Cousins at Linuxcare) so correct me if I'm wrong but isn't Hurd rather focused on doing things "properly" in a somewhat academic/research sense?

If so is it not reasonable to believe that the vendors would find it just as restrictive (if not more so) working with the Hurd?

It's been discussed in the kernel mailing list recently. The general consensus is that since Linux will soon have a bunch of "real" journaling filesystems which are more robust soft updates are not necessary, and also it'd be hard to port anyway because the VFS layers are quite different. Here is a summary from KernelTraffic.

There was some talk of this in Kernel Traffic.

• You can either "mount" the resultant FS publicly, so that anyone on your system can see it, or
• Each and every program that wants to go after encrypted data needs to individually explicitly include cryptographic support to read keys and access/update encrypted data.

As is nicely outlined here , the Plan 9 operating system provides the ability to do this Another Way, using the concept of namespaces. The basic idea is that the "file tree" is no longer a global thing, but is, instead, localized to processes.

In effect, I might, from my shell, run the command:

mount -t crypto /home/cbbrowne/encrypted-stuff /mounts/plaintext

This results in the encrypted stuff in my home area getting attached to the file tree under /mounts/plaintext

The two clever things about this are that:

• /mounts/plaintext is visible to the shell that invoked the mount, as well as to its children.
• /mounts/plaintext is not visible to any other processes.

  Entertainingly, perhaps not even to root.

Why should this be considered relevant to Linux? Because there has been considerable discussion of namespaces in relation to the Linux kernel. It won't be in 2.4, but it's the sort of thing Alex Viro is liable to consider experimenting with in 2.5 or some such version.

And for those who want to follow things more easily, read Kernel Traffic. (Click latest on the left bar).

And for those who want to follow things more easily, read Kernel Traffic. (Click latest on the left bar).

as far as I have read on kernel threads (http://kt.linuxcare.com) there will be no journalling systems in 2.4, initially at least.

This is kind of an odd announcement especially with the kernel in its current 'slushy' state.. I am guessing that 2.4.X with X>5 before the first journalling systems begin to appear.

There are quite a few bright people employed with Linuxcare: http://www.linuxcare.com/abou t-u s/os-dev/index.epl. I prefer postfix to qmail, myself:-)

Actually, Sun is an investor in Linuxcare. As is Dell: http://www.linuxcare.com/about-us/press-center/pre ss-release/2000/07-31-00-funding. epl

This is the same silly argument people used with Linux for a while. There are a lot of people, however, who sell tech support for Debian, including my employer, Linuxcare.

Well, if you go back to the original Slashdot article, and then from there follow the link to the Kernel Traffic discussion , you'll see that about four paragraphs down, you see the following.

The last thing they need is for me to take the stand and testify just what kind of deals they offered to get us to leave Novell in 1997 and divide the NetWare markets by using the "Linux IP Laundry-Mat" to launder Novell's NDS for their consumption (Oh! Look what we found on the internet and downloaded today!).

So maybe there is more reason than meets the eye for why they might have apologized and dropped their threats. Could their lawyers have said, "Hey you better not pursue this one."?

I posted this already, but thought it was relevant again here.

Well, if you go back to the original Slashdot article, and then from there follow the link to the Kernel Traffic discussion , you'll see that about four paragraphs down, you see the following.

The last thing they need is for me to take the stand and testify just what kind of deals they offered to get us to leave Novell in 1997 and divide the NetWare markets by using the "Linux IP Laundry-Mat" to launder Novell's NDS for their consumption (Oh! Look what we found on the internet and downloaded today!).

So maybe there is more reason than meets the eye for why they might have apologized and dropped the lawsuit. Could their lawyers have said, "Hey you better not pursue this one."?

Jeff V. Merkey knows something interesting. I think we can all be glad they backed off.

Sun isn't interested in the hobbyist market.

They don't make money dealing in individual little-fish customers. When they talk about being "the dot in dot-com", they're not talking about pers ona l home page dot-com's. They're talking about businesses that make (want to make) money hands-over-fist on-line.

1. Consistency of server management procedures.

1. In-house tools (scripts) written for Solaris SPARC would run (mostly) unaltered on Solaris x86.

1. In-house applications (binaries) written for Solaris SPARC would run (mostly) unaltered on Solaris x86 after a quick recompile.

1. CDE/Motif (Yeah, large corporate organizations use it instead of GNOME or KDE. Live with it.)

1. Excellent support from Sun (as long as you pay the $upport Contract)

1. Entry-level Solaris-on-RaQ customers would eventually graduate to Solaris-on-SPARC

1. Revenue from support fees.

1. Larger installed based - bigger mind share.

1. Easier to manage support/service organization when dealing with one OS. A more controlled-development OS, for that matter.

When your $5,000-per-hour revenue stream stops because of a subtle server problem at 3am, do you think a linux support organization is going to call the author of the broken code and make him fix the problem? You are mistaken.

I'm afraid your information is out of date. A cursory glance at Kernel Traffic indicates that Linux's "scalability of the most common workloads is limited by hardware (ie. the kernel lets those workloads scale 'down to the metal')."

In said same conversation, they mention that "I would be surprised if we had any serious problem at 32 or 64 CPUs."

This issue of scalability of Linux has been put to rest, IMHO.

Read KT. Read KT often.

Read KT. Read KT often.

It's not a question of older but of smaller, and if you've ever compiled a kernel from scratch, you know how insanely flexible the choices are. Kernel Traffic, as others have mentioned is a must-read if you want to understand the design decisions being made.

For systems with limited resources -- embeded systems, or those mini-distribututions with under 16MB of storage (flash) and RAM -- the decisions made for the kernel in general are the same as larger systems with a few gigs of RAM and multiple processors. Read a few comments on these in KT, and the reasons will become more obvious.

I agree with others who said that this is just Ziff-Davis making an issue out of nothing, and that nearly everything can be a patch or an ifdef -- no fork needed.