Isn't "due diligance" one of the requirements for patent enforcement? That is, if they have failed to enforce their patent rights for a year, it seems unlikely that they will ever have the right to enforce them in the future. Am I missing something?
Do you have a right to know every time someone else got pulled over and had a criminal history check run on them? Do you have a right to know every time law enforcement may have suspected someone of committing a crime whether they actually were convicted or not?
Yes. In most states, police blotters are a matter of public record. In many municipalities, the material in those blotters is condensed and printed in the local newspaper.
There is more to software than the specific operations it performs. If I and a coworker wrote two programs to do the same thing, his was 20% faster but mine was maintainable, flexible, and still likely to be useful into the future even if I leave the company, which do you think the manager will prefer?
If they're like a lot of managers I've met, probably the one that's 20% faster.:-)
Some companies have tried it as an experiment. It never works. People misinterpret and twist parts of the bug reports in ways that make them sound much worse than they really are, then make bad PR for the company.
This sort of thing eventually happens every time a company tries to do a public bug site, without fail. That's why you don't see companies doing it anymore. Burn me once, shame on you; burn me twice, shame on me.
Second that. I've bought about ten CDs by artists as a direct result of having downloaded their music. I hear a song on the radio, I dl a handful of songs to see if that's the only song I like. If I decide the group or artist is a one-hit-wonder, I toss them. If I decide the group or artist is actually good, I buy the CD.
I'm far more likely to buy an artist if I can listen to all of the tracks in a -decent- -quality- format like an end-user-ripped MP3 rather than these crappy RealAudio tracks that many of them pt on their web sites. (Nothing wrong with RealAudio if you know when to use particular codecs, just that most content providers don't.:-)
So for those of you in the industry, know this: if you stop people from making your music available, I'll stop buying your CDs, pure and simple. I'm not alone.
It doesn't require tag tracking. They do that here in CA, too. It's done with sensors in the road. It's quite simple. Measure the capacitance on two sensors in the road, a la traffic light sensors. Now calculate the time between the peaks. Do a little quick math and you can convert that into miles per hour.
Don't believe me? Look on the road beneath every traffic sign on a highway. Two small circular road cuts with sensor wires embedded, one slightly in front of the other. The signs have a transceiver that sends data back about traffic motion and receives data to display on the sign. Pretty elegant, IMHO.
It's not completely accurate, though. Certain things can really throw it off, like a car crossing into the lane right at the sensor. That's why those systems occasionally report numbers like 130 mph for a couple of seconds when you know that there's no way somebody could be going that fast on the 101 in rush hour.
The point being that while they aren't accurate enough to catch speeders, they are perfectly fine for estimating the speed of traffic flow, and don't require any sort of non-anonymous tracking of your vehicle.
I think part of the problem with multi-button mice is that it is entirely too easy to hit the wrong one, not because of carelessness, but because they were built, not designed.
Having two or three buttons on top of a mouse is nuts. Your finger slips, and you're pulling down a contextual menu. You move the wrong finger and... blam.
Having one button on top and one on each side, however, works nicely. Since the thumb and pinkie finger are naturally dormant during mousing, your brain is much less likely to inadvertantly cause one of them to click when you meant to click with a normal clicking finger on top of the mouse.
To follow up on my own post, when I described those things as HID devices, I should probably have noted that the internal keyboard and mouse on PowerBooks aren't USB, and thus are not HID devices. The trackpad and keyboard are pseudo-ADB devices controlled by the PMU chip (the same one that handles sleep/wakeup).
I'm about 99% sure that there's no way to add this support at the driver level. I don't know about the electrical interfaces and whether there's enough information at the PMU level to add such support by changing the PMU firmware or if you'd actually have to change the firmware of the trackpad itself (assuming that it has firmware to update... I have no idea).
To make a long story short, though, it's very unlikely that this is something that could be done by anyone other than an Apple engineer (and possibly not without hardware changes). It would certainly not be as simple as creating a new driver.
That would be B. The side scroll feature on the trackpad works because the hardware remaps it into scroll wheel messages.
There's a group of devices called USB human interface devices (referred to as HID devices for short) that includes mice, keyboards, etc. Any USB device that acts like a keyboard or a pointing device should fall into that category.
USB HID devices have a set standard for communication that includes things like multiple buttons, scroll wheels, etc. Since the requirements for a driver for such devices are clearly spelled out, any keyboard or mouse or similar should "just work" out-of-the-box, OS bugs or device firmware bugs (or both) notwithstanding.
First, since they tended to be mechanical rather than optical devices, the wheels in trackballs tended to get constantly gummed up.
Second, it added an inch to the thickness of the machine. A PB1xx trackball, when placed beside a TiBook, is taller, I believe. At best, it's about the same height.
Recall that a trackball requires at least a little space below the ball. It also requires that the case be completely inflexible with a pretty sizable clearance above the ball to prevent the trackball from shattering the LCD panel. Either that or go back to huge borders around the LCD, your choice....
Long story short, the trackpad is a big part of why modern laptops can be half as thick and weigh a quarter as much as their trackballed predecessors.:-)
Of course, one should note that not all computer or math theories map equally well onto real-world problems. Some of them fit nicely. The halting problem is a good example of one that doesn't.
In the case of the halting problem, the key to its solution is recognizing that a program's semantics are only known when you examine it in the context of its environment, something which theoretical computer science often ignores.
Computers are finite state machines, with deterministic state transitions (hardware bugs notwithstanding). If you really wanted to do so, you could definitively determine whether a program would halt by exhaustive testing. Run it once. If the system has twenty trillion states, it can take at most twenty trillion minus one instructions to either A. repeat a state (in which case the program will not halt) or B. halt.
That's an extreme example because the number of states is mind-boggling in most systems, but a good approximation can be achieved by looking at only the different states in certain components (e.g. certain registers, RAM, etc.), and by limiting the problem domain, you end up making the solution easier.
In certain cases, public key encryption can be cracked trivially. PK encryption has pattern weaknesses and short data weaknesses that can be exploited. The fact that you can't recover the private key doesn't always mean you can't recover the encrypted data.
Again, if you limit the domain of the problem, it often ceases to be a hard problem. The real question then becomes how one could limit the complexity of breaking RSA. There's a lot of work going on in that area, as I recall. It will certainly be interesting to watch.
The point is that it is possible in many cases to do reasonable bounds checking on your own. To restrict use of common facilities because somebody -might- misuse them is just wrong. I believe in letting people shoot themselves in the foot so that they'll learn to make sure the gun isn't loaded the next time.
Yeah, but if you're really paranoid about people taking out the hard drive and messing with the system, you're probably paranoid enough to lock the machine in a box so that they can't.:-)
-Bad- benchmarks frequently lie, as your post proves. By publishing the 1p information, the article's author basically proved that their test was, whether intentionally or unintentionally, skewed heavily against the Mac.
Why? Simple. A 1p x86 machine should not perform anywhere near as well as a 2p x86 machine unless the tasks do not scale well to SMP. If a task doesn't scale well to two processors, it's even less likely that it would be improved by a SIMD architecture like Altivec.
It's all too easy to construct a benchmark that "proves" that Altivec doesn't improve performance, and that the Mac is slower than the PC. The only real benchmark is a customer sitting in front of the machine and doing his or her daily work, whatever that might be. That's why Apple doesn't publish benchmarks. They don't mean anything unless they accurately represent your workload.
The only thing this article shows is that for operations that Altivec doesn't significantly speed up, a single P4 or Athlon is faster than a single G4, which is not at all what the article's author claimed, nor is it at all interesting, which is, of course, why the article chose to sensationalize its findings....
Also, SPEC doesn't show -any- Mac benchmarks for SPEC CPU2000. That tells me that the results you show above are... at the very least of questionable origin.
If you're going to troll, at least do a good job of it....
Depends on how you define PowerPC. Do you mean the PPC architecture or the PPC instruction set? Power4 is an architecture, and is not considered to be part of the PPC architecture, but then, the PPC 601 is generally not considered to be PPC architecture, either. (Scary, eh?) In both cases, this is due to major differences in the supervisor mode instructions.
The PPC user space instruction set, however, is another issue, and historically Power* architectures have been "close enough" for binary compatibility to be trivial with appropriate compiler flags.
Describing Power4 as PowerPC, though, is a bit of a stretch. IBM's documentation describes it as being "compatible" with the PowerPC user space instruction set, but does not describe it as being a PowerPC chip.
Motorola has built and continues to build 64-bit PowerPC CPUs for the embedded market. Whether Motorola has any plans for 64-bit desktop CPUs is another question, and I have no idea either way.
Doesn't help security in the slightest. Pop in a Mac OS X CD and hold down the C key. Change the root password on the system. Reboot, log in.
Open Firmware passwords help to some extent (by preventing people from booting from alternate devices), but only if you can't open the machine and move memory around to reset it.
Bottom line, the first rule of computer security is that there can be no security without physical security.
LC case... ick. It was just too small to get much useful hardware into it. Expandability was a nightmare, though it did open up easily....
The 610-style case (also used in the PowerMac 6100), though, was cool. They're the last macs that were easily stackable up until the XServe. I have a whole server farm of these things.:-)
You're both right and wrong. Classic, Carbon, and Cocoa applications are all clients of both BSD and Mach. Trying to think of BSD as a layer on top of Mach is an exercise in futility because the second you draw it that way, you'll never be able to come up with a layered model that works.:-)
Carbon and Cocoa are just APIs and the libraries, programs, headers, etc. needed to support them. CF is much the same. Carbon and Cocoa are both dependent on CF for some of their functionality.
However, CF does not sit "beside" BSD. CF is a bunch of library code that applications can use. To say that it sits "beside" BSD simply because it might or might not use any BSD services is perverse. A library is a user-space abstraction. The BSD "compatibility layer" is part of the kernel. By definition, then CF sits on top of BSD, whether it is a client of BSD or not. (And I don't know if it is or not, but the odds are pretty good that it uses it for something.)
Every executable program must (directly or indirectly, e.g. Classic apps) sit on top of BSD, because BSD manages the process model. However, something sitting on BSD doesn't mean that everything it does must be through BSD. It isn't that clear-cut.
A BSD program can easily make calls directly to Mach. It can use ports, Mach RPC, Mach messaging, etc. It can also communicate with other BSD programs.
The only completely precise way to model Mac OS X is as a network of client-server relationships. Then, and only then do things really start to make sense.:-)
Carbon apps (at least well-written Carbon apps) work fine with UFS. I assume you meant Classic apps, which of course, can't see anything but HFS/HFS+ and certain remotely mounted volumes, and can't launch except from HFS+.
The concept is sound. The utility isn't. Mac OS X ships with OpenSSL installed, which is capable of encrypting/decrypting with a wide variety of encryption schemes.
The real problem with this is that it's far too easy to recover the original unencrypted material if you just delete it. You also need to do a multi-pass wipe. I don't know of any tools to do this (apart from Wipe in Classic), but you could write one pretty easily.
There's also the issue of multiple concurrent login sessions, but since I assume you meant login via the GUI login pane, that's not so much of an issue (except when you try to ssh into the machine).
Slashdot Mirror
Isn't "due diligance" one of the requirements for patent enforcement? That is, if they have failed to enforce their patent rights for a year, it seems unlikely that they will ever have the right to enforce them in the future. Am I missing something?
Yes. In most states, police blotters are a matter of public record. In many municipalities, the material in those blotters is condensed and printed in the local newspaper.
If they're like a lot of managers I've met, probably the one that's 20% faster.
Some companies have tried it as an experiment. It never works. People misinterpret and twist parts of the bug reports in ways that make them sound much worse than they really are, then make bad PR for the company.
This sort of thing eventually happens every time a company tries to do a public bug site, without fail. That's why you don't see companies doing it anymore. Burn me once, shame on you; burn me twice, shame on me.
Respect must be earned.
Second that. I've bought about ten CDs by artists as a direct result of having downloaded their music. I hear a song on the radio, I dl a handful of songs to see if that's the only song I like. If I decide the group or artist is a one-hit-wonder, I toss them. If I decide the group or artist is actually good, I buy the CD.
:-)
I'm far more likely to buy an artist if I can listen to all of the tracks in a -decent- -quality- format like an end-user-ripped MP3 rather than these crappy RealAudio tracks that many of them pt on their web sites. (Nothing wrong with RealAudio if you know when to use particular codecs, just that most content providers don't.
So for those of you in the industry, know this: if you stop people from making your music available, I'll stop buying your CDs, pure and simple. I'm not alone.
It doesn't require tag tracking. They do that here in CA, too. It's done with sensors in the road. It's quite simple. Measure the capacitance on two sensors in the road, a la traffic light sensors. Now calculate the time between the peaks. Do a little quick math and you can convert that into miles per hour.
Don't believe me? Look on the road beneath every traffic sign on a highway. Two small circular road cuts with sensor wires embedded, one slightly in front of the other. The signs have a transceiver that sends data back about traffic motion and receives data to display on the sign. Pretty elegant, IMHO.
It's not completely accurate, though. Certain things can really throw it off, like a car crossing into the lane right at the sensor. That's why those systems occasionally report numbers like 130 mph for a couple of seconds when you know that there's no way somebody could be going that fast on the 101 in rush hour.
The point being that while they aren't accurate enough to catch speeders, they are perfectly fine for estimating the speed of traffic flow, and don't require any sort of non-anonymous tracking of your vehicle.
I think part of the problem with multi-button mice is that it is entirely too easy to hit the wrong one, not because of carelessness, but because they were built, not designed.
Having two or three buttons on top of a mouse is nuts. Your finger slips, and you're pulling down a contextual menu. You move the wrong finger and... blam.
Having one button on top and one on each side, however, works nicely. Since the thumb and pinkie finger are naturally dormant during mousing, your brain is much less likely to inadvertantly cause one of them to click when you meant to click with a normal clicking finger on top of the mouse.
It's all about design, design, design.
To follow up on my own post, when I described those things as HID devices, I should probably have noted that the internal keyboard and mouse on PowerBooks aren't USB, and thus are not HID devices. The trackpad and keyboard are pseudo-ADB devices controlled by the PMU chip (the same one that handles sleep/wakeup).
I'm about 99% sure that there's no way to add this support at the driver level. I don't know about the electrical interfaces and whether there's enough information at the PMU level to add such support by changing the PMU firmware or if you'd actually have to change the firmware of the trackpad itself (assuming that it has firmware to update... I have no idea).
To make a long story short, though, it's very unlikely that this is something that could be done by anyone other than an Apple engineer (and possibly not without hardware changes). It would certainly not be as simple as creating a new driver.
That would be B. The side scroll feature on the trackpad works because the hardware remaps it into scroll wheel messages.
There's a group of devices called USB human interface devices (referred to as HID devices for short) that includes mice, keyboards, etc. Any USB device that acts like a keyboard or a pointing device should fall into that category.
USB HID devices have a set standard for communication that includes things like multiple buttons, scroll wheels, etc. Since the requirements for a driver for such devices are clearly spelled out, any keyboard or mouse or similar should "just work" out-of-the-box, OS bugs or device firmware bugs (or both) notwithstanding.
First, since they tended to be mechanical rather than optical devices, the wheels in trackballs tended to get constantly gummed up.
:-)
Second, it added an inch to the thickness of the machine. A PB1xx trackball, when placed beside a TiBook, is taller, I believe. At best, it's about the same height.
Recall that a trackball requires at least a little space below the ball. It also requires that the case be completely inflexible with a pretty sizable clearance above the ball to prevent the trackball from shattering the LCD panel. Either that or go back to huge borders around the LCD, your choice....
Long story short, the trackpad is a big part of why modern laptops can be half as thick and weigh a quarter as much as their trackballed predecessors.
Of course, one should note that not all computer or math theories map equally well onto real-world problems. Some of them fit nicely. The halting problem is a good example of one that doesn't.
In the case of the halting problem, the key to its solution is recognizing that a program's semantics are only known when you examine it in the context of its environment, something which theoretical computer science often ignores.
Computers are finite state machines, with deterministic state transitions (hardware bugs notwithstanding). If you really wanted to do so, you could definitively determine whether a program would halt by exhaustive testing. Run it once. If the system has twenty trillion states, it can take at most twenty trillion minus one instructions to either A. repeat a state (in which case the program will not halt) or B. halt.
That's an extreme example because the number of states is mind-boggling in most systems, but a good approximation can be achieved by looking at only the different states in certain components (e.g. certain registers, RAM, etc.), and by limiting the problem domain, you end up making the solution easier.
In certain cases, public key encryption can be cracked trivially. PK encryption has pattern weaknesses and short data weaknesses that can be exploited. The fact that you can't recover the private key doesn't always mean you can't recover the encrypted data.
Again, if you limit the domain of the problem, it often ceases to be a hard problem. The real question then becomes how one could limit the complexity of breaking RSA. There's a lot of work going on in that area, as I recall. It will certainly be interesting to watch.
int barfunc(char *string)
{
char foo[120];
char foofoo[239];
if (strlen(string) >119) return -1;
sprintf(foo, "%s", string);
strcpy(foofoo, string);
strcat(fooofoo, string);
return 0;
}
The point is that it is possible in many cases to do reasonable bounds checking on your own. To restrict use of common facilities because somebody -might- misuse them is just wrong. I believe in letting people shoot themselves in the foot so that they'll learn to make sure the gun isn't loaded the next time.
Yeah, but if you're really paranoid about people taking out the hard drive and messing with the system, you're probably paranoid enough to lock the machine in a box so that they can't.
-Bad- benchmarks frequently lie, as your post proves. By publishing the 1p information, the article's author basically proved that their test was, whether intentionally or unintentionally, skewed heavily against the Mac.
Why? Simple. A 1p x86 machine should not perform anywhere near as well as a 2p x86 machine unless the tasks do not scale well to SMP. If a task doesn't scale well to two processors, it's even less likely that it would be improved by a SIMD architecture like Altivec.
It's all too easy to construct a benchmark that "proves" that Altivec doesn't improve performance, and that the Mac is slower than the PC. The only real benchmark is a customer sitting in front of the machine and doing his or her daily work, whatever that might be. That's why Apple doesn't publish benchmarks. They don't mean anything unless they accurately represent your workload.
The only thing this article shows is that for operations that Altivec doesn't significantly speed up, a single P4 or Athlon is faster than a single G4, which is not at all what the article's author claimed, nor is it at all interesting, which is, of course, why the article chose to sensationalize its findings....
Also, SPEC doesn't show -any- Mac benchmarks for SPEC CPU2000. That tells me that the results you show above are... at the very least of questionable origin.
If you're going to troll, at least do a good job of it....
Depends on how you define PowerPC. Do you mean the PPC architecture or the PPC instruction set? Power4 is an architecture, and is not considered to be part of the PPC architecture, but then, the PPC 601 is generally not considered to be PPC architecture, either. (Scary, eh?) In both cases, this is due to major differences in the supervisor mode instructions.
The PPC user space instruction set, however, is another issue, and historically Power* architectures have been "close enough" for binary compatibility to be trivial with appropriate compiler flags.
Describing Power4 as PowerPC, though, is a bit of a stretch. IBM's documentation describes it as being "compatible" with the PowerPC user space instruction set, but does not describe it as being a PowerPC chip.
Just to pick nits.
Motorola has built and continues to build 64-bit PowerPC CPUs for the embedded market. Whether Motorola has any plans for 64-bit desktop CPUs is another question, and I have no idea either way.
Open Firmware passwords help to some extent (by preventing people from booting from alternate devices), but only if you can't open the machine and move memory around to reset it.
Bottom line, the first rule of computer security is that there can be no security without physical security.
Ahem, you mean like the PC-compatible PowerMac 6100? :-p
MkLinux Floppy Driver
(Note, servers down right now due to blackout.)
LC case... ick. It was just too small to get much useful hardware into it. Expandability was a nightmare, though it did open up easily....
:-)
The 610-style case (also used in the PowerMac 6100), though, was cool. They're the last macs that were easily stackable up until the XServe. I have a whole server farm of these things.
You're both right and wrong. Classic, Carbon, and Cocoa applications are all clients of both BSD and Mach. Trying to think of BSD as a layer on top of Mach is an exercise in futility because the second you draw it that way, you'll never be able to come up with a layered model that works. :-)
:-)
Carbon and Cocoa are just APIs and the libraries, programs, headers, etc. needed to support them. CF is much the same. Carbon and Cocoa are both dependent on CF for some of their functionality.
However, CF does not sit "beside" BSD. CF is a bunch of library code that applications can use. To say that it sits "beside" BSD simply because it might or might not use any BSD services is perverse. A library is a user-space abstraction. The BSD "compatibility layer" is part of the kernel. By definition, then CF sits on top of BSD, whether it is a client of BSD or not. (And I don't know if it is or not, but the odds are pretty good that it uses it for something.)
Every executable program must (directly or indirectly, e.g. Classic apps) sit on top of BSD, because BSD manages the process model. However, something sitting on BSD doesn't mean that everything it does must be through BSD. It isn't that clear-cut.
A BSD program can easily make calls directly to Mach. It can use ports, Mach RPC, Mach messaging, etc. It can also communicate with other BSD programs.
The only completely precise way to model Mac OS X is as a network of client-server relationships. Then, and only then do things really start to make sense.
Carbon apps (at least well-written Carbon apps) work fine with UFS. I assume you meant Classic apps, which of course, can't see anything but HFS/HFS+ and certain remotely mounted volumes, and can't launch except from HFS+.
The concept is sound. The utility isn't. Mac OS X ships with OpenSSL installed, which is capable of encrypting/decrypting with a wide variety of encryption schemes.
The real problem with this is that it's far too easy to recover the original unencrypted material if you just delete it. You also need to do a multi-pass wipe. I don't know of any tools to do this (apart from Wipe in Classic), but you could write one pretty easily.
There's also the issue of multiple concurrent login sessions, but since I assume you meant login via the GUI login pane, that's not so much of an issue (except when you try to ssh into the machine).
Are you big enough for your home DNS to point only at root?
Yup.
In God we trust. All others must provide DSA keys.