Re:Heh, love how science works
on
Flying Snakes
·
· Score: 2
that sounds a lot like the (true!) urban legend about Disney filmmakers forcing lemmings to jump off a cliff. Contrary to popular belief, lemmings do not commit suicide en masse or leap from cliffs. However, Disney did not want reality to prevent a good movie.
what if the clocks at each endpoint are not properly synchronized? you might be able to challenge the ticket claiming the second clock was a few minutes "slow".
Creates another market for Corn. By opening another market, we might reduce farm subsidies.
If government laws were to require ethanol in gasoline, then that would simply be an indirect farm subsidies. The US likes to pretend it believes in the free market, but it obviously does not.
Re:Anti-spam law will not achieve much
on
Meet the Spammers
·
· Score: 2
free speech is the right to say anything you want.. it is not the right to force people to listen to what you say, and it certainly isn't the right to force people to pay to listen to you.
what about telemarketers? are they protected by the first amendment? I'm not really sure..
The gist of my rant was that GNU glibc should not worry about maintaining compatibility with DANGEROUS and BROKEN "standards". They can do better than the standards!
Re:Don't Do That - my uni is telling me to do this
on
Shattering Windows
·
· Score: 2
use strncpy() and strncat(). This functions let you specify that byte length of the destination buffer, so the function does not write past the end.
WARNING! strncpy() and strncat() are still dangerous. If the destination buffer is too small, the string in the destination buffer will NOT be null-terminated! So every time you call strncpy(), strncat(), or snprintf(), you should manually null-terminate the destination buffer just in case. For example:
char destBuffer[20]; strncpy(destBuffer, srcBuffer, 20); destBuffer[19] = '\0';// null-terminate the string just in case!!
sprintf() is defined in C89. Good luck getting rid of it.
Why not? GNU prides itself in being "not Unix" and has been known to write code with identifiers like POSIX_ME_HARDER. Why can't glibc help make the world a better place by dropping dangerous functions, such as gets(), sprintf(), strcpy(), strcat(), etc. Safer alternatives to these functions exist and their use should be forcefully encouraged.
If glibc does not want to break source compatibility so drastically, they could move the dangerous functions to a new header such as "bufferoverflow.h". Or require the user program to #define GNU_BUFFER_OVERFLOWS_PLEASE before including stdio.h.
Sure this makes porting to GNU slightly more difficult, but I think GNU can pull this off because they have enough clout with developers and no profit motive to worry about!
Elecrokinetic propulsion means that no propellers or jets are used.
I think that means they are using telekinesis. That would explain why the CIA is harboring so many al Quaeda members in psionic prisons in Cuba. Islamic people are well known to have strong psychic powers. There brand of Evil is strong.
I forgot to mention that the "security cookie" pushed on the stack before the return address is called a canary. I thought that was pretty clever.:-)
Microsoft Visual C++ .NET has a similar feature
on
Stack-Smashing Protector
·
· Score: 5, Informative
Microsoft Visual C++.NET (aka MSVC7) has a similar feature called Buffer Security Check. This is for "unmanaged" C++ code, not C#/.NET/CLR code. This new compiler option/GS is on by default.
/GS (Buffer Security Check)
The/GS option is used to detect buffer overruns, which overwrite the return address -- a common technique for exploiting code that does not enforce buffer size restrictions. This is achieved by injecting security checks into the compiled code.
On functions subject to buffer overrun problems, the compiler will allocate space on the stack before the return address. On function entry, the allocated space is loaded with a security cookie that is computed once at module load. Then, on function exit, a compiler helper is called to make sure the cookie's value is still the same. If the value is not the same, an overwrite of the return address has potentially occurred, and so an error will be reported and the process (or at least the thread) terminated.
How do spammers make money if they are difficult to track down? If a spammer uses false email headers and routes his spam through China to hide his identity, how does he expect me to pay him? How do spammers hide from law, but not from "MAKING MONEY FAST"?
Using 64 bits for time_t is wasteful. It would be better to just use 33 bits for time_t. This would save space and push the Y2038 probably out a few more decades.;)
Please give an example of something that the Cocoa APIs can do that the Carbon APIs cannot. According to this article, Cocoa and Carbon are functionally equivalent. Cocoa is the Objective C API. Carbon is the C/C++ API.
Is Cocoa Better than Carbon?
The short answer is no. The Cocoa and Carbon APIs both call functions in the Application Services and Core Services layers of Mac OS X. Contrary to what some people think, Carbon APIs do not call Cocoa APIs. There is no more overhead in calling Carbon APIs than there is in calling Cocoa APIs. The long answer is that if you were going to start writing a new application in a language such as C or Java, and you were only concerned with your application running on Mac OS X, you might choose to learn the Cocoa APIs because they are a higher level API than Carbon. Most Mac developers want to utilize the large base of code they have written over the years as well as their knowledge of C or C++ so they are likely to stick with Carbon rather than learn Objective-C and rewrite their code using the Cocoa APIs.
Can applications that use Cocoa do more things than applications that use Carbon?
The short answer is no. The Cocoa and Carbon APIs both call into the same parts of Mac OS X. However, there is a small set of functions that Apple has not yet made available to Carbon simply because they weren't needed for Mac applications to be made native on Mac OS X. The reverse is also true. There is a small set of functions that Carbon applications can access on Mac OS X that Cocoa-based applications can't simply because Cocoa applications didn't need them because they weren't used to having those functions anyway. Apple is working to reduce these differences to zero.
Are Cocoa-based applications "more native" than Carbon-based applications?
No. Both Cocoa and Carbon call into the same parts of Mac OS X. Cocoa applications are no more or less native than Carbon applications. The Carbon APIs are newer to Mac OS X than the Cocoa APIs and as a result there may be more problems with them in the short term than there are with Cocoa but that is a problem that Apple will solve.
Microsoft's Visual C++ debugger is excellent. You can visually debug multiple threads, watch variable values, even set breakpoints depending expression evaluated at runtime. You can even debug processes on remote machines.
oh, wait a minute.. Linux? then nevermind. Linus says debuggers are for wimps anyway, dontcha know?
Visual C++.NET 2002 (aka MSVC7) supports "managed" C++ for the.NET CLR. That is, C++ code can be compiled down to MSIL byte bytes, be garbage-collected (!!), and interact with.NET libraries. Sounds like a good transition strategy for legacy C++ code..
Re:why are we securing it this way?
on
Future of Wi-Fi
·
· Score: 2
I think you're right. Wireless networks are, by defintion, insecure. Instead of trying to secure just one insecure link in the chain, we should use the end-to-end principle and use IP and/or application level encryption.
With the rising tide of Corporatism and the all powerful Department of Homeland Defense, this nation of the people, by the people, and for the people has lost sight of the people. Our founding fathers, in their wisdom, created checks and balances to keep our federal government and military branches honest. These checks and balances are quickly eroding as the Borg-like Department of Homeland Defense assimilates all homeland (and corporate profit) protection.
Watching the TV news makes me want to stock up on guns and ammo for the coming revolution..
if they really want to help curtail piracy they need to aggressively pursue DVD audio. Make it sound so good no one will want mp3s and the files will be so large it will take forever to download.
That is a very good idea. If they provide added-value (over MP3s) then I will be more likely to buy their products.
Slashdot Mirror
that sounds a lot like the (true!) urban legend about Disney filmmakers forcing lemmings to jump off a cliff. Contrary to popular belief, lemmings do not commit suicide en masse or leap from cliffs. However, Disney did not want reality to prevent a good movie.
that Houston Traffic Map is pretty cool. I thought the animated historical traffic speed data was especially cool.
what if the clocks at each endpoint are not properly synchronized? you might be able to challenge the ticket claiming the second clock was a few minutes "slow".
I'm sure glad I was never asked to explain how I made it nine miles in under eight minutes on a 55 MPH road.
well, for all they know, maybe you just took a shortcut!
agreed. Cell phones are practically free these days..
I wish TV news had analysis this lucid! thank you!
The RIAA are Nazis.
Creates another market for Corn. By opening another market, we might reduce farm subsidies.
If government laws were to require ethanol in gasoline, then that would simply be an indirect farm subsidies. The US likes to pretend it believes in the free market, but it obviously does not.
free speech is the right to say anything you want.. it is not the right to force people to listen to what you say, and it certainly isn't the right to force people to pay to listen to you.
what about telemarketers? are they protected by the first amendment? I'm not really sure..
The gist of my rant was that GNU glibc should not worry about maintaining compatibility with DANGEROUS and BROKEN "standards". They can do better than the standards!
use strncpy() and strncat(). This functions let you specify that byte length of the destination buffer, so the function does not write past the end.
// null-terminate the string just in case!!
WARNING! strncpy() and strncat() are still dangerous. If the destination buffer is too small, the string in the destination buffer will NOT be null-terminated! So every time you call strncpy(), strncat(), or snprintf(), you should manually null-terminate the destination buffer just in case. For example:
char destBuffer[20];
strncpy(destBuffer, srcBuffer, 20);
destBuffer[19] = '\0';
Are you refering to Richard Stallman's short "fictional" story on this subject, "The Right to Read"?
sprintf() is defined in C89. Good luck getting rid of it.
Why not? GNU prides itself in being "not Unix" and has been known to write code with identifiers like POSIX_ME_HARDER. Why can't glibc help make the world a better place by dropping dangerous functions, such as gets(), sprintf(), strcpy(), strcat(), etc. Safer alternatives to these functions exist and their use should be forcefully encouraged.
If glibc does not want to break source compatibility so drastically, they could move the dangerous functions to a new header such as "bufferoverflow.h". Or require the user program to #define GNU_BUFFER_OVERFLOWS_PLEASE before including stdio.h.
Sure this makes porting to GNU slightly more difficult, but I think GNU can pull this off because they have enough clout with developers and no profit motive to worry about!
Elecrokinetic propulsion means that no propellers or jets are used.
I think that means they are using telekinesis. That would explain why the CIA is harboring so many al Quaeda members in psionic prisons in Cuba. Islamic people are well known to have strong psychic powers. There brand of Evil is strong.
I forgot to mention that the "security cookie" pushed on the stack before the return address is called a canary. I thought that was pretty clever. :-)
The
On functions subject to buffer overrun problems, the compiler will allocate space on the stack before the return address. On function entry, the allocated space is loaded with a security cookie that is computed once at module load. Then, on function exit, a compiler helper is called to make sure the cookie's value is still the same. If the value is not the same, an overwrite of the return address has potentially occurred, and so an error will be reported and the process (or at least the thread) terminated.
How do spammers make money if they are difficult to track down? If a spammer uses false email headers and routes his spam through China to hide his identity, how does he expect me to pay him? How do spammers hide from law, but not from "MAKING MONEY FAST"?
Using 64 bits for time_t is wasteful. It would be better to just use 33 bits for time_t. This would save space and push the Y2038 probably out a few more decades.
Please give an example of something that the Cocoa APIs can do that the Carbon APIs cannot. According to this article, Cocoa and Carbon are functionally equivalent. Cocoa is the Objective C API. Carbon is the C/C++ API.
Is Cocoa Better than Carbon?
The short answer is no. The Cocoa and Carbon APIs both call functions in the Application Services and Core Services layers of Mac OS X. Contrary to what some people think, Carbon APIs do not call Cocoa APIs. There is no more overhead in calling Carbon APIs than there is in calling Cocoa APIs. The long answer is that if you were going to start writing a new application in a language such as C or Java, and you were only concerned with your application running on Mac OS X, you might choose to learn the Cocoa APIs because they are a higher level API than Carbon. Most Mac developers want to utilize the large base of code they have written over the years as well as their knowledge of C or C++ so they are likely to stick with Carbon rather than learn Objective-C and rewrite their code using the Cocoa APIs.
Can applications that use Cocoa do more things than applications that use Carbon?
The short answer is no. The Cocoa and Carbon APIs both call into the same parts of Mac OS X. However, there is a small set of functions that Apple has not yet made available to Carbon simply because they weren't needed for Mac applications to be made native on Mac OS X. The reverse is also true. There is a small set of functions that Carbon applications can access on Mac OS X that Cocoa-based applications can't simply because Cocoa applications didn't need them because they weren't used to having those functions anyway. Apple is working to reduce these differences to zero.
Are Cocoa-based applications "more native" than Carbon-based applications?
No. Both Cocoa and Carbon call into the same parts of Mac OS X. Cocoa applications are no more or less native than Carbon applications. The Carbon APIs are newer to Mac OS X than the Cocoa APIs and as a result there may be more problems with them in the short term than there are with Cocoa but that is a problem that Apple will solve.
Microsoft's Visual C++ debugger is excellent. You can visually debug multiple threads, watch variable values, even set breakpoints depending expression evaluated at runtime. You can even debug processes on remote machines.
oh, wait a minute.. Linux? then nevermind. Linus says debuggers are for wimps anyway, dontcha know?
that can't be. I thought that Disney and Oracle were competing to buy out Apple...
Visual C++
Visual C++
I think you're right. Wireless networks are, by defintion, insecure. Instead of trying to secure just one insecure link in the chain, we should use the end-to-end principle and use IP and/or application level encryption.
With the rising tide of Corporatism and the all powerful Department of Homeland Defense, this nation of the people, by the people, and for the people has lost sight of the people. Our founding fathers, in their wisdom, created checks and balances to keep our federal government and military branches honest. These checks and balances are quickly eroding as the Borg-like Department of Homeland Defense assimilates all homeland (and corporate profit) protection.
Watching the TV news makes me want to stock up on guns and ammo for the coming revolution..
if they really want to help curtail piracy they need to aggressively pursue DVD audio. Make it sound so good no one will want mp3s and the files will be so large it will take forever to download.
That is a very good idea. If they provide added-value (over MP3s) then I will be more likely to buy their products.