I know I'm tempting moderator retribution but let me summarize some of what I see above:
The contractor owns everything; customer gets license to a binary
The contractor owns everything; customer gets license to binaries and the source code under some circumstances (such as contractor unavailability)
The contractor owns everything; customer gets license to use and modify binary or source for any internal purpose
The contractor owns everything; customer gets an unlimited but non-exclusive rights to binary or source.
The contractor owns everything, but agrees on limitations on reuse or redistribution; customer gets some license from above
The contractor owns nothing; it's a work for hire, since the customer contracted for the work rather than a service
The contractor owns nothing, but the customer grants certain rights to the contractor, such as limited reuse of modules.
Ownership is mixed, with some parts retained by either sides.
It sounds like what you need to do is agree with your customer what their expectation is on licensing, and get that in the contract. For example, if you own the work but agree not to disclose certain modules dealing with business process, it's clear to both sides what you can and can not disclose later. That may mean reuse on other contracts, provision to their competitors, or release to the general public.
In general, the more restrictive the customer rights to work performed, the higher the rates.
Probably because agendacomputing.com is a ghost site, not actually belonging to a functioning US company.
For you Boy Scouts out there: Please don't go pestering the web hosting company. There's useful stuff around in various staff member home directories. I think it's all been mirrored now, but still.
If you bring down the site, I will personally stand outside your house with a megaphone, and appropriate gesutures, shouting:
For many years, IBM was the performance, feature, and credibility leader in the IDE market. I regularly paid significant price premiums for their drives, and wouldn't recommend any other drive brand for machines that I cared about working. Sometimes they got overtaken on capacity, but my view was that the extra 20% of drive space wasn't useful if the drive was slow or died after a year.
Then, IBM's reputation got hurt; you all know that story by now. Of course, this happened after most of the IDE machines I run ended up with IBM drives in them.:-( I'm no longer willing to pay $50-100 extra for that IBM brand name. In fact, I don't know if discounting the IBM drives would convince me to buy them at this point.
I just wish IBM had fixed their quality problems, and without looking like they were covering something up. The "you are only allowed 333 hours of uptime per month" hack didn't help them at all.
I'd like to go back to the days when I could say "buy IBM brand drives or lose". Now I don't know what to buy or recommend. This sucks.
What about Solaris x86 as well? I only see IE availble for Solaris SPARC.
Why are you running Solaris x86 on a machine that's perfectly capable of running Windows?
I think that's some of the reasoning behind not porting IE to Linux. Obviously, most of the compatibility layer for Unix is already done, but why encourage people to use an different OS on the hardware you 0wn?
IE 5 and OE 5 for Solaris are quite good. But AFAICT they were written to convince large organizations who already have a pile of Solaris/HPUX client boxes that it's safe to switch all their servers to IIS and start using features that are only supported in IE. Of course, how long the customers actually keep the Unix boxes after that, who knows. Must suck to be on that team, knowing that the most important thing you provide to Microsoft is a feature checkbox in the brochure....
I'm experimentally running Debian/SPARC woody on my Ultra 10 at work. Now that I have Evolution and a choice of konq and galeon, I'm mostly happy. But when I have to boot back into Solaris you can bet I'm going to be using IE5 and OE5 again.
First, a good way to map Ctrl next to A, like God intended it. (Until today, I didn't know about this completely undocumented bit of black magic.)
Next, remove the goddamn video resolution lock on the consumer hardware. I've got an iMac here stuck sending 1024x768@75 video out the VGA port. The video hardware can do much better, but there's no way of saying "turn off the builtin display". iBooks are similarly crippled; PC laptops aren't.
Think very hard about adding a second trackpad button on the laptops. I can easily replace the USB mouse on a desktop box to get a second button, but there's no way to upgrade the trackpad without a bandsaw. Support for context menus in OS X is soooo nice; why make it harder for laptop users to take advantage of it on the go? (Yes, I know you can use modifier keys to get the same effect, but it's not the same.)
Make a really fast web browser. This Celeron 450 seems much faster than the iMac 450 for browsing; similarly with 800MHz machines at work.
Give me the source to Mail.app, so I can add support for certificates. It's not like your competition is going to steal anything useful out of that excellent, Cocoa-centric app.
Pay Valve Software to port the Half-Life engine to OS X. Geez, if the Mac doesn't run Counter-Strike, how are we going to AWP all the Windows weenies?
I was daydreaming in a meeting the other day. Somehow, the complaints about the length of the show and the finger-pointing sermon collided. So I had this vision:
Rosen and Valenti's corporate masters suggest that because it's a music show, next year's rant should be a musical number. They've even got the rights lined up for the appropriate song, with a few modifications.
A band launches into the Squirrel Nut Zippers song
"Hell"; the two mouthpieces bound onto stage, dressed in tuxes, carrying canes. They sing:
(Cue swing/calypso music)
Hell Innnn the afterlife
You could be headed for the serious strife
Now you make the scene all day
But tomorrow there'll be hell to pay [...]
Oh, the D and the M and the C and the A,
And the S and the S and the S-C-A Lose your net, lose your games
Then get fitted for a suit of flames!
(The committee in charge of coming up with this was delighted by how little they had to change, but they couldn't quite figure out how to change "suit" to "lawsuit" and still have it sound right.)
No. I don't think you understand. We *REALLY* hate the DMCA.
So if you think you have been wronged, feel free to send out your lawyers. Just do NOT invoke the DMCA, or you are going to have a lot of your potential early adopters start spitting when they see your corporate logo.
I don't care what a particular implementation of RPM will install. The implementation is not standardized. I care about the format. Let me demonstrate to you that v4 RPMs exist:
nop@family-values:/tmp$ od -t x1 ash-0.3.7-2.i386.rpm | head -1
0000000 ed ab ee db 04 00 00 00 00 01 61 73 68 2d 30 2e
You will note the "04 00" after the magic number. Is this accusation still unjustified?
The place I first saw these in the wild was source RPMs. In several cases, I've gotten SRPMs that I could not extract due to version mismatches. (Extraction of SRPMs is not a LSB issue, however.)
I'm not complaining that Red Hat was not a good player in the LSB standardization process; I've no reason to think otherwise. I'm complaining about the attitude that "interoperability with Red Hat" is an important goal for Debian or other distros. It's more important to interop via standards, not testing against a perceived market leader.
Note that the LSB specifies the version of the RPM file format in the book Maximum RPM. That's version 3. Let me repeat that; the LSB standard RPM package format is version 3. So now that RH is shipping v4 RPMs, a lot of other people are too, and those packages are simply not compliant with the LSB.
More broadly, the LSB did not intend to give RedHat the power to define standard Linux. You shouldn't let RedHat define the standard either.
After thinking about this a little, I realized that you actually need two pages; on MIPS, a load instruction won't complete if there aren't TLB entries for both the instruction and its target. I really need to instrument the kernel TLB code; I have this suspicion that part of why snow is such a faster ABI is that it gets rid of the GOT pages, which are inherently quite "hot".
Yeah, the VR3 is a fun lab for exploring the pressures on embedded Linux devices. For instance, 8M is not quite enough memory for the software that people want to run on the device. So we want to cut down memory usage, but before we can do that, we have to understand what exactly memory usage is.
That's a difficult issue. Take a program that has no heap/stack usage. How much memory does it use while running?
One 4k page, containing either the current instruction, or the target address the current instruction is loading. All the other pages can be dropped by the kernel VM system, and demand-loaded back in when needed. Plus whatever kernel overhead there is to support the task and memory maps.
OK, clearly that's not a useful answer. Any real app that's really eating only one page is thrashing so hard that it won't get anything useful done in a timely manner. But it does get you thinking about what the nature of memory usage is, and possible ways to reduce it.
eXecute In Place support is one strategy. When you build VR3 compressed rom images, you can flag some files as sticky. Through the magic of VM, those uncompressed files are mapped directly into processes, and their code really does run from ROM---no copy in RAM needed. But VR3 ROM is slower than RAM, and you use up more ROM space this way. VR3 hackers have spent a lot of time exploring the tradeoffs here. But there are plenty of other strategies, and some that go deeper into the build process.
For instance, it would be nice if each code page had as much useful stuff on it as possible. If you have a short "hot" function, a long bunch of rare exception handling, and then another short "hot" function, you have to keep the exception handling code paged in even though you're not using it much. It would be better to reorder the hot functions so that they share a page.
You can do some of this with gprof's function reordering profiles and some linker scripts, but I haven't gotten around to trying this on the VR3. I think that some of the approaches to small-device tailoring do require the deep, system-wide approaches the parent article describes.
No, it isn't all GPL; a lot of it is covered by the LGPL and X11 licenses.:-)
Seriously, we have the source to every bit on the device. And I mean Open Source. It did take some effort to get the X11 sources, and source for the PMON boot loader, but we have them all. I know this because Brian Webb, who isn't an Agenda employee, rebuilt everything from source to support my snow ABI, which is not binary compatible---if it wasn't rebuilt, it wouldn't work!
We're still working on automating the rebuild. Right now, doing this rebuild is a manual process, but I think we're a few weeks away from having a big "make World" that will spit out a cross compiler and then a romdisk image.
Now, if you're fretting about PDAs with components that aren't Open Source, go check out the Zaurus. Its Java implementation is proprietary. (If you want to write apps for it, they have to be GPL'd unless you're a Troll licensee; I guess some people see that as a positive thing.)
and the device was expensive
$250 always seemed a touch high to me. I think there's a Linux PDA niche somewhere below the iPaqs, competing directly with low-end Palm devices. LinuxDA is a little too low end for my taste; I want virtual memory. I would think that had Agenda's parent company not stumbled, pricing on the VR3 would have come down.
I don't remember an NDA on their developer pages.
(I wish people would stop moderating articles with "overrated/underrated" just to avoid metamod; the parent is at score 3 with no moderation reason. And the parent msg is substantially incorrect.)
I'm always looking for more data on the relative performance of systems. For almost all of us, the quality of compiler-generated code is an inseparable part of system performance. If you have a processor that looks really fast but no compiler can produce good code for it, you'll have better performance if you use a "slower" machine that compilers do support well.
The best performance measure is running your code on a variety of systems. Because most people can't do that, it may make sense to look for standard benchmarks that look like your code, and then make analogies based on the similarities of those loads to what you want to do. It's critical to pick the right benchmarks to have a good analogy; if you're interested in 3d performance, it doesn't make sense to make performance comparisons based on the number of rc5 keys per second.
Unfortunately, the Open Magazine article doesn't give any information on what exactly their tests are doing. So it's not possible for you to figure out which, if any, of their tests will be analogous to your code.:-(
As I've mentioned before, I'm mostly interested in integer performance. From what I've read about the Intel C compiler, its strength is floating point. If I did a lot of FP work, I'd be sending Intel a credit card number about now, and I imagine many FP people will.
But for integer work, I think it's not so clear. Andreas Jaeger has a nice page benchmarking versions of GCC. On Athlon processors, SPEC CPU2000CINT2000 base looks like it's around 10% faster when built with the Intel C compiler than with GCC 3.0.1. I think I can live with that.
It's a lot easier to modify gcc than icc too, and yes, I really do hack on gcc from time to time.
What a great time to read this. Now, for the second day in a row, I have a huge headache at the end of the day from using KDE antialiasing.
This was on a 1024x768 laptop display, with subpixel rendering correctly configured.
All sizes antialiased. Hey, it workes on the Mac, and I really do want to know if antialiasing is better for me for the majority of text I work with. With subpixel rendering, it seems plausible...
So why did I put up with this headache for a *second* day? Because I seem to be unusually sensitive to changes in text display. When I switched from a Diamond Stealth 64 VRAM (968) to a Matrox Millenium, I got this same headache for like four days, even though I was running the same monitor, same resolution, same refresh rate, and same fonts. IIRC, it even had the same TI ramdac! But the Millenium had higher quality analog circuitry after the ramdac, and had sharper edges. After I got used to it, it was much nicer.
It may not be sharpness. If I get stuck in an environment where I have to spend a lot of time reading fonts I'm not used to, I get this kind of headache for a while too.
So now, the question is, do I care enough to try another day using the Xft setup? Will it be worth it? Who knows, but I'm gonna go have a beer and go nowhere near a display for about 12 hours....
Yeah, but what if he wants to use the gameport to play games?
The gameport outputs are not used by conventional Apple II joysticks. We do need to steal a pushbutton, but standard joysticks only have two buttons, so PB2 is free. So you could build a passthrough connector that would allow standard joysticks to continue to work.
The only problem I see is the shift key mod. Because the original Apple keyboards didn't support lower case, it was common for users to run a wire from the shift key to PB2 to let software interpret upper and lower case.
The 6502 has to do bit banging to talk to serial devices such as MMC. I would be impressed if anyone can get more than 30K/sec this way. IDE/CF on the other hand can be read a byte at a time.
Yeah, if you talk to SPI devices through something like the game port you're stuck with relatively slow rates. But if you're going to the trouble of building an expansion card for IDE, you could build an expansion card for SPI.
I'm guessing the easiest thing to do is build a small FPGA that lives on the 6502 bus that has a shift register and a one-shot 8-clock SPI clock generator. (FPGA clocked from the pin 36 7MHz signal?) I'm already way past my knowledge of design, but it seems like this would be very easy to build, and should deliver bytes as fast as the 6502 could digest them---reading from a slot address takes 4 cycles, and writing somewhere takes at least 4 more. Likely this kind of system would end up blocking on the flash device itself some of the time.
Anyway, I think it's possible you could have a two chip design: FPGA and level shifter. Amazing what might be possible with just a few chips these days!
Serial interfaces are especially nice on the Apple because you don't have to build an expansion card to talk to them---you can use the game port. There are four outputs and three inputs there. You'd need a level shifter to get the voltages down to the 3.3v range those flash cards want.
I just wrote out a little 6502 assembly bitbanger to talk to a purported SPI device on an Apple game port, and it looks like it's around 40 cycles per bit. So that's around 3kBytes/sec, raw. Not too bad for a 1 chip interface that doesn't take up a slot!
I don't remember if the analog electronics on the gameport inputs let you pump bits that fast. But it sure would be cool to have a single module plugged into the gameport, with 64M of storage---on a package smaller than the 6502.
Re:You're going to be waiting a while...
on
New iMac Announced
·
· Score: 2
ppc is about 30% "better"
at the same
frequency than x86
I'm aware that different processor architectures perform differently at the same clock speed, but I'd like to see some hard numbers on this. People repeat the 30% and "one third" numbers a lot, and I'd like to know where they come from
Does this mean that popular benchmarks are 30% faster at the same clock, or does this mean that Photoshop and a select few other flashy products perform 30% better?
Well, I did a
benchmark last summer, although it's hardly popular.
See also the
slashdot story and John Carmack's
post (cheap appeal-to-authority).
The most favorable
interpretation is that, for the load in question,
the G4/533 is roughly 21% faster than you might
expect a P3/533 to be.
I've slowly been putting together another round
of tests with more recent kernels; add another 10%
or so for improvements there. So 30% is the
rule of thumb I used to use.
The OS X SPECint numbers I have imply a smaller
clock-for-clock performance ratio, so I'm back to
using 20% as my rule of thumb.
Keep in mind that I'm not that interested
in floating point performance, and I have made
no attempt to quantify it. As always, the best
performance measurements are those made on
the workloads you actually use.
(Snide remark: and if all you bought your
computer for was to run SETI units, then
that's a useful cross-platform comparison.:-)
versions for Linux, Solaris etc. which come WITHOUT AN INSTALLER - i.e. you just un-tar/zip them and get some.jar files you can run (and if you're lucky a shell script to do it for you) - no Windows or spyware nonsense at all.
Right, and when I run those jar files, they extract a bunch of Windows DLLs. So yes, the independent spyware installers don't come with this, but Windows-specific components do.
I don't know what those DLLs do. Of course, I don't know what the Java code does either....
No, running the packaged Linux version of limewire on Windows still gets you Windows components. I just tried this and it extracted a "CBanner2.dll" and "LimeWire20.dll" into the install directory. So maybe you're not getting all the stuff packaged into the standard PC install, but there's still a bunch of wacky code there. Maybe it's time to go find a *truly* weird architecture. Bet there's no spyware for the OS/400 JVM...
[...] one of the bundled software installers included with LimeWire 2.0.2 for the PC is now considered a SpyWare/Trojan by various anti-virus software packages. We have received complaints from our users and we have worked quickly to resolve this issue by putting out a new beta immediately yesterday[...]
So the question is, did they remove the SpyWare/Trojan, or did they just hide it better?
I'm really surprised that linux wasn't mentioned a single time in this article,...
Willard said the company's exit from the commodity NT server business was a good one. Its current strategy, to focus on its proprietary, high-end systems running Irix, its version of the Unix operating system and Linux, makes sense.
Slashdot Mirror
- The contractor owns everything; customer gets license to a binary
- The contractor owns everything; customer gets license to binaries and the source code under some circumstances (such as contractor unavailability)
- The contractor owns everything; customer gets license to use and modify binary or source for any internal purpose
- The contractor owns everything; customer gets an unlimited but non-exclusive rights to binary or source.
- The contractor owns everything, but agrees on limitations on reuse or redistribution; customer gets some license from above
- The contractor owns nothing; it's a work for hire, since the customer contracted for the work rather than a service
- The contractor owns nothing, but the customer grants certain rights to the contractor, such as limited reuse of modules.
- Ownership is mixed, with some parts retained by either sides.
It sounds like what you need to do is agree with your customer what their expectation is on licensing, and get that in the contract. For example, if you own the work but agree not to disclose certain modules dealing with business process, it's clear to both sides what you can and can not disclose later. That may mean reuse on other contracts, provision to their competitors, or release to the general public.In general, the more restrictive the customer rights to work performed, the higher the rates.
For you Boy Scouts out there: Please don't go pestering the web hosting company. There's useful stuff around in various staff member home directories. I think it's all been mirrored now, but still.
If you bring down the site, I will personally stand outside your house with a megaphone, and appropriate gesutures, shouting:
Duh, yes, I should have rewritten the title after I rethought what I was saying. I agree with what you wrote.
Then, IBM's reputation got hurt; you all know that story by now. Of course, this happened after most of the IDE machines I run ended up with IBM drives in them. :-( I'm no longer willing to pay $50-100 extra for that IBM brand name. In fact, I don't know if discounting the IBM drives would convince me to buy them at this point.
I just wish IBM had fixed their quality problems, and without looking like they were covering something up. The "you are only allowed 333 hours of uptime per month" hack didn't help them at all.
I'd like to go back to the days when I could say "buy IBM brand drives or lose". Now I don't know what to buy or recommend. This sucks.
Why are you running Solaris x86 on a machine that's perfectly capable of running Windows?
I think that's some of the reasoning behind not porting IE to Linux. Obviously, most of the compatibility layer for Unix is already done, but why encourage people to use an different OS on the hardware you 0wn?
IE 5 and OE 5 for Solaris are quite good. But AFAICT they were written to convince large organizations who already have a pile of Solaris/HPUX client boxes that it's safe to switch all their servers to IIS and start using features that are only supported in IE. Of course, how long the customers actually keep the Unix boxes after that, who knows. Must suck to be on that team, knowing that the most important thing you provide to Microsoft is a feature checkbox in the brochure....
I'm experimentally running Debian/SPARC woody on my Ultra 10 at work. Now that I have Evolution and a choice of konq and galeon, I'm mostly happy. But when I have to boot back into Solaris you can bet I'm going to be using IE5 and OE5 again.
Next, remove the goddamn video resolution lock on the consumer hardware. I've got an iMac here stuck sending 1024x768@75 video out the VGA port. The video hardware can do much better, but there's no way of saying "turn off the builtin display". iBooks are similarly crippled; PC laptops aren't.
Think very hard about adding a second trackpad button on the laptops. I can easily replace the USB mouse on a desktop box to get a second button, but there's no way to upgrade the trackpad without a bandsaw. Support for context menus in OS X is soooo nice; why make it harder for laptop users to take advantage of it on the go? (Yes, I know you can use modifier keys to get the same effect, but it's not the same.)
Make a really fast web browser. This Celeron 450 seems much faster than the iMac 450 for browsing; similarly with 800MHz machines at work.
Give me the source to Mail.app, so I can add support for certificates. It's not like your competition is going to steal anything useful out of that excellent, Cocoa-centric app.
Pay Valve Software to port the Half-Life engine to OS X. Geez, if the Mac doesn't run Counter-Strike, how are we going to AWP all the Windows weenies?
Oh, like the government use of force to implement civil and criminal penalties for copyright infringement, or to enforce contracts?
Rosen and Valenti's corporate masters suggest that because it's a music show, next year's rant should be a musical number. They've even got the rights lined up for the appropriate song, with a few modifications.
A band launches into the Squirrel Nut Zippers song "Hell"; the two mouthpieces bound onto stage, dressed in tuxes, carrying canes. They sing:
(Cue swing/calypso music)
(The committee in charge of coming up with this was delighted by how little they had to change, but they couldn't quite figure out how to change "suit" to "lawsuit" and still have it sound right.)I had one of those annoying on-the-tip-of-my-tongue experiences, but I felt like I had to say something. So I stammered and blurted out:
Unfortunately, that expansion is now stuck in my head.We really hate the DMCA.
No. I don't think you understand. We *REALLY* hate the DMCA.
So if you think you have been wronged, feel free to send out your lawyers. Just do NOT invoke the DMCA, or you are going to have a lot of your potential early adopters start spitting when they see your corporate logo.
Signed,
Someone who usually will buy your games
nop@family-values:/tmp$ wget ftp://ftp.redhat.com/pub/redhat/linux/7.2/en/os/i
[...]
nop@family-values:/tmp$ od -t x1 ash-0.3.7-2.i386.rpm | head -1
0000000 ed ab ee db 04 00 00 00 00 01 61 73 68 2d 30 2e
You will note the "04 00" after the magic number. Is this accusation still unjustified?
The place I first saw these in the wild was source RPMs. In several cases, I've gotten SRPMs that I could not extract due to version mismatches. (Extraction of SRPMs is not a LSB issue, however.)
I'm not complaining that Red Hat was not a good player in the LSB standardization process; I've no reason to think otherwise. I'm complaining about the attitude that "interoperability with Red Hat" is an important goal for Debian or other distros. It's more important to interop via standards, not testing against a perceived market leader.
More broadly, the LSB did not intend to give RedHat the power to define standard Linux. You shouldn't let RedHat define the standard either.
After thinking about this a little, I realized that you actually need two pages; on MIPS, a load instruction won't complete if there aren't TLB entries for both the instruction and its target. I really need to instrument the kernel TLB code; I have this suspicion that part of why snow is such a faster ABI is that it gets rid of the GOT pages, which are inherently quite "hot".
That's a difficult issue. Take a program that has no heap/stack usage. How much memory does it use while running?
One 4k page, containing either the current instruction, or the target address the current instruction is loading. All the other pages can be dropped by the kernel VM system, and demand-loaded back in when needed. Plus whatever kernel overhead there is to support the task and memory maps.
OK, clearly that's not a useful answer. Any real app that's really eating only one page is thrashing so hard that it won't get anything useful done in a timely manner. But it does get you thinking about what the nature of memory usage is, and possible ways to reduce it.
eXecute In Place support is one strategy. When you build VR3 compressed rom images, you can flag some files as sticky. Through the magic of VM, those uncompressed files are mapped directly into processes, and their code really does run from ROM---no copy in RAM needed. But VR3 ROM is slower than RAM, and you use up more ROM space this way. VR3 hackers have spent a lot of time exploring the tradeoffs here. But there are plenty of other strategies, and some that go deeper into the build process.
For instance, it would be nice if each code page had as much useful stuff on it as possible. If you have a short "hot" function, a long bunch of rare exception handling, and then another short "hot" function, you have to keep the exception handling code paged in even though you're not using it much. It would be better to reorder the hot functions so that they share a page.
You can do some of this with gprof's function reordering profiles and some linker scripts, but I haven't gotten around to trying this on the VR3. I think that some of the approaches to small-device tailoring do require the deep, system-wide approaches the parent article describes.
Seriously, we have the source to every bit on the device. And I mean Open Source. It did take some effort to get the X11 sources, and source for the PMON boot loader, but we have them all. I know this because Brian Webb, who isn't an Agenda employee, rebuilt everything from source to support my snow ABI, which is not binary compatible---if it wasn't rebuilt, it wouldn't work!
We're still working on automating the rebuild. Right now, doing this rebuild is a manual process, but I think we're a few weeks away from having a big "make World" that will spit out a cross compiler and then a romdisk image.
Now, if you're fretting about PDAs with components that aren't Open Source, go check out the Zaurus. Its Java implementation is proprietary. (If you want to write apps for it, they have to be GPL'd unless you're a Troll licensee; I guess some people see that as a positive thing.)
$250 always seemed a touch high to me. I think there's a Linux PDA niche somewhere below the iPaqs, competing directly with low-end Palm devices. LinuxDA is a little too low end for my taste; I want virtual memory. I would think that had Agenda's parent company not stumbled, pricing on the VR3 would have come down.I don't remember an NDA on their developer pages.
(I wish people would stop moderating articles with "overrated/underrated" just to avoid metamod; the parent is at score 3 with no moderation reason. And the parent msg is substantially incorrect.)
The best performance measure is running your code on a variety of systems. Because most people can't do that, it may make sense to look for standard benchmarks that look like your code, and then make analogies based on the similarities of those loads to what you want to do. It's critical to pick the right benchmarks to have a good analogy; if you're interested in 3d performance, it doesn't make sense to make performance comparisons based on the number of rc5 keys per second.
Unfortunately, the Open Magazine article doesn't give any information on what exactly their tests are doing. So it's not possible for you to figure out which, if any, of their tests will be analogous to your code. :-(
As I've mentioned before, I'm mostly interested in integer performance. From what I've read about the Intel C compiler, its strength is floating point. If I did a lot of FP work, I'd be sending Intel a credit card number about now, and I imagine many FP people will.
But for integer work, I think it's not so clear. Andreas Jaeger has a nice page benchmarking versions of GCC. On Athlon processors, SPEC CPU2000 CINT2000 base looks like it's around 10% faster when built with the Intel C compiler than with GCC 3.0.1. I think I can live with that.
It's a lot easier to modify gcc than icc too, and yes, I really do hack on gcc from time to time.
- This was on a 1024x768 laptop display, with subpixel rendering correctly configured.
- All sizes antialiased. Hey, it workes on the Mac, and I really do want to know if antialiasing is better for me for the majority of text I work with. With subpixel rendering, it seems plausible...
- Using a variety of well-hinted fonts, primarily the "Microsoft Web core fonts"
- At sizes comparable to what I normally use
So why did I put up with this headache for a *second* day? Because I seem to be unusually sensitive to changes in text display. When I switched from a Diamond Stealth 64 VRAM (968) to a Matrox Millenium, I got this same headache for like four days, even though I was running the same monitor, same resolution, same refresh rate, and same fonts. IIRC, it even had the same TI ramdac! But the Millenium had higher quality analog circuitry after the ramdac, and had sharper edges. After I got used to it, it was much nicer.It may not be sharpness. If I get stuck in an environment where I have to spend a lot of time reading fonts I'm not used to, I get this kind of headache for a while too.
So now, the question is, do I care enough to try another day using the Xft setup? Will it be worth it? Who knows, but I'm gonna go have a beer and go nowhere near a display for about 12 hours....
The only problem I see is the shift key mod. Because the original Apple keyboards didn't support lower case, it was common for users to run a wire from the shift key to PB2 to let software interpret upper and lower case.
I'm guessing the easiest thing to do is build a small FPGA that lives on the 6502 bus that has a shift register and a one-shot 8-clock SPI clock generator. (FPGA clocked from the pin 36 7MHz signal?) I'm already way past my knowledge of design, but it seems like this would be very easy to build, and should deliver bytes as fast as the 6502 could digest them---reading from a slot address takes 4 cycles, and writing somewhere takes at least 4 more. Likely this kind of system would end up blocking on the flash device itself some of the time.
Anyway, I think it's possible you could have a two chip design: FPGA and level shifter. Amazing what might be possible with just a few chips these days!
Serial interfaces are especially nice on the Apple because you don't have to build an expansion card to talk to them---you can use the game port. There are four outputs and three inputs there. You'd need a level shifter to get the voltages down to the 3.3v range those flash cards want.
I just wrote out a little 6502 assembly bitbanger to talk to a purported SPI device on an Apple game port, and it looks like it's around 40 cycles per bit. So that's around 3kBytes/sec, raw. Not too bad for a 1 chip interface that doesn't take up a slot!
I don't remember if the analog electronics on the gameport inputs let you pump bits that fast. But it sure would be cool to have a single module plugged into the gameport, with 64M of storage---on a package smaller than the 6502.
The most favorable interpretation is that, for the load in question, the G4/533 is roughly 21% faster than you might expect a P3/533 to be.
I've slowly been putting together another round of tests with more recent kernels; add another 10% or so for improvements there. So 30% is the rule of thumb I used to use. The OS X SPECint numbers I have imply a smaller clock-for-clock performance ratio, so I'm back to using 20% as my rule of thumb.
Keep in mind that I'm not that interested in floating point performance, and I have made no attempt to quantify it. As always, the best performance measurements are those made on the workloads you actually use.
(Snide remark: and if all you bought your computer for was to run SETI units, then that's a useful cross-platform comparison. :-)
I don't know what those DLLs do. Of course, I don't know what the Java code does either....
Oh yeah, it was fixed the same day it was reported.
Anyway, here's the maintainer response:
Looks like RedHat applied the same ill-advised security patch.Well, it was mentioned *once*....