Comparing Linux To System VR4

robyannetta writes "Paul Murphy from LinuxInsider.com asks the question What's the difference between Linux and System VR4? From the article: 'If there's a real bottom line here, the one thing I'm clear on is that I haven't found it yet, but the questions raised have been more interesting that the answers -- so more help would be welcomed.'"

Comments

Various differences

[Lindsay Lohan]

So what's the difference between SVR4 and Linux? At a glance they may look the same because they're both in the Unix family, but they're actually quite different.

GNU/Linux has a wider variety of software natively written for it

the Linux kernel includes support for more hardware than SVR4

Linux is more popular as a desktop operating system than SVR4.

Another important factor to consider for many users is price, although there are inexpensive and free versions of UNIX.

Linux issues and bugs generally are often fixed extremely fast.

For a more in-depth technical reference, see this good article on the fundamental difference between BSD and UNIX (although BSD is not technically SVR4 it's still a good read).

Re:Various differences

[Lawrence_Bird]

mmm.. when people ask a question like that I tend to think
more of the technical aspects, ie like threads and smp and
stuff like that and how its implemented differently. Not
that the qualitative differences aren't of some import too
but I just see that more as the color of the cars vs the
types of engines/trannies.

nice link on bsd philosophy.

Re:Various differences

[Steve Embalmer]

Thanks, that link was interesting and you made alot of good points, except the one about Linux and desktop OSs... Solaris has a rocking good desktop manager.

Re:Various differences

[Anonymous Coward]

mmm.. when people ask a question like that I tend to think more of the technical aspects

Well you might think like that but I appreciated the general comparisons. Everything isn't about bitfiddling and pthread variants, sometimes the basics help to clarify for the beginner.

Re:Various differences

[Anonymous Coward]

Okay, I call B.S.

> # GNU/Linux has a wider variety of software
> natively written for it

There is a huge base of professionally written
and supported apps for SVR4/Solaris/UnixWare/...
The GNU compiler and toolchain, while useable,
perhaps even good, is inferior to the offerings
from Sun, IBM, HP, and the commercial vendors.
The same can be said for nearly, if not every,
category of GNU/Linux/Open-Source software.
Linux may in fact have more "stuff" available
for it but when you weed out the crap, it isn't
that impressive.

> # the Linux kernel includes support for more
> hardware than SVR4
>

No it doesn't. Their is little if no support
in Linux for Sun, HP, DEC, Compaq, IBM hardware.
And with few exceptions, what support is in place
is pretty poor. Likewise, when you look at the
offerings from Sun, SCO, and others, the amount
of support on the PC is just about as good.

> # Linux is more popular as a desktop operating
> system than SVR4.
>

Maybe, but maybe not. People at home and dorm
geeks dork'ing around don't count. I'll guarantee
you their are more scientific and engineering
shops that are using SVR4 based desktops than
Linux.

> # Another important factor to consider for many > users is price, although there are inexpensive > and free versions of UNIX.

Define "price". Having to wait around for days
on end while somebody on the mailing list or web
forum decides to answer your question (or some-
times not at all)is unacceptable. Sun, HP, and
IBM, provide guaranteed response times and they
do it well. When your systems are down and
costing you $5000 an hour open-source "support"
don't cut and ends up costing you a lot more.

> # Linux issues and bugs generally are often fixed extremely fast.

Sometimes yes, sometimes no.

Re:Various differences

[Anonymous Coward]

Their is little if no support in Linux for Sun, HP, DEC, Compaq, IBM hardware.

What planet are you living on...?

Oh, that was a troll... sorry.

Re:Various differences

[defile]

Define "price". Having to wait around for days on end while somebody on the mailing list or web forum decides to answer your question (or some- times not at all)is unacceptable. Sun, HP, and IBM, provide guaranteed response times and they do it well. When your systems are down and costing you $5000 an hour open-source "support" don't cut and ends up costing you a lot more.

What the hell? You don't get enterprise support for free as a result of popping in a Solaris installation disc. Why would you expect one if it's Linux disc?

Re:Various differences

[Anonymous Coward]

Actually, Linux support for midrange hardware is pretty crappy. SGI makes a box, but that's about it. IBM doesn't.

Re:Various differences

[Pseudonym]

Here, have a few goats...

There is a huge base of professionally written and supported apps for SVR4/Solaris/UnixWare/...

Correct, kind of. There are arguably more commercially supported apps for Unix or Solaris than for Linux, and generally speaking, more money is involved. (That is, the apps in question are serious ones that companies rely on; if the software fails, the company goes south.)

Having said that, there are probably more "professionally written" apps for Linux, it's just that most of them aren't as commercial or mission-critical.

The GNU compiler and toolchain, while useable, perhaps even good, is inferior to the offerings from Sun, IBM, HP, and the commercial vendors.

That depends what metric you use. If the only measure that you use is the performance of generated code, then I will concede that you're probably right. On the other hand, the GNU compiler tends to be much more standards-compliant than its commercial competitors. The GNU toolchain is ported to more architectures and platforms than any other. Moreover, the open source suite has more "off the shelf" than any other (e.g. valgrind, though it's not ported to anything other than IA32), where on the Sun or IBM systems you'd need to buy something extra (e.g. Purify). One notable exception is the Sun ONE Studio performance collector/analyzer; I haven't seen anything like it for Linux.

The same can be said for nearly, if not every, category of GNU/Linux/Open-Source software.

Strongly disagree. In the desktop arena, open source is way ahead of commercial Unix.

Commercial Unix definitely has the upper hand here because they can use the best of open source as well as the best of proprietary. So, for example, you can run Apache on your Solaris machine and get the best of both worlds, so to speak.

Linux may in fact have more "stuff" available for it but when you weed out the crap, it isn't that impressive.

That's a false dichotomy, and Sturgeon's Law applies here. There's a lot of crap in Linux, but that's because there's a lot of stuff, and 90% of everything is crap. The 10% left over is equally impressive, but it tends to do different things than the 10% of commercial offerings which aren't crap.

Open source doesn't have a "Verilog-killer", but commercial Unix doesn't have an "Apache-killer".

Re:Various differences

[terrox]

.... Linux is something "most computer users" have heard of whereas SVR4 is not. This is just something to get noticed.

Re:Various differences

[Anonymous Coward]

Read this

You are such a fucking loser your monger.

I'll give you a rundown of the categories on that page, in case you are too lazy to read it.

Linux on POWER
Linux on Intel processor-based servers
Linux on AMD processor-based servers
Linux on Mainframe

The Linux s390 and PPC and PPC64 (and even m68k) architecture maintainers all work for IBM. The POWER5 processor had features designed with Linux in mind to better suit its low level memory management system. The IBM Linux guys go do Linux bringup and verification on sample silicon.

Oh also, the Linux IA64 maintainers work for Intel and HP, both companies have quite a few staff doing Linux (especially ia64) work. SGI has a lot of staff working on the kernel alone.

Sun these days is probably not supported as well, but why would you buy a sparc server running Linux when you could buy an Altix, or a POWER5 (or zSeries if you want a real mainframe)? You would have to be insane. The only reason sparcs are still being sold is the solaris on sparc legacy.

Re:Various differences

[Lally Singh]

His point was that the potential time delays on the listed Linux support mechanisms may be much more expensive to a customer than a support contract.

This isn't discounting the fact that one can get various levels of paid support for Linux as well.

Re:Various differences

[SunFan]

why would you buy a sparc server running Linux when you could buy an Altix, or a POWER5 (or zSeries if you want a real mainframe)?

1) Sun is cheaper. Yes, this is true.

2) OpenSolaris is coming, soon. Free as in speech. Solaris 10 is free as in beer.

3) Sun Opterons with Solaris 10 are breaking some records.

4) Sun UltraSPARCs still manage to hold their own, too (UltraSPARC IV can keep up with Opteron in SPEC rate benchmarks, but can go up to much bigger SMP).

The only reason sparcs are still being sold is the solaris on sparc legacy.

This is an opinion, and many people disagree.

Re:Various differences

[Grant_Watson]

.... Linux is something "most computer users" have heard of whereas SVR4 is not. This is just something to get noticed.

I seriously doubt that most of the sellers of SVR4 care whether or not "most computer users" have heard of them. They don't exactly expect Joe Sixpack to buy a System V box; he's not the target customer.

Re:Various differences

[Anonymous Coward]

How about you back up some of your conjecture with a bit of facts?

1) Oh, so that's why everybody is clamoring to buy Sun (and you haven't even provided facts)

2) Doesn't mean anything.

3) Doesn't mean anything (and you haven't even provided facts).

4) Are you joking? First of all, SPEC rate is more a function of interconnect and memory performance than CPU performance. Second, if it can keep up, this is only due to it having two cores on die. In that case, only just keeping up with a single core processor is pretty pathetic. Third, the big US-IV installations aren't glueless systems so you're wrong, Opteron could "go up to as much SMP" as US provided the glue logic is there. Fourth, I'm not even talking about the consumer/low end server chip that is the Opteron. I'm talking about the POWER5 and Itanium 2. The REAL big iron. Both utterly demolish anything Sun has. In fact, I've seen benchmarks where IIRC a 16-way POWER5 system put a 72-way Sun system to shame (I'll post a link when the site comes back up).

Re:Various differences

[Anonymous Coward]

You are a very skilled troll, I'll give you that.

Re:Various differences

[Anonymous Coward]

If you want to try to win the argument, you come up with facts to rebut my points.

Being the first one to call "troll" doesn't mean shit. And in this context you've just shown that you can't back up anything you've claimed and are giving up.

Re:Various differences

[SunFan]

Actually, I can't take credit for the AC post.

Re:Various differences

[Anonymous Coward]

OK, sorry. The jist of my post still applies to the AC who did post it though.

Re:Various differences

[calidoscope]

First of all, SPEC rate is more a function of interconnect and memory performance than CPU performance.

The flip side of that is CPU performance doesn't mean squat on a multiprocessor system if the interconnect and memory systems are not up to snuff.

Opteron could "go up to as much SMP" as US provided the glue logic is there.

Are you sure about that?

The high end US chips have provisions for maintaining cache coherency in systems with up to 1023 processors. I don't recall seeing a similar feature in the Opterons (IIRC, they're good for up to 8 processors). The Opteron more closely competes with the US-IIIi than the US-III or US-IV.

I also recall reading that one generation (Power4?) of IBM's Power boxes had some performance problems when doing real SMP workloads due to IBM messing up the memory system. The same systems did wonderfullly with single processor tasks.

Re:Various differences

[Anonymous Coward]

The flip side of that is CPU performance doesn't mean squat on a multiprocessor system if the interconnect and memory systems are not up to snuff.

And Sun's interconnect and memory systems are not up to snuff. Consider that POWER5 systems have 16GB/s memory bandwidth and 36MB L3 cache per chip, while the Sun systems have 2.4 GB/s memory bandwidth and 16MB cache per chip (although I suppose that may sufficient to feed a slow ultrasparc).

I'm not sure what the inter processor memory bandwidth figures look like on the p595, but you can bet your bottom dollar that they'd blow the doors off the E25K.

Are you sure about that?

The high end US chips have provisions for maintaining cache coherency in systems with up to 1023 processors. I don't recall seeing a similar feature in the Opterons (IIRC, they're good for up to 8 processors).

