Nothing else to the story? You didn't add flattering graffiti about her to the bathroom walls or show up drunk and belligerent to her parties? I don't believe that she just disappeared.
I really wish there was a moderation option for, "Incorrect."
Your statement is completely incorrect.
The ATA controller does not enable nor constrain the command set used by the operating system to communicate with the drive. You can, quite easily, use a 500 gig parralel ATA drive on a 486 with an ISA IDE interface. If you boot up a reasonably new Linux kernel, in fact, you will be able to address the entirety of the drive.
You might not be able to boot from said 486, but BIOS limitations are different and are not the fault of any hardware limitations.
Just to be clear, large IDE disks only need operating system support for LBA48, regardless of the IDE interface.
>If I need multi-monitor and/or multi-device hardware acceleration on anything other than an upper end SGI, like what I currently work on, I HAVE to use DirectX9/10 and Win32.
Why can't you use nvidia on linux with OpenGL? I do dual monitor (seperate X screens,:0.0 and:0.1) and it works well, running OpenGL on both monitors, simultaneously. I suspect I can do it with a single xinerama-style X screen too, but have not tried. Is this insufficient? Why?
DVD playback isn't cpu intensive. It's bound by, if nothing else, the frame rate of the movie you're decoding.
If you want an infinite workload, however, try using the program/usr/bin/yes
That's right, just open up a terminal and run yes
yes just generates an inifite stream of y's followed by a newline, it's meant to be piped into annoying programs that require confirmation for everything. However, when you're not piping it, it's just causing your terminal to scroll and your kernel to context switch regularily. It's also bound by your cpu, so you can easily max it out.
I have a Thinkpad T42p with aforementioned 1400x1050 display.
First thing I did upon receiving laptop was to nuke windows and the recovery partition, installed linux. Works like a champ.
At one point, for some contracting work, needed windows. Installed a regular OEM version using product-key found on bottom of laptop. I installed the regular ATI drivers from ATI. Selected the resolution 1400x1050 and had no problem, whatsoever.
I think you should elaborate on what exactly your problem is. Because, it would appear by your statement, that the problem is specific to the 1400x1050 models. Do you not have a problem with the 1600x1200 models?
Could you clarify what "DOES NOT WORK" means in regard to the retail copy of windows?
It's worse to give bad advice or inaccurate advice, than no advice at all.
Personally, I wouldn't buy laptops from anybody else. All my thinkpads have been rock solid.
I've been using solaris in some capacity since 2.5 or so. While I cut my teeth on SunOS 4.x on a sun 3/60, that's before I really spent more than 4 hours at a time on a regular basis in front of a Sun.
Does anyone at sun really use CDE or the java environment (or twm?) for their every day stuff? I grant that it may be simply be bad administrators who set up our machines or something else, but the default install set included with many editions of Solaris have been far from convenient to use. I know that solaris 9, 10, etc. do include a supplemental install CD with gnu software which, thankfully, our sysadmins have included on the kickstart installs.
Basically, my point is this, am I missing something important - suggesting that the default Solaris environment is very effective and useful OR do the people at Sun always customize their set up so radically that they rarely use the default system?
I really mean this seriously, as I keep finding myself replacing dtwm (throught the.dtsession or whatever) with fvwm or blackbox and installing my own xterm variant (color!) and need to configure my own termcap/terminfo entries in my home directory (color in vim! proper terminal handling in vim!) etc.
I know Sun isn't stupid, so what am I doing wrong?
It's always been 8 bits, except during the energy crisis when pushing electrons around got a lil more expensive, they used 7 bits for a while. Measure the size of a 2x4 some time.
1, How is supporting Mach and FreeBSD system calls an advantage? Apps should not be making direct system calls and instead invoke the appropriate c library wrapper. This doesn't seem like a feature, it sounds like a bad design decision. What was the reasoning by basing OSX on Mach in the first place? What is the justification for this excessive, per system call overhead?
How many Mach messages per second does my conventional UNIX benchmark at? None. It can't. Does this preclude me from doing anything I need to do? No.
2, The 4/4 memory split only applies to 32 bit environments. Haven't the G3/G4/G5 been 64 bit? I know the current Core Duo's are 32 bit, but the next generation are supposed to support AMD's x86-64 (called EM64T in Intel language.). There's no advantage to seperate virtual address spaces when you have 64 bit architectures. Even on 32bit architectures, a 2/2 or 3/1 split is only a problem if you have more than two or three gigabytes of physical ram or if your application wants to memory map more than two or three gigs of virtual address space. If you need to do that, then get an architecture that supports it. Most people still have less than 2 gigs of ram in their computers, why optimize for those that do when the computers people will be buying when four gigs of ram or more is common will already be 64 bit.
3, Are you suggesting that FreeBSD, Linux, Windows, or any other modern operating system doesn't use dynamic libraries? What is so special about OSX's dynamic loader that Benchmarks need to take it into account?
1, Agreed.
2, What? Please. Yes, there is an advantage to not using the buffer cache in some cases, something you can do in linux with the O_DIRECT filedescriptor flag, but in most cases, it's not worth the trouble. Bypassing the buffer cache spares you the cost of a copy, but if you ever need the block again, you are at a clear advantage if it could have been read out of the buffer cache.
3. Don't know anything about it, but it's quite possible.
You wouldn't need to display the clip while encoding it to take advantage of the graphics card. The whole gpgpu system, general purpose graphics processing, uses off screen rendering targets such as the OpenGL pixel buffer object or frame buffer object. It would be straightforward, with an OpenGL 2.0 compliant graphics card, to offload the colorspace transforms, fast/discrete fourier transforms, and a few other compute intensive algorithms.
But, you are right when you said its not normal. Hopefully, as OpenGL 2.0 becomes more ubiquitous, we'll see more useful offloading.
Microsoft - On campus interview about 1 hr straightforward questions, semi trivial programming problem to verify logical thinking. Fly out to redmond, four technical interviews, depends on interviewer. I had two difficult sessions, two easy ones. Most remarkable question, "Whats the third bit in an x86 page table entry?" my answer, "No idea, but it's in the third volume of the intel ia32 manuals." Had a whole interview of discrete math questions and problems. Despite length, very pleasant.
VMWare - Six 30 minute to 1 Hour interviews. First one had a "find the bugs in the code we emailed you." The rest were very unscripted chatting. Got the impression interviewers were forming their own general assessment of talent and competency. Asked about courses, projects. Asked questions regarding details. Was surprised by number of interviews, but otherwise pleasant. I think I stared interviewing with one group, then was switched to another group - hence the large number of interviews.
You know, not that I minded downloading 700 megs and watching the episode, you could've been kind enough to mention that the tits and ass only constituted almost 5 seconds of the episode.
I've always thought this was an interesting remark to make regarding "Jet Fuel":
Tthe SR-71 needed to use USAF JP-7 fuel. This is thicker, less flamable fuel that the SR-71 used because the the SR-71 gets quite hot during its extended supersonic flights, and the SR-71 was also somewhat leaky at lower temperatures. The JP-7 kerosene is so thick that a careless technician would flick a lit cigarette butt into a bucket of JP-7 without igniting it. In fact, it would extinguish the flame.
Source, Wikipedia article. Corroborated with a google search of "JP-7 cigarette"
ad 1: Compilers can improve easily, with a recompile. this remark I consider extremely naive and it really, really hurts your credibility.
Agreed. The point I was trying to make was that realizing the benefits of compiler improvements requires updating your software, not replacing the processor. Obviously, recompiling the same software isn't going to be an advantage.
B huh? Are you mixing up RISC and VLIW (EPIC) designs?
No, I'm not mixing them up. I was trying to compare their merits.
Essentially, I tried to reason a guess to the following question.
What would be the effect of removing the data-hazard protection from the chip and relying on the compiler to insert explicit noops? I surmise that a unpredicted branch will hurt more on IA64.
Then I babble on for too long about different features. Sorry.
Look at Itaniums performance on data dependent branches, it is underwhelming...
This is unfortunate; do you know what is limiting the chip here?
Itanium greatly (like: insanely) benefits from repeated compile-execute-profile iterations of the benchmark.
Where, generally, does the compile-and-execute profile work improve things? Does it use the profiling output to hint the processor's branch predictor?
Patterson and Hennesey, Computer Organization and Design - on the shelf, well worn and well read.
Truth be told, IA64 is a fantastically better architecture than IA32 or x86-64. Some of it's current caveats, for example, suboptimal software support and high costs, are not due to it's technical qualifications or drawbacks. Once the architecture reaches a critical mass and reasonable market acceptance, these issues should disappear. (more chips -> more people will target software for it, more chips produced in volume -> less cost per chip, etc.)
It's other caveats, for example, poor compiler support, are issues that need to be considered carefully. I'd like to specifically address the poor compiler support. I am not concerned about this issue for the following reasons:
1. Compilers can improve easily, with a recompile. If the architecture achieves a critical mass, then more people and organizations will justify the time and effort to improve compilers on the architecture. Not only can they improve, but taking advantage of such improvements would not require replacing hardware, which makes it an issue of time.
2. The architecture is much more realistic about the guarantees that it's willing to make as a processor. One of the early complaints, was that initial generation of compilers for IA64 would generate, on average, 40% NOPs. It's important to consider a few details when regarding that statement.
A. First, each clock cycle could allow the execution of up to 3 concurrent operations.
B. Second, the architecture is not inserting extra NOPs transparently into the pipeline, as almost all modern processors do in the event of a pipeline data hazard. This fact can be viewed different ways.
i. Most modern processors have to evaluate wether to insert a pipeline stall every single time that an instruction is executed. This is, essentially, wasted work because such a computation could be done by the assembler, however, it does spare the processor the burden of loading useless NOPs into the pipeline and the cache. On the other hand, minimizing the logic that a processor has to complete per cycle generally decreases the minimum amount of time necessary per clock (meaning that it could scale to higher clock speeds.)
ii. The immediate question is, does reading all these NOPs out of memory cause a bigger hit to performance, than making the processor calculate the data hazards? Personally, I don't know. But, let's consider the idea for a moment. On both processors, let's assume that the instruction cache is fast enough to deliver data without wait states, assuming the cache has the data. When your processor is prefetching well, then the NOP issue shouldn't be a big issue. (Except for the fact that the NOPs will now be in the binary, making the binaries larger. I consider this a moot point given the inexpense of modern storage.) When your prefetcher can't anticipate correctly, though, I think the IA64 loses. Both IA64 and other modern architectures have branch predictors, so I suspect unanticipated branches which cause a pipeline flush (unavoidable) and unanticipated cache fills (unavoidable) will be mitigated roughly equally, But because the IA64 has longer instructions that aren't quite as dense, the IA64 will stall longer. Btw, I'm ignoring data stalls, to simplify my argument and because I don't think the architectural differences in the IA64 will significantly impact it. I'd enjoy being corrected on this point.
The IA64 includes a predicate register, which stores the results of comparison instructions. Instructions in an IA64 'bundle' can be qualified to be executed conditionally, based on the condition of a certain bit in the predicate register. This allows the IA64 to avoid some branches. The compiler/assembler can pack a bundle which includes the appropriate two instructions, each qualified to execute for different states of the predicate register. Essentially, the processor is simultaneously issued the commands for both p
Huh. That's really strange, my T42p, with the 1.8 ghz Pentium-M only even seems to ever even turn ON the fan when I do a kernel compile. For just about everything, however, it's damn near silent. Maybe you should have IBM service your laptop?
I saw and worked on this a bit while interning at Microsoft. Although what I say is my own and doesn't reflect Microsoft in any way, it's important to remember that this is a research operating system, so its not challenging or replacing Windows. They have some very good, solid ideas. I hope that, someday, it will be released.
Slashdot Mirror
Nothing else to the story? You didn't add flattering graffiti about her to the bathroom walls or show up drunk and belligerent to her parties? I don't believe that she just disappeared.
U of M's Michigan Radio or WCMU from Central?
I really wish there was a moderation option for, "Incorrect."
Your statement is completely incorrect.
The ATA controller does not enable nor constrain the command set used by the operating system to communicate with the drive. You can, quite easily, use a 500 gig parralel ATA drive on a 486 with an ISA IDE interface. If you boot up a reasonably new Linux kernel, in fact, you will be able to address the entirety of the drive.
You might not be able to boot from said 486, but BIOS limitations are different and are not the fault of any hardware limitations.
Just to be clear, large IDE disks only need operating system support for LBA48, regardless of the IDE interface.
>If I need multi-monitor and/or multi-device hardware acceleration on anything other than an upper end SGI, like what I currently work on, I HAVE to use DirectX9/10 and Win32.
:0.0 and :0.1) and it works well, running OpenGL on both monitors, simultaneously. I suspect I can do it with a single xinerama-style X screen too, but have not tried. Is this insufficient? Why?
Why can't you use nvidia on linux with OpenGL? I do dual monitor (seperate X screens,
DVD playback isn't cpu intensive. It's bound by, if nothing else, the frame rate of the movie you're decoding.
/usr/bin/yes
If you want an infinite workload, however, try using the program
That's right, just open up a terminal and run yes
yes just generates an inifite stream of y's followed by a newline, it's meant to be piped into annoying programs that require confirmation for everything. However, when you're not piping it, it's just causing your terminal to scroll and your kernel to context switch regularily. It's also bound by your cpu, so you can easily max it out.
>> I know I'm coming off as rude
> No, you're coming off as a complete dick.
We need a +1, "Situation appropriate smack-down."
Uhh, not sure what you're talking about.
I have a Thinkpad T42p with aforementioned 1400x1050 display.
First thing I did upon receiving laptop was to nuke windows and the recovery partition, installed linux. Works like a champ.
At one point, for some contracting work, needed windows. Installed a regular OEM version using product-key found on bottom of laptop. I installed the regular ATI drivers from ATI. Selected the resolution 1400x1050 and had no problem, whatsoever.
I think you should elaborate on what exactly your problem is. Because, it would appear by your statement, that the problem is specific to the 1400x1050 models. Do you not have a problem with the 1600x1200 models?
Could you clarify what "DOES NOT WORK" means in regard to the retail copy of windows?
It's worse to give bad advice or inaccurate advice, than no advice at all.
Personally, I wouldn't buy laptops from anybody else. All my thinkpads have been rock solid.
Serious but offtopic question:
.dtsession or whatever) with fvwm or blackbox and installing my own xterm variant (color!) and need to configure my own termcap/terminfo entries in my home directory (color in vim! proper terminal handling in vim!) etc.
I've been using solaris in some capacity since 2.5 or so. While I cut my teeth on SunOS 4.x on a sun 3/60, that's before I really spent more than 4 hours at a time on a regular basis in front of a Sun.
Does anyone at sun really use CDE or the java environment (or twm?) for their every day stuff? I grant that it may be simply be bad administrators who set up our machines or something else, but the default install set included with many editions of Solaris have been far from convenient to use. I know that solaris 9, 10, etc. do include a supplemental install CD with gnu software which, thankfully, our sysadmins have included on the kickstart installs.
Basically, my point is this, am I missing something important - suggesting that the default Solaris environment is very effective and useful OR do the people at Sun always customize their set up so radically that they rarely use the default system?
I really mean this seriously, as I keep finding myself replacing dtwm (throught the
I know Sun isn't stupid, so what am I doing wrong?
Whats your desktop setup?
It's always been 8 bits, except during the energy crisis when pushing electrons around got a lil more expensive, they used 7 bits for a while. Measure the size of a 2x4 some time.
1, How is supporting Mach and FreeBSD system calls an advantage? Apps should not be making direct system calls and instead invoke the appropriate c library wrapper. This doesn't seem like a feature, it sounds like a bad design decision. What was the reasoning by basing OSX on Mach in the first place? What is the justification for this excessive, per system call overhead?
How many Mach messages per second does my conventional UNIX benchmark at? None. It can't. Does this preclude me from doing anything I need to do? No.
2, The 4/4 memory split only applies to 32 bit environments. Haven't the G3/G4/G5 been 64 bit? I know the current Core Duo's are 32 bit, but the next generation are supposed to support AMD's x86-64 (called EM64T in Intel language.). There's no advantage to seperate virtual address spaces when you have 64 bit architectures. Even on 32bit architectures, a 2/2 or 3/1 split is only a problem if you have more than two or three gigabytes of physical ram or if your application wants to memory map more than two or three gigs of virtual address space. If you need to do that, then get an architecture that supports it. Most people still have less than 2 gigs of ram in their computers, why optimize for those that do when the computers people will be buying when four gigs of ram or more is common will already be 64 bit.
3, Are you suggesting that FreeBSD, Linux, Windows, or any other modern operating system doesn't use dynamic libraries? What is so special about OSX's dynamic loader that Benchmarks need to take it into account?
1, Agreed.
2, What? Please. Yes, there is an advantage to not using the buffer cache in some cases, something you can do in linux with the O_DIRECT filedescriptor flag, but in most cases, it's not worth the trouble. Bypassing the buffer cache spares you the cost of a copy, but if you ever need the block again, you are at a clear advantage if it could have been read out of the buffer cache.
3. Don't know anything about it, but it's quite possible.
You wouldn't need to display the clip while encoding it to take advantage of the graphics card. The whole gpgpu system, general purpose graphics processing, uses off screen rendering targets such as the OpenGL pixel buffer object or frame buffer object. It would be straightforward, with an OpenGL 2.0 compliant graphics card, to offload the colorspace transforms, fast/discrete fourier transforms, and a few other compute intensive algorithms.
But, you are right when you said its not normal. Hopefully, as OpenGL 2.0 becomes more ubiquitous, we'll see more useful offloading.
You're just jealous. At least he has a girlfriend.
Microsoft - On campus interview about 1 hr straightforward questions, semi trivial programming problem to verify logical thinking. Fly out to redmond, four technical interviews, depends on interviewer. I had two difficult sessions, two easy ones. Most remarkable question, "Whats the third bit in an x86 page table entry?" my answer, "No idea, but it's in the third volume of the intel ia32 manuals." Had a whole interview of discrete math questions and problems. Despite length, very pleasant.
VMWare - Six 30 minute to 1 Hour interviews. First one had a "find the bugs in the code we emailed you." The rest were very unscripted chatting. Got the impression interviewers were forming their own general assessment of talent and competency. Asked about courses, projects. Asked questions regarding details. Was surprised by number of interviews, but otherwise pleasant. I think I stared interviewing with one group, then was switched to another group - hence the large number of interviews.
I love the smell of Napalm in the morning.
You know, not that I minded downloading 700 megs and watching the episode, you could've been kind enough to mention that the tits and ass only constituted almost 5 seconds of the episode.
there are myriad of complicated structures (ie LLCs, FLPs, trusts, promissory notes) that require incredibly intense accounting.
I have a new purpose in life, I will direct all my efforts to becoming an extreme, hardcore accountant.
Bring it on.
Getting raw ethernet frames, in Linux, is trivial. For example, to get such a socket from python: (copied from the scapy startup routines)
self.ins = socket.socket(socket.AF_PACKET, socket.SOCK_RAW, socket.htons(ETH_P_ALL))
Whats that? You want to only get the traffic from a certain ethernet card, or want to transmit out a certain card? Easy. (In C, from my own code.)
struct sockaddr_ll device_sa;
int filedes;
filedes = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
device_sa.sll_family = AF_PACKET;
device_sa.sll_protocol = htons(ETH_P_ALL);
device_sa.sll_ifindex = ifindex;
bind(filedes, (struct sockaddr *)&device_sa, sizeof(device_sa));
You can get a device's ifindex with the SIOCGIFINDEX call, or with the rtnetlink RTM_GETLINK request.
All you need for this is root, or suid root. In fact, I think you can just use CAP_RAW and CAP_NET_ADMIN, I believe.
I've always thought this was an interesting remark to make regarding "Jet Fuel":
Tthe SR-71 needed to use USAF JP-7 fuel. This is thicker, less flamable fuel that the SR-71 used because the the SR-71 gets quite hot during its extended supersonic flights, and the SR-71 was also somewhat leaky at lower temperatures. The JP-7 kerosene is so thick that a careless technician would flick a lit cigarette butt into a bucket of JP-7 without igniting it. In fact, it would extinguish the flame.
Source, Wikipedia article. Corroborated with a google search of "JP-7 cigarette"
ad 1: Compilers can improve easily, with a recompile. this remark I consider extremely naive and it really, really hurts your credibility.
Agreed. The point I was trying to make was that realizing the benefits of compiler improvements requires updating your software, not replacing the processor. Obviously, recompiling the same software isn't going to be an advantage.
B huh? Are you mixing up RISC and VLIW (EPIC) designs?
No, I'm not mixing them up. I was trying to compare their merits.
Essentially, I tried to reason a guess to the following question.
What would be the effect of removing the data-hazard protection from the chip and relying on the compiler to insert explicit noops? I surmise that a unpredicted branch will hurt more on IA64.
Then I babble on for too long about different features. Sorry.
Look at Itaniums performance on data dependent branches, it is underwhelming...
This is unfortunate; do you know what is limiting the chip here?
Itanium greatly (like: insanely) benefits from repeated compile-execute-profile iterations of the benchmark.
Where, generally, does the compile-and-execute profile work improve things? Does it use the profiling output to hint the processor's branch predictor?
Patterson and Hennesey, Computer Organization and Design - on the shelf, well worn and well read.
I'll check out the others at the library.
Truth be told, IA64 is a fantastically better architecture than IA32 or x86-64. Some of it's current caveats, for example, suboptimal software support and high costs, are not due to it's technical qualifications or drawbacks. Once the architecture reaches a critical mass and reasonable market acceptance, these issues should disappear. (more chips -> more people will target software for it, more chips produced in volume -> less cost per chip, etc.)
It's other caveats, for example, poor compiler support, are issues that need to be considered carefully. I'd like to specifically address the poor compiler support. I am not concerned about this issue for the following reasons:
1. Compilers can improve easily, with a recompile. If the architecture achieves a critical mass, then more people and organizations will justify the time and effort to improve compilers on the architecture. Not only can they improve, but taking advantage of such improvements would not require replacing hardware, which makes it an issue of time.
2. The architecture is much more realistic about the guarantees that it's willing to make as a processor. One of the early complaints, was that initial generation of compilers for IA64 would generate, on average, 40% NOPs. It's important to consider a few details when regarding that statement.
A. First, each clock cycle could allow the execution of up to 3 concurrent operations.
B. Second, the architecture is not inserting extra NOPs transparently into the pipeline, as almost all modern processors do in the event of a pipeline data hazard. This fact can be viewed different ways.
i. Most modern processors have to evaluate wether to insert a pipeline stall every single time that an instruction is executed. This is, essentially, wasted work because such a computation could be done by the assembler, however, it does spare the processor the burden of loading useless NOPs into the pipeline and the cache. On the other hand, minimizing the logic that a processor has to complete per cycle generally decreases the minimum amount of time necessary per clock (meaning that it could scale to higher clock speeds.)
ii. The immediate question is, does reading all these NOPs out of memory cause a bigger hit to performance, than making the processor calculate the data hazards? Personally, I don't know. But, let's consider the idea for a moment. On both processors, let's assume that the instruction cache is fast enough to deliver data without wait states, assuming the cache has the data. When your processor is prefetching well, then the NOP issue shouldn't be a big issue. (Except for the fact that the NOPs will now be in the binary, making the binaries larger. I consider this a moot point given the inexpense of modern storage.) When your prefetcher can't anticipate correctly, though, I think the IA64 loses. Both IA64 and other modern architectures have branch predictors, so I suspect unanticipated branches which cause a pipeline flush (unavoidable) and unanticipated cache fills (unavoidable) will be mitigated roughly equally, But because the IA64 has longer instructions that aren't quite as dense, the IA64 will stall longer. Btw, I'm ignoring data stalls, to simplify my argument and because I don't think the architectural differences in the IA64 will significantly impact it. I'd enjoy being corrected on this point.
The IA64 includes a predicate register, which stores the results of comparison instructions. Instructions in an IA64 'bundle' can be qualified to be executed conditionally, based on the condition of a certain bit in the predicate register. This allows the IA64 to avoid some branches. The compiler/assembler can pack a bundle which includes the appropriate two instructions, each qualified to execute for different states of the predicate register. Essentially, the processor is simultaneously issued the commands for both p
Huh. That's really strange, my T42p, with the 1.8 ghz Pentium-M only even seems to ever even turn ON the fan when I do a kernel compile. For just about everything, however, it's damn near silent. Maybe you should have IBM service your laptop?
Actually, you can boot DOS boot disk images from GRUB using memdisk!
/path/to/memdisk /path/to/bootdisk.image
/mbr and get rid of that pesky grub MBR.
memdisk is a part of the syslinux package. You can write a rule for it in the grub config, or bootstrap it from the command line. Just use
root [insert drive,partition here]
kernel
initrd
boot
and voila! now he can fdisk
Another option, is boot up into linux and execute:
dd if=/dev/zero of=/dev/[insert harddrive here] bs=512 count=1
it should do a fine job of nuking your MBR and partition table.
I saw and worked on this a bit while interning at Microsoft. Although what I say is my own and doesn't reflect Microsoft in any way, it's important to remember that this is a research operating system, so its not challenging or replacing Windows. They have some very good, solid ideas. I hope that, someday, it will be released.
Err, I mean, should I feel bad about it. Apologies. I suffered through using Sun3's for a while too.
Should I feel that my linksys router can do more MIPS and has more RAM than your Sun 3/60? :)