Agreed. No need for root. Root on developers workstations is also very poor. The main case would be for device driver development. Not for modelling. This just looks like poor administration to me.
Solaris will run on whitebox x86 hardware - I did this for years. It's just like linux. You need to mug up on device compatibility. You can go to blastwave & friends if you want another toolset. Not a problem, nosireee. Just the RPM generation.
I don't think these lads need Trusted Solaris, but they probably do need to make use of Role Based Access Control.
As Mr Boner indicates, Sun do have a good story. They have cheap gear, know their kit from the chips up to the shell.
The costs of migration may look cheap, but if you are throwing away experience and a developed environment, then the those costs ought to have been factored into the 'persuasion'. They are big numbers. It can yeake admin-years to re-establish stability.
It's very sad to see a original poster asking such basic questions, especially if he is driving the technical direction of an organisation.
Note: my first linux installation was a slackware with 0.97. My first solaris was 3.0.6. Anyone remember Whitechapel ?
Add sun's own J2EE stack to that - and that's certainly enterprise. and 'glassfish' which is the follow-on.
It made more sense for Microsoft to develop CLI as multi-language, than for Sun. Windows desktops are the target for all sorts of ancient corporate code. The sort of business app that used to live on a box in a datacentre corner used by 20 specialists often transitions to a PC. It's a cheap target. If the app's old, it may use several languages..NET helps you get around that. But you still get to live with the characters of all those languages.
Java ended up solving a a differnet problem & coding up *reliable* datacentre apps. The nice thing is that no Java app is much over 10 years old. An interesting thing is how the requirements for big, datacentre apps echo into mobile phones where the reliabilty needs are actually similar.
I admit I don't program any more, but the language compromises in Java, whilst tedious, do appear to have been beneficial.
A few years ago it was declared that problems with rejection of skin had been overcome. That led to a few people receiving hand grafts. These were actually forearm and hand.
The recipients had problems with these. One went so far (and he had difficulties in persuading surgeons to do this) as to have it removed. Others were happier.
One of the obvious problems on the footage I saw was the damage to the skin of the grafted limbs. It was in a state of semi-rejection, puffy and scaly. Not very good. For a face replacement, this is obviously going to be a major issue. The tissue is always under attack by the immune system, the drugs only suppress this. Over time, the skin and muscle will degrade due to this.
Rejection is always a problem with transplants. The drugs have considerable side effects and are really only used because the alternate is death or severe disability to the patient. The transplant route is not taken lightly. You will note that it is used only where the alternates are worse.
Given the above, I would personally question why they want to do this. A cosmetic issue is not life threatening. It might lead to a poor quality of life for the patient, but it is not going to kill them. The transplant itself may (through drug effects) lead to a much worse one.
their problem has been an existing launch manifest at vandenberg. there is a atlas 5 or somesuch in the way. as it has a $bn payload on top, they cannot fly. hence the relocation to the (amusingly) named ronald reagan ABM test facility of kawaljein island.
spacex have done their development right. they are using intelligent designs. they have done an awful lot of testing and simulation. they look to have a chance.
it may seem odd to actually put a commercial payload on an untested rocket, but given that nearly every launch is on virgin equipment it makes sense (discounting ariane 501, for which parts of the payload were dug out of a rainforest and displayed - some instruments were nearly reusable)
Interesting thing about Sun's approach to 10 is that they are engineering a way to do without Linux at the application level.
If you get a nice 4-way opteron box, install solaris/x86, compartmentalise it via zones you get N effective linuxes (where N will be usefully large) on one chassis. Its gives you the same thing as IBM/VM/Linux, without buying a mainframe.
If you choose a server which has hardware supported by Solaris, then you don't actually need Linux at all. Oh, and Sun are pretty well imdenified already against patent risk with Solaris.
I do not think Sun is going away. They build good kit. It lasts, its reliable and its not power hungry. Solaris has been around a long time. Its stable, scales extremely well and is well understood. Its is also very network aware. It does cache filesystems for instance.
The N1 idea is a pearl. Admittedly they have a way to go in implementation but you can see the point where they completely virtualise storage and hardware. If you read the docs for the blade stuff (computer on a card with standard connectors) you see that they are already offering automatic drop out & replacement from pool of failed gear. That is really very impressive. And they will do Linux. You try and do this at home...
PS
For some reason these forums now seem to attract a huge amount of vacuous posts. No reasoning, just kneejerk "X company are dead cos they dont do linux/wintel".
A very large base of the open source software you all now use was created on Sun gear. If SMCC had not survived 12 years ago I really doubt there would be a Linux. Show some perspective.
Re:Since when is apache == covalent?
on
.NET for Apache
·
· Score: 1
This is the true. Covalent employs a (diminishing) number of core Apache people. The original founder left the company recently leaving it in the hands of more VC-friendly placemen.
The press release was made by Covalent. They can work with whosoever they want to. The Apache license does not prevent MicroSoft from using the code base nor does it prevent Covalent from releasing products that use or link to proprietary Microsoft code.
Given the state of the industry, and the management of Covalent this is not a surprising move. If it guarantees funding and continuing employment for and of guys who hack on Apache then it might well be construed a good thing.
As the thread sez, you can surely port OS/X over to PC chassis.
Unfortunately, you then got to start creating stable device drivers, coping with motherboard incompatibilities, the versions of different card etc etc ad infinitum
Which costs. Linux suceeds because of the nmber of contributors. prepared to do this. It probably would not be the case for OS/X.
We (as users) are better off with the current situation. Apple make hardware and the OS, restrict the hardware they use and are thus able to prove stable, reliable systems. They can also afford to program funky tools, rather than spend on compatibility issues.
Well, I was involved for a while in a project that used an OODBMS. O2 in fact -- a product that was, last I looked, discontinued.
Problems with OODBMS
1. OQL implemations
2. dont' share data so well because most
are file-based implementations NOT servers
3. schema
4. administration
O2 worked, but the schema issue turned into a problem. Same sort of thing as versioning interfaces in CORBA. Every time an object is changed, Phoof.
OQL implementations are not particularly well done. Some systems do, some don't. And the variation in these is wide.
Administrative tools for a application on the OODBMS we used had to be written as part of the project. Reporting out of a OODBMS data set of course needs you to write more code. You cannot just use a copy of Access or similar.
You do not have a tidy client-server relationship across the wire in most of the products I checked out. There was one, but it cost $50,000. so you have to host the OODBMS on the same server as the application. Unless you care to get into CORBA or other 3rd party wire protocol.
Oh, and there are few 3rd party tools around for them.
OODBMS really must/not/ be confused with SQL datbases. They are not implimented in anything like the same way. And they have a very different set of costs.
Hmmm... if SCSI committee (T10) has implemented a version of this copy protection scheme, then does anyone know which document would contain the spec on www.t10.org ? Acronym navigation is no longer my strong point.
FYI: if you grab the jre.xpi from NS6.0 distro tree you can (finally) get mozilla nightly + java going. Or at least you could with 2000111321. lots better:-)
and yes ns6/moz is clunky, but i have been using it for some months now and it works -- better than 4.7x for me anyway.
remember, mozilla 1.0 is 2Q2001. so it would have been too long a time to wait for netscape.
This is mainly moz m14 code, with repackaging (but we all knew that!). From the newsgroups it does seem there are a lot of performance issues to sort out still. But in any project, performance and optimization comes after you get the basic featureset together. APIs are still not done, and the mozilla milestone releases stretch out into October:
i once had a machine that would write stuff in any of several hundred floppy formats onto 2.5" 3.5" 5.25" 8" floppy. try c:>format/h on dos. then versados, rsx, rt11 data formats. and those tiny, dinky tapes you used to boot vaxen 11-730s from.
and then we lost the bsd 4.3 image -- arrrgh....
seriously, what i really sez is that you should invest in long lived, big, media. thumping big jukes if need be that copy data automatically at the first sign of media aging.
the thing about this policy is that you tend to keep things available without thinking about it (and dont forget the data format docs & software)
DATA DOES NOT BECOME OBSOLETE. MEDIA DOES. THIS IS A ENORMOUS PROBLEM. WE HAVE SUMERIAN TABLETS WE CAN STILL READ. IN 5000 YEARS NOONE WILL REMEMBER OUR CULTURE BEYOND 2005 & ONSET OF E-BOOKS -- IT WILL HAVE BITROTTED, MEDIADECAYED, FORMATLOST.
1. if you use Java, test JVMs. some are much slower than others. volano.com's benchmarks make intersting reading. they are a narrow test, mind you. you can also try running an alternate OS (solaris-intel springs to mind as it does have stable JVMs & does SMP bette than linux -- if you follow that route, beware of hardware compatibility issues) 2. check the raw query performance of the SQL server. you can use a command line tool for this. if the database is the bottleneck this will show it up. then you can go look at speeding it up.
Slashdot Mirror
You don't.
You run ZFS, which does not require defragging.
Merlin 2 would not be the most powerful motor. More like #5. SpaceX is shooting for design simplicity.
Agreed. No need for root. Root on developers workstations is also very poor. The main case would be for device driver development. Not for modelling. This just looks like poor administration to me.
Solaris will run on whitebox x86 hardware - I did this for years. It's just like linux. You need to mug up on device compatibility. You can go to blastwave & friends if you want another toolset. Not a problem, nosireee. Just the RPM generation.
I don't think these lads need Trusted Solaris, but they probably do need to make use of Role Based Access Control.
As Mr Boner indicates, Sun do have a good story. They have cheap gear, know their kit from the chips up to the shell.
The costs of migration may look cheap, but if you are throwing away experience and a developed environment, then the those costs ought to have been factored into the 'persuasion'. They are big numbers. It can yeake admin-years to re-establish stability.
It's very sad to see a original poster asking such basic questions, especially if he is driving the technical direction of an organisation.
Note: my first linux installation was a slackware with 0.97. My first solaris was 3.0.6. Anyone remember Whitechapel ?
Add sun's own J2EE stack to that - and that's certainly enterprise. and 'glassfish' which is the follow-on.
.NET helps you get around that. But you still get to live with the characters of all those languages.
It made more sense for Microsoft to develop CLI as multi-language, than for Sun. Windows desktops are the target for all sorts of ancient corporate code. The sort of business app that used to live on a box in a datacentre corner used by 20 specialists often transitions to a PC. It's a cheap target. If the app's old, it may use several languages.
Java ended up solving a a differnet problem & coding up *reliable* datacentre apps. The nice thing is that no Java app is much over 10 years old. An interesting thing is how the requirements for big, datacentre apps echo into mobile phones where the reliabilty needs are actually similar.
I admit I don't program any more, but the language compromises in Java, whilst tedious, do appear to have been beneficial.
A few years ago it was declared that problems with rejection of skin had been overcome. That led to a few people receiving hand grafts. These were actually forearm and hand.
The recipients had problems with these. One went so far (and he had difficulties in persuading surgeons to do this) as to have it removed. Others were happier.
One of the obvious problems on the footage I saw was the damage to the skin of the grafted limbs. It was in a state of semi-rejection, puffy and scaly. Not very good. For a face replacement, this is obviously going to be a major issue. The tissue is always under attack by the immune system, the drugs only suppress this. Over time, the skin and muscle will degrade due to this.
Rejection is always a problem with transplants. The drugs have considerable side effects and are really only used because the alternate is death or severe disability to the patient. The transplant route is not taken lightly. You will note that it is used only where the alternates are worse.
Given the above, I would personally question why they want to do this. A cosmetic issue is not life threatening. It might lead to a poor quality of life for the patient, but it is not going to kill them. The transplant itself may (through drug effects) lead to a much worse one.
See http://www.handtransplant.com/ for information on the procedure and risks.
their problem has been an existing launch manifest at vandenberg. there is a atlas 5 or somesuch in the way. as it has a $bn payload on top, they cannot fly. hence the relocation to the (amusingly) named ronald reagan ABM test facility of kawaljein island.
spacex have done their development right. they are using intelligent designs. they have done an awful lot of testing and simulation. they look to have a chance.
it may seem odd to actually put a commercial payload on an untested rocket, but given that nearly every launch is on virgin equipment it makes sense (discounting ariane 501, for which parts of the payload were dug out of a rainforest and displayed - some instruments were nearly reusable)
Interesting thing about Sun's approach to 10 is that they are engineering a way to do without Linux at the application level.
/x86, compartmentalise it via zones you get N effective linuxes (where N will be usefully large) on one chassis. Its gives you the same thing as IBM/VM/Linux, without buying a mainframe.
If you get a nice 4-way opteron box, install solaris
If you choose a server which has hardware supported by Solaris, then you don't actually need Linux at all. Oh, and Sun are pretty well imdenified already against patent risk with Solaris.
It has been done in some of the older work. It's not as bad as yu think.
www.wirelessleiden.nl
it's open access WiFi. it may slightly off-topic, but its worth a look.
Actually, this is quite important.
...
I do not think Sun is going away. They build good
kit. It lasts, its reliable and its not power hungry. Solaris has been around a long time. Its stable, scales extremely well and is well understood. Its is also very network aware. It does cache filesystems for instance.
The N1 idea is a pearl. Admittedly they have a way to go in implementation but you can see the point where they completely virtualise storage and hardware. If you read the docs for the blade stuff (computer on a card with standard connectors) you see that they are already offering automatic drop out & replacement from pool of failed gear. That is really very impressive. And they will do Linux. You try and do this at home
PS
For some reason these forums now seem to attract a huge amount of vacuous posts. No reasoning, just kneejerk "X company are dead cos they dont do linux/wintel".
A very large base of the open source software you all now use was created on Sun gear. If SMCC had not survived 12 years ago I really doubt there would be a Linux. Show some perspective.
This is the true. Covalent employs a (diminishing) number of core Apache people. The original founder left the company recently leaving it in the hands of more VC-friendly placemen.
The press release was made by Covalent. They can work with whosoever they want to. The Apache license does not prevent MicroSoft from using the code base nor does it prevent Covalent from releasing products that use or link to proprietary Microsoft code.
Given the state of the industry, and the management of Covalent this is not a surprising move. If it guarantees funding and continuing employment for and of guys who hack on Apache then it might well be construed a good thing.
As the thread sez, you can surely port OS/X over to PC chassis.
Unfortunately, you then got to start creating stable device drivers, coping with motherboard incompatibilities, the versions of different card etc etc ad infinitum
Which costs. Linux suceeds because of the nmber of contributors. prepared to do this. It probably would not be the case for OS/X.
We (as users) are better off with the current situation. Apple make hardware and the OS, restrict the hardware they use and are thus able to prove stable, reliable systems. They can also afford to program funky tools, rather than spend on compatibility issues.
Well, I was involved for a while in a project that used an OODBMS. O2 in fact -- a product that was, last I looked, discontinued.
/not/ be confused with SQL datbases. They are not implimented in anything like the same way. And they have a very different set of costs.
Problems with OODBMS
1. OQL implemations
2. dont' share data so well because most
are file-based implementations NOT servers
3. schema
4. administration
O2 worked, but the schema issue turned into a problem. Same sort of thing as versioning interfaces in CORBA. Every time an object is changed, Phoof.
OQL implementations are not particularly well done. Some systems do, some don't. And the variation in these is wide.
Administrative tools for a application on the OODBMS we used had to be written as part of the project. Reporting out of a OODBMS data set of course needs you to write more code. You cannot just use a copy of Access or similar.
You do not have a tidy client-server relationship across the wire in most of the products I checked out. There was one, but it cost $50,000. so you have to host the OODBMS on the same server as the application. Unless you care to get into CORBA or other 3rd party wire protocol.
Oh, and there are few 3rd party tools around for them.
OODBMS really must
My 1/2 penny worth.
Hmmm... if SCSI committee (T10) has implemented a version of this copy protection scheme, then does anyone know which document would contain the spec on www.t10.org ? Acronym navigation is no longer my strong point.
that should have mentioned linux ;-)
FYI: if you grab the jre.xpi from NS6.0 distro tree you can (finally) get mozilla nightly + java going. Or at least you could with 2000111321. lots better :-)
and yes ns6/moz is clunky, but i have been using it for some months now and it works -- better than 4.7x for me anyway.
remember, mozilla 1.0 is 2Q2001. so it would have been too long a time to wait for netscape.
This is mainly moz m14 code, with repackaging (but we all knew that!). From the newsgroups it does seem there are a lot of performance issues to sort out still. But in any project, performance and optimization comes after you get the basic featureset together. APIs are still not done, and the mozilla milestone releases stretch out into October:
t ones/
http://www.mozilla.org/projects/seamonkey/miles
Recall the NS4 beta cycle -- that went on for months. What was it? 12 of them?
Problem with the implementaion is that every window is a new web browser, and at the moment, that seems slow.
It will get better!
Do not expect a full product then for a while yet.
To keep things in perspective, each of these projects cost as much as a "Summer Blockbuster" movie. How many of those bomb every year?
Last I heard, Schwartzenegger was still working...
and then we lost the bsd 4.3 image -- arrrgh....
seriously, what i really sez is that you should invest in long lived, big, media. thumping big jukes if need be that copy data automatically at the first sign of media aging.
the thing about this policy is that you tend to keep things available without thinking about it (and dont forget the data format docs & software)
DATA DOES NOT BECOME OBSOLETE. MEDIA DOES. THIS IS A ENORMOUS PROBLEM. WE HAVE SUMERIAN TABLETS WE CAN STILL READ. IN 5000 YEARS NOONE WILL REMEMBER OUR CULTURE BEYOND 2005 & ONSET OF E-BOOKS -- IT WILL HAVE BITROTTED, MEDIADECAYED, FORMATLOST.
nice to shout sometimes, innit :-)
1. if you use Java, test JVMs. some are much slower than others. volano.com's benchmarks make intersting reading. they are a narrow test, mind you. you can also try running an alternate OS (solaris-intel springs to mind as it does have stable JVMs & does SMP bette than linux -- if you follow that route, beware of hardware compatibility issues) 2. check the raw query performance of the SQL server. you can use a command line tool for this. if the database is the bottleneck this will show it up. then you can go look at speeding it up.