I don't know about the size of their cache coherency domain, but I said "with the right glue logic". Cache coherency can be handled by the external logic ala Altix. Getting a system to "scale" isn't so much the ability of the chip. In fact, it will be harder to get a good chip to scale well because you need to feed it more.

The Opteron more closely competes with the US-IIIi than the US-III or US-IV.

You've got to be joking. Unless competing means grinding its bones to make its bread.

Re:Various differences

[andreyw]

Nice troll. I call BS. Ever try installing Solaris x86 on a PC? Good luck! The only configuration I found laying around that worked with *that* turd was an ol' Pentium Pro i440-based mobo. Solaris x86 - the only PC operating system these days that brings back the joys of hunting for crappy, unsupported or just plain non-existant drivers for your:
a) Network card. Wow. Just... wow. And this wasn't something arcane either.
b) Video... well.. "driver" heh. If the Xserver doesn't support it, have fun running CDE in 640x480.
c) Sound driver.
d) Chipset driver... for those that actually WANT to use their ATA-133 drive as an ATA-133 drive.

People complain that Linux is "hard to install," complaining about Slackware and Debian installers. They must have never dealt with the Solaris installer. Its amazing how a corp can put ALL this work into tweaking their kernel to the extreme... and the f*&#-up something absolutely simple as an... installer.

After the pain I've been through... the ONLY machine I will ever want to deal with Solaris on... is a Sun machine. At least there they don't have an excuse for having skeleton hardware support.

If Physics researchers and IT departments are now classified as "dorm geeks", you're right on the spot. Personally, I've noticed that when institutions want Big Iron, they usually go for a pSeries... you know, the AIX-wielding beast with 12GB (or so) of RAM and 4-way Power5 SMP. Sun has its place as a developer workstation, I agree. But SCO? What kind of a douche would buy into that? What exactly do you get with SCO that I can't get from Sun or IBM?

Re:Various differences

[sysboy]

I have just evaluated a pSeries 590 and while Suse is supported the support for AIX on the same platform is miles ahead in terms of hardware support.

You would be shooting yourself in the foot to run Linux on your brand new IBM hardware.

As for the Solaris, their main problem at the moment is clock speed, they just can't match IBM and Intel. However if you were looking to upgrade your legacy Solaris equipment you wouldn't go too far wrong by looking at Fujitsu's offerings.

Solaris 10 is a pretty awesome OS, it's worth it's weight in gold for Dtrace alone...

Re:Various differences

[Anonymous Coward]

I have just evaluated a pSeries 590 and while Suse is supported the support for AIX on the same platform is miles ahead in terms of hardware support.

I've no doubt AIX would be ahead in hardware support on pseries. "miles ahead"? Can you give us a couple of examples of what is supported by AIX and not Linux?

You would be shooting yourself in the foot to run Linux on your brand new IBM hardware.

Apparently IBM doesn't think so. I guess you're the expert though, having just evaluated a p590.

Re:Various differences

[koekepeer]

> # Linux is more popular as a desktop operating
> system than SVR4.
>

Maybe, but maybe not. People at home and dorm
geeks dork'ing around don't count. I'll guarantee
you their are more scientific and engineering
shops that are using SVR4 based desktops than
Linux.


well as a postdoc fellow working in a university computer science department, i can tell you that the amount of linux desktops/workstations clearly outnumbers the amount of workstations running other unices (unixes? - whatever). oh ya, and many of the workstations run windows XP by-the-way.

that put aside, using the argument that science and engineering shops running "desktop" software is indicatiove of success or failure of linux on the desktop is a bit silly IMO. the largest market for desktop computing is corporate offices, and then perhaps home computing. and yes, "desktop linux" didn't penetrate that market sufficiently (yet). but much more than solaris etc ever will. why do you think sun jumped the linux bandwagon?

but most importantly, the separation between desktop and server is kinda artificial, as the original article already suggested. so this discussion is kinda pointless IM-not-so-HO.

Re:Various differences

[Anonymous Coward]

Stop posting monospaced and narrow columns. It's annoying.

Re:Various differences

[defile]

His point was that the potential time delays on the listed Linux support mechanisms may be much more expensive to a customer than a support contract.

The original poster stated Linux has good free support. The poster didn't come outright and say that SVR4 by contrast has terrible free support, but it's implied.

The response was that free support doesn't cut it if you're doing something important! Paid support for SVR4 is ENTERPRISE grade, but it's a pointless argument since you can find enterprise grade paid support for Linux as well.

Oh shit, I've been trolled.

Re:Various differences

[sysboy]

I was interested in the virtulization aspects, and the VIO server is only (currently) available as AIX, there is a Linux alpha version that I tested with some success but IBM won't support it out of the box.

When testing our multi threaded apps, performance under AIX was around 15% better than on Linux on similarly specced lpars.

The impression I got was that IBM were using Linux support as a selling point to people looking to migrate from AIX/Solaris/HPUX etc to Linux.

Support issues for Linux on the Power 5 is also questionable, I had a few problems which went around the houses, bouncing off Suse, IBM, Suse etc.

Re:Various differences

[Lawrence_Bird]

are you a /. bot? I like monospace and as long
as its a pref I'll use it. Get over it.

Re:Various differences

[Lally Singh]

I wasn't trying to troll, just explain what looked like a misunderstanding. And yeah, comparing free Linux support to enterprise commercial unix support is thoroughly invalid, especially since you can get similar support offerings for Linux.

Distribtuion method

[niteice]

Well, Linux can be downloaded in a friendly ISO format, but my SVR4 2.1 disks are in some wierd-ass format I can't use with anything except this one german program.

The difference is...

[FiReaNGeL]

That everyone says "What you said?" when they're asked about VR4.

Lets compare apples to apples, would'ya?

Re:The difference is...

[0racle]

Apples are BSD based not SysV.

Re:The difference is...

[idiotnot]

Haven't always been.

And, on a kernel level, OSX isn't BSD, either. It's mach, which has things like native threading, and its own message-passing facility...separate from what you'd find in a traditional unix kernel. (NetBSD supports Mach IPC now, too, to support Darwin binary emulation)

Re:The difference is...

[0racle]

It was a joke.

Re:The difference is...

[0racle]

Well since I've been using a Mac since the SE and I am often the one pointing out that the BSD portion of the kernel is a subsystem in the Mach kernel, yes it was a joke.

Did it hurt to have your sense of humour removed, or were you born that way?

Re:The difference is...

[Anonymous Coward]

Oh I was laughing alright, but it just wasn't with you.

Re:The difference is...

[mikiN]

You can't buy SVR4 bumper stickers.

Well, not in one piece maybe, but go to any Rice-Boy aftersales joint and get those stickers:

- S for 'Sport'
- V-Tec (naturally)
- R for the -R version
- 4 (well, just install 4(!) fart-cannons for good measure.)

Re:The difference is...

[Anonymous Coward]

YHBT, apparently.

Anyway, it was my understanding that OS X/Darwin uses the Mach kernel and BSD userland/tools. Is there an actual part of the kernel that is BSD?

(posting AC, as this is getting off topic and my karma has already suffered elsewhere for being offtopic)

Re:The difference is...

[Ohreally_factor]

Nor does SVr4 have a mascot, unless you want to count the football referee on the cover of my old O'Reilly Unix in a Nutshell handbook.

Re:The difference is...

[0racle]

Yes there is a BSD subsystem that runs in kernel space.

Sigh

[devphil]

It took me three paragraphs before I figured out that the author of the article wasn't talking about an operating system called "VR4".

Whitespace matters, people. "SystemV R4" or "SVR4" or "SysVR4" woulda done just fine...

Re:Sigh

[kbahey]

Exactly what I thought. I have been using System V since R2, and SVR4 since it first came out (before Solaris came out even).

I have seen it as : SVR4, System V Release 4, or SysVr4 even ...

But System VR4 ? Never saw it spelled this way, and indicates little familiarity with the subject matter.

Re:Sigh

[Chris Mattern]

I liked VR5. That was a cool series.

Chris Mattern

Re:Sigh

[Derwen]

I liked VR5. That was a cool series.

Hey, me too - even though it was on late at night - eventually at something like three in the morning - in the UK, and I had to work at 7am, I persisted with it. I was always sure it wasn't as bad as it sounded when you tried to describe it to someone else ;-)
- Derwen

Re:Linux is much more revolutionary

[Anonymous Coward]

You dissed osx, be prepared for a troll mod.

The difference is...

[mrogers]

You can't buy SVR4 bumper stickers.

Looks like a troll to me...

[jpetts]

LinuxInsider has on several occasions in the past been a troll site for the SCO/IBM Linux dispute, coming down firmly on the FUD-mongers' side. They are a platform for people like Enderle, DiDio. Ignore, is my advice...

Re:Looks like a troll to me...

[Anonymous Coward]

LinuxInsider has on several occasions in the past been a troll site for the SCO/IBM Linux dispute

Publishing both sides of the debate does not make LinuxInsider a "troll site."

They are a platform for people like Enderle, DiDio

...and anybody else with something interesting to say re: Linux.

Ignore, is my advice...

Slashdot Reality Distortion Field: Activate

"FUDFUDFUDFUD I CANT HEAR YOU"

Re:Looks like a troll to me...

[worldcitizen]

