From: Peter Arremann loony@loonybin.org
*rofl* either you forgot how damned slow a E4500 is or you never worked with them... There is _nothing_ fast about them (see, I learned how to use the underscore from you, aren't you happy?)...
Dude, compared to modern UltraSPARC III/IV, _yes_ they _are_ slow. But there are a lot of UltraSPARC II options that are still quite viable solutions.
Oh - misquote to omit my acknowledgment of the inadequacy of my comparison. What was the reason for you leaving off where I said "compilers aren't a good benchmark"? :-) Are you that desperate to win an agrument that you have to misquote me to infer that I'm saying something else?
Dude, this is _not_ about "winning an argument."
It's about reminding you that "build times" are _not_ a good indictator of _server_ benchmark (please note that I said _server_).
I mean, if you want to see one benchmark that Intel has _always_ lost to AMD -- and handily -- build times are it. ;->
That's why I made the comment that you so nicely cut out :-) Performance tuning of provisioning apps is another thing I do :-) Working for a fortune 5 and dealing with the biggest systems that company has can be fun...
Dude, stop with the resume. The problem with pulling credentials is that someone else _always_ has more. Now stop while you _think_ you are "ahead." ;->
4TB databases, used by Java and C++ programs, 48way 96GB ram... that a better example or still too small for you to accept that I might not just do little things?
Once again, I will re-iterate, there are _other_ performance considerations than computational. And even then, "build" times are _not_ very representative of performance in even some computational
An Athlon64 3200+/4GB running on a 3ware controller with mirrored disks beats an 8way E4500/4GB running a 400GB oracle database... give the sun box 8GB and the performance is roughly equal...
Depends on if you are computationally limited, and also what is your I/O -- let alone the number of sessions you are serving. In raw, unthreaded, linear aspects -- hell yes, the E4500 is a _dog_.
Yes, and one of the limitations on the E4500 is throughput... A 3510 on a v490 does 61MB/sec - same lun, just connected into the SUNW,socal of a E4500 IO board does about 20MB/sec...
It all depends on how distributed your environment works, as well as the application.
I'm not saying an old UltraSPARC II platform is always going to be faster. But man, you are like a single track that thinks there are _no_ other considerations.
-- Bryan J. Smith mailto:b.j.smith@ieee.org
On Thursday 30 June 2005 17:52, Bryan J. Smith b.j.smith@ieee.org wrote:
From: Peter Arremann loony@loonybin.org
*rofl* either you forgot how damned slow a E4500 is or you never worked with them... There is _nothing_ fast about them (see, I learned how to use the underscore from you, aren't you happy?)...
Dude, compared to modern UltraSPARC III/IV, _yes_ they _are_ slow. But there are a lot of UltraSPARC II options that are still quite viable solutions.
Yeah - for a boat anchor or a door stop... Other than that, a US-II isn't worth the power it would take to run it... That's why you see so many of them on ebay now - cause no one wants it anymore :-)
Oh - misquote to omit my acknowledgment of the inadequacy of my comparison. What was the reason for you leaving off where I said "compilers aren't a good benchmark"? :-) Are you that desperate to win an agrument that you have to misquote me to infer that I'm saying something else?
Dude, this is _not_ about "winning an argument."
It's about reminding you that "build times" are _not_ a good indictator of _server_ benchmark (please note that I said _server_).
That is exactly what I said before you trimmed it off :-)
I mean, if you want to see one benchmark that Intel has _always_ lost to AMD -- and handily -- build times are it. ;->
But thanks for not acknowledging that you purposefully trimmed off a sentence that was essential for the statement I made.
That's why I made the comment that you so nicely cut out :-) Performance tuning of provisioning apps is another thing I do :-) Working for a fortune 5 and dealing with the biggest systems that company has can be fun...
Dude, stop with the resume. The problem with pulling credentials is that someone else _always_ has more. Now stop while you _think_ you are "ahead." ;->
Oh - but its ok if you do the same, right? :-)
4TB databases, used by Java and C++ programs, 48way 96GB ram... that a better example or still too small for you to accept that I might not just do little things?
Once again, I will re-iterate, there are _other_ performance considerations than computational. And even then, "build" times are _not_ very representative of performance in even some computational
I wasn't talking about builds - This is 100% transaction load. Very heavy on the DB.. (just so you know what I mean with heavy - so heavy that Informix had to produce a specific release just for us otherwise no commercial DB was able to handle the load at the time)...
An Athlon64 3200+/4GB running on a 3ware controller with mirrored disks beats an 8way E4500/4GB running a 400GB oracle database... give the sun box 8GB and the performance is roughly equal...
Depends on if you are computationally limited, and also what is your I/O -- let alone the number of sessions you are serving. In raw, unthreaded, linear aspects -- hell yes, the E4500 is a _dog_.
Yep - and for threaded apps its hmmm... a _dog_ :-) 14 CPU E4500 is 67103 TPC-C ... a 16CPU p5 570 is 809144... But I guess that doesn't count either for you :-)
Point being a E4500 for todays standards is slow no matter what you use it for.
Yes, and one of the limitations on the E4500 is throughput... A 3510 on a v490 does 61MB/sec - same lun, just connected into the SUNW,socal of a E4500 IO board does about 20MB/sec...
It all depends on how distributed your environment works, as well as the application.
I'm not saying an old UltraSPARC II platform is always going to be faster. But man, you are like a single track that thinks there are _no_ other considerations.
???? What does a distributed app have to do with an inheret IO limit of the hardware????
Peter.
On Thursday 30 June 2005 19:14, Peter Arremann wrote:
On Thursday 30 June 2005 17:52, Bryan J. Smith b.j.smith@ieee.org wrote:
Dude, compared to modern UltraSPARC III/IV, _yes_ they _are_ slow. But there are a lot of UltraSPARC II options that are still quite viable solutions.
Yeah - for a boat anchor or a door stop... Other than that, a US-II isn't worth the power it would take to run it... That's why you see so many of them on ebay now - cause no one wants it anymore :-)
I'll differ on this.
We at PARI are currently running two live servers that are UltraSPARC II-based, in particular, Ultra30's. The specs: USIIi 248MHz, 384MB RAM, 2x4.2GB UW SCSI drives). Is it a barnburner? No. Its performance beats a 400MHz Pentium II with IDE two to one, though, running the same apps I am using the Ultra30's for. Very usable machines. More usable than the quad AlphaServer 2100 I have, that's for sure (the AS2100 we have is configured with four 275MHz EV45's and a GB of RAM with the DAC960 hardware RAID controller, and burns 800+ watts). Although proper setup and optimization might make the AS2100 worthwhile, particularly since I can run CentOS on it! Still, it takes 800 watts!
My U30's are doing antivirus, antispam, webmail, and regular e-mail services, running Aurora Linux 1.92 (Fedora Core 2, basically, for SPARC). The machines are responsive, fairly low load average running, and moderate e-mail volume being processed. Profiling them, the MailScanner activities use the most CPU.
The hardware is more reliable than comparable Intel hardware would be (comparable, again, being a PII 400+ with 256-384MB RAM, an Adaptec 2940UW, and 8GB Seagate UW drives: I know this because I have benchmarked another of our servers here that is a dual 400MHz PII with those drives and came up with comparable numbers (using UnixBench 4.1, which benchmarks quite a few areas)). Those U30s are built like tanks; they also take approximately the same amount of power as the dual 400 does; about 100 watts.
Now, if you're going to compare the E4500 to Intel hardware, you need to look at high-end Proliants and PowerEdges of that time period, not modern Dell PowerEdges. Hmmm, there weren't any comparable Intel servers in that time period (with the exception of Sequent's Dynix stuff that ran dozens of 66Hz 486's and cost a mint).
And when you (we) are donated 30 Ultra 30 workstations, you (we) use them.
On Saturday 02 July 2005 12:29, Lamar Owen wrote:
time period (with the exception of Sequent's Dynix stuff that ran dozens of 66Hz 486's and cost a mint).
Those 486's just seemed that slow.... in reality they ran at 66MHz.
Lamar Owen wrote:
Now, if you're going to compare the E4500 to Intel hardware, you need to look at high-end Proliants and PowerEdges of that time period, not modern Dell PowerEdges. Hmmm, there weren't any comparable Intel servers in that time period (with the exception of Sequent's Dynix stuff that ran dozens of 66Hz 486's and cost a mint).
Actually E4500's are not bad machines. Yes, they are slow compared to PeeCee's/servers these days, but they are still darn reliable. I had a couple of E4500's with 8x400 Mhz US-II ( 8 MB Cache), 8 GB RAM connected to a A5100. They ran reliably and flawlessly (except for replacing the battery on A5100). They have a lot of resilience to load. We've had load averages of up to 300-350 on the machine and it didn't break a sweat. I've had many other machine crumble to this heavy load.
Now only if they were more energy friendly!
Warm Regards,
-Bruno
On Saturday 02 July 2005 12:46, Bruno Delbono wrote:
Actually E4500's are not bad machines. Yes, they are slow compared to PeeCee's/servers these days, but they are still darn reliable. I had a couple of E4500's with 8x400 Mhz US-II ( 8 MB Cache), 8 GB RAM connected to a A5100. They ran reliably and flawlessly (except for replacing the battery on A5100). They have a lot of resilience to load. We've had load averages of up to 300-350 on the machine and it didn't break a sweat. I've had many other machine crumble to this heavy load.
Then you're luckier than us... About 40% of our E4500s had centerplane or clockboard errors over the last year... :-( the system and io boards seem to be fine but the clock boards definitely don't age gracefully... But if you have working hardware, yep - they surely are stable...
Now only if they were more energy friendly!
:-)
Peter.
On Sat, 2005-07-02 at 12:29 -0400, Lamar Owen wrote:
The specs: USIIi 248MHz, 384MB RAM, 2x4.2GB UW SCSI drives).
And it should be noted these are II"i" processors/interconnects. Not nearly as capable in the interconnect-I/O as a true II (let alone III/IV).
Now, if you're going to compare the E4500 to Intel hardware, you need to look at high-end Proliants and PowerEdges of that time period, not modern Dell PowerEdges. Hmmm, there weren't any comparable Intel servers in that time period (with the exception of Sequent's Dynix stuff that ran dozens of 66Hz 486's and cost a mint). And when you (we) are donated 30 Ultra 30 workstations, you (we) use them.
I still take in 4+ way UltraSPARC II systems when I'm at companies. They are many tasks where their distributed interconnects are very useful.
On Saturday 02 July 2005 13:16, Bryan J. Smith wrote:
I still take in 4+ way UltraSPARC II systems when I'm at companies. They are many tasks where their distributed interconnects are very useful.
And discussing them would be more on-topic if there were a CentOS/SPARC64, which would be nice to no end.
On Sat, 2005-07-02 at 15:22 -0400, Lamar Owen wrote:
And discussing them would be more on-topic if there were a CentOS/SPARC64, which would be nice to no end.
Agreed. But at the same time, there is something to be said for Solaris. While Solaris (especially GNU/Solaris) might be partially on- topic for a Linux list, you are correct, it's not for this CentOS list.
It's funny where we've gone since Bruno's post, and the couple of back'n forths after that before I (let alone yourself) entered.
On Sat, 2 Jul 2005, Bryan J. Smith wrote:
On Sat, 2005-07-02 at 15:22 -0400, Lamar Owen wrote:
And discussing them would be more on-topic if there were a CentOS/SPARC64, which would be nice to no end.
It's funny where we've gone since Bruno's post, and the couple of back'n forths after that before I (let alone yourself) entered.
Yes, and it would be nice if we can keep the off-topic stuff off the list.
Even though it contains a lot of information someone might find useful, most of the people on the list consider it noise and it brings down the signal-to-noise ratio of the list.
It happened now 3 or 4 times that we got an overly long off-topic discussion (flamewar even) which most of the subscribers are really not interested in. (I hope I can speak for most here anyway)
Keep it CentOS related please, as soon as you have a non-CentOS related argument or monologue, keep it off-list.
PS This is a general statement, not targetting Bryan specifically here.
Thanks, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Sat, 2005-07-02 at 14:35 -0500, Bryan J. Smith wrote:
On Sat, 2005-07-02 at 15:22 -0400, Lamar Owen wrote:
And discussing them would be more on-topic if there were a CentOS/SPARC64, which would be nice to no end.
Believe it or not ... there is a plan for a future SPARC distro for CentOS. It is only in the planning stages now :)
There is already an beta 4.1 release for the ALPHA processor.
Johnny Hughes wrote:
On Sat, 2005-07-02 at 14:35 -0500, Bryan J. Smith wrote:
On Sat, 2005-07-02 at 15:22 -0400, Lamar Owen wrote:
And discussing them would be more on-topic if there were a CentOS/SPARC64, which would be nice to no end.
Believe it or not ... there is a plan for a future SPARC distro for CentOS. It is only in the planning stages now :)
There is already an beta 4.1 release for the ALPHA processor.
Why? Are there THAT many of these boxes laying around to overcome the PITA factor of generating a new release?
Just curious. S390 CentOS coming soon too? :-P
Cheers,
C
On Sun, 2005-07-03 at 07:25 -0400, Chris Mauritz wrote:
Johnny Hughes wrote:
On Sat, 2005-07-02 at 14:35 -0500, Bryan J. Smith wrote:
On Sat, 2005-07-02 at 15:22 -0400, Lamar Owen wrote:
And discussing them would be more on-topic if there were a CentOS/SPARC64, which would be nice to no end.
Believe it or not ... there is a plan for a future SPARC distro for CentOS. It is only in the planning stages now :)
There is already an beta 4.1 release for the ALPHA processor.
Why? Are there THAT many of these boxes laying around to overcome the PITA factor of generating a new release?
There are many sparc boxes in the world (and alpha too). CentOS is dedicated to being the best Enterprise Distro out there.
We are not satisfied just to be the best rebuild of upstream software for i386 and x86_64, and to provide rapid updates to those products ... Though CentOS does that better than anyone else offering it for free (in my opinion).
Since we are not about making money, we will try to provide CentOS for platforms that the upstream provider might not care to provide, being that people might not pay $2500/server for it on that platform.
Just curious. S390 CentOS coming soon too? :-P
Cheers,
C
s390 for CentOS-4.1beta is building right now :) (thanks Pasi)
there is already an s390 and s390x for CentOS-3.
Hi,
On Sun, Jul 03, 2005 at 07:25:40AM -0400, Chris Mauritz wrote:
Johnny Hughes wrote:
Believe it or not ... there is a plan for a future SPARC distro for CentOS. It is only in the planning stages now :)
There is already an beta 4.1 release for the ALPHA processor.
Why? Are there THAT many of these boxes laying around to overcome the PITA factor of generating a new release?
If i say few words about this, while i am the guy who pushed the CentOS-4.1/alpha out to public.
Making 1:1 (more or like) distros from source base doesn't get one excited quite long. Actually it's not that challenging at all. One must find something more challenging to work with and these 'out of mainstream releases' are by product of that. So it's just hobby challeging the dev team IMO more like 'the world really, really, really needs this'
If you look the torrent tracker stats, there would be only ia32 release, if it would only judged by the downloads/arch. Maybe x86-64 too, but rest are really something minority on quantity.
I'd actually have the 32bit part of the sparc64 already build and fixed. No anaconda, no kernel etc. and the 64bit needed parts were stuck on producing 64bit xorg build for gcc proper build last time i worked with that. For my side, it's pretty much freezed ATM, but no promises to any direction.
Just curious. S390 CentOS coming soon too? :-P
Actually it is. I'd say s390 is less than week as it's now on final build round on real iron. s390x is soemthing built under hercules and there are some floating point problems (more like features than BUGs) which prevest some package test to get right results. I am not so confident on that side as i do have to just blindly trust gcc soinf it job right while the pre-defined test on package advices that the package was not built right. It's just few packages and we have talked/tested this with the hercules developers, so i am quite confident the s390x being allright even tho it's saying other.
The problems there is that the accuracy of FP-units are different. The floating point is calcultaed natively on hosts FP-unit and the rounding after some 6-8 digits aren't alwways what youd' expect (or something. I am not good on this). Emulating the floating point isn't much option either as it would be maybe two magnitudes penalty and the emulation is emulation already :)
For s390 i was fortunate anought to get real iron LPAR for building like week ago.
Chris Mauritz wrote:
Johnny Hughes wrote:
On Sat, 2005-07-02 at 14:35 -0500, Bryan J. Smith wrote:
On Sat, 2005-07-02 at 15:22 -0400, Lamar Owen wrote:
And discussing them would be more on-topic if there were a CentOS/SPARC64, which would be nice to no end.
Believe it or not ... there is a plan for a future SPARC distro for CentOS. It is only in the planning stages now :)
There is already an beta 4.1 release for the ALPHA processor.
Why? Are there THAT many of these boxes laying around to overcome the PITA factor of generating a new release?
Er... I have an E150 in my basement. One of the two power supplies died couple of months ago, so it is collecting dust right now. I was playing with Aurora (rebuild of Fedora Core for sparc64), Debian and OpenBSD while it was still in usable condition. If it was still working, I'd give CentOS a try as soon as it was released ;-)
Aleksandar Milivojevic wrote:
Why? Are there THAT many of these boxes laying around to overcome the PITA factor of generating a new release?
Er... I have an E150 in my basement. One of the two power supplies died couple of months ago, so it is collecting dust right now. I was playing with Aurora (rebuild of Fedora Core for sparc64), Debian and OpenBSD while it was still in usable condition. If it was still working, I'd give CentOS a try as soon as it was released ;-) _______________________________________________
I have a pair of ultra 5's that are currently being used as bookends in my office. I don't think either of them has been powered on in 3-4 years. They do a great job of keeping the books straight. 8-) I had some E250 and E450 machines that I believe got donated to a local school a while back. I'm not sure if they continued to run Slowlaris on them or if they installed some incarnation of Linux. I figure any remotely modern laptop could probably compute rings around any of these boxes with much lower power usage, cooling and space requirements.
Now when CentOS runs on a PDP-11, that might be worth a trip to the attic to see if THAT still runs. 8-)
Cheers,
C
Chris Mauritz wrote:
I have a pair of ultra 5's that are currently being used as bookends in my office. I don't think either of them has been powered on in 3-4 years. They do a great job of keeping the books straight. 8-)
Well, you know, not every application requires processors in 2 or 3 GHz range. I used to run my basement mail server (just couple of accounts) on 200MHz Pentium MMX until recently (upgraded to 500 MHz Celeron). Sendmail and Cyrus IMAP. And it was running resonable. Currently I'm using it as a dedicated firewall box in my home setup. The before mentioned E150 (wich is first generation of Sun's UltraSparc workstations/servers, U5 is the second) was happily running squid proxy server (moved to that 500 MHz box, but only because E150 hardware failed, and even if I had new power supply for the thing, replacing it would be almost one-day job, terribly designed case, and my house seems plesently quiet after that anyhow).
So, there's still some usage for those old boxes (other than bookends).
On Mon, 2005-07-04 at 07:43 -0400, Chris Mauritz wrote:
I'm not sure if they continued to run Slowlaris on them or if they installed some incarnation of Linux.
Could we stop this bigotry?
Until someone can demonstrate Linux runs on 2 or even 4-way systems as good as Solaris, I would rather not hear this chest pounding junk.
I figure any remotely modern laptop could probably compute rings around any of these boxes with much lower power usage, cooling and space requirements.
Ummm, I would actually very much _differ_ with that for many applications. Most notebook processors have very limited interconnects and greatly reduced performance for power, as well as slower memory, disk, etc..., typically resulting in only 1/2 - 1/3rd the nominal power of a desktop (especially when on battery and a P4 or an older Athlon slows to under 1GHz).
Bryan J. Smith wrote:
On Mon, 2005-07-04 at 07:43 -0400, Chris Mauritz wrote:
I'm not sure if they continued to run Slowlaris on them or if they installed some incarnation of Linux.
Could we stop this bigotry?
Until someone can demonstrate Linux runs on 2 or even 4-way systems as good as Solaris, I would rather not hear this chest pounding junk.
Heh. This 'slowlaris' has nothing to do with what kernel you are running. It's the blinking libraries/programs that come with Slowlaris 8. They are so bad that you will find an instant demonstration with the Slowlaris find and GNU find program. The first takes hours even days whereas the second will take a few minutes or even less than a minute. Same hardware, same box running Slowlaris 8. I heard Solaris 10 was much better but I have not had the chance to verify that.
On Tue, 2005-07-05 at 08:16 +0800, Feizhou wrote:
Heh. This 'slowlaris' ...
Please stop.
I'm caught between either taking the time to correct bigots like yourself, and not bothering the list with even responding to this non- sense.
Bryan J. Smith wrote:
On Tue, 2005-07-05 at 08:16 +0800, Feizhou wrote:
Heh. This 'slowlaris' ...
Please stop.
I'm caught between either taking the time to correct bigots like yourself, and not bothering the list with even responding to this non- sense.
Perhaps you can show me how to make Solaris 8 find run as fast as the GNU find or explain the very large difference in performance of these?
I used to have a qmail queue on a Solaris 8 box. qmail-qstat, which is basically a script that calls find and then pipes the output to awk, took ages to run whenever the queue is stuff by crap. Installing GNU find and changing the script to use that made it possible to finally get the number of mails in the queue.
Before I was informed of the speed difference between using the dumb Solaris provided find and the GNU find, my impression of a Sun box + Solaris 8 was: 'this sucks, it is SO VERY SLOW'.
Feizhou wrote:
Bryan J. Smith wrote:
On Tue, 2005-07-05 at 08:16 +0800, Feizhou wrote:
Heh. This 'slowlaris' ...
Please stop.
I'm caught between either taking the time to correct bigots like yourself, and not bothering the list with even responding to this non- sense.
Perhaps you can show me how to make Solaris 8 find run as fast as the GNU find or explain the very large difference in performance of these?
Please take this conversation offlist, there are other forums where such issues might be better discussed.
On Tue, 2005-07-05 at 02:23 +0100, Karanbir Singh wrote:
Please take this conversation offlist, there are other forums where such issues might be better discussed.
I have no idea why people continue to insist this is an advocacy list. It's one thing to be off-topic, but I tire of the non-sense that is stirred up from 1 post by one innocent by-stander.
I'm sorry I even tried to correct some things. I really am.
Bryan J. Smith wrote:
On Tue, 2005-07-05 at 02:23 +0100, Karanbir Singh wrote:
Please take this conversation offlist, there are other forums where such issues might be better discussed.
I have no idea why people continue to insist this is an advocacy list. It's one thing to be off-topic, but I tire of the non-sense that is stirred up from 1 post by one innocent by-stander.
Some people just don't want to compare I guess. They may have the mindset of I am going to use CentOS no matter what and somehow don't like anything that is not related to CentOS...
I'm sorry I even tried to correct some things. I really am.
Say, can you send me mail in private about the Solaris/Slowlaris issue?
I really want to know what about the comparison between Solaris' find and the GNU find that makes you think it is non-sense.
On Tue, 2005-07-05 at 15:11 +0800, Feizhou wrote:
Say, can you send me mail in private about the Solaris/Slowlaris issue? I really want to know what about the comparison between Solaris' find and the GNU find that makes you think it is non-sense.
Say, can you stop being argumentative? ;->
If you want to nitpick on little things in Solaris (which I seriously disbelieve that find is sevral orders of magnitude in performance difference, more like a specific run-time bug), we can do the same as Linux. So let's _not_ go there, okay? ;->
Again, this is _not_ an advocacy list AFAIAC, but I leave it to the CentOS maintainers, who have the ultimate say on that.
Quoting Johnny Hughes mailing-lists@hughesjr.com:
On Sat, 2005-07-02 at 14:35 -0500, Bryan J. Smith wrote:
On Sat, 2005-07-02 at 15:22 -0400, Lamar Owen wrote:
And discussing them would be more on-topic if there were a CentOS/SPARC64, which would be nice to no end.
Believe it or not ... there is a plan for a future SPARC distro for CentOS. It is only in the planning stages now :)
And that would be very nice to have. Currently, I'm aware of only two "working" sparc64 distros:
Debian. It works and installs more or less nicely. There are some gotchas to get it installed (if one wants 2.6 kernels and more recent versions of packages), so not really for total beginers.
Aurora. Rebuild of Fedora Core. It is lagging in release cycles behind Fedora. I believe currently they are still at FC2 stage, no installer for current version. One needs to install version 1.0 (rebuild of Red Hat 7.3) and than use yum to upgrade to 1.92 (rebuild of FC2).
With both of them I remember having trouble setting up mirroring + LVM at install time, and both of them had some odd trouble with disc geometry and partitioning (with my SCSI controller and discs), and my hme ethernet card would freeze occasionally. And I vaugly remember having some issues with Native Posix Thread Library, but couldn't remember which one was it and/or what it was about (at about the same time I was experimenting with OpenBSD on that box, got mirroring running, hme was working flawlessly, so I left it that way until the power supply in box died). So you might want to watch about those.
My guess is that you'll be doing only sparc64 distribution, and not sparc32? I remember reading somewhere that 2.6 kernel was not fully ported to sparc32 (and it was uncertain if it will be ever fully ported), but that might be old news. So I guess it will be combination of 64-bit kernel and mixed 32/64-bit userland?
While we are at that, is AXP port fully 64-bit (like OpenVMS and/or Digital UNIX), or you use 32/64-bit mix model (as most other 64-bit operating systems on most other 64-bit processors)?
I hope you'll be able to get Anaconda installer working with full set of configuration options as in x86 version (this is the single main show killer for Aurora and/or all other ports of Linux distributions to non-Intel architectures).
P.S. For Richey. Linux kernel doesn't run on PDP-11, but there is a port for VAX. Only 2.4 kernel currently, don't know if any work was done on 2.6 kernel, limited hardware support, legendary VAX 11/780 (1 VAX MIPS is the speed of that machine, and when people quote "MIPS" numbers, they usually mean VAX MIPS even nowdays) not supported unfortunately. That is the closest "to the Unix origins" that Linux ever got ;-)
So my guess is that it might be possible to port CentOS 3 to VAX. Not that I know of anybody who would reinstall their VAX to try it out. The rare sites that still have them (for running legacy apps tied to the VAX) mostly run VMS, Ultrix or some flavour of BSD on them and don't touch 'em. And as soon as legacy applications are replaced, it usually means the end of the life for VAX on that site. The AXP port is something that might interest many more people in next few years to come (and maybe even after that, if miracle happens and somebody starts some serious development on that line of processors again).
BTW, while we are still at usability of old hardware, I know for sure (I visited the site and saw them personally) that a redundant pair of PDP-11 machines was controlling the electricity distribution system of one mid-sized European country as far as late 90's, maybe even into the 2000's (and they never had blackouts like you guys down in US get occasionally). Not sure if they replaced them in more recent years. That would be classic example of legacy applications where you would would find such old systems still used. Not much processing power required, but system must be rock-solid stable and reliable. Of course, to be fair, down in US you have couple of big cities with population (city and its metropolitan area) in the order of average mid-sized European country ;-)
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Hi,
On Mon, Jul 04, 2005 at 10:02:04AM -0500, alex@milivojevic.org wrote:
My guess is that you'll be doing only sparc64 distribution, and not sparc32? I remember reading somewhere that 2.6 kernel was not fully ported to sparc32 (and it was uncertain if it will be ever fully ported), but that might be old news. So I guess it will be combination of 64-bit kernel and mixed 32/64-bit userland?
I don't know if anything ever comes out to public, but most propably it would be more like the current ppc64, where the userspace is mostly 32bit and the 64bit parts are from 'what is needed'. I hate summer. Even now the temperatures are high enought that i can't even dream of keeping any sparc hardware running for ón/off efforts make it progress while i do have spare minutes :/
While we are at that, is AXP port fully 64-bit (like OpenVMS and/or Digital UNIX), or you use 32/64-bit mix model (as most other 64-bit operating systems on most other 64-bit processors)?
As long a i have worked with alpha, the Linux for it has always been 'native 64bit only'. I've read that alpha would be capable of running 32bit apps too and even that the initial (non public) port of Linux to alha at DEC labs (or something) has been 32bit. While i was working with the debian installer for alpha (back -97. Google should tell :), the system was fully 64bit back then too. Now the so called CentOS-4.1beta/alpha is 64bit too.
-
Aleksandar Milivojevic -
alex＠milivojevic.org
-
Bruno Delbono -
Bryan J. Smith -
Bryan J. Smith <b.j.smith＠ieee.org> -
Chris Mauritz -
Dag Wieers -
Feizhou -
Johnny Hughes -
Karanbir Singh -
Lamar Owen -
Pasi Pirhonen -
Peter Arremann