You didn't RTFA before posting did you? When they say assembler they mean something of their own that takes a binary blob and one you have already and reassembles the original binary. It just so happens that the disassembler knows a lot about windows executables and the archive format that google uses breaks it up into some portions and assigns labels to addresses. Then it runs bsdiff on this smaller subset.
The code outlined in the blog post is really in these files:
win32_x86_generator.h win32_x86_patcher.h
Notice these names? This is the disappointing aspect to all of this, it is one more new reason that Chrome is x86 and primarily Windows. You would need one for Mach-O and ELF to do this on other platforms and then if you were on another processor, say ARM or PPC, you would need something that understood that as well. Then there is the issue about 64-bit. In any case the assembler is not something like gas or MASM which is what you imagined.
In the '80s those of us not using English had a real problem with fonts in that we had no uniform way of having what we wrote appear on a screen or printer. I remember embedding printer control escape sequences that would back the print head up and then print a slash or tick over what was there so people could understand what letter it was. But even back then people were complaining about not having fancy fonts when there was this real problem. Remember font cartridges for printers?
Now the real problem is largely solved but these font weenies are still coming-up with crazy schemes to make text look a certain particular way and it is pretty ridiculous the amount of effort that has been spent over the years on this with schemes that end-up only working for a few short years before something new shows-up on the horizone when for the most part electronic text is about information rather than the appearance. Don't try and tell me that this is simple until you look up EOT.
You know why it panic()ed (no not a segfault)? Because the processor board was not offlined first. That guy was a moron, more over since the boards on those systems did not have pins of sufficiently different lengths it could have fried an expensive component to simply yank the card out.
Re:Breaking out of chroot for a non root user
on
R.I.P. FTP
·
· Score: 1
I forgot how good of an article that was, these were fixed in OpenBSD 3.1, they are errata 014 and 015.
chroot failing with EPERM when euid is not 0 is not universal. In fact it is relatively recent. I think it appeared circa FreeBSD 4.8 (or was that 4.4) in fact as a result of another exploit to escape chroot. I would not count on chroot only working for root, I've used systems where it was not the default and others that were poorly configured so that it was allowed (see man 5 privileges on solaris for example). There are a whole list of ways to break out of a chroot jail, and work a rounds have been adopted over the years. Another popular one was using mknod and using the superblock in there, but that has required root for as long as I know of.
Then there is the problem that a lot of programs that are run in a chroot jail do not call setuid (and only sometimes seteuid) since they do in fact need some root permission. For example an ftp server might need it for ports below 1024. In fact Samba was vulnerable to such a chroot escape in the past a couple of times.
Again, that's another reason to use something jail like instead of chroot like, the intent is that even root cannot escape a jail.
Then there is the whole can of worms that chroot really only tried to capture you to a portion of the filesystem. There were attacks where yo could send signals to other processes and just look at processes of other users for example. It all leads to the desire of having something jail like like jail or zones.
Okay the guy you replied did not write in a pleasant way but he has a point. chroot is not jail, chroot is easy to break out of on many systems. The reason is because once you are chrooted you can call chroot yourself. The canonical approach to break out of a chroot jail that has been known about now for 10 years or so works like so:
mkdir "foo" fd = open "." chroot "foo" fchdir fd for (i = 0; i < 0x100; i++) chdir ".." exec "/bin/sh"
Most chroots don't change the the cwd so the fchdir is often not needed also the dirent approach works as well in other cases.
So now you are running as nobody or yourself and you can use the local privilege escalation of the day to get root access, but just breaking out of the chrooted environment may have been the goal, you know like you were not supposed to be able to run a shell at all. Or you may now run some denial of service (local or remote).
So some systems prevent this. One notable is BSD where chroot fails if you have fds open. There also are other approaches for breaking out of a chrooted environment, as well as countermeasures.
One point is how would you run this stuff at all. Well one argument is that this might be a webserver where you have CGI and therefore an interpreter like perl, and doesn't that example I wrote there look a whole lot like perl. The other argument is that this was first seen in the wild against wu-ftpd back in 1999, and it used a buffer overflow to inject that same code to break out of the chroot jail and execute the shell in place.
So the argument I am trying to make in a much more civil manner is that if you need something like jail, use something like jail and not the poor substitute of chroot instead.
Close the lid, open the lid, and sleep and resume actually worked. The battery life was better in OS X than linux.
That is really all that there was to it, that and X11 plus gcc with the stuff in/usr/bin was good enough. It has nothing to do with UI, cause there were a whole lot of people that used fvwm+xterm+vim or whatever they are accustomed to in full screen X11.
I lived pretty close to one, a huge one with tens of thousands of dairy cows. The stench was in fact unimaginable when driving by. I think you do not live near dairy farms of an industrial scale.
Though it looks from the slides that they did in fact translate line by line and did not use any of the object oriented features of java. That would have been like the opposite of another project I was involved in. I wrote a bunch of python code. later it was deemed that perl was known by more of the devs so I would need to translate that to perl. The python code used classes so I translated that by hand into a subset of python that was very procedural. Then I wrote a python script that translated that into perl. And then I cleaned that perl up in places by hand to make it look like perl code a perl programmer would write. That was an annoying project.
We used p2c to migrate a bunch of pascal code to C many years ago. It was not perfect, but not that bad. You got pretty good at figuring-out the likely places that screwed-up. Also save for the with statements in pascal being translated to accesses to structures, it made relatively readable C.
Actually some of the TARP money is being paid back soon. The government will likely have made a tidy sum from the interest on those coupons. At the rate Tesla is burning through cash, it is very unlikely that they will be able to repay this DOE money unless they take out a loan.
"I've been watching Tesla since day one. The make cars the way they should be made. You place an order for your car, then the car is built..." up to two and a half years later, for nearly $10K more in base price, plus all the extra for the higher priced options, and without meeting the promised performance numbers.
You may want to buy your cars like that, but I certainly don't.
"There is a bit more to the Tesla cars than just ripping out the ICE and putting in a regular electric motor. There is very advanced liquid-cooled Lithium Ion battery technology, a next-gen 3-phase/4 pole motor, etc. It performs at par or better than other cars in its price point, and is also practical (can carry 5 passengers and their luggage comfortably)."
Where is this car? It is only a full scale one-off mock-up at this point. A mock-up prior to the Daimler announcement. A mock-up that they are currently taking deposits on.
There is something similar on the way to the desk of Obama. It looks like out of committee will be the following:
$1 000 000 000 of funding.
You trade in a car that has been registered in your name for a year from after '76 (or '85 depending on bill) that gets less than 19 MPG combined on adjusted EPA or a table to be created for older models.
You buy a new car that gets 5 MPG more than the old, you get $2 500 for the trade in.
You buy a new car that gets 10 MPG more than the old, you get $3 500 for the trade in.
The rules are a bit different for trucks of various classes, most SUVs and vans fall into the you get the full benefit at 5 MPG more.
How do you feel about that? I actually dislike this very much. It is very hard to find a car that is listed at 19 MPG or worse. Moreover what individual is driving such a bucket and has the means to afford a new car? (Some college students? Some farmers with a work vehicle?) It looks like this will benefit those people that have old trucks in their farm or small business. They will be able to buy more trucks that get worse fuel economy than cars, those same trucks that already have incredible manufacturer incentives.
The one good thing it may do for dealerships is that it may drive in foot traffic from people that think their car is eligible.
The top of the roadster is of notoriously poor construction. The plant is so far behind on simply making new roadsters with deposits, that there is a very long wait time for repairs. In fact owners are resorting to duct tape. Soon out of warranty that will be very expensive if you want a water tight roof.
Tesla also said that they are getting VC funding before the deal was finalized with Diamler. Tesla also said that they were getting this DOE funding, before that was finalized. Tesla also said the Roadster would be under $100k and meet various benchmarks like 0-60 times. The car was nearly $10K over, people that made deposits had to cough up the extra $10K, also if they wanted the options that they had selected, they had to cough-up more since the prices on all of the options packages increased, and the car has not met its performance benchmarks as well as there was the transmission bait and switch. Finally Tesla also claimed that they were building the Model S on a new platform of their own design when later it was learned after the Diamler deal that it likely would be an older platform of theirs. Actually most of these lies have been from Musk, high people from Tesla have resigned due to such repeated statements.
Because the money is going to a Nissan plant in TN that is being retrofitted to develop, manufacture, and test cutting edge batteries. Would you rather that the DOE does not provided to money on some idiotic jingoistic grounds only so that a future industry in and that portion of the economy is cornered in Japan?
1: GM never made a production version of the Impact (EV-1) since the CARB changed course mid stream and no longer required any zero emissions vehicles per automaker fleet.
2: They are using the money for plants. They have almost no money for actual development of the Model S. That money is likely being laundered via those plants at this point. Multiple times now Musk has made claims regarding funding that have proven to be false, like that they had already gotten approved for this program or the VC funds earlier. They are likely using the deposits on the Model S to build roadsters at this point.
Freddie Fish is actually a very good children's game, sort of an easy point and click adventure game. I assume the others are just as good. It is a shame they will be no more.
The amount of carbon produced by the cow in its lifetime plus decomposition after death is essentially the same as if the cow had never lived and all the corn and soy it would have eaten simply decomposed. The problem is that a cow produces not just carbon in one form, it tends to produce methane (the burps referred to) and methane has a much larger impact in global warming than CO2. The reason that the cows produce large amounts of methane is because the bacteria in their rumen (first stomach) is not right for the diets of mostly corn and soy that they are typically fed and this produces the methane burps. (Incidentally that is why there is relatively little methane in cow farts, almost all of the methane is produced in the rumen.)
So one option is to feed cows mostly grass, that is not sustainable in the large industrial scale used. Another option would be to genetically engineer bacteria that produces less methane and introduce it to the cow rumen. That actually makes more sense than engineering cows with a rumen more like a stomach. Another far fetched option would be to capture the methane, then sequester or burn it outright (the green house gases then are much less harmful).
If you have ever been near an industrial cattle or dairy farm, the stench is unimaginable. In a large cattle farm you can see the methane pockets causing the horizon to wiggle.
FTP also gets the line endings right too. A long time ago I had MPW and CW source code that three of us shared. I decided to get it into a in CVS repository on a solaris box after a couple of times we trampled over each other's changes. The code had mac line endings and the macs used for building were various machines with System 7 to 9. I diddled with all sorts of mac cvs clients all broken to various degrees until an older wiser programmer told me to use FTP. I installed Fetch (a mac ftp client) and what we did was just drag the source files files over that we had modified to a FreeBSD or Solaris box. The Solaris box was kerberized and the macs that were new enough used MIT kerberos for Mac to get to the solaris box directly, the FreeBSD box had some firewall rules to allow the old macs to ftp and used a chrooted ftpd. The solaris box nfs mounted those dirs from the FreeBSD box. Once we got the files onto the FreeBSD box or Solaris box we would ssh into the Solaris box and use cvs co, commit, update, etc. The reverse was well the reverse, first cvs update in your ws, then use Fetch to drag the files over to the mac. Sometimes you would grab more than you needed, but whatever. The beauty of this approach was that ftp automatically converted the line endings between unix and mac style so that the rcs diffs in the repository made sense and we could do all the cvs diff stuff from the Solaris box and only got the changes that actually were different. The other good aspect was that we always used a version of cvs client that was stable and well tested.
If you mean SMT as is in mutli processor, Sun copied that from other folks. If you actually mean HTT then Intel came-up with that years before the T1 from Sun. Though the T1 uses more of a CMT idea. HTT was pretty bad in the P4, but returns in Nehalem. It works in a different way than the Sun Niagara approach (only issues so many instructions per clock and from two threads to fill in pipeline bubbles) But with the pipeline much wider than on P4 it is much better and fairer. That said if both of your threads are saturating all of the AU say, you won't get a lick of better performance. The Niagara approach is different. It switches threads in certain situations (like waiting for a cache line to fill) but you can see the same kind of problem as on Intel's HTT when all your threads are doing a lot of FP.
The M30000 has DDR2-533 ECC RAM, can you see now that you were not compute bound (unless your dataset was less than 4MB or so)? Also it uses Fujitsu SPARC64 processors which typically have worse FP performance than UltraSparc IV+ even years later. The other thing is were you doing 32-bit or 64-bit FP? By using 32-bit FP and the SIMD features on AMD/Intel that can be a lot faster than 32-bit FP. Sparc FP went through a few revisions over the years. What you have now is 32 double precision registers, the first 16 of which you can use as two single precision each or use them as pairs for 8 quads. The upper 16 can only be used as doubles. Some of the single precision operations are SIMD like, that was very useful in sparcv8 and made some single precision faster than double precision. Almost every sparc out today does all FP in double precision and creates a single precision result if it needs to. That is why double is just as fast as float. The instructions handled by the FP unit are very rich. The ones for quad are almost as rich, but some trap. There is also VIS (a SIMD extension for sparc) but relative to FP all it had were some instructions to more speedily get values in and out of the FP registers. The VIS 3.0 in RK (just cancelled) was going to offer more in the way of FP.
For performance measurements. When Opteron came-out it was faster than the fastest UltraSparc at 32-bit FP, actually by a good margin. It was a tad slower at double and did not have a snowballs chance in hell with quad (but nobody uses that). Then with the UltraSparc IV and IV+ sparc was again faster at all FP. The T1 and T2 were not as fast at FP as USIV and USIV has stagnated (RK was expected so USV was canned). We now again see that for single precision Intel (incredible strides) and AMD are faster than UltraSparc and are on the doorstep with regards to double precision. But again the memory being used in modern Intel and AMD machines is faster than that used in current Sparc kit. The FP on Sparc is so fast that it is memory bound in more cases than Intel and AMD, certainly in HPC types of workloads.
Apple has a history of making ASICs. In fact the first intels were the first case of no Apple ASICs. The last example was the PHB chip on G5 systems, Apple designed, IBM fabbed. In fact they currently sell chips for iPod authentication fabbed in Taiwan. The rumors are that they are designing the SoC for a new line of small devices. Apple is very much in the hardware design game and positions continue to show-up on job listings.
Slashdot Mirror
You didn't RTFA before posting did you? When they say assembler they mean something of their own that takes a binary blob and one you have already and reassembles the original binary. It just so happens that the disassembler knows a lot about windows executables and the archive format that google uses breaks it up into some portions and assigns labels to addresses. Then it runs bsdiff on this smaller subset.
The code outlined in the blog post is really in these files:
win32_x86_generator.h
win32_x86_patcher.h
Notice these names? This is the disappointing aspect to all of this, it is one more new reason that Chrome is x86 and primarily Windows. You would need one for Mach-O and ELF to do this on other platforms and then if you were on another processor, say ARM or PPC, you would need something that understood that as well. Then there is the issue about 64-bit. In any case the assembler is not something like gas or MASM which is what you imagined.
In the '80s those of us not using English had a real problem with fonts in that we had no uniform way of having what we wrote appear on a screen or printer. I remember embedding printer control escape sequences that would back the print head up and then print a slash or tick over what was there so people could understand what letter it was. But even back then people were complaining about not having fancy fonts when there was this real problem. Remember font cartridges for printers?
Now the real problem is largely solved but these font weenies are still coming-up with crazy schemes to make text look a certain particular way and it is pretty ridiculous the amount of effort that has been spent over the years on this with schemes that end-up only working for a few short years before something new shows-up on the horizone when for the most part electronic text is about information rather than the appearance. Don't try and tell me that this is simple until you look up EOT.
You know why it panic()ed (no not a segfault)? Because the processor board was not offlined first. That guy was a moron, more over since the boards on those systems did not have pins of sufficiently different lengths it could have fried an expensive component to simply yank the card out.
I forgot how good of an article that was, these were fixed in OpenBSD 3.1, they are errata 014 and 015.
http://www.openbsd.org/errata31.html
chroot failing with EPERM when euid is not 0 is not universal. In fact it is relatively recent. I think it appeared circa FreeBSD 4.8 (or was that 4.4) in fact as a result of another exploit to escape chroot. I would not count on chroot only working for root, I've used systems where it was not the default and others that were poorly configured so that it was allowed (see man 5 privileges on solaris for example). There are a whole list of ways to break out of a chroot jail, and work a rounds have been adopted over the years. Another popular one was using mknod and using the superblock in there, but that has required root for as long as I know of.
Then there is the problem that a lot of programs that are run in a chroot jail do not call setuid (and only sometimes seteuid) since they do in fact need some root permission. For example an ftp server might need it for ports below 1024. In fact Samba was vulnerable to such a chroot escape in the past a couple of times.
Again, that's another reason to use something jail like instead of chroot like, the intent is that even root cannot escape a jail.
Then there is the whole can of worms that chroot really only tried to capture you to a portion of the filesystem. There were attacks where yo could send signals to other processes and just look at processes of other users for example. It all leads to the desire of having something jail like like jail or zones.
Okay the guy you replied did not write in a pleasant way but he has a point. chroot is not jail, chroot is easy to break out of on many systems. The reason is because once you are chrooted you can call chroot yourself. The canonical approach to break out of a chroot jail that has been known about now for 10 years or so works like so:
mkdir "foo"
fd = open "."
chroot "foo"
fchdir fd
for (i = 0; i < 0x100; i++) chdir ".."
exec "/bin/sh"
Most chroots don't change the the cwd so the fchdir is often not needed also the dirent approach works as well in other cases.
So now you are running as nobody or yourself and you can use the local privilege escalation of the day to get root access, but just breaking out of the chrooted environment may have been the goal, you know like you were not supposed to be able to run a shell at all. Or you may now run some denial of service (local or remote).
So some systems prevent this. One notable is BSD where chroot fails if you have fds open. There also are other approaches for breaking out of a chrooted environment, as well as countermeasures.
One point is how would you run this stuff at all. Well one argument is that this might be a webserver where you have CGI and therefore an interpreter like perl, and doesn't that example I wrote there look a whole lot like perl. The other argument is that this was first seen in the wild against wu-ftpd back in 1999, and it used a buffer overflow to inject that same code to break out of the chroot jail and execute the shell in place.
So the argument I am trying to make in a much more civil manner is that if you need something like jail, use something like jail and not the poor substitute of chroot instead.
The two simple reasons for this are/have been:
Close the lid, open the lid, and sleep and resume actually worked.
The battery life was better in OS X than linux.
That is really all that there was to it, that and X11 plus gcc with the stuff in /usr/bin was good enough. It has nothing to do with UI, cause there were a whole lot of people that used fvwm+xterm+vim or whatever they are accustomed to in full screen X11.
Now that is some vision, it's just like we stepped back to the '50s while groking the economic realities of the new world order.
I lived pretty close to one, a huge one with tens of thousands of dairy cows. The stench was in fact unimaginable when driving by. I think you do not live near dairy farms of an industrial scale.
Though it looks from the slides that they did in fact translate line by line and did not use any of the object oriented features of java. That would have been like the opposite of another project I was involved in. I wrote a bunch of python code. later it was deemed that perl was known by more of the devs so I would need to translate that to perl. The python code used classes so I translated that by hand into a subset of python that was very procedural. Then I wrote a python script that translated that into perl. And then I cleaned that perl up in places by hand to make it look like perl code a perl programmer would write. That was an annoying project.
We used p2c to migrate a bunch of pascal code to C many years ago. It was not perfect, but not that bad. You got pretty good at figuring-out the likely places that screwed-up. Also save for the with statements in pascal being translated to accesses to structures, it made relatively readable C.
Actually some of the TARP money is being paid back soon. The government will likely have made a tidy sum from the interest on those coupons. At the rate Tesla is burning through cash, it is very unlikely that they will be able to repay this DOE money unless they take out a loan.
"I've been watching Tesla since day one. The make cars the way they should be made. You place an order for your car, then the car is built..." up to two and a half years later, for nearly $10K more in base price, plus all the extra for the higher priced options, and without meeting the promised performance numbers.
You may want to buy your cars like that, but I certainly don't.
"There is a bit more to the Tesla cars than just ripping out the ICE and putting in a regular electric motor. There is very advanced liquid-cooled Lithium Ion battery technology, a next-gen 3-phase/4 pole motor, etc. It performs at par or better than other cars in its price point, and is also practical (can carry 5 passengers and their luggage comfortably)."
Where is this car? It is only a full scale one-off mock-up at this point. A mock-up prior to the Daimler announcement. A mock-up that they are currently taking deposits on.
There is something similar on the way to the desk of Obama. It looks like out of committee will be the following:
$1 000 000 000 of funding.
You trade in a car that has been registered in your name for a year from after '76 (or '85 depending on bill) that gets less than 19 MPG combined on adjusted EPA or a table to be created for older models.
You buy a new car that gets 5 MPG more than the old, you get $2 500 for the trade in.
You buy a new car that gets 10 MPG more than the old, you get $3 500 for the trade in.
The rules are a bit different for trucks of various classes, most SUVs and vans fall into the you get the full benefit at 5 MPG more.
How do you feel about that? I actually dislike this very much. It is very hard to find a car that is listed at 19 MPG or worse. Moreover what individual is driving such a bucket and has the means to afford a new car? (Some college students? Some farmers with a work vehicle?) It looks like this will benefit those people that have old trucks in their farm or small business. They will be able to buy more trucks that get worse fuel economy than cars, those same trucks that already have incredible manufacturer incentives.
The one good thing it may do for dealerships is that it may drive in foot traffic from people that think their car is eligible.
The top of the roadster is of notoriously poor construction. The plant is so far behind on simply making new roadsters with deposits, that there is a very long wait time for repairs. In fact owners are resorting to duct tape. Soon out of warranty that will be very expensive if you want a water tight roof.
Tesla also said that they are getting VC funding before the deal was finalized with Diamler. Tesla also said that they were getting this DOE funding, before that was finalized. Tesla also said the Roadster would be under $100k and meet various benchmarks like 0-60 times. The car was nearly $10K over, people that made deposits had to cough up the extra $10K, also if they wanted the options that they had selected, they had to cough-up more since the prices on all of the options packages increased, and the car has not met its performance benchmarks as well as there was the transmission bait and switch. Finally Tesla also claimed that they were building the Model S on a new platform of their own design when later it was learned after the Diamler deal that it likely would be an older platform of theirs. Actually most of these lies have been from Musk, high people from Tesla have resigned due to such repeated statements.
Because the money is going to a Nissan plant in TN that is being retrofitted to develop, manufacture, and test cutting edge batteries. Would you rather that the DOE does not provided to money on some idiotic jingoistic grounds only so that a future industry in and that portion of the economy is cornered in Japan?
1: GM never made a production version of the Impact (EV-1) since the CARB changed course mid stream and no longer required any zero emissions vehicles per automaker fleet.
2: They are using the money for plants. They have almost no money for actual development of the Model S. That money is likely being laundered via those plants at this point. Multiple times now Musk has made claims regarding funding that have proven to be false, like that they had already gotten approved for this program or the VC funds earlier. They are likely using the deposits on the Model S to build roadsters at this point.
3: There is no edit, but there is a preview.
Pajama Sam, Freddi Fish, and SPY Fox
Freddie Fish is actually a very good children's game, sort of an easy point and click adventure game. I assume the others are just as good. It is a shame they will be no more.
The amount of carbon produced by the cow in its lifetime plus decomposition after death is essentially the same as if the cow had never lived and all the corn and soy it would have eaten simply decomposed. The problem is that a cow produces not just carbon in one form, it tends to produce methane (the burps referred to) and methane has a much larger impact in global warming than CO2. The reason that the cows produce large amounts of methane is because the bacteria in their rumen (first stomach) is not right for the diets of mostly corn and soy that they are typically fed and this produces the methane burps. (Incidentally that is why there is relatively little methane in cow farts, almost all of the methane is produced in the rumen.)
So one option is to feed cows mostly grass, that is not sustainable in the large industrial scale used. Another option would be to genetically engineer bacteria that produces less methane and introduce it to the cow rumen. That actually makes more sense than engineering cows with a rumen more like a stomach. Another far fetched option would be to capture the methane, then sequester or burn it outright (the green house gases then are much less harmful).
If you have ever been near an industrial cattle or dairy farm, the stench is unimaginable. In a large cattle farm you can see the methane pockets causing the horizon to wiggle.
FTP also gets the line endings right too. A long time ago I had MPW and CW source code that three of us shared. I decided to get it into a in CVS repository on a solaris box after a couple of times we trampled over each other's changes. The code had mac line endings and the macs used for building were various machines with System 7 to 9. I diddled with all sorts of mac cvs clients all broken to various degrees until an older wiser programmer told me to use FTP. I installed Fetch (a mac ftp client) and what we did was just drag the source files files over that we had modified to a FreeBSD or Solaris box. The Solaris box was kerberized and the macs that were new enough used MIT kerberos for Mac to get to the solaris box directly, the FreeBSD box had some firewall rules to allow the old macs to ftp and used a chrooted ftpd. The solaris box nfs mounted those dirs from the FreeBSD box. Once we got the files onto the FreeBSD box or Solaris box we would ssh into the Solaris box and use cvs co, commit, update, etc. The reverse was well the reverse, first cvs update in your ws, then use Fetch to drag the files over to the mac. Sometimes you would grab more than you needed, but whatever. The beauty of this approach was that ftp automatically converted the line endings between unix and mac style so that the rcs diffs in the repository made sense and we could do all the cvs diff stuff from the Solaris box and only got the changes that actually were different. The other good aspect was that we always used a version of cvs client that was stable and well tested.
If you mean SMT as is in mutli processor, Sun copied that from other folks. If you actually mean HTT then Intel came-up with that years before the T1 from Sun. Though the T1 uses more of a CMT idea. HTT was pretty bad in the P4, but returns in Nehalem. It works in a different way than the Sun Niagara approach (only issues so many instructions per clock and from two threads to fill in pipeline bubbles) But with the pipeline much wider than on P4 it is much better and fairer. That said if both of your threads are saturating all of the AU say, you won't get a lick of better performance. The Niagara approach is different. It switches threads in certain situations (like waiting for a cache line to fill) but you can see the same kind of problem as on Intel's HTT when all your threads are doing a lot of FP.
The M30000 has DDR2-533 ECC RAM, can you see now that you were not compute bound (unless your dataset was less than 4MB or so)? Also it uses Fujitsu SPARC64 processors which typically have worse FP performance than UltraSparc IV+ even years later. The other thing is were you doing 32-bit or 64-bit FP? By using 32-bit FP and the SIMD features on AMD/Intel that can be a lot faster than 32-bit FP. Sparc FP went through a few revisions over the years. What you have now is 32 double precision registers, the first 16 of which you can use as two single precision each or use them as pairs for 8 quads. The upper 16 can only be used as doubles. Some of the single precision operations are SIMD like, that was very useful in sparcv8 and made some single precision faster than double precision. Almost every sparc out today does all FP in double precision and creates a single precision result if it needs to. That is why double is just as fast as float. The instructions handled by the FP unit are very rich. The ones for quad are almost as rich, but some trap. There is also VIS (a SIMD extension for sparc) but relative to FP all it had were some instructions to more speedily get values in and out of the FP registers. The VIS 3.0 in RK (just cancelled) was going to offer more in the way of FP.
For performance measurements. When Opteron came-out it was faster than the fastest UltraSparc at 32-bit FP, actually by a good margin. It was a tad slower at double and did not have a snowballs chance in hell with quad (but nobody uses that). Then with the UltraSparc IV and IV+ sparc was again faster at all FP. The T1 and T2 were not as fast at FP as USIV and USIV has stagnated (RK was expected so USV was canned). We now again see that for single precision Intel (incredible strides) and AMD are faster than UltraSparc and are on the doorstep with regards to double precision. But again the memory being used in modern Intel and AMD machines is faster than that used in current Sparc kit. The FP on Sparc is so fast that it is memory bound in more cases than Intel and AMD, certainly in HPC types of workloads.
Apple has a history of making ASICs. In fact the first intels were the first case of no Apple ASICs. The last example was the PHB chip on G5 systems, Apple designed, IBM fabbed. In fact they currently sell chips for iPod authentication fabbed in Taiwan. The rumors are that they are designing the SoC for a new line of small devices. Apple is very much in the hardware design game and positions continue to show-up on job listings.