Hehe, at some point I thought that the name linuxinsider came from trying to do an "inside job" (although, they didn't really seem to be inside anywhere :P)

Re:Looks like a troll to me...

[PenGun]

ASsTROllTURF, I'd guess.

PenGun
Do What Now ??? ... Standards and Practices !

Re:The difference is obvious

[Anonymous Coward]

Never heard of SysV? I seriously hope you're joking...

(I can understand never having used it. But never heard of it? Sheesh.)

RTFA

[QuantumG]

It's a technical comparison between the Solaris and Linux kernels. He's not interested in your opinions of which makes a better embedded operating system for a toaster oven.

Re:RTFA

[Anonymous Coward]

Well put.

Re:RTFA

[Anonymous Coward]

I've never seen a desktop in a toaster oven, but maybe they have one somewhere in Japan I guess. Mod GP up :)

Re:RTFA

[Bruce Perens]

He's not interested in data either. The article's a troll, with almost zero real technical content.

Bruce

Re:RTFA

[QuantumG]

It's a follow on from another article. If you havn't read the other article then it makes no sense to read this article. The only reason why the brain dead Slashdot editors posted it is because the brain dead OSNews.com had it. I'm sure neither Eugenia over at OSNews, nor timothy here on Slashdot read anything more than the title of the article. Not even knowing what VR4 was refering to they posted it.

Re:RTFA

[j_w_d]

It's a technical comparison between the Solaris and Linux kernels.

irony-on And the unsubtle implications concerning the changes in 2.6 respecting the SCO-IBM fracas are legitimate technical observations. irony-off

The article read like troll-bait to me. A serious journalist could have simply asked developers what the technical differences are and how they are affected by the intended platforms. A serious programmer could have answered his own questions. What class does that leave article's author in - bridge dweller?

Re:RTFA

[SpaceLifeForm]

I have to agree. I thinking that SCO/MS is behind this.

Who cares about SVR4 these days anyway?

Re:RTFA

[QuantumG]

Wow, what a brilliant part of the Microsoft plan! How could we possibly not have recognised this as part of their ploy!

Maybe, just maybe this isn't part of the great SCO/MS conspiracy and you're just confused cause you don't have half the article cause you don't read the news site it is posted on and you don't follow this author's work?

Re:RTFA

[lakeland]

Is it a troll? I found it too confusing to say. The article is looking for technical differences between linux and SVR4. Consider this quote: "Specifically, what's needed here is the low level programmer view, not of what's out there by way of applications..."

The impression I got was the author was way over his depth writing it, and was largely aware of this. Consider the final conclusion "If there's a real bottom line here, the one thing I'm clear on is that I haven't found it yet". Now, that's either a very good troll or a genuine article.

As for answering the article. Well, the painfully obvious difference is in hardware support. SVR4 is a joke in terms of hardware support compared to linux.

In terms of 'features' like kgdb, ptrace, LVM, NUMA, SMP, well I don't think I even know enough to make an informed comment. I will note that the author's attempts to draw comparisons appear extremely weak to me (particularly WRT threading).

Also, the author also seemed to confuse a number of architectural weaknesses with kernel weaknesses. Run linux on a toy mainframe and it won't have mainframe hardware features. Well, Doh. Run Solaris on personal computer hardware and it won't either. Run linux on mainframe hardware and it will.

So, I consider the article very weak, and not worth the electrons it was distributed on. However, it is a fair enough question to ask. It is just a pity to ask it so badly and then slip in bits like the SCO lawsuit for extra hits.

Re:RTFA

[kbmccarty]

The article's a troll, with almost zero real technical content.

No surprise here -- LinuxInsider.com is to Linux as MozillaQuest.com is to Mozilla. Move along, move along.

Re:RTFA

[Bruce Perens]

Well, I think it's a troll because he displays very little knowledge of systems programming and confuses CPU features and OS features, and yet takes every opportunity to say something snotty and disparaging.

Companies like Sun have PR firms that will synthesize buzz if they can't get any legitimate buzz. I'd suspect something like that is afoot, or it's just an ill-informed person biting off more than he can chew.

Bruce

Re:RTFA

[Anonymous Coward]

I would think that epoll or the principles informing udev would have played a stronger role in this article. They don't strike me as incremental refinements over 2.4 and they aren't hand-me-downs.

Re:RTFA

[Anonymous Coward]

Zero real technical content, eh?

Isn't that a bit like the pot calling the kettle black, Bruce? Other than ElectricFence, when's the last time you produced anything worth talking about?

Being that this is /.

[Anonymous Coward]

I'm sure nobody bothered to actually RTFA.

The article is basically worthless. It's like walking through a classroom about 20 minutes into the lecture, and walking out 15 minutes later.

It starts in the middle, and leads nowhere. Just a bleem of time that, for whatever reason, is, unfortunatley, recorded here for posteriry.

SVR4 utilities

[Anonymous Coward]

Gunnar Ritter maintains a huge set of SVR4 utilities: The Heirloom Toolchest

L-A-M-E

[johnthorensen]

Could this guy TRY to be more disparaging in his tone? Sure, he tries to give a little back with a comment regarding the quality of Linux code, but for those that haven't RTFA, here's the gist:

1) Linux runs on a 'toy' platform (x86), and why the hell would a programmer want threads when there's not TRUE concurrency?

2) Linux does nothing significant that AT&T wasn't doing 10 years ago.

3) Generally speaking, Linux sucks.

IMHO I expect to see this sort of thing about half-way down in a thread of /. comments, not on an actual computing news site.

-JT

Re:L-A-M-E

[McAddress]

1) Linux runs on a 'toy' platform (x86), and why the hell would a programmer want threads when there's not TRUE concurrency?

It's not that a programmer would not want threads. However, if you want threads to handle truly concurrent events, as opposed to just multiple strongly related processes, the design of the threads will be entirely different. His point was that on an x86 any attempt to design truly concurrent threads is a waste of time b/c of the underlying architecture. Of course Linux runs on more than just x86 hardware, so the point moot.

Re:L-A-M-E

[FyRE666]

As another comment above noted, "LinuxInsider" is not a computing news site in any real sense of the term. It is in fact little more than a FUD factory. The list of contributors reads like the who's who of Microsoft/SCO paid schills...

I'm surprised that Slashdot gave this latest garbage a front page headline. Hopefully if enough people ignore LinuxInsider it'll go away...

Re:L-A-M-E

[Anonymous Coward]

Which is really stupid: when you need to wait on I/O it's a really good idea to have some real form of threading and concurrency, when you have a kernel with some form of preemption you cannot go without a system designed for concurrency.

On a side note the main underlying architecture for Linux will probably be in the comming years SMP x86-64 ... which means _real_ concurrency ...

Re:L-A-M-E

[viktor]

Linux runs on a 'toy' platform (x86)... Linux does nothing significant that AT&T wasn't doing 10 years ago... Generally speaking, Linux sucks.

As usual, what your eyes see depends on which glasses you have on when the text is in front of them. If you are expecting to find critique, you can always find it.

Personally, I did not see any form of "Linux sucks" message in the article. He does not write "Linux, Linux, Hallelujah", but lack of worship does not mean that he condemns. The article is, from beginning to end, explicitly about a work-in-progress. He writes that he does not know yet, that more needs to be said, that he wants help, that he needs more information.

IMHO I expect to see this sort of thing about half-way down in a thread of /. comments, not on an actual computing news site.

I sincerely apologize for making you a target here, but your comment is the kind of comment I expect to see not half-way down but even at the top of a /. thread.

If anyone, anywhere so much as whispers anything about Linux maybe not being absolutely perfect in every single regard, there will always be a lot of people calling that author a Linux-basher or anti-Linux.

