Yes, Mac OS X is based on BSD. This doesn't necessarily mean that UNIX software will compile and work unmodified. As an example, my company makes products that run on Windows as well as various UNIX variants, including HP-UX, Solaris, Irix, BSD, various SysV-like systems, etc.
Believe me, you do not want to see what the Makefiles for a piece of software like that look like. We're talking about the era before GNU-style "configure" scripts and Makefile modularity. It's hideous. But it works. And it makes the differences between the various UNIX platforms as clear as day.
Right now, I'm in the middle of porting our main project to run on OS X, so this article is very timely. To be honest, I anticipate that the majority of the difficulty will be in getting the make system to run correctly, and possibly fixing a number of linker issues. I expect that the code itself will work almost unmodified.
For all we know they did use N-way cross-validation. These are not stupid people so there is a good chance they did.
Probably not. The purpose of the system is to make people more money. Whether the results are statistically valid isn't the point.
What academic journal would ever publish an article written for a newspaper? What's your point here?
I wasn't suggesting it. Just pointing out that their statistical claims are at the level of bullshit that would cause such a report to be rejected had they written one.
Are those same extended (Unicode) characters allowed in SSL certificates? If not, then it would be impossible to get a certificate matching the configured hostname, and browsers would bitch loudly when people went to the site...
But then again, you could just not use SSL, and most people wouldn't even notice that they weren't at a secure site.
In the field of machine learning, it's considered a major no-no to quote performance figures based on your training data.
The typical way to validate your results is called an N-way cross-validation. You split the data into N parts, and perform N training runs. Each run uses N-1 chunks to train, and tests on the remaining chunk. Then you average the results to get a general performance estimate, or you can use a T-test to compare the results against another algorithm.
This report would have been rejected immediately from any academic journal of any significance. It's a fucking joke.
You can accomplish what you want with VPNs. The WAP exists in a little isolated world along with a VPN server. Clients connect to the AP and have to log in to the VPN in order to go anywhere "real."
The particular choice of VPN client/server software depends on the types of clients you'll want to allow, etc.
A certificate's purpose is not to demonstrate that a particular party is trustworthy. It's purpose is to demonstrate that a party is who they say they are. To this end, Verisign provides a very acceptable service.
If you trust ABC Corp, and a piece of code has been signed by ABC Corp, then you can trust that code as much as you trust ABC Corp. The certificate isn't making you safe, it is providing information you can use to make your own decisions about security.
Couldn't buy the software, instead the company wanted to provide a "Solution", the salesperson wouldn't even give an idea of the price for the 'solutions', but demanded we wade through a web demo with him for an afternoon before it was to be discussed.
Out of curiosity, what company were you dealing with?
What you describe is surprisingly similar to PDF. A PDF file is a stream of objects with a cross reference table to allow random access. The format is general and can be used to store all kinds of stuff besides PDF documents.
Adobe uses a language called FDF for submitting PDF form data to form servers. The format is identical to PDF from a structural standpoint and serves the same purpose as XML for that application.
Another advantage to PDF/FDF is that it is human-readable (unless you use compressed object streams, which is another issue). However, generating the cross reference table is not something easily accomplished by hand.
Modern pistols have failure rates measured in the single digits per 10,000 rounds
Then you said..
Two nines is not acceptable
Two nines is 99.99%, which is a failure rate of 1 in 10,000. So "single digits per 10,000 rounds" is even less than two nines. So what the hell is it? According to what you've just said, pistols have an unacceptably high failure rate.
JPEG is basically a discrete cosine transform, followed by aggressive quantization of the DCT coefficients -- higher compression levels imply more extreme quantization -- followed by Huffman or arithmetic coding of the quantized coefficients.
It is this last step which is not particularly efficient. There are several reasons why ZIP cannot significantly compress this data. First, ZIP is a byte-oriented compressor. Huffman codes are bit-oriented. This causes ZIP to miss many patterns that could be backreferenced simply because they fall on a weird bit position. Second, data can be highly compressible and yet have no repetitive patterns in it.
For example, consider the sequence 1,2,3,4,5,6,7,8,9,10,...,1000. It has no repeating pattern, but it would be absurd to claim that it cannot be compressed. In this case, applying the simple transform x[i] --> x[i+1] - x[i] transforms the sequence to all zeros, and that is trivially compressible. To decompress, just apply the inverse transform.
ZIP is too naive to use any sort of transforms. It really was only intended for textual data, program executables, etc.
While I love to advocate PNG in the right situations, using it for storage of photographic-type imagery is not the best choice.
Before settling on PNG, I would first recommend that he try simply bzip2'ing the raw image files. Compare that to the size of the same image saved in PNG format. It's very likely that bzip2 will be the better performer.
Try it yourself, on some photographic images you have laying around.
Of course, if PNG turns out to work better (it doesn't usually, but it might), then by all means, he should use that. But do the test first.
It's not hard to believe at all. The Huffman codes used in standard JPG files are extremely naive. Improving on their performance would take some clever thinking, but it's not rocket science.
It's simply that these are the first people who've ever bothered to try it.
Some people drink lots of caffeine. Caffeine tends to keep you awake, and it also raises blood cortisol levels. Elevated cortisol is strongly linked with weight gain. Thus, the two conditions "less sleep" and "weight gain" might both stem from a third factor, namely, excessive intake of caffeine.
When I stopped drinking caffeine last year my weight plummeted. I started again in the winter, and my weight is increasing again.
Earth can speed up if you either "add energy" or "remove stuff" from the closed system.
Explain the proverbial ice skater who speeds up her spin as she pulls her arms toward her body. According to you, this can only explained by "adding energy" (what energy?) or "removing stuff" (she lost mass?!)
For some bizarre reasons you seem to think that the r in L=r x p is a constant. It isn't. The earth contracted somewhat after the earthquake, bringing mass closer to the center of rotation and decreasing the moment of inertia.
Your understanding of this stuff is very incomplete.
And I forgot to mention that it's only winter on one hemisphere at a time, so the redistribution of mass would be lopsided. It probably makes the planet wobble a bit.
Believe me, you do not want to see what the Makefiles for a piece of software like that look like. We're talking about the era before GNU-style "configure" scripts and Makefile modularity. It's hideous. But it works. And it makes the differences between the various UNIX platforms as clear as day.
Right now, I'm in the middle of porting our main project to run on OS X, so this article is very timely. To be honest, I anticipate that the majority of the difficulty will be in getting the make system to run correctly, and possibly fixing a number of linker issues. I expect that the code itself will work almost unmodified.
I think I'll wait to RTFA until after I've tried everything on my own first. Nothing like thrashing randomly to help you learn about a system :-)
Probably not. The purpose of the system is to make people more money. Whether the results are statistically valid isn't the point.
What academic journal would ever publish an article written for a newspaper? What's your point here?
I wasn't suggesting it. Just pointing out that their statistical claims are at the level of bullshit that would cause such a report to be rejected had they written one.
But then again, you could just not use SSL, and most people wouldn't even notice that they weren't at a secure site.
In the field of machine learning, it's considered a major no-no to quote performance figures based on your training data.
The typical way to validate your results is called an N-way cross-validation. You split the data into N parts, and perform N training runs. Each run uses N-1 chunks to train, and tests on the remaining chunk. Then you average the results to get a general performance estimate, or you can use a T-test to compare the results against another algorithm.
This report would have been rejected immediately from any academic journal of any significance. It's a fucking joke.
Because "rewriting the kernel to avoid patent infringement" implies that you knew about the infringements before, which makes you legally liable.
It would be admitting that kernel developers knowingly used patented methods in the kernel, which would open them to willful infringement lawsuits.
So, in the sense that you are completely, utterly wrong, yes, that was an insightful post.
The particular choice of VPN client/server software depends on the types of clients you'll want to allow, etc.
A certificate's purpose is not to demonstrate that a particular party is trustworthy. It's purpose is to demonstrate that a party is who they say they are. To this end, Verisign provides a very acceptable service.
If you trust ABC Corp, and a piece of code has been signed by ABC Corp, then you can trust that code as much as you trust ABC Corp. The certificate isn't making you safe, it is providing information you can use to make your own decisions about security.
Out of curiosity, what company were you dealing with?
Not only do they not have the time, they'd lose their "common carrier" status if they did.
Adobe uses a language called FDF for submitting PDF form data to form servers. The format is identical to PDF from a structural standpoint and serves the same purpose as XML for that application.
Another advantage to PDF/FDF is that it is human-readable (unless you use compressed object streams, which is another issue). However, generating the cross reference table is not something easily accomplished by hand.
Modern pistols have failure rates measured in the single digits per 10,000 rounds
Then you said..
Two nines is not acceptable
Two nines is 99.99%, which is a failure rate of 1 in 10,000. So "single digits per 10,000 rounds" is even less than two nines. So what the hell is it? According to what you've just said, pistols have an unacceptably high failure rate.
I think you're pulling figures out of your ass.
What a genius idea, all the enemy has to do is paint his face white and the weapons won't fire at him.
Gee, because tar is an archiver, not a compression method?
JPEG == name of standard
JPG == file extension
JFIF == name of file format
Oops, I meant x[i] --> x[i+1] - x[i] - 1, obviously.
It is this last step which is not particularly efficient. There are several reasons why ZIP cannot significantly compress this data. First, ZIP is a byte-oriented compressor. Huffman codes are bit-oriented. This causes ZIP to miss many patterns that could be backreferenced simply because they fall on a weird bit position. Second, data can be highly compressible and yet have no repetitive patterns in it.
For example, consider the sequence 1,2,3,4,5,6,7,8,9,10,...,1000. It has no repeating pattern, but it would be absurd to claim that it cannot be compressed. In this case, applying the simple transform x[i] --> x[i+1] - x[i] transforms the sequence to all zeros, and that is trivially compressible. To decompress, just apply the inverse transform.
ZIP is too naive to use any sort of transforms. It really was only intended for textual data, program executables, etc.
Before settling on PNG, I would first recommend that he try simply bzip2'ing the raw image files. Compare that to the size of the same image saved in PNG format. It's very likely that bzip2 will be the better performer.
Try it yourself, on some photographic images you have laying around.
Of course, if PNG turns out to work better (it doesn't usually, but it might), then by all means, he should use that. But do the test first.
It's simply that these are the first people who've ever bothered to try it.
As another person who has implemented JPEG, I vouch for his accuracy :-)
What exactly is the point of war if people don't die?
Some people drink lots of caffeine. Caffeine tends to keep you awake, and it also raises blood cortisol levels. Elevated cortisol is strongly linked with weight gain. Thus, the two conditions "less sleep" and "weight gain" might both stem from a third factor, namely, excessive intake of caffeine.
When I stopped drinking caffeine last year my weight plummeted. I started again in the winter, and my weight is increasing again.
Explain the proverbial ice skater who speeds up her spin as she pulls her arms toward her body. According to you, this can only explained by "adding energy" (what energy?) or "removing stuff" (she lost mass?!)
For some bizarre reasons you seem to think that the r in L=r x p is a constant. It isn't. The earth contracted somewhat after the earthquake, bringing mass closer to the center of rotation and decreasing the moment of inertia.
Your understanding of this stuff is very incomplete.
And I forgot to mention that it's only winter on one hemisphere at a time, so the redistribution of mass would be lopsided. It probably makes the planet wobble a bit.