How can an IDE RAID controller efficiently order reads and writes when it can't know the true drive layout?
At the very least, (AFAIK) both SCSI and IDE drives will remap bad sectors into unused (spare) space in a way that is invisible to the controller. Plus, there are more sectors per track as you go further out toward the edge of the platter. The geometry that is presented to the controller is synthetic and fake (it's been a long time since I've seen a drive with 16 heads).
Without an intimate knowledge of the drive geometry, how can reordering reads/writes be done efficiently?
While you have to pay for the media kit, you can load Solaris on as many machines as you want (as long as they are not SMP). Don't confuse the OS with the maintenance costs for an e10k.
While I have criticised Solaris before, one would be hard-pressed to find another UNIX98 compliant system for x86. Technically, Solaris wins on x86 in several areas.
It is generally understood that on Solaris UltraSparc, the 32-bit Oracle version will outperform the 64-bit version for databases that do not need large SGAs (shared memory/db cache).
There are LOTS of cases where a 32-bit app is better on a 64-bit cpu.
I have one on my 650 MHz Athlon (best PC in my house). It also has a floppy drive from the early 90s.
I also have a DEC Multia (UDB), Sparc IPX, Sparc 20, a couple of HP PA-RISC 7000 systems, and a bunch of old PCs (pentium 60, anyone?).
My home gateway is also a 486 - Compaq Contura Laptop, vintage 1992 or so. LCD disabled, only 27 Watts. I should unplug the floppy for less power consumption.
$ uname -a OpenBSD bart.rhadmin.org 3.3 GENERIC#44 i386 $ uptime 10:05AM up 31 days, 22:47, 1 user, load averages: 0.26, 0.17, 0.12 $ head -6/var/run/dmesg.boot OpenBSD 3.3 (GENERIC) #44: Sat Mar 29 13:22:05 MST 2003 deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/co mpile/GENERIC cpu0: Intel 486DX2 ("GenuineIntel" 486-class) cpu0: FPU,V86 real mem = 25800704 (25196K) avail mem = 18366464 (17936K)
Signals aren't part of the C standard, so you're right there.
Signals are part of standard C. Check your K&R second edition, or the discussion in Advanced Programming in the UNIX Environment by W. Richard Stevens.
stdio library is slow... That's nothing to do with C - it's a library. You could write it in assembler if you liked.
The library is part of the C language specification. If some vendor decided to remove stdio and replace it with sfio, their implementation would no longer be ANSI-C compliant. The design of the standard is no longer appropriate for modern systems - C was built for PDP-11s with severe memory limitations.
C can be readable in written in a stylistally pleasing way if you`re up to it.
In Python, you must make use of a uniform style. You will never have to hunt for a bracket in Python.
People will always want something fast and low level.
C is an unreasonable trade-off between safe practices and low level access. Eventually, it will be replaced.
Re:Imagine that you are an alcoholic...
on
The Next Path for Joy
·
· Score: 2, Insightful
Fortran is easier to optimize and vectorize than C, which is why it has a strong hold on scientific computing. Optimizers can assume a great deal about Fortran programs that cannot be assumed about C.
Cobol is still alive and well in many business-oriented computing environments. There are Cobol programmers working in the office down the hall from me. New systems implementations in Cobol continue today.
Imagine that you are an alcoholic...
on
The Next Path for Joy
·
· Score: 3, Interesting
...and that, after some real calamity in your life, you have decided to go cold turkey.
Now, where would you rather go cold turkey? Locked in a liquor store, or locked somewhere free of alcohol?
A C compiler is the liquor store of systems programming. It reinforces all the bad habits and rewards none of the good.
C has no formal definition for exceptions (signals can't really count), it does not force good behavior in allocating memory/objects from the heap, the stdio library is slow because of multiple buffer copies (David Korn replaced it with sfio in ksh93), C is constantly beaten by Fortran in computation-intensive applications, Python has shown that C sylistically leaves much to be desired, and this is only the beginning of the criticism.
I like C a lot too, but ultimately, there is no future in it beyond low-level applications that need to work at a near-assembler level.
Can you really imagine C being used for systems work in 50 years?
When I say "environment," I mean a utility with support for various, unrelated systems provided by various, unrelated entities under active development.
For practical purposes in this case, let's define an environment as:
GUI tools
Database tools
Network tools
Neither Sun Perl nor Sun CDE dtksh implement all of these points. They are closed; if you call them an environment, then you have to call them a stagnant environment - the additional features most likely will not be implemented in these tools by Sun (or anybody else).
Sun do ship archives as zip files, but then what is wrong with that?
If you are going to compress, you might as well compress effectively. bzip2 wins most contests here hands down, which is why it was implemented in RPM.
The few packages that I need, I get from Sunfreeware.com.
However, no matter how many packages that I install from sunfreeware, I will never have the functionality of the following python utilities included in redhat. It's a question of integration.
[root@prdcrm2l bin]# uname -a Linux prdcrm2l 2.4.20-19.7 #1 Tue Jul 15 13:44:14 EDT 2003 i686 unknown [root@prdcrm2l bin]# ls redhat* redhat-config-apache redhat-config-network-cmd redhat-config-services redhat-config-date redhat-config-network-druid redhat-config-time redhat-config-network redhat-config-printer-gui redhat-config-users
Solaris patches are very much based on ZIP. I may have been wrong about the Korn shell, however.
uname -a SunOS unknown 5.8 Generic_108529-07 i86pc i386 i86pc
# perl patchk.pl 108436 01 11 Shared library patch for C++ _x86
# ftp sunsolve.sun.com cd/pub/patches 250 CWD command successful. mget 108436* mget 108436-11.zip? y 221-Thank you for using the FTP service on sunsolve7.
# unzip -l 108436-11.zip Archive: 108436-11.zip Length Date Time Name 316468 06-04-03 16:02 108436-11/SUNWlibC/reloc/usr/lib/libC.so.5 26730 22 25 files
Dr. David Korn disagrees with you as to the number of shells in Solaris here (based on my previous questions) and also politely requests that you clean your act up.
As Sun is moving away from CDE, can I even count on dtksh to be included in future versions? This situation is absolutely ridiculous - tying important system software to the GUI environment. What are you thinking?
Does IBM put SMIT on a companion CD? Does HP put SAM on a companion CD? Does your motif management tool hold a candle to either of these? It's great that you've got a companion cd; now move some of it into the base install and start using it.
I will have to reboot into Solaris to examine your package/patch system again, so that will take a little time.
No, I'm not arguing that the Solaris kernel is quite technically advanced. It's the userland utilities that have been ignored for 10 years. Wake up, man!
Laugh all you like. Laughter does not profits make.
The truth is that nobody at Sun cares about userland Solaris, and all of us have to live with its shoddy and decrepit design. Perhaps you are a maintainer of this cruft? Get to work! Your 10 year coffee break is over!
This is a very simple situation: Sun is getting bulldozed by commodity parts. AMD is 15% of the commodity parts (processor) market. If Sun buys AMD, it will live.
This will be complex, because Sun has avoided PCs for a long time with good reason. But Sun can be a commodity parts supplier without being a commodity systems manufacturer.
Bringing together the Sparc and Opteron design teams could also breathe new ideas into both architectures.
If Sun owned AMD, Sun would have to tone down the anti-Microsoft rhetoric, which should have happened aeons ago anyway.
If Sun built Starcats or E15ks out of Opterons, Sun could theoretically scale Linux and Windows in addition to Solaris.
Sun could also introduce components into the Opteron family that would make scaling the chip difficult for competetors (by clever use of patents, etc.). Sun could cede the low end Opterons to Dell, but be the only player for the high end.
In any case, Sun needs to pick some commodity area of the market and invest heavily to survive. As Sun has a hardware focus, AMD seems to be the most reasonable choice.
Sun puts all its energy into the Solaris scalability features, and ignores some pretty basic things that make the operating system have the flavor of a Victrola.
Let's just run through a few of the problems:
There are three versions of the Korn shell./usr/bin/ksh is ksh88,/bin/sh is the "POSIX" shell (ksh88 with a few patches), and/usr/dt/bin/dtksh is Novell's ksh93 with Motif extensions. This should have been standardized on ksh93 a long time ago, and I can see why people love the unified Linux-Bash approach, even if Bash is much inferior to ksh93 in several respects. At least Linux improves occasionally.
Solaris still includes both awk and nawk, but not gawk. (HP-UX standardized on nawk and called it awk, at least slightly to their favor.)
Solaris introduced UFS journaling some time ago, but doesn't enable it by default. Why?
The Solaris package system is old old old, and based on pkzip.
Solaris does not include a scripting environment with GUI capabilities. RedHat's use of Python makes it look miles ahead.
The list goes on and on...
Sun has this attitude of "if it's not in the SVR4 codebase, then it doesn't go into the Solaris base install." This is just dumb. I realize that it is important to preserve compatibility for old shell scripts and utilities, and that Sun has taken some strides with Gnome and perl integration, but 95% of the new and interesting work in UNIX is taking place in the GPL and BSD spheres of influence, which Sun mostly ignores.
In many respects, Solaris has been at a standstill for the past 10 years.
Slashdot Mirror
How can an IDE RAID controller efficiently order reads and writes when it can't know the true drive layout?
At the very least, (AFAIK) both SCSI and IDE drives will remap bad sectors into unused (spare) space in a way that is invisible to the controller. Plus, there are more sectors per track as you go further out toward the edge of the platter. The geometry that is presented to the controller is synthetic and fake (it's been a long time since I've seen a drive with 16 heads).
Without an intimate knowledge of the drive geometry, how can reordering reads/writes be done efficiently?
Why would you pick it?
There are probably lots of other reasons. Solaris is by no means perfect, but it does have its strengths.
While you have to pay for the media kit, you can load Solaris on as many machines as you want (as long as they are not SMP). Don't confuse the OS with the maintenance costs for an e10k.
While I have criticised Solaris before, one would be hard-pressed to find another UNIX98 compliant system for x86. Technically, Solaris wins on x86 in several areas.
One user activation key for everything in the VMS suite.
You just need the media.
It is generally understood that on Solaris UltraSparc, the 32-bit Oracle version will outperform the 64-bit version for databases that do not need large SGAs (shared memory/db cache).
There are LOTS of cases where a 32-bit app is better on a 64-bit cpu.
Look, Objective-C will always be slower because of OO late binding issues.
Wouldn't it be much more fair to test the CPU and I/O systems with SPEC and TPC-C?
Oracle is available for OSX. I'd like to see some TPC scores for this platform.
I have one on my 650 MHz Athlon (best PC in my house). It also has a floppy drive from the early 90s.
I also have a DEC Multia (UDB), Sparc IPX, Sparc 20, a couple of HP PA-RISC 7000 systems, and a bunch of old PCs (pentium 60, anyone?).
My home gateway is also a 486 - Compaq Contura Laptop, vintage 1992 or so. LCD disabled, only 27 Watts. I should unplug the floppy for less power consumption.
I've said a couple of times before that the federal tax that we pay for landline and cellphones was originally a temporary measure in 1898 to finance the Spanish-American War.
VOIP is an opportunity to get out from under all of this stupid infrastructure. Even without 911 service, I am all for it.
These taxes were originally supposed to be temporary. It's high time that we got rid of them!
They have no place in the world of TCP/IP.
Signals are part of standard C. Check your K&R second edition, or the discussion in Advanced Programming in the UNIX Environment by W. Richard Stevens.
The library is part of the C language specification. If some vendor decided to remove stdio and replace it with sfio, their implementation would no longer be ANSI-C compliant. The design of the standard is no longer appropriate for modern systems - C was built for PDP-11s with severe memory limitations.
In Python, you must make use of a uniform style. You will never have to hunt for a bracket in Python.
C is an unreasonable trade-off between safe practices and low level access. Eventually, it will be replaced.
Fortran is easier to optimize and vectorize than C, which is why it has a strong hold on scientific computing. Optimizers can assume a great deal about Fortran programs that cannot be assumed about C.
Cobol is still alive and well in many business-oriented computing environments. There are Cobol programmers working in the office down the hall from me. New systems implementations in Cobol continue today.
...and that, after some real calamity in your life, you have decided to go cold turkey.
Now, where would you rather go cold turkey? Locked in a liquor store, or locked somewhere free of alcohol?
A C compiler is the liquor store of systems programming. It reinforces all the bad habits and rewards none of the good.
C has no formal definition for exceptions (signals can't really count), it does not force good behavior in allocating memory/objects from the heap, the stdio library is slow because of multiple buffer copies (David Korn replaced it with sfio in ksh93), C is constantly beaten by Fortran in computation-intensive applications, Python has shown that C sylistically leaves much to be desired, and this is only the beginning of the criticism.
I like C a lot too, but ultimately, there is no future in it beyond low-level applications that need to work at a near-assembler level.
Can you really imagine C being used for systems work in 50 years?
I thought somebody would try to catch me on that.
When I say "environment," I mean a utility with support for various, unrelated systems provided by various, unrelated entities under active development.
For practical purposes in this case, let's define an environment as:
Neither Sun Perl nor Sun CDE dtksh implement all of these points. They are closed; if you call them an environment, then you have to call them a stagnant environment - the additional features most likely will not be implemented in these tools by Sun (or anybody else).
If I use AIX I get SMIT.
If I use HP-UX I get SAM.
If I use Solaris I get...
Do you see the problem here?
p.s. Actually there is a motif-based Solaris app called "admintool," but it is really awful.
If you are going to compress, you might as well compress effectively. bzip2 wins most contests here hands down, which is why it was implemented in RPM.
The few packages that I need, I get from Sunfreeware.com.
However, no matter how many packages that I install from sunfreeware, I will never have the functionality of the following python utilities included in redhat. It's a question of integration.
Solaris patches are very much based on ZIP. I may have been wrong about the Korn shell, however.
Dr. David Korn disagrees with you as to the number of shells in Solaris here (based on my previous questions) and also politely requests that you clean your act up.
As Sun is moving away from CDE, can I even count on dtksh to be included in future versions? This situation is absolutely ridiculous - tying important system software to the GUI environment. What are you thinking?
Does IBM put SMIT on a companion CD? Does HP put SAM on a companion CD? Does your motif management tool hold a candle to either of these? It's great that you've got a companion cd; now move some of it into the base install and start using it.
I will have to reboot into Solaris to examine your package/patch system again, so that will take a little time.
No, I'm not arguing that the Solaris kernel is quite technically advanced. It's the userland utilities that have been ignored for 10 years. Wake up, man!
Laugh all you like. Laughter does not profits make.
The truth is that nobody at Sun cares about userland Solaris, and all of us have to live with its shoddy and decrepit design. Perhaps you are a maintainer of this cruft? Get to work! Your 10 year coffee break is over!
Yes. Did they fix my problems? No.
This is a very simple situation: Sun is getting bulldozed by commodity parts. AMD is 15% of the commodity parts (processor) market. If Sun buys AMD, it will live.
This will be complex, because Sun has avoided PCs for a long time with good reason. But Sun can be a commodity parts supplier without being a commodity systems manufacturer.
Bringing together the Sparc and Opteron design teams could also breathe new ideas into both architectures.
If Sun owned AMD, Sun would have to tone down the anti-Microsoft rhetoric, which should have happened aeons ago anyway.
If Sun built Starcats or E15ks out of Opterons, Sun could theoretically scale Linux and Windows in addition to Solaris.
Sun could also introduce components into the Opteron family that would make scaling the chip difficult for competetors (by clever use of patents, etc.). Sun could cede the low end Opterons to Dell, but be the only player for the high end.
In any case, Sun needs to pick some commodity area of the market and invest heavily to survive. As Sun has a hardware focus, AMD seems to be the most reasonable choice.
If I am reading Netcraft active sites properly.
Sun puts all its energy into the Solaris scalability features, and ignores some pretty basic things that make the operating system have the flavor of a Victrola.
Let's just run through a few of the problems:
Sun has this attitude of "if it's not in the SVR4 codebase, then it doesn't go into the Solaris base install." This is just dumb. I realize that it is important to preserve compatibility for old shell scripts and utilities, and that Sun has taken some strides with Gnome and perl integration, but 95% of the new and interesting work in UNIX is taking place in the GPL and BSD spheres of influence, which Sun mostly ignores.
In many respects, Solaris has been at a standstill for the past 10 years.
And they don't even like it, so let's not start assuming anything about our particular member of the Bourne family.
Besides, Bash is rather bloated and doesn't implement a few important features. Why can't we all just use ksh93? It is really better.
In any case, you have been bested, sir. :)