And every email sent to such an author (note that I'm not trying to in any way imply that you sent such a message!), telling her/him how stupid he is will inevitably make Linux continue to look more and more as a religion rather than a project to make the best OS in the world.

Imagine where Linux could be in five years if people were actually free to express critique against current implementations and ideas without being flamed to pieces once their article/blog/message/scanned-lipstick-on-a-napkin finds it's way to Slashdot.

Or, as in this case, if people are even free to ask wether there might be anything worth commenting on in the future.

Re:L-A-M-E

[arkanes]

Well, he re-defines what he's asking for at least 3 times. He wants stuff that Solaris can do that Linux can't. No, wait, he wants to know how Linux is different than SVR4. No, he wants to know which one is better for teaching.

He's got a point that Linux isn't causing any revolutions in OS technology. But he dithers and blathers around so much it's hard to even see that statement for what it is - it almost sounds like he's saying you may as well use SVR4 instead because it's the same basic concepts(!).

Honestly, this is the sort of thing I'd expect to see left on a publishers desk at 4AM, with the faint smell of coffee and bourbon lingering in the air. It's incoherent, rambling, and of marginal if any technical value (programmers don't want threads because they only mimic concurrency?!). He doesn't have the technical skills to evaluate the differences he's supposedly looking for, but he decides to draw conclusions anyway. He needs to really decide what he wants, why he wants it, and then to move from there. And while he does that, it'd be nice if he didn't spew any more half-realized thoughts into his articles on LinuxInsider.

Re:L-A-M-E

[Syberghost]

You left out "one of the cool things Linux can't do that AT&T SVR4 can is that Sun might be able to do some compiler stuff some day that nobody cares about".

You know, because AT&T SVR4 is Solaris from a few years in the future.

SVR4

[tuxter]

Sounds like a new performance vehicle.

What does this say?

[aluser]

There are several paragraphs in the article which, I think, don't actually say anything. Example:

Imagine, for example, trying to build a compiler able to produce an efficient executable in exactly one pass. Nobody does this now, for obvious design reasons consequent to an underlying sequential processing assumption, but it shouldn't be impossible. "All" it would take is a complete re-appraisal of everything we know about optimization and related issues in a truly concurrent, shared-everything, multi-threading environment with enough threads.

Am I completely out of my depth? What does threading have to do with efficient one-pass optimizing compilers? What's his issue with concurrency under linux anyway?
Or this:

On the other hand, this variation on the main question also raises new issues because many of the changes made to process and memory management between the 2.4 and 2.6 Linux kernels look a bit artificial -- meaning that they don't seem to be direct continuations of code evolution up to 2.4 and thus raise the suspicion that the SCO/IBM lawsuit might be having some unexpected design consequences.

What makes a patch "artificial" ? Whatever that means, how does it imply anything about the sco/ibm lawsuit? Weren't the 2.5 development line split and the major scheduler changes introduced before the lawsuit? Even if not, what would he consider a continuation of the development up to 2.4? In short, can somebody explain to me what this guy is saying?

Re:What does this say?

[ScrewMaster]

Well, doing a little reading between the lines, as it were, I think what he's really saying is "I want to pay off my mortgage early and this is the best way I've found to do it."

Re:What does this say?

[Pseudonym]

What's his issue with concurrency under linux anyway?

I didn't get that either. I had some (very serious) issues with concurrency in Linux, but they've all been fixed in 2.6/NPTL.

One thing I did like was his comment that the distinction between desktops and servers is mostly one of marketing. I thought that was quite insightful, if not entirely original.

Re:What does this say?

[coyote-san]

Imagine, for example, trying to build a compiler able to produce an efficient executable in exactly one pass. Nobody does this now, for obvious design reasons consequent to an underlying sequential processing assumption, but it shouldn't be impossible. "All" it would take is a complete re-appraisal of everything we know about optimization and related issues in a truly concurrent, shared-everything, multi-threading environment with enough threads.

Am I completely out of my depth? What does threading have to do with efficient one-pass optimizing compilers?

It's been a while since I studied this, but it escapes me why anyone would want to roll the clock back by decades to return to single-pass compilers.

Background: modern compilers, e.g., the Gnu suite, use multiple passes to cleanly separate functionality. In a nutshell the first pass compiles the source code into an arbitrary intermediate format. IIRC gcc covers C, C++, Fortran (g77), Ada (gnat), Java (gcj) and more. Bob could add support for BobTalk with relatively modest effort.

The next pass performs generic optimizations on the intermediate code - extracting loop invariants, unrolling loops, eliminating dead code, etc.

The final pass translates the intermediate code into processor-specific object code.

(Reality is much more complex with the C preprocessor, register coloring and keyhole optmization of the object code, etc.)

The key thing isn't sequential thinking, it's the way that adding support for a new language is handled entirely in the first pass. Adding support for a new processor is handled entirely in the final pass. Adding new optimizations for your master's thesis is handled entirely in the second pass.

Back in the dark ages you did have "single-pass" compilers... and they were an absolute bitch to maintain since each language and processor stood alone. (I used quotes since these compilers normally produced assembly code (.s) that was then compiled/assembled into the object code files. So even "single pass" compilers normally used multiple passes, but with a processor-specific intermediate language.)

It was a major innovation when AT&T released a C++ compiler that worked by compiling the C++ code into C code instead of assembler. It allowed the new language to be supported in a fraction of the time required before.

So tell me again why we would want to return to the days when we went directly from a high level language to object code....

Re:What does this say?

[arkanes]

It was a major innovation when AT&T released a C++ compiler that worked by compiling the C++ code into C code instead of assembler. It allowed the new language to be supported in a fraction of the time required before.

Er, no. The very first C++ compiler did this. So did a lot of the early ones. At least one still does (Cousteau C++).

Re:What does this say?

[BayBlade]

Well, as a matter of history,

take a wild guess who Stroustrup was working for (and still is today) when he released that language and first implementation thereof...

Hrmph.... "System VR4"

[McNihil]

SVR4 you insensitive clod... no it really matters... also why no word about Amiga 300UX being the first one having full compliance to the SVR4 spec? Also why not wander down the XPG specs... the UNIX95 and UNIX98... and most importantly POSIX... OK yes the article did rub me the wrong way for its lack of reverence I suppose... let it be known that I for one think that just because using linux and OSS in general gives me no right to even try to rewrite history the way big corporations do.

Re:Hrmph.... "System VR4"

[McNihil]

and that would be A-3000UX and not 300... see you made me angry! grrrrrrr.

Re:Hrmph.... "System VR4"

[Renegrade]

Hmmm, Amiga 300.. Long awaited, never released PDA or tablet?

Woot!

Really offtopic: I picked up a new Asus notebook recently, and it consumes almost three times the power of an Amiga 1200 with an 030 accellerator. It made my old power inverter (50W) fall over in a very bad way. What ever happened to the people saying that the custom chips ate too much power? Was going to McGuyver an external battery pack out of NiMH D-cells, until I realized that I'd need literally 45 to get any decent extra run time out of them. The wiring would also have to support 3.5 amps at ~19v. Gah!

Re:The difference is obvious

[Anonymous Coward]

Don't laugh. Half of the people here have never heard of GNU/Linux either.

They use Gentoo, d00d, and it R0X0|2Z!!!!!!111!

Best part of the article

[Anonymous Coward]

My request for help included a list of some things you can do with Solaris but not with Linux, and more than 40 readers sent me e-mail responding to this by telling me that Linux (or, in several cases, Windows) can do all of those things [...] those responses suggested a frightening thought for future exploration: that the knowledge gap between the Linux and Solaris communities might be much bigger than I think it is.

Re:Best part of the article

[Oddly_Drac]

"list of some things you can do with Solaris but not with Linux"

Hey, you think this could be because Solaris was a closed source product for a while Linux is a re-engineered unix?

"those responses suggested a frightening thought for future exploration: that the knowledge gap between the Linux and Solaris communities might be much bigger than I think it is."

I can see why that would keep you up at nights, but consider that the vast number of Linux users you heard from are the next generation of sysadmins and that software moves on. Or are you still using supercalc?

The guy's a phony.

[kma]

An actual technical comparison between SVR4 and some of its derivatives with Linux would be interesting. However, this guy is utterly incompetent to perform such a comparison. His babblings about the x86 and threads are just word salad. Consider:

Indeed, I'm starting to believe that threading doesn't have a legitimate role in the Intel (Nasdaq: INTC) x86 hardware environment because the hardware defeats the goal of true concurrency between threads -- and if you can't achieve concurrency, what point is there in threading?

Confused? That's what Paul Murphy hoped. He's just as confused as you are. Ignore him.

Re:The guy's a phony.

[aluser]

I wonder if the writer just found out that you can't run processes concurrently on a uniprocessor system. He acts like that's only true for x86.

Re:The guy's a phony.

[ScrewMaster]

Yeah, well ... this guy is threading water and he's losing ground by the minute.

Re:The guy's a phony.

[Neo-Rio-101]

I think what he was trying to say was that there's no point putting code to do threading into the OS when there is threading functionality built into the hardware (such as in Intel's hyperthreading CPUs).

But yeah, he really didn't re-edit his article to make that blindingly clear.

Re:The guy's a phony.

[Anonymous Coward]

there's no point putting code to do threading into the OS when there is threading functionality built into the hardware

Actually, just the opposite. He is of the opinion that X86 does not thread like Sparcs do. Basically, he is wrong about hardware, and he obviosuly does not understand the use of threads; basically, to prevent a general block when waiting on other resources. If nothing else think how green threads in Java work. They simply are cooperative. This works well for many programs.

Personally, I would say to leave to paul alone. He is pulling an OGrady or Dorvack

Re:The guy's a phony.

[arkanes]

He'd be totally wrong if he said that, too. HT isn't a magical concurrency generator any more than OS threads are. There aren't any magic concurrency generators. This guy doesn't know what the hell he's talking about, at least with regards to the two technical things he mentioned in the article (compilers and threads).

I read the FA

[thogard]

They guy never saw the SVR4 code... talk about a mess. AT&T had nice clean code that worked well was efficient but didn't do networking very well at all. So they hopped into bed with Sun who had real good networking stuff from BSD. The result was the two of them spawned SVR4. The read system call in the old unix was short and sweet and fit on a vt100 screen. The new one took pages even when printed out and didn't do anything new. It was a rewrite for the sake of a rewrite.

There are some very clever things in Unix that you don't notice till someone redoes them and turns them into a stinking heap. For example the new Solaris 10 services. It does what init and inetd does but needs a binary config file which it rewrites on boots and when it changes stuff (ala windows registry for unix). Having been way too deep on too many broken systems, I don't like binary files that change that are essential for my os to work. But this is progress...

Re:I read the FA

[Ungrounded Lightning]

AT&T had nice clean code that worked well was efficient but didn't do networking very well at all. So they hopped into bed with Sun who had real good networking stuff from BSD. The result was the two of them spawned SVR4. The read system call in the old unix was short and sweet and fit on a vt100 screen. The new one took pages even when printed out and didn't do anything new. It was a rewrite for the sake of a rewrite.

My impression of the SystemV series was that the proprietary status of Unix was in doubt and SystemV was intended to fix that.

Unix was written before the US copyright law was were extended to apply to software, and before the "program as component of patentable invention" hack was invented and debugged. So the only IP protection AT&T had on it was trade secret. Trade secret goes "poof!" when the secret is out, and AT&T had distributed several generations of source and documentation to universities around the world.

(This was also before the breakup of the Bell System, and there was some mandate on them publishing releasing certain telephone-related work as part of their monopoly mandate which, separately, might have imperiled its IP status. I don't recall the details. But it was probably made moot by the court-mandated breakup later.)

Unix had been a back-room project by a team that had been explicitly forbidden, at least initially, from building an OS. (Indeed, one factor driving the kernel's simplicity and the design goal of pushing as much out to the application layer as possible was the creation of plausable deniability: "An OS does X, Y, and Z and this doesn't. So it's not an OS. Right?")

Since they weren't writing something viewed as productizable or proprietary, they were at Bell Labs (where publishing was the usual route for most work), and software in those days wasn't productized anyhow, they felt no need to keep it under their hats.

The broad circulation of source and docs spawned the era of the commodity unix box. A new hardware vendor, rather than writing his own OS, could just port Unix to the box - a matter of hacking a couple thousand lines of hardware-interface code. AT&T would look the other way as long as they weren't selling it. Once they got it working, AT&T would cut a licensing deal on very good terms. (For them it was free money.)

This continued until the University of New South Wales built a course around System 6 (i.e. release 6 of the documentation set, which was how System N was named). They printed a two-volume coursebook - volume 1 being the kernel source pretty-formatted, while volume 2 was a textbook walking you through the guts. This immediately became an underground classic, and finally got onto the administrative radar screen at AT&T. The lawyers "Cease and Desist"ed the University.

The SystemV project, if I recall correctly, started shortly after the CONTU (Committee On New Technological Uses - charged with studying and proposing to Congress whether/how software should receive copyright protection) reported and Congress explicitly extended copyright to cover software. Now that IP protection was available, AT&T got together with several of the big Unix players and together they reimplemented the kernel from scratch, and tried to move everybody to the result.

They gave a number of plausable-sounding reasons for the work - claiming it was a great improvement on the previous stuff. But they didn't include the Berkeley work (especially noticible: no Berkeley Signals) which had its own proprietary issues. The resulting functionality of SystemV was both incompatible with and lower than both BSD and some other System N derivatives. So the general consensus (at least among the people I hung out with at the time) was that the whole exercise was to clean up the IP status of Unix for its future as a product.

Re:I read the FA

[808140]

I too find svc to be extremely annoying. However, replacing SYSV style inits with something else is not, on the face of it, a bad idea.

Consider that for the vast majority of init scripts, a process is started, stopped, or restarted. Lots of UNIX systems (including debian) provide a special utility that starts and stops daemons in a standardized way, and virtually all startup scripts just call that program.

Consider that everytime you run a startup script, you're loading a shell interpreter into memory, parsing an interpreted language (shell) and then freeing said memory (this is slow).

Consider that to enable or disable services (a fairly frequent task, unfortunately) you need to muck with symbolic links from rc directories (sometimes hard links). A pain in the butt for a simple task.

Consider that sysv init provides no dependency information, forcing the computer to abandon parallelisation methods (this short coming of SYSV and BSD style inits has been treated extensively in the past, but no interesting solutions have gained widespread acceptance).

I think that svc has a few good ideas, but I don't think they're being used properly. One, the addition of svc enable and svc disable makes enabling and disabling services very, very simple. Currently, when I install a service on my debian box, it usually is enabled right away -- but in some cases, this may not be what I want at all. For example, my laptop has dhcpd on it, because I occasionally use it to network boot windows systems into Linux. But I definitely don't want this service enabled -- when I need it, I want to launch it manually. My using update-rc.d to remove the rc.d links to the init.d file are not seen as a configuration change by my debian system and it will reinstate them, and it will start dhcpd when I install a new version of it, even if I don't have it running.

Having an "enabled" and "disabled" state for services is thus a very good idea.

Furthermore, given that virtually all services do exactly the same thing -- start, kill, restart (and occasionally reload) a process, running a different script for every service seems a bit silly. Sun's idea of having a series of XML files describing how to start, restart and kill processes isn't bad. It would be trivially easy to extend this to include dependency information, allowing services to be started in parallel. And distributions could flag these as configuration files, allowing you to hack them and have them be updated sanely, instead of relying on filesystem characteristics (links).

All in all, I think that there are some good ideas there. Perhaps XML is overkill... but open standards aren't a bad thing, and XML is as simple as you make it (Sun's svc XML, alas, is not very simple).

I didn't know they generated binary crap at boottime -- kind of stupid, that.

Anyway, let's not throw the baby out with the bathwater.

Re:I read the FA

[segfaultcoredump]

There are some very clever things in Unix that you don't notice till someone redoes them and turns them into a stinking heap. For example the new Solaris 10 services. It does what init and inetd does but needs a binary config file which it rewrites on boots and when it changes stuff (ala windows registry for unix). Having been way too deep on too many broken systems, I don't like binary files that change that are essential for my os to work. But this is progress...

Ok, from this little statement it is obvious that you missed the major feature behind the new 'greenline' code in Solaris 10. (I know, this is slashdot...)

In short, generates a vectored graph of services. This gives the system a list of services and their dependencies. The old init.d/rc.X only provides a linear `these scripts must run in this order` relationship.

This has several advantages that immediately come to mind:

1. The system can start faster since it can now run several init scripts at once. No longer does one have to wait for nfs to start before starting the web server (assuming one uses the all too common setup where nfs is rc3.d/S15nfs and the web server is rc3.d/S99apache)
2. Since the system tracks dependencies, it can restart dependant services as needed (and not touch services that are not impacted)
3. You can disable things and patches will no longer re-enable them. Under solaris 9, a common way to disable something was to rename the SXXbla file by putting a `.` or `_` in front of it. This works great unless they release a patch to that file and the new (patched) file gets dumped out there in the rc directory.
4. During a jumpstart (kickstart for you RedHat folks), you can drop in your own site.xml file and instantly customize a ton of thigns that used to require editing dozens of files.
5. It is now easy to drop in a service monitoring facility (like sun's SMF) that monitors key services and restarts both them and their dependent services.

By the way, the file that it uses is xml, not binary.

And it is also not a 'file that changes'. The actual config file is static (unless you make a change). The only thing that may change is the order that two nondependent services start in relationship to each other. And that is the point, they are not dependent and thus you should not care if apache starts before sshd. In fact, this is a very good thing as you probably dont want a problem in the apache rc file to cause sshd to never start (guess how many times i've seen rc3.d/S99apache and rc3.d/S99sshd on a single system... guess which one runs first under init.d... yup.... apache.)

For more details, you can check out the blogs of Stephen Hahn, Bill Moffitt, or Tobin Coziahr.

Re:I read the FA

[thogard]

Ok, so they mix make with init as well. It was done over 20 years ago (and the current init file format allows for this)

There is a binary file living in /etc that changes with every boot. If it is newer than the xml files, it doesn't get recreated. Its a sqLite file in fact. If you insert stuff in that file in the right spot,
it gets run even if you never touch the xml code.

I've never had dependency problems but the 1st thing I do when I get s solaris box is rename the Sxx to a proper order and nuke most of the useless ones. Then I add a & that should have been there for the last decade that sun seems to have forgot (but AT&T didn't)

I've found some very interesting things to do to the new system that can mess up a box in a way that the current tool set won't even let you see what is wrong. It appears to be a script kiddies back door dream. Sorry but that level of crud isn't going on a production system I run. If Sun insists on svc, thats fine, there are other OSs out there.

It seems to me that every time something in IT gets reinvented, its at least 10x as complex and only provides a slight improvement on the old system. When those improvements cause the complexity to rise to the level that prevents rapid tracing, then I've always found that its time to dump the system and look for a simpler solution.

Re:I read the FA

[thogard]

What you claim has been repeated by several others so I guess you got your incorrect info from a reliable source :-)

Software could always be copyrighted in the US. You just had to print it out and send it to the copyright office. This was done at least in the 1960s. All that changed was the copyrightability of stuff like tapes and diskettes.

There was little "trade secret" stuff in Unix. They shared the source with so many universities and the early contracts didn't mention trade secrests.

You also seem to be confusing System V development with SVR4. Sys V started out as a logical extenuation of System III which was already having problems with the extensions that the Version 8 were trying to bring back into it. Then there was the version that ran the ESS phone switches and would also run on the new 3B2 line. That was around the mid 1980s. SVR2 on the 3b2 would page (not swap, no real vm but its hardware supported it) and its idea of a network was uucp. Sun started selling workstations into AT&T and someone got the great idea to mix the sys V core with the sun networking and thats what R4 was. It was a bit embarrassing for AT&T to have to use a sun workstation as a front-end for stuff like their pixel machine as well. Because if issues of "not invented here", both sun and at&t thought they could rewrite all of it and get rid of all the old code. That upset IBM and DEC and HP who then decided to do their own project too.

Of course my memory of the facts my be as clouded by time as everyone else's. AT&T was a huge bureaucracy at the time right after the breakup there were lots of groups with no real direction and there might have many reasons for any action they took and today no one will know which reason was the real reason.

Re:I read the FA

[segfaultcoredump]

Wow, so are you saying that complexity is bad and that we should all stick with DOS?

The sql file gets recreated at every boot, unless you didnt change anything, then it doesnt (so it does not get changed at every boot? or does it? please pick one.)

Ok, so you removed bad init files (standard security practice provided that it is documented) and always remember to verify your changes after patching. Yeah, I've been doing that for years... a real pain in the ass compared to using smf.

But the kicker is that you changed the start order around from the default and added an & that causes the init scripts to get put into the background.... that kinda breaks things that may depend on those other files to finish running first.... There is a reason that AT&T didnt add it.

As a general purpose solution that needs to be administered by others, this is not a good thing. You _do_ work as a member of a larger team, right? I've cleaned up enough messes from admins who came before me and thought that they were just soooo clever. The folks who have to support the boxes after I leave for the day should not be hit by any nasty surprises at 4am when something goes wrong. I don't like taking my pager and laptop on hiking trips, and if I did my job right, anybody in my team can step in and not be blindsided by my way of doing things.

As for messing up boxes, that is easy. I dont see how smf makes it any easier or harder than just playing with the startup scripts themselves. The script kiddies wont bother w/ smf if they can just rootkit the box. Besides, why are you even trying to clean up the mess when you should have just flashed the system from a known good image and restored the user data?

As for complexity vs functionality... its a balancing act and always has been. Storage area networks (real fabrics, not those FC-AL things) can make setting up the storage a real pain in the ass compared to the old days of directly connected ide/scsi. They also let you do things that were never possible before (or at least very difficult). In the environment that I work in, that extra complexity was worth it for our DR system. The same goes for all advances in the past 40 years of computers: networks, multi user systems, file permissions, non root administrators, etc. They all add complexity, they all solve problems that were not solvable (or were so nasty they may as well have been left unsolved), and they all involve tradeoffs. The job of a good system architect is to determine if the pros outweigh the cons.

Re:I read the FA

[igb]

The SMF code you refer to as replacing init and
inetd doesn't use a binary config file. It
uses XML, which you can quite easily edit by
hand if svccfg isn't doing what you want.
Use svccfg export to see what's going on.
For example, see below.

Note the upside of all this is that the dependencies
between services are precisely defined, so on
MP machines they boot _much_ faster because
init scripts that don't depend on each other
can be run in parallel. And of course you can
get a manifest of what's running on a machine,
checkpoint it, consisently restart things
(svcadm restart network/ssh), consistently
turn things off (svcadm disable network/ssh) and
so on. chkconfig on Linux sort of does the same
job, but surely to God no-one is defending the
SVR4 init.d format? The howls of protest when
that arrived in Solaris 2, replacing /etc/rc.local
in SunOS4, could be heard from coast to coast.

ian

# svccfg export network/ssh

[ and so on ]

Re:I read the FA

[Anonymous Coward]

Consider that everytime you run a startup script, you're loading a shell interpreter into memory, parsing an interpreted language (shell) and then freeing said memory (this is slow).

No it isn't.
Except the first time, the shell interpreter is already loaded into memory.
In fact the only reason why shell scripting is slow (relative to other interpreted environments) is because so many of the trivial operations require a fork/exec. But you're not talking about that, so you're wrong.
fork and mmaping an interpreter (especially if it's statically linked) is a relatively cheap operation.

For example, with python and perl, which are both used for scripting, much more time is spent in their own start up code than in the kernel forking and execing.

For service startup and shutdown which is relatively infrequent, I have never heard of shell script execution time being considered a problem if the script isn't completely retarded.

Re:I read the FA

[R.Caley]

However, replacing SYSV style inits with something else is not, on the face of it, a bad idea.

You might want to have a peek at the FBSD5 init setup. They took the useful bit of the SysV init (modularity, and the ability when push comes to shove to do as much work as necessary to get reliable startup etc because you have the ability to write any old script), removed the evil of run levels, added in dependencies and the existing FBSD sanity of having all the enable/disable settings and parameters (eg what port to run the service on) in one easy to find and easy to change file.

I haven't butted heads with it too much, so I haven't found the inevitable problems and idiocies (everything has problems and idiocies), but I did smile when I first saw it, thinking someone was on my side for once.

Re:I read the FA

[808140]

That's a good point, thanks.

Re:I read the FA

[thogard]

On my system the binary file contains the last time when the service started. That means a file in /etc gets written with every boot.

And yes I'm saying complexity is bad and we should stick with what works (and it isn't dos)

the Solaris start order has been wrong since they 1st used the term solaris.

I currently work as a team of 3 and I'm the point guy when junk hits the fan. I've been a member of much larger teams (nearly 100) and I'm always the point guy who gets called out to fix what can't be fixed. I also make it clear that when I go away there is no way they are going to contact me at all (Dive N Queensland!)

My way of doing things may be the old BOFH way but I've got a mailing list in a yellow book which has almost a dozen people who can fix problem on my systems with out ever seeing them in a reasonable about of time from 1st (unix) principals. Can your team?

Of course I've blown away the concept of net work storage (it doesn't work in the real word) and built systems that don't depend on it. I've been doing this for over a decade and my systems cope will all kinds of unexpected outages. My most basic rule is KISS.

Re:I read the FA

[thogard]

On build 72 it was stored in a sqlite database which looks binary to me.

I'll leave it to the script kiddies to provide an example of where the current design is wrong.

Re:I read the FA

[Anonymous Coward]

Other systems are working on newer inits, notably rubyx has redone the init system with parallel inits and dependancy following (without a binary file) - he rethought the packaging at the same time, nicely done for one guy a few packagers.

Re:I read the FA

[Crazy Eight]

Gerrit Pape's runit -- an enhanced, GPL'd workalike of DJB's daemontools might be worth a gander if you haven't noticed it already.

Re:I read the FA

[Anonymous Coward]

Stop posting using a narrow-column format. It's annoying. Let the browser do the wrapping.

Re:I read the FA

[runderwo]

Having an "enabled" and "disabled" state for services is thus a very good idea.

man update-rc.d - disabling a service is as easy as update-rc.d -f remove . Re-enabling the service has a specific syntax to give the runlevels you want it started in, as well as its order number in that runlevel. You could put this in a fancy GUI if you wanted.

Re:I read the FA

[808140]

I appreciate your pointer, but you probably ought to have read what I wrote a little bit more carefully.

But I definitely don't want this service enabled -- when I need it, I want to launch it manually. My using update-rc.d to remove the rc.d links to the init.d file are not seen as a configuration change by my debian system and it will reinstate them, and it will start dhcpd when I install a new version of it, even if I don't have it running.

So as you can see, I'm quite aware of update-rc.d's existance. It just doesn't work particularly well. It's an improvement on manually removing links, of course. It forces me to remember the runlevels of the service in order to re-enable it, which is lame. What I most generally end up doing is editing the init script directly to avoid this mess. It shouldn't be such a pain.

Re:I read the FA

[runderwo]

You could file a bug on the package to include a default file. Most packages' init scripts source an /etc/default/* script for their settings, which _is_ considered a configuration file and won't be overwritten on upgrades.

Off the top of my head, here you go

[Anonymous Coward]

Here are some obvious differences from someone who's worked on both. These are just some quick things which come to mind, off the top of my head.

1. Streams. ATT's streams was just a mistake. It was a great idea in theory. In practice, it adds too much overhead without enough advantages. Even at Sun, it's recognized among Engineers as a mistake, and it's significant that methods of speeding up the networking stack involve discussions on how to get away from streams.

2. The VM. Linux's VM in 2.6 is vastly superiour to stock ATT VM. And it's probably better than Sun's, in the 2.6 Kernel (NOT before 2.4 however). For example, the VM limitations are one reason why NFS sucks in 2.4 kernels; and even Trond has admitted this.

3. Boot-up code. Grub + Linux rocks. It's the best solution out there. Vastly superious to everything, including Sun's implementation. Of course, Sun is hobbled by that Open Boot nonsense, where you have to type an absolutely absurd amount of stuff to specify a device.

4. kernel debugging. Stock ATT blows here. Sun rules, with Linux becoming a close second. This is with respect to kgdb. Although some new technologies are under development in Linux which are interesting.

5. SMP. Stock ATT blows, but not much has been done lately here. Sun's implementation is superiour to everything, which is why you can support so many processors. Linux is starting to catch up though.

Well, that's just off the top of my head. There are probably other things, but I've got to get back to work. :P

Re:Off the top of my head, here you go

[carcosa30]

Just so you know... best boot manager out there is called Gag. It has no problem supporting whatever operating systems it finds on your disk, and it finds new operating systems AT BOOT TIME.

Re:Off the top of my head, here you go

[Anonymous Coward]

You are correct on a bunch of this. Apparently, they did internal benchmarking and found that 2.6 was killing them esp. con networking.

In fact, Sun has recently had to re-write major portions of Solaris BEFORE releasing 10.0 to the public. My understanding is that the top ppl spent a lot of time looking at Linux and then "borrowed" ideas.

I find it funny, that when they take ideas, it is borrowing, but when Linux takes ideas, it is theft. Oh, well one groups terrorists is another's freedom fighter.

Re:Off the top of my head, here you go

[Anonymous Coward]

With regard to # 5, what about SGI which has 2048 CPUs using Linux in a near Linux scaling. Is Sun better than that these days?

Re:Off the top of my head, here you go

[Alien Being]

AFAIK, the big SGI machines are NUMA, not SMP.

Re:Off the top of my head, here you go

[thammoud]

Great commentary. Blows, Sucks and rules. Wow. Great technical insight. A mod 4? /. is sad indeed.

Re:Off the top of my head, here you go

[idiotnot]

3. Boot-up code. Grub + Linux rocks. It's the best solution out there. Vastly superious to everything, including Sun's implementation. Of course, Sun is hobbled by that Open Boot nonsense, where you have to type an absolutely absurd amount of stuff to specify a device.

Not. OpenBoot/OpenFirmware are vastly superior to the cheesy i-must-look-like-a-floppy system that crippled pcs have. When grub supports testing hardware, or listing the devices present inside the system over a serial console, let me know. List the scsi busses and the devices present? I've used OpenBoot(sun), OpenFirmware(Apple), the NeXT Rom monitor, as well as the stuff on Alpha and PA-RISC, which I can't remember the names of right now -- they're all much more flexible than grub.

Grub also still doesn't work on all PC hardware. I've never gotten it to work with a Compaq SmartArray card. Never. Several different versions of Grub, several different SmartArrays.

Granted, Grub is a massive improvement over crap like lilo, but it's nowhere near as flexible as what you'd find on a good unix machine.

Re:Off the top of my head, here you go

[Anonymous Coward]

damn, i just knew someone would bite on that particular comment...

Re:Off the top of my head, here you go

[cortana]

First of all, you are correct; Grub can't compare to OpenBoot/Firmware, etc.

However, you can list devices present with tab completion. Type root (hd and you will get a list of all your disks. At least the ones that Grub can see through the PC BIOS calls. *shudder*. God knows how you're supposed to boot off a PCI IDE controller, I sure as hell can't.

Re:Off the top of my head, here you go

[idiotnot]

But that just barfs out what's written in device.map, a file that's sitting in /boot/grub. If those devices change and you don't update it...

Or if you want to boot from a device you've just inserted, or you manage to kill the filesystem where grub lived (/me raises hand there)....

PCs have this problem with too much backwards compatibility. The fucked up 1981 boot code perfectly illustrates that. There is absolutely no good reason that a PC built in 2005 should be able to boot DOS. Not one.

Re:Off the top of my head, here you go

[Anonymous Coward]

First, the biggest single system Linux box is 512 CPUs (although I think NASA has 2048 CPUs in a BX2 machine, which has an expanded cache coherency domain to 1024 or 2048 CPUs, I'm not sure if they've actually hooked them up yet).

Still, that literally blows Sun's biggest machine out of the water. Especially in absolute performance, when you consider a new 9MB cache I2 is probably a clear twice the speed of the fastest of sun's sparcs.

Second, Sun's machines are NUMA as well. That's right, they have Non Uniform Memory Access. See here. They have a 4 tiered access hierarcy on memory. Either way, SGI's NUMAlink interconnect is far better than Sun's old crossbar switch dinosaur. See here. The Altix has 4 times the top-of-the-line Sun's memory bandwidth per CPU. That is SGI's old interconnect too, mind you.

Re:Off the top of my head, here you go

[Anonymous Coward]

> 1. Streams. ATT's streams was just a mistake.

Have to disagree here. Streams are elegant
and provide a very modular approach to solving
certain kinds of problems. They may or may not
be the most efficient but "efficiency" isn't
the only measure of a good system.

> The VM. Linux's VM in 2.6 is vastly superiour
> to stock ATT VM. And it's probably better than
> Sun's, in the 2.6 Kernel (NOT before 2.4
> however).

Wow... if there is one where Linux *does* have
a weak spot it is the VM. I doubt if it is better
than stock SVR4 and it is definately inferior
to Solaris.

> 3. Boot-up code. Grub + Linux rocks. It's the
> best solution out there. Vastly superious to
> everything, including Sun's implementation. Of
> course, Sun is hobbled by that Open Boot
> nonsense, where you have to type an absolutely
> absurd amount of stuff to specify a device.

This is definately one area in which SVR4
shined. SVR4 had a simple but entirely ef-
fective mechanism for handling kernel booting.
It used a simple, continguous layout filesystem
call the 'Boot File System' or BFS. If you wanted
to install a new kernel to boot the only thing
you had to do was:

mv /boot/kernel /boot/old_kernel
cp new_kernel /boot/kernel

and then reboot your machine. No fuss no muss.
I would really like to see that mechanism make
its way into Linux.

Re:Off the top of my head, here you go

[Anonymous Coward]

>> The VM. Linux's VM in 2.6 is vastly superiour
>> to stock ATT VM. And it's probably better than
>> Sun's, in the 2.6 Kernel (NOT before 2.4
>> however).
>
> Wow... if there is one where Linux *does* have
> a weak spot it is the VM. I doubt if it is
> better than stock SVR4 and it is definately
> inferior to Solaris.
>

