...lets have triplictate monkeys for all our data, in case one dies, or runs away, or simply forgets...
Authough they have a much larger footprint than monkeys, I'm told Elephants have better data retention characteristics and the peanut has a much smaller form factor than the banana.
...you need engineers, factory workers, politicians, even telemarketers...
Don't forget the telephone sanitisers, hairdressers and management consultants - in fact lets put them in the same ark as the politicians and telemarketers...
...Yea, we can all pretend to hate Microsoft, but the PPC stuff is just fabulous...
Have you actually used PocketPC 2002? It's dreadful.
I was stuck with it on my Ipaq 3850 for about 4 months, while I waited for Compaq Research Labs to tweak Familiar linux support for this model. During that time I learned to hate PocketPC. It's unstable, slow, buggy and bloated when compared to Familiar.
Meanwhile I'll be a hypothetical man in a black hat at another table. I'll be watching you through two holes cut in a newspaper. When You've finished and switched off your PDA/notebook/whatever, I'll assume the MAC address which my PDA recorded you were using and start to upload illegal things through your DSL line. If you are using WEP, it'll take a hundred meg or so of your data to be transfered before I've got your key.
Don't rely on MAC address filtering or WEP, this stuff was poorly thought out to start with. Use IPSec or SSH tunnels if you can, or failing that firewall off your access point from the rest of your apartment network and treat it like any other public network - insecure.
Not strictly true. It ran under a DOS32 extender (I seem to remember they used Watcom's DOS4GW). I'm pretty sure this provided a thread library (it's been a while, etc. etc.)
I'm reminded of that Farside cartoon - the one where a band is recording in a studio and the technician is reaching for the 'Suck' control on the mixing desk.
I've heard of a major British ferry operating company who doesn't mess about with halon in their datacentre. They simply cut the power then drench the kit in water - evidently they can stand the amount of downtime required to dry it out again:)
The evidence is becoming very persuasive that immunizations do bear a large portion of the blame...
There may be commonality between the vaccination figures and autism figures. That does not mean that the one causes the other.
(Commence the flamebait about how we're playing with fire, yadda yadda yadda...)
To be successful a vaccination programme needs to include over 95% of the population in order to achieve 'herd immunity'. Less than 95% and you run the risk of an epidemic. Remember, the ultimate aim is to erradicate the virus. Deciding not to vaccinate your children based on the unsubstantiated causality between vaccination and autism is selfish and irresponsible.
You're quite right, but they won't learn, you know.
The very next Lego related story will contain the word 'Legos' - just to annoy you and I. Then again, I stopped caring about Lego at about the age of 13, when I noticed that I fancied girls...
Generating 64bit code from a compiler will often run slower than equivalent 32bit code. For example; all of the binaries in/usr/bin on Solaris9 are 32bit, both for backwards compatibility and for performance - there are nearly 600 files. There are separate sparcv7 (32bit) and sparcv9 (64bit) binaries for only very few commands. Of these, some are 64bit so that they understand the 64bit kernel structures (adb, mdb, truss, the 'p' commands (pmap, pcred, pstack etc.) and there's sort. sort is the only command compiled to 64bit for performance. It's the only command deemed likely to encounter a large enough dataset to benefit from being 64bit.
EVERY situation I've seen a large Sun used it could have been handled with Linux
You need to get out more.
I've worked on several large scale Sun projects within the finance industry - Each with more than 1 million pounds worth of hardware. In each case the choice of the hardware was influenced by the following factors:
1. Which platforms does the application run on - (You'd be surprised how often the answer is - SPARC/Solaris only - less so these days, but many small finance ISV's still only support SPARC/Solaris)
2. Which database platform is required. (More often than not it's Sybase, sometimes Oracle, hardly ever anything else - DB2 rarely) Sybase will normally recommend SPARC/Solaris as it's their development platform. Likewise Oracle - authough they tend to be a little more platform agnostic.
3. How much downtime is acceptable - or put another way how much will downtime cost the business in real terms. For a major commercial bank, loosing their general ledger for example, will not only make it impossible to settle but they could be closed down by the finacial regulators. For an exchange, if they loose the ability to process trades and have to suspend the market, they will loose money directly (their profit on each trade) and may also have to pay customers compensation for their loss of earnings.
4. What availability figures will a particular vendor be willing to gaurantee (technically and financially). All large hardware vendors are very conservative on this - all vendors have product reliability issues from time to time - many customers refuse to admit responsibility for their mistakes (patch management, environmental issues). Going to court is expensive for all concerned, so vendors normally try to placate an angry customer with a better discount or by free hardware. Customers in turn appeciate the relationship and continue to place large orders. Many vendors are only willing to gaurantee very high (more than 5 nines) availability figures on their highest end server and disk products.
5. Large systems are likely to be more reliable than small systems from the same stable. Fact. The systems vendor has spent more money in R&D to make it so. They typically have more redundant/better quality components, dynamic partitioning capabilities (seldom used dynamically, of course) better systems management capabilities, more data replication options. Most importantly, larger systems are administered better, during the implementation phase the sys admins are trained, their systems runbook is developed, patch management and backup strategies are developed and the systems are tested properly. Human error (or process) is almost always to blame when large systems incur significant downtime.
6. How credible is the vendor? What platform is your major competitor using? If a particular vendor (systems and software) it's likely to be for a good reason - they understand the market, have strong relationships with ISV's, produce strong products and have decent service people to fix things when they go wrong.
7. The principle of locality of data. Many (not all) finance systems will benefit from keeping data in memory. High end 64 bit chips have large (8 or more Megabyte) E-caches. High end SMP 64 bit machines can address hundreds of Gigabytes of memory with (mostly) uniform performance and good reliability. Data is more likely to be in memory when it's needed, therefore you can process more trades per second, run risk analysis faster and generally make money faster.
Finance is a risk averse industry, in order to maintain transactional integrity, with robust reliability, with decent disaster recovery and finally good performance. They are willing to spend the money on (and often require) high end 64 bitness. In fact the cost of the hardware often pales into insignificance in comparison to software costs, running a datacentre, employing decent architecture design, systems admin and programming people, not to mention hardware support contracts, leasing DR fibre pairs, etc. etc.
As a reseller you are a middleman, Sun spends the billions on research and development, you reap a large share of the rewards when times are good. During the inflation of the dot-com bubble you helped Sun to keep headcount and warehouse space to a minimum - and your price was a generous discount on Sun hardware and software. Now you are a waste of space. I know of 2 decent Sun resellers in my old vertical market (both of which covered many other markets as well) they provided a tangible value-add - both in terms of technical pre-sales skills, benchmarking facilities and post sales consultancy services. I'm sure they're feeling the pinch at the moment, but I think their customers will return.
If I were running the partner programme at Sun, I would certainly want to weed out the underperforming resellers, especially those who complain about mandatory training sessions. You are a cost of sale and even during the good times your performance was often embarrasing. It's all about value-add, if you're not adding anything other than a customer base for Sun, prepare for those customers to cut out out of the loop and deal direct with Sun.
Not exactly a solution to your problem, but you might consider AutoFS. I got fed up with having multiple pools of storage at home and no sensible way to back data up over many machines. All my machines are NIS clients to my Qube which is the NIS master. Any machine which exports a filesystem via NFS gets given a NIS entry in auto_master/auto_direct (Solaris/Linux). Everything is available, in my case via/han.
/han/mp3 /han/code /han/divx /han/pr0n etc. etc.
The nice thing is, you never have to su to root in order to mount anything - you just cd into the directory (on any machine) and it gets mounted in the background. You still get UNIX file semantics and permissions, the normal NIS & NFS behaviour.
On the machine with the DDS3 drive. I just kick of a script which traverses the NIS map and catches all the directories which I deem worth backing up. Works a charm, but really only on UNIX, which suits me. There are windows clients for much of this stuff (reflection, Solstice network client if you can still find it) but they're mostly crap.
That issue has largely gone away with mirrored SRAM modules. Every major systems manufacturer has product issues from time to time. For Sun it has recently been ecache, GBICs and the odd 420R power supply. Yes, they should have been more pro-active and open about the problems, but once they were discovered Sun's service organistation takes over and manages the problem to resolution. Sun Enterprise services are generally excellent at what they do.
As for N1, I shouldn't worry too much. This whole story smells like a marketing pipedream. Anyone remember being given the 'top secret' genesis briefings, later rebranded as Datacenter.com? The technology they talked about was 'almost like' what Sun could with SunCluster 3.0/E10K dynamic domains (if they were supported together at the time) and some imaginary highspeed interconnect, hooked together in some configuration which would almost certainly never be supported.
I expect their next step will be to rebrand all their software products as 'N1' compliant, knock together some laughable management console which only works marginally well with bits of it and move on to the next amateur marketing stunt. That's what normally happens (cynical, me?).
...calling it the World Series sounds a little arrogant, perhaps, but it remains called that because of tradition...
Nothing wrong with tradition. I'm told (by a genuine American no less) that the first World Series was so named because it was originally sponsored by a newspaper called the 'World News' or some such name.
Being an Anglophile Xenophobe, my maxim has always been 'If it annoys foreigners, keep doing it'. Well done America.
...lets have triplictate monkeys for all our data, in case one dies, or runs away, or simply forgets...
Authough they have a much larger footprint than monkeys, I'm told Elephants have better data retention characteristics and the peanut has a much smaller form factor than the banana.
Of the 'real' companies, I'm afraid the small will die first.
Redhat (possibly et. al.) have the best chance of success in the business world because the have:
a) Industry credibility
b) A half decent support organisation
No serious business customer is going to invest any money without those...
...you need engineers, factory workers, politicians, even telemarketers...
Don't forget the telephone sanitisers, hairdressers and management consultants - in fact lets put them in the same ark as the politicians and telemarketers...
...Yea, we can all pretend to hate Microsoft, but the PPC stuff is just fabulous...
Have you actually used PocketPC 2002? It's dreadful.
I was stuck with it on my Ipaq 3850 for about 4 months, while I waited for Compaq Research Labs to tweak Familiar linux support for this model. During that time I learned to hate PocketPC. It's unstable, slow, buggy and bloated when compared to Familiar.
...only allow the MACs of your PDA...
Meanwhile I'll be a hypothetical man in a black hat at another table. I'll be watching you through two holes cut in a newspaper. When You've finished and switched off your PDA/notebook/whatever, I'll assume the MAC address which my PDA recorded you were using and start to upload illegal things through your DSL line. If you are using WEP, it'll take a hundred meg or so of your data to be transfered before I've got your key.
Don't rely on MAC address filtering or WEP, this stuff was poorly thought out to start with. Use IPSec or SSH tunnels if you can, or failing that firewall off your access point from the rest of your apartment network and treat it like any other public network - insecure.
Not strictly true. It ran under a DOS32 extender (I seem to remember they used Watcom's DOS4GW). I'm pretty sure this provided a thread library (it's been a while, etc. etc.)
I think u r riit.
All I want to know is if Sun is back to being the . in .com
:)
I think Sun's marketing department finally realised that's not a good thing to be
...produce next to no radiation...
How do you see it then?
Of course, sitting hunched over a laptop and squinting at the 15" screen for 6 hours a day has got to better for you...
The non geek probably ignores "Xiph Ogg Vorbis"
And some geeks. It's such a naff sounding name - I detest it...
Strikes me as being a good porn star name surname.
Woody Longhorn perhaps...
I'm reminded of that Farside cartoon - the one where a band is recording in a studio and the technician is reaching for the 'Suck' control on the mixing desk.
Hang on...
# cd daikatana-src/
# grep CFLAGS Makefile
CFLAGS = -O2 -suck
Ah, here's the problem.
This is the first port of a major OS to x86 in years really, yes?
I assume this a clumsy attempt at sarcasm.
It's not a new port. Solaris has been available (in various states of usability and support from Sun) since version 2.1-x86 in 1993.
You've got no business here.
I've heard of a major British ferry operating company who doesn't mess about with halon in their datacentre. They simply cut the power then drench the kit in water - evidently they can stand the amount of downtime required to dry it out again :)
We'll have no shouting.
Does anyone know if Norton Anti-Virus runs under Wine?
/usr/local/wine
No, but:
# rm -rf
does.
The evidence is becoming very persuasive that immunizations do bear a large portion of the blame...
There may be commonality between the vaccination figures and autism figures. That does not mean that the one causes the other.
(Commence the flamebait about how we're playing with fire, yadda yadda yadda...)
To be successful a vaccination programme needs to include over 95% of the population in order to achieve 'herd immunity'. Less than 95% and you run the risk of an epidemic. Remember, the ultimate aim is to erradicate the virus. Deciding not to vaccinate your children based on the unsubstantiated causality between vaccination and autism is selfish and irresponsible.
You're quite right, but they won't learn, you know.
The very next Lego related story will contain the word 'Legos' - just to annoy you and I. Then again, I stopped caring about Lego at about the age of 13, when I noticed that I fancied girls...
Generating 64bit code from a compiler will often run slower than equivalent 32bit code. For example; all of the binaries in /usr/bin on Solaris9 are 32bit, both for backwards compatibility and for performance - there are nearly 600 files. There are separate sparcv7 (32bit) and sparcv9 (64bit) binaries for only very few commands. Of these, some are 64bit so that they understand the 64bit kernel structures (adb, mdb, truss, the 'p' commands (pmap, pcred, pstack etc.) and there's sort. sort is the only command compiled to 64bit for performance. It's the only command deemed likely to encounter a large enough dataset to benefit from being 64bit.
EVERY situation I've seen a large Sun used it could have been handled with Linux
You need to get out more.
I've worked on several large scale Sun projects within the finance industry - Each with more than 1 million pounds worth of hardware. In each case the choice of the hardware was influenced by the following factors:
1. Which platforms does the application run on - (You'd be surprised how often the answer is - SPARC/Solaris only - less so these days, but many small finance ISV's still only support SPARC/Solaris)
2. Which database platform is required. (More often than not it's Sybase, sometimes Oracle, hardly ever anything else - DB2 rarely) Sybase will normally recommend SPARC/Solaris as it's their development platform. Likewise Oracle - authough they tend to be a little more platform agnostic.
3. How much downtime is acceptable - or put another way how much will downtime cost the business in real terms. For a major commercial bank, loosing their general ledger for example, will not only make it impossible to settle but they could be closed down by the finacial regulators. For an exchange, if they loose the ability to process trades and have to suspend the market, they will loose money directly (their profit on each trade) and may also have to pay customers compensation for their loss of earnings.
4. What availability figures will a particular vendor be willing to gaurantee (technically and financially). All large hardware vendors are very conservative on this - all vendors have product reliability issues from time to time - many customers refuse to admit responsibility for their mistakes (patch management, environmental issues). Going to court is expensive for all concerned, so vendors normally try to placate an angry customer with a better discount or by free hardware. Customers in turn appeciate the relationship and continue to place large orders. Many vendors are only willing to gaurantee very high (more than 5 nines) availability figures on their highest end server and disk products.
5. Large systems are likely to be more reliable than small systems from the same stable. Fact. The systems vendor has spent more money in R&D to make it so. They typically have more redundant/better quality components, dynamic partitioning capabilities (seldom used dynamically, of course) better systems management capabilities, more data replication options. Most importantly, larger systems are administered better, during the implementation phase the sys admins are trained, their systems runbook is developed, patch management and backup strategies are developed and the systems are tested properly. Human error (or process) is almost always to blame when large systems incur significant downtime.
6. How credible is the vendor? What platform is your major competitor using? If a particular vendor (systems and software) it's likely to be for a good reason - they understand the market, have strong relationships with ISV's, produce strong products and have decent service people to fix things when they go wrong.
7. The principle of locality of data. Many (not all) finance systems will benefit from keeping data in memory. High end 64 bit chips have large (8 or more Megabyte) E-caches. High end SMP 64 bit machines can address hundreds of Gigabytes of memory with (mostly) uniform performance and good reliability. Data is more likely to be in memory when it's needed, therefore you can process more trades per second, run risk analysis faster and generally make money faster.
Finance is a risk averse industry, in order to maintain transactional integrity, with robust reliability, with decent disaster recovery and finally good performance. They are willing to spend the money on (and often require) high end 64 bitness. In fact the cost of the hardware often pales into insignificance in comparison to software costs, running a datacentre, employing decent architecture design, systems admin and programming people, not to mention hardware support contracts, leasing DR fibre pairs, etc. etc.
..cos Kansas is going bye-bye.
As a reseller you are a middleman, Sun spends the billions on research and development, you reap a large share of the rewards when times are good. During the inflation of the dot-com bubble you helped Sun to keep headcount and warehouse space to a minimum - and your price was a generous discount on Sun hardware and software. Now you are a waste of space. I know of 2 decent Sun resellers in my old vertical market (both of which covered many other markets as well) they provided a tangible value-add - both in terms of technical pre-sales skills, benchmarking facilities and post sales consultancy services. I'm sure they're feeling the pinch at the moment, but I think their customers will return.
If I were running the partner programme at Sun, I would certainly want to weed out the underperforming resellers, especially those who complain about mandatory training sessions. You are a cost of sale and even during the good times your performance was often embarrasing. It's all about value-add, if you're not adding anything other than a customer base for Sun, prepare for those customers to cut out out of the loop and deal direct with Sun.
Not exactly a solution to your problem, but you might consider AutoFS. I got fed up with having multiple pools of storage at home and no sensible way to back data up over many machines. All my machines are NIS clients to my Qube which is the NIS master. Any machine which exports a filesystem via NFS gets given a NIS entry in auto_master/auto_direct (Solaris/Linux). Everything is available, in my case via /han.
/han/mp3
/han/code
/han/divx
/han/pr0n etc. etc.
The nice thing is, you never have to su to root in order to mount anything - you just cd into the directory (on any machine) and it gets mounted in the background. You still get UNIX file semantics and permissions, the normal NIS & NFS behaviour.
On the machine with the DDS3 drive. I just kick of a script which traverses the NIS map and catches all the directories which I deem worth backing up. Works a charm, but really only on UNIX, which suits me. There are windows clients for much of this stuff (reflection, Solstice network client if you can still find it) but they're mostly crap.
after it crashes **cough **cough ecache
That issue has largely gone away with mirrored SRAM modules. Every major systems manufacturer has product issues from time to time. For Sun it has recently been ecache, GBICs and the odd 420R power supply. Yes, they should have been more pro-active and open about the problems, but once they were discovered Sun's service organistation takes over and manages the problem to resolution. Sun Enterprise services are generally excellent at what they do.
As for N1, I shouldn't worry too much. This whole story smells like a marketing pipedream. Anyone remember being given the 'top secret' genesis briefings, later rebranded as Datacenter.com? The technology they talked about was 'almost like' what Sun could with SunCluster 3.0/E10K dynamic domains (if they were supported together at the time) and some imaginary highspeed interconnect, hooked together in some configuration which would almost certainly never be supported.
I expect their next step will be to rebrand all their software products as 'N1' compliant, knock together some laughable management console which only works marginally well with bits of it and move on to the next amateur marketing stunt. That's what normally happens (cynical, me?).
...calling it the World Series sounds a little arrogant, perhaps, but it remains called that because of tradition...
Nothing wrong with tradition. I'm told (by a genuine American no less) that the first World Series was so named because it was originally sponsored by a newspaper called the 'World News' or some such name.
Being an Anglophile Xenophobe, my maxim has always been 'If it annoys foreigners, keep doing it'. Well done America.