Wha? Not better than stock SVR4?! Are you joking? Sorry, Linux's memory management system is up there with the best of them.

Being the well informed person that you are, you probably heard about all these memory management problems Linux 2.4 had, and drew your conclusions from there, right?

Actaully, it wasn't a bad mm either the main problems it had were on PAE "highmem" systems, and not being able to properly manage a huge amount (16GB+) of high memory with a small 1GB of directly mapped kernel memory. This was a definite failing, but due to the fact that mm developers at the time did not have access to such machines, not something you can really hold against them.

If you think SVR4 could cope with such machines, you'd be talking from your ass hole, right?

Re:Off the top of my head, here you go

[eviltypeguy]

Except for the reason that PC's are still used with DOS for embedded systems applications...

Re:Off the top of my head, here you go

[SunFan]

Still, that literally blows Sun's biggest machine out of the water.

Would it have ever occurred to you that Sun doesn't sell bigger than 72-way SMP, right now, because that is what their target customers want? UltraSPARC IV can scale to 1000s of CPUs by design, just like Itanium.

Since you seem to know so much about SGI, I'd like you to tell us how many Altix machines have been sold. You might find that the market for 2048-CPU single image servers is rather limited. A niche, you might say.

Re:Off the top of my head, here you go

[SunFan]

Is Sun better than that these days?

They could be, because UltraSPARC will scale that big, but they don't, because Sun understands that practically no one buys 2048 CPU single-image systems.

Re:Off the top of my head, here you go

[SunFan]

Of course, Sun is hobbled by that Open Boot nonsense, where you have to type an absolutely absurd amount of stuff to specify a device.

Of course, if I have a dozen network ports, several hard drives with several operating systems, and another dozen CD-ROM and DVD drives, OpenBoot will allow me to easily boot from any of them. Also, I recommend you look up documentation regarding devalias and nvramrc.

OpenBoot is so superior to the PC BIOS that it is the main reason I would hesitate to buy another PC.

Re:Off the top of my head, here you go

[Anonymous Coward]

No, their systems will not scale that big. No way, no how.

And it is not a matter of the chip scaling that much, it is a matter of the interconnect and glue logic (cache coherency, etc).

Their dinosaur SunFire crossbar switch based interconnect *cannot* scale that high due to its quadratic nature by design. Their current high end switch tops out at 18 links (and has done for a long time). This gets it up to 144 CPUs I think. To get to 2048 CPUs, the switch would need to be over 200 times bigger, more expensive, etc. (although it may very well be simply impossible due to electrical timing constraints).

And you'd be right that nobody would buy a 2048 CPU SPARC system from Sun, because the buyers are interested in high performance computing. Wait till SGI roll out their 2048 CPU single system image systems.

Re:Off the top of my head, here you go

[Anonymous Coward]

Would it have ever occurred to you that Sun doesn't sell bigger than 72-way SMP, right now, because that is what their target customers want? UltraSPARC IV can scale to 1000s of CPUs by design, just like Itanium.

Sun's current technology would not scale the UltraSPARC to 1000s of CPUs (see other post). Anyway, it isn't about the CPU, but the glue logic. And Sun's doesn't.

Since you seem to know so much about SGI, I'd like you to tell us how many Altix machines have been sold. You might find that the market for 2048-CPU single image servers is rather limited. A niche, you might say.

I don't know how many Altix machines have been sold. I'm not even remotely interested in that figure. You must be from the marketing department, you could probably find estimates or figures somewhere. But no, this discussion is purely about technical prowess (or was until you arrived).

Re:Off the top of my head, here you go

[SunFan]

Wait till SGI roll out their 2048 CPU single system image systems.

Will they be able to before Itanium gets canned? Let's hope so.

As far as scaling goes, UltraSPARC _does_ scale that big. The crossbar is a red herring. If Sun saw a place for themselves in that market, they would make a new interconnect. They have engineers, too, you know.

I think you are just a benchmark fanboy. If Sun's next CPU manages to edge out Itanium the next go-around, can I use sed to swap the names in your post above?

Re:Off the top of my head, here you go

[SunFan]

You must be from the marketing department...

No, my ID says "fan", not "employee" or "astroturfer". Big difference.

So the advantage of SGI is their interconnect. That's fine, but my original intended point was that Sun and SGI don't even live in the same market universe, meaning comparisons between them aren't very fruitful.

Re:Off the top of my head, here you go

[Anonymous Coward]

As far as scaling goes, UltraSPARC _does_ scale that big. The crossbar is a red herring. If Sun saw a place for themselves in that market, they would make a new interconnect. They have engineers, too, you know.

They don't have a place in that market though because nobody would want to use UltraSPARC CPUs for HPC. The only single entry in the top 500 list of supercomputers that uses Sun systems of any kind uses ones with Intel processors.

And the "they would make themselves a new interconnect" crap doesn't fly with me boy. That's just a cop out for someone who lost the argument. Oh, they "could make faster CPUs too", right?

I think you are just a benchmark fanboy. If Sun's next CPU manages to edge out Itanium the next go-around, can I use sed to swap the names in your post above?

Do whatever you want, and keep up the name calling too, while you're at it.

I'll talk about what is currently happening and what is currently relevant. For the past probably 10 years or more, Sun's SPARCs have been consistently on the bottom of the CPU performance pile, they are most definitely not participating in the game of leap frog that happens between the top of the line players (ie. POWER4 I2 POWER5 ...).

Re:Off the top of my head, here you go

[Anonymous Coward]

Well, the initial question was about the scaling of the operating systems. So no, you can't make a useful comparison of Linux versus Solaris when comparing Linux on Altix versus Solaris on E25K (or whatever).

You could say that the Linux on Altix system has better scalability than the Solaris on Sun system though, if you measured that to be the case on a specific workload.

I believe Linux is at least as scalable as Solaris these days though, if not more so. You're entitled to the opposite opinion, but please don't present it as fact (ie. don't tell me "no") unless you can show me some data to back it up.

Re:Off the top of my head, here you go

[SunFan]

My understanding is that the top ppl spent a lot of time looking at Linux and then "borrowed" ideas.

How can Sun borrow ideas that aren't in Linux? Their TCP/IP stack leapfrogs Linux, for example. Solaris Containers don't exist in Linux. dtrace doesn't exist in Linux.

Solaris does now use GNOME, but Sun is an active participant in GNOME...not exactly borrowing. Overall, Sun is a pretty good FOSS citizen (I'd figure OpenOffice.org is worth the GNU tools in /usr/sfw).

Re:Off the top of my head, here you go

[Anonymous Coward]

4. kernel debugging. Stock ATT blows here. Sun rules, with Linux becoming a close second. This is with respect to kgdb. Although some new technologies are under development in Linux which are interesting.

You say this as if it were a good thing. It probably isn't!

Re:Off the top of my head, here you go

[andreyw]

Gah, I loved your post but I disagree with GRUB being somehow better than OpenBoot/OpenFirmware. The drive enumeration is completely braindead, doesn't match up with anything in Linux (heck, doesn't even match up with the enumeration in Hurd, and Grub is the Hurd bootloader, dammit). Also, GRUB is just a bootloader - thats it. Sure, if you use the Multiboot format it can pass some information like memory size to the kernel, but OF/OB is a system monitor that manages all the hardware at start-up. The naming isn't ridiculous - its descriptive of WHAT the device is and WHERE the device is (including the bus its on). Also OF/OB provide an architecture-independent language (a variation of Forth) for writing PCI-card onboard ROMs, as well as an easy interface for USING these device from within OF/OB (the device tree). Technically, a SCSI controller from UltraSparc would be able to be booted from by a Mac's OpenFirmware.

Re:Off the top of my head, here you go

[runderwo]

You can use Grub over a serial console.

Re:Off the top of my head, here you go

[Anonymous Coward]

Others have mentioned OpenFirmware, but you should also check out FreeBSD's current solution to 3. (and 4., for that matter).

Re:Off the top of my head, here you go

[ader]

Actually, no. Sun took the approach that anywhere Solaris was slower than Linux was a (formally logged) bug, and therefore required fixing.

Re:Off the top of my head, here you go

[Saatan]

It is interesting, after an hour of reading docs & googling grub worked well on a Smart Array 5.

Re:Off the top of my head, here you go

[Anonymous Coward]

Err, yeah that's probably right. Parent was just saying that there was a number of important places where they found Solaris to be slower (and your post adds weight to this - they wouldn't have taken that approach if Linux wasn't actually faster).

That is not to say that all these "bugs" have been fixed, however. I have observed a number of areas where Solaris 10 lags Linux 2.6 in performance.

Re:Off the top of my head, here you go

[Colm Buckley]

Still, that literally blows Sun's biggest machine out of the water.

Aah, don't you just love it when people say "literally" when they mean "metaphorically"...

Re:Off the top of my head, here you go

[_damnit_]

Umm, here's the UltraSparc page which states that USIV scales to ~1000 CPUs. I think the number is actually 1024, but hey close enough, huh. If there was a market, they could probably extend that out to a multiple with some specialized hardware, but who cares! This is all like measuring cock sizes.
USIV specs

And yes I am an employee of Sun. I am not a marketing drone though. If you have any doubt about that, read my past posts. There are a few since I've been here since around the beginning.

Re:Off the top of my head, here you go

[Crazy Eight]

It literally drives me up a wall.

Re:Off the top of my head, here you go

[Anonymous Coward]

I love it when I shut people up so hard that they can't do anything but pick around the sides of my arguments. It means I'm right, and they're angry. And that makes me happy.

Re:Off the top of my head, here you go

[Anonymous Coward]

Yeah so the CPU may be able to go to 1024, but the interconnect and system logic can't.

Conversely, the opteron may only have enough internal logic to gluelessly run in an 8 CPU system (I don't actually know), however off board cache controllers could "easily" remove that limit.

The difference is easy... and surprisingly simple

[Supp0rtLinux]

One is completely and totally open source. The other is not.

Re:The Facts

[Anonymous Coward]

WASP

Actually, he's a WSA - a white, Scandinavian agnostic.

Euh?

[Anonymous Coward]

I'm not a native english speaker but does anybody can make head or tail of whatever he says?

On the other hand he seems a credible source of insight, being the author of the best seller "The Unix Guide to Defenestration". That my friends is a book I missed, somehow. Here's the beginning of the blurb for the book:

This book explains that most commercial systems work disappoints because the incentives favor exactly the kind of continuous low level failure we usually see. Systems management careers are enhanced by budget growth and staff expansion, both of which are maximized by maintaining a level of non performance that teeters on the edge of catastrophe. Correspondingly, systems budgets and staffing levels, and therefore management careers, are diminished by successful execution of the cost reduction, or cost avoidance, mandates that normally go with the job.

Maybe it's just me...

Re:Euh?

[Ungrounded Lightning]

On the other hand he seems a credible source of insight, being the author of the best seller "The Unix Guide to Defenestration".

The book is NOT a how-to about using Unix as a tool for completely purging Windows from your IT operation. He grabs the term "Defenistration" and defines it to mean something else - something unrelated to windows. So IMHO a significant part of the book's reason for existence is to co-opt the word and the book title.

Re:Euh?

[Elvis77]

Don't worry mate... I speak an open source version of English known as Australian and I don't follow either. I think he's a speakin' crapinese.

Yup

[Anonymous Coward]

The author of this piece is an idiot. Why anyone would pay him to write about computers isn't beyond me though. Seems like most of these computer journalist types are hopelessly dense. Their chief talent seems to be writing countless paragraphs about how ignorant they are.

In other news today

[donnz]

ASDA boxer shorts are very similar to those sold in Tescos...

I mean, no shit, OSs doing similar things, what an insight.

Leave Paul alone.

[Anonymous Coward]

Paul is dieing a slow death, and he has recently seen that OGrady is doing so much better be taking on OSS. So what is he doing? taking on OSS. Basically, this is his attempt to make a comeback (think of john dovrack for the last 15 years).

Comparing Linux to SVR4

[yorugua]

what??? I mean, sccs, you know... I kind of miss "what".

The GPL is Linux's hallmark

[andrel]

What can you do with Linux that you couldn't do with SVr4 in 1992? Freely share the source with all your friends and customers without fear of lawsuit and include pre-installed binaries on hardware without paying royalties. GPL licensing is the single most important feature distinguishing Linux from proprietary kernels such as UNIX and other free kernels like the BSDs. The GPL's copyleft provision and the dual-licensing opportunity it creates are why companies like IBM and SGI have contributed subsystems like JFS and XFS to Linux. They wouldn't have shared the same code under a BSD license. Linus has said that choosing the GPL is the best decision he made in the early days.

Re:The difference is obvious

[sp0rk173]

Please remove your slashdot accound. Your assumed clever comment has shown you to be, as esr would say, a "luser." But, then again, esr is a loser. So, go figure!

bahaha

[sp0rk173]

NICE.

Reasons to use threads on uniprocessor x86

[pslam]

He's obviously quite unqualified to write the article and didn't even bother to ask anyone. A single processor can emulate multiple processors, and this is often a convenient and even efficient programming model. To elaborate:

• Sometimes it's cheaper in memory and/or clock cycles to use context switching and multiple stacks than scheduling functions off a single thread. This can be true even if the threads aren't concurrent (e.g coroutines).
• It's often easier to use multiple threads even when not necessary, despite having to deal with mutexes. The amount of state in some protocols can lead to a mess.
• When you need low latency, threads are often the only solution.
• Single threaded apps cannot schedule tasks preemptively. Reason enough right there.
• If you need prioritisation of preemptive tasks. When you do, the kernel is best off doing the scheduling because you might not be the only process with priority needs.
• A thread is just a process without most of the baggage, and you don't see people arguing that processes don't belong on x86.

Then again, mindless use of threads does annoy me. So I'll list some "soft" indicators of when you shouldn't use threads:

• When a single threaded app would be substantially faster.
• When you don't need preemption.
• When you're going to be using 8,000 of them. It's at least 4-16KB per thread, and thread switches aren't negligably cheap. Rewrite with poll().
• When you cannot say with certainty that you won't deadlock or race.
• When you don't understand what the previous point means.
• When your hardware/OS/platform has a hideous thread switching cost. Can't think of any reasonable system these days where this is a show stopper.

Leave criticism of OS features to those who are qualified, Murphy. Better still, try asking one of them - there's no shortage.

Re:Reasons to use threads on uniprocessor x86

[starfishsystems]

So I'll list some "soft" indicators of when you shouldn't use threads

• When event dispatch is sufficient.

I came across a paper about five years ago which I thought argued this point quite eloquently, basically reminding people that lots of problems don't require true concurrency. I've lost track of it now, but I'd be delighted if someone remembers it.

Re:Reasons to use threads on uniprocessor x86

[pslam]

When event dispatch is sufficient.

Yes, that's the term I was grasping for. It's amazing how quickly people dive into a monstrously threaded program without considering that option. I put the blame for a lot of this down to the original (thankfully going obsolete) Java programming model - have a thread for everything that blocks. Many people are unfortunately now raised on this misdesigned concept.

Re:Reasons to use threads on uniprocessor x86

[wirde]

Maybe this is what you are referring to?

http://home.pacbell.net/ouster/threads.pdf

Re:Reasons to use threads on uniprocessor x86

[starfishsystems]

It is! I recognize it for sure. It turns out that there is no paper, but there are some very readable slides. John Ousterhout is the author, and that makes total sense in retrospect. He developed Tcl/Tk, which emphasizes events. Actually, the event mechanism itself was migrated from Tk to Tcl only a few years ago. Thank you!!!

Linux Concurrency

[Anonymous Coward]

I'm not sure what the kernel has to do with it. The point of achieving concurrency is to avoid kernel entanglement. That means lock-free programming where possible. How successful you are there depends on the hardware architecture and who's supporting lock-free programming. As someone who's doing the latter (Atomic Ptr Plus), it's not likely I'm going to get ahold of a Niagra processor based system (and I'm going to dump my SB100) so you won't see too much there. However, I am going to get a Mac Mini, so you will see support for Darwin as well as Linux.

My Thoughts Exactly

[oli_freyr]

Just a "me too", nothing to see here... ;)

Almost all articles on LinuxInsider seem to have one thing in common: look legit to the PHB's out there, but contain a grain of FUD, that when joined could fill a FUD-shaker...

Why is it that slashdot can never....

[Anonymous Coward]

Talk about technology along with both pros and cons. Why is everything so religious and arguments are based on policy rather then technology.

We can all learn from everyone, even if we can't see their source code! Inovate rather then immatate.

Re:The difference is easy... and surprisingly simp

[black mariah]

And in what way, exactly, does that have a motherfucking thing to do with technical aspects of the OS? Give me that "because it's Free! You can modify it!" bullshit and I'll take a crap on your dinner.

why

[suezz]

he doesn't need any help - he seems to have figured everything out himself - System V is great and "enterprise ready" and linux is nothing but a toy. he is a troll just fishing for SCO I bet - last thing I would do is help this joker -

VR?!

[adriantam]

System V Release 4 has nothing to deal with virtual reality. Please write it as System V R4 but not System VR4.

Re:The difference is easy... and surprisingly simp

[SpaceLifeForm]

You are quite correct. Not surprisingly, your post was moderated 'Redundant'. Not surprisingly, your post was the first to point out the difference in licenses. Not surprisingly, the astromods are out in force.

His compiler gibberish is...gibberish

[Anonymous Coward]

The reason you don't see "one pass" compilers is that the *sequential form of source code* (top to bottom) is not an easy representation to do anything with as far as optimizations go.

That said, for languages without goto it's possible to create SSA form for a program in one pass, and that *is* a useful format for subsequent optimizations. More importantly, for real languages like C/C++ you can still create SSA form in near-linear time.

WARNING: BACKGROUND AHEAD

[Anonymous Coward]

The author of TFA thinks that SCO has a case. Hopefully, that should alert you all which corner this guy is in. I've tried reasoning with him over e-mail, but:

• He would not respond to my argument that there is BSD code in UNIX.
• He thinks SCO has a case, but their lawyers are doing a bad job of explaining it.
• He thinks IBM's lawyers are in cahoots with Groklaw to make SCO look bad

Just for grins, I will now debunk TFA:

• "Imagine, for example, trying to build a compiler able to produce an efficient executable in exactly one pass. Nobody does this now" - Except TCC.
• "raises new issues because many of the changes made to process and memory management between the 2.4 and 2.6 Linux kernels look a bit artificial" - Bold claims (and no reference) for someone who claims to be ignorant. But historically, a large fraction of Linux gets re-written between major versions anyway. Compare V2.0 and V2.2 or V2.2 to V2.4. I dare you!
• "which kernel would better illustrate the implementation ideas? [..] the right answer here is System VR4, mainly because it's almost equally portable but simpler and clearer." - It also performs terribly. An O(1) scheduler will look messier than an O(n) scheduler. Hmm, MINIX is even simpler and clearer still.. Hey, I see where this is going!
• "Compare Microport's AT&T Unix port [..] in 1992 to CDE running under Linux 2.4 [..] today and there are enormous practical differences, but few conceptual ones." - Maybe because they both stick to the POSIX API? Look at it the other way: Windows XP is conceptually the same as Windows 3.1. You just send messages and handle events, right?
• "they didn't come from the Minix/SysV foundation." - Aha! Here he is red-handed implying that Linux was "founded" on Minix/SysV. Go read Groklaw you SCO shill.

Re:WARNING: BACKGROUND AHEAD

[Cryptnotic]

• "Imagine, for example, trying to build a compiler able to produce an efficient executable in exactly one pass. Nobody does this now" - Except TCC.

He said "efficent executable". No one tries to argue that TCC produces faster executables than GCC because it doesn't. TCC does however produce executables faster than GCC. So if you want a working executable as fast as possible, then you want TCC. If you want a fast executable even if it takes longer, then you want GCC.

• "they didn't come from the Minix/SysV foundation." - Aha! Here he is red-handed implying that Linux was "founded" on Minix/SysV. Go read Groklaw you SCO shill.

Actually, he was comparing OpenLook running on AT&T UNIX to CDE running on Linux, saying that they were conceptually similar. Then he went on to say that both of those were very different from Gnome and KDE, but that they didn't come from the Minix/SysV foundation.

I'm not really defending the guy. He's still a SCO/Microsoft shill. But if you're going to debunk him, at least you should get your reading of TFA correct. If you don't, you're the one who looks silly.

Re:WARNING: BACKGROUND AHEAD

[Anonymous Coward]

Windows XP is conceptually the same as Windows 3.1. You just send messages and handle events, right?

Wrong. Windows NT (and everything it spawned) is a proper operating system, with memory protection, preemptive multitasking and so on. Windows 3.1 is not an operating system, it's a GUI on top of DOS. DOS isn't an operating system either, it's "a single-tasking non-reentrant interrupt handler"

Re:The difference is easy... and surprisingly simp

[Anonymous Coward]

Yeah waddap bitch motherfucker nigga fuck bitch fucker nigger motherfucker shit yeah bitch yeah yeah homie shit ass bitch fuck shit nigger yeah yeah nigger bitch fucker motherfucker shit yeah?

Re:The difference is easy... and surprisingly simp

[black mariah]

Oh wow, a random string of swear words. I'm so pwned. I'm going to go and cry. Really dude, that was just fucking pathetic. Try harder next time.

Re:The difference is easy... and surprisingly simp

[Anonymous Coward]

You want to talk about pathetic? Start with "pwned".

Phony as a Three Dollar Duck

[Ohreally_factor]

He's on that slippery slope between a rock and a hard place, out of the frying pan and into hot water.

=)

Two Words:

[Anonymous Coward]

YAW--WN.

What's in the list?

[b00m3rang]

I'm curious, and trying to learn more about Solaris... what /can/ Solaris do that Linux can't?

Amazing

[Anonymous Coward]

That info was straight from several Sun engineers who were re-writing major sections of the networking code BECAUSE they had lost badly to linxu kernel 2.6 during internal benchmarking. Now, you state that it is not so. I have known these guys for years. Are you calling them liars?

WTF does GNOME have to do with Networking and redoing their kernel? And WTF does dtrace or containers have to do with borrowing ideas from Linux on how to improve their speed and stability?

You may wish to go anonymous or simply use different names since it appears that you are a marketer for Sun. I would suggest that you take lessons from MS (or IBM about 20 years ago).

Re:Amazing

[SunFan]

Are you calling them liars?

Absolutely not. So, either you have privileged inside information or are lying, I can't tell, because I don't have privileged inside information to check against.

you are a marketer for Sun

No. The main problem is that it is impossible to have any sort of real conversation on Slashdot. For example, the earlier point was about "stealing" from Linux without giving back (a troll), and I pointed out that the borrowing and giving goes both ways way beyond the kernel and networking. FOSS and commercial software are an _ecosystem_, and I have learned my lesson to ignore narrow-minded trolls from now on.

Another ODD

[Anonymous Coward]

You say there is not much market for top machines. IBM, HP, and SGI all seem to think otherwise. They are developing very large systems.

www.top500.org shows otherwise, as well. In fact, in top500, the first hint of Sun is @ #31. Right now, even Apple is ahead of Sun (yeah, it is a cluster, but their are plenty of others that are not).

Re:Another ODD

[Anonymous Coward]

Actually, that is the only hint of Sun. And that is a few Sun machines in a cluster along with commodity systems from other vendors too. And the Sun machines are using Intel processors.

Re:Another ODD

[SunFan]

You say there is not much market for top machines. IBM, HP, and SGI all seem to think otherwise. They are developing very large systems.

The really huge computers are all for government labs, which are not in huge abundance. The other markets for these computers can be satisfied with niche players like Cray and SGI. Sun's sweet spot is for business servers and medium-scale engineering, IMO. The fact of the matter is that people want high flop/$ in a supercomputer, which is why it appears that x86 dominates the top 500. Outside of supercomputing, flop/$ takes a backseat to many other factors.

One other thing about the top 500 that isn't advertised is how much of it is subsidized by manufacturers discounting their hardware just for the PR. IBM dumping out a supercomputer is like Bill Gates giving a couch to Goodwill. And IBM knows that fanboys on Slashdot will eat it up like free crack.

bottom line, indeed

[clacke]

If there's a real bottom line here, the one thing I'm clear on is that I haven't found it yet

Indeed. Lots of "I have no idea, but the feeling I get..." and "I don't know Linux, but...".

Can a Sparc multiprocess on one processor? No. Does it therefore "[defeat] the goal of true concurrency between threads"? No, and neither does x86.

And what's this BSD blabbering bit at the end?

the BSD people have had their technical focus fractured by more than a few explosive rebellions

You mean, like the forks? Is 4-5 forks "more than a few"? And have they really been that explosive? How is DragonFlyBSD "technical focus fractured" by the fact that Matt doesn't try to develop for 55 platforms simultaneously while revamping the entire VFS and the threads infrastructure?

you'll find essentially nothing in the [Darwin] kernel that's directly from either BSD 4.3 or SunOS 4

That's because they are old systems, and because Darwin relies on the Mach kernel for basic operations. If the BSD server has borrowed from anything, it's FreeBSD 4/5. But why am I even bothering? You haven't been in the kernel.

but the ancestral relationship is blindingly obvious to anyone who has used both.

The relationship you see is that Darwin userspace is basically FreeBSD 5 userspace. "Blindingly obvious" to anyone who has even briefly glanced at the lists the last year.

Oh great, guy.

[zak]

Call it VR4, so you sound cool and hip and absolutely clueless. Why not call Linux LX, while you're at it? And change the picture (or face), whichever comes easiest. You _do_ happen to look like you could use a thorough thrashing with a cluestick, you idiot.
Please stop discussing this troll of an article - it just encourages the asshats.

Simple

[Anonymous Coward]

Linux is to SVR4 as Windows XP is to Win2k (washing out my mouth with soap).

Seriously: SVR4 is a hog of clustered nostalgic accidental backward compatibility in several flavors, Linux is merely an implementation of all the relevant standards associated with that.

Who cares how good the loader is?

[Viol8]

If the OS is set up correctly all the loader needs to do is start it. I have the BIOS for doing everything else. I don't WANT a loader that does everything , its just extra rubbish that can go wrong. Why do I NEED to check devices in a loader for fscks sake? Its not like its going to use them! Let the OS do the work , thats why its called an "operating system".

Re:Who cares how good the loader is?

[_damnit_]

Because it's there when the OS is fubar. If you think a BIOS will do "everything else", you probably haven't used OBP or anything like it before. You NEED to check devices for many reasons. One of the best reasons is probe-scsi or probe-fcal. Wonder why you can't boot off your device? Check if your scsi/ata/fibre controller can even see it. Want to see if there is network activity on the interface you are trying to boot from? Easy. Do that on a BIOS. While some x86 servers come with a serviceable serial interface for their BIOS, they all have real limitations or proprietary interfaces which have a learning curve. OBP/OF and others are forth based and really standard in implementation. You can get on any Sun box and the OBP is going to be the same. An OS is great for all the things, but you need to get there first.

I couldn't read the article

[cjames53]

I tried to read the article, but the animated advertisements distracted me so much I simply had to quit.

Don't news web sites understand that the human brain can't cope with serious issues and animation at the same time? I include SlashDot in this category ...

Craig