I hate to break it to ya, but in a low-level language like C, doing proper bounds checks and data sanitization required for security does not help performance (although it doesn't harm it much either, and should of course always be done)
There is a lot of bloated code out there, but the bad news for people who always post "just write better code!" is that the truly processor-intensive stuff (like image processing, 3D games) is already pretty well optimized to take advantage of modern hardware.
There's also the definition of what "good code" actually is. I could write a parallelized sort algorithm that would be nowhere near as fast as a decent quicksort on modern hardware. However, on hardware from 10 years from now with a big number of cores, the parallelized algorithm would end up being faster. So which one is the 'good' code?
As usual, real programming problems in the real world are too complex to be solved by 1-line Slashdot memes.
Hey... I'm actually replying to your sig, I'm studying for that thing right now and in another month I'll be through the MPEP. I'm in freakin' lawschool and I've never seen so many regs before in my life! (Back to chugging through 700... ooh public use proceedings!)
Oh, and more on-topic, this is sort of interesting since Crazy Ted would normally be the guy who you'd expect would support anything with the right buzzwords in it. While I'm somewhat dubious of giving all the spectrum up to just one company at a discount price, there is something to be said for having those frequency bands available. The technology exists to allow emergency services to cut-through when necessary, but the rest of the time there is no reason the bandwidth should not be available for commercial use.
Those are called "dependent claims" where the first claim (claim 1 in this case) is the major claim and the dependencies all add an extra "limitation" to the claim. Example: Say I make a semiconductor circuit that is novel as my invention and then I say: The same circuit described in claim 1, wherein said circuit is manufactured using gallium arsenide. Now, the dependent claim is narrower than the original which just described the basic circuit since I'm saying the invention is now also manufactured using gallium arsenide. The claims you have spotted are actually narrowing the main claim to more detailed searches. This is a popular technique since the main independent claim is often shot down by the examiner, but one of the dependent claims (that is strictly narrower) can be elected to replace it if the narrower claim actually avoids prior art. Also, most Slashdot stories about patents imply that 1 patent covers the whole Internet or something dumb like that. In real life, the USPTO (and courts) generally keep the scope narrower. Just because this patent describes a method for doing geo-aware searches does not mean that every geo-aware search is covered, companies work around patents every single day.
You also have to remember, that it is not simply the claims that matter, but rather the disclosure of the actual subject matter in the patent that work. I can claim to cure cancer, but if my disclosed method is to throw ketchup packets at the cancer patient, then somebody else who actually cures cancer will have nothing to fear from my patent even if the claims are the same. If Verizon is using a technique that is substantially different from what is disclosed (or 'taught') by this patent, then it has nothing to fear, simply 'claiming' a technology is necessary but not sufficient to show infringement.
To those of you including the story poster who cavalierly call this "obvious", you have to remember that it is not the fact that it might be obvious today it was what was obvious in 1996.... so before you say "Google already does this!" Just remember these guys had the idea and applied for the patent in 1996... 2 years before Google even freakin' existed. Finding obviousness requires a careful reading of the patent and the prior art. It reminds me of a story about some digital photography patents that Kodak got in the late 1980's that some moron on this site called 'obvious' because his camera (from 2006) had the same features that were in the patent.....
As for the trolls who own the patent now, they can suck it, but at the same time, if the actual disclosures that are actually described in this patent are being used by Verizon, they should pay. If you were the lone inventor and some big company came and took your idea and never paid you for it, you'd probably want to be paid too.
Once again someone who does not understand "net neutrality". Note the regardless of provider in the summary. Unless Time Warner is actively degrading service from other providers while simultaneously not doing anyything to degrade its own services, this is not a violation of net neutrality. Remember kids, net neutrality doesn't mean you get everything you want for free, it means the people who own the pipes cannot leverage there monopoly/oligopoly to advantage their own higher-level services against other players who have already paid for access.
I don't know if I'd believe either source fully, but bear in mind the Inq's article is a photo from Computex, where lots of products that are not officially for sale yet are being shown. If I took everything I saw at Computex as something I could get immediately, then I'd be busy comparing Barcelona vs. Penryn servers with DDR3 RAM, and that ain't happenin' for at least 4 months.
100% agree that there is no such thing as 100% protection. I think both SELinux and AppArmor are great things (I did my MS thesis (woefully out of date) on Domain & Type enforcement which is one of the major systems (along with RBAC & Bell-Lepadula/Biba) in Mandatory Access Control (MAC). The SELinux approach is (usually) a more 'pure' variety in that it encompasses the entire system, all of the namespaces in the system in one setup. When I say 'namespace' think of that scene in the Matrix when Neo can't open his mouth to make a phone call..... Tell me Mr. HAcker, how are you going to steal my passwords when you can't even name the/etc/shadow file? SELinux will allow policies where even the root user (under certain contexts) cannot screw with the system. This can make administration harder like in some SELinux setups you literally have to login as root from the physical console to have full access, su'ing to root or SSHing in as root will not get the same privileges. In the most extreme cases, an SELinux policy could literally require you to reboot the box off of a rescue CD to get full access to certain files. The controls are extremely fine grained and very powerful, but potentially cumbersome.
AppArmor's main approach is somewhat less broad. It is more like putting certain applications into a MAC container to limit what an application can do, no matter who the user using the application is. A great example of this that most Slashdot readers should look into is putting the browser into a safety container. I've been using Linux since right before 2.4 came out, and I can't count the number of times I've heard 'Linux is more secure because even if your account gets hacked the system isn't hacked' While there is certainly truth to that from the perspective of the full system, it fails to mention that the only data I actually give a rat's ass about is the data in my account, I can always get the rest of the crap from CD/downloading! AppArmor can help fix this by saying: Hey Firefox, just because you are running as user CajunArson, you DON'T get to do everything CajunArson can do, we will only let you operate on some files, and you can't get full access to his data, you can't fork/exec any ol' program that CajunArson can, and in general you are limited to doing what you are supposed to do: Browse the Web. The underlying concepts are still based on the MAC used by SELinux, but the implementation, while not as air-tight theoretically, is also easier to adjust. If there is something I really need firefox to do that the profile will not allow, AppArmor makes the process of tweaking the security easier than SELinux in general (although RedHat could be working on better SELinux tools to fix that).
Sorry for the long post, but remember: the next time someone says Linux is more secure than Windows, remember that things like SELinux and AppArmor really are what make it better, not just because it has a mean looking penguin!
Two words: RAID 0 Nothing can possibly go wrong. Especially if you use, like, 10 disks.
For the love of God and all that's holy will someone mod this 'Funny' instead of Informative? I get the joke, but there's always somebody who won't! (Then again... maybe people who won't oughta make a 10 disk RAID 0, hell mod it insightful sucka!)
It must be a really slow news day. From the dateline:
Published: February 11, 2007
Not to mention that Slashdot (even Zonk) Covered this LAST YEAR. But that's OK, I'm sure Slashdot gave insightful and cogent coverage of real events that actually matter to geeks on this site, you know, like the Release of a new major version of GCC Oh wait.... that (like a bunch of other actually interesting stories) would be in the aptly-named, sir not appearing on this website category due to it not making enough banner revenue.
You can do that now with a virtual machine image (see the wiki). I have been able to boot it in qemu and even developed my own game for it using straight-up python & pygtk. However, my game can also run on any box that has python & pygtk, it is not taking advantage of any OLPC-specific software or hardware. One advantage of having everybody in a single physical location is that things like the built-in networking and cameras can be tested out.
A little OT, but I think that the interface is generally pretty good, but at least so far in the beta builds the file-selection dialogs for opening up text & drawings are still the (absolutely atrocious) Gnome defaults that are made even worse because the limited screen real estate on OLPC means the fields are too small to even see properly. Making a simplified and OLPC-friendly file dialog would be a major improvement.
They basically gave up pretending Windows is a multitasking multiuser platform and now start recommending one Windows per one service.
The issue is not one server per OS, it is one customer per OS instance in a hosted environment. Linux would do the same thing, after all just because it can have multiple regular users doesn't mean that customers who want root access will be willing to share one system. The virtualization allows this.
> independent event, therefore they have nothing to do with each other and you can't add up their probablities.
Take a coin with a 50/50 chance of turning up heads. Each flip is independent of all the others. Now, what is the chance that for 100 flips EVERY flip will come up tails with 0 flips coming up heads?
(0.5) ^ 100 = 7.8 * 10^-31 (0 for any chance this side of hell of not getting a heads)
If the chance of a hit is only 5% (meaning a miss is 95%):
(0.95) ^ 100 = 0.0059205292203339975 (0.59% chance of a miss, or about a 99.4% chance of a hit)
Killing the missile only requires 1 hit. The parent may be optimistic in some ways, but he is completely right with his figures, and you need to go back to probability 101.
Good point, but you can run Parallels (and a bunch of other commercial & open source VM's) on Linux too, so virtualization is still an option without the Mac part (and is probably the most reliable way to test).
BadAnalogyGuy... an apt name for your bad analogy:)
The problem with your logic is that you are assuming the security of the system is really more based around not being able to figure out and access most system-level services. The issue there is that if the OS is setup properly, the ACLs and other security checks in place should catch attempts at manipulating files/network sockets/ registry keys/etc. I know that bashing Windows security is in vogue around here, but to be perfectly blunt there is no real difference between the security services offered by Windows and those offered by Linux*, namely that non-root users should get limited access and superusers have the run of the machine. You can argue that Linux gets patches out faster when bugs are found, but the basics of the models are not really different.
If there really is a vulnerability in such a service, the existence of a convenient API will not substantially reduce the security, as it stands now the blackhat community is more than capable of messing with things at the binary level like you mentioned. The existence of open API's to system components could actually help security since a consistent set of interfaces would probably encourage better design and better testing, plus it would not allow the developers to pull stupid stunts that happen when they know nobody can interface with the program.
* SELinux, Apparmor, and even my master's thesis on mandatory access controls with Domain & Type Enforcement do give Linux a big leg up, but unfortunately they are not as widely deployed as they should be.
After having been in a real control center (and I'm talking about a real FAA center, not the control tower at Podunk regional) I can tell you that they use a fully digital customized GUI to track planes and everthing is tracked electrnically... with thermal printers that print out the paper strips you mentioned because... the old system sits right next to each workstation and every controller is still fully trained and proficient in building takeoff & landing ladders. In the event of a major emergency where the computers all choked they can safely handle every plane the old fashioned way. There is something to be said for having a low-tech backup.
Money is evil. It makes people do horrible things.
Good, then my recomendation to you is to quit your job so you are not polluted by any of this 'money' (and no going on welfare either!)
In fact since you care so much, you should actively go around to the HP workers who were not laid off and tell them to quit their jobs too to prevent them from being corrupted by money as well.
Yeah but I'm sure that Bill & Co would have no problem with you paying MS for 10 server licenses and then dropping Linux on them (at least not as much of a problem as you buying from Sun). Sorta like Ford wouldn't mind you buying 2 Mustangs, running them off a cliff, then refurbishing an old Camaro.
Ahh crap... there are some brackets in that last post you can't see... I meant: next[Object] where [Object] is a descriptive name of the type of object I'm iterating over.
That's easy... first all my iterators are 'I' based (just a personal preference) Secondly, as I was taught by me Jedi Masters in undergrad I use iterators with names like 'II', 'JJ', 'KK'...
The reason is, in some cases where somebody else was dumb enough to put in a 'j' or 'k' variable, the iterator will stand out which helps with overall readability. Now that I'm using python heavily, I tend to stick to the II, JJ... style for numeric loops. But for walking through collections or dictionaries I've started to gravitate towards a next style where is descriptive of the type of thing I'm iterating through.
I still have fond memories of screwing around with Turbo Pascal on those (even at the time) ancient IBM floppy-PC things we were stuck with in high school. At the time Java was still called Oak, and many PC's would not be happy with even a C compiler for speed. Pascal was a major step up in power and performance from the BASIC we had done, and even though I've forgotten most of it, I did learn one lesson I still use today: useDescriptiveVariableNamesPlease (Ok, a little extreme, but I can't remember the last time I used 'x' as a variable name... joy)
Bzzztt.... wrong, Thankyou for playing. As I learned firsthand when coding buffer overflows in a security class, it is a simple, easy, and wrong assumption to think that the stack growing down is the main reason you can do buffer overflows. The main reason is that you are allowed to write where you're not supposed to, not matter what direction the stack grows. Hint: Remember what a stack is exactly... a buffer overflow can just as easily write up into another function's space and execute the overflow from there.
It actually turns out that a bunch of the random relocation and offset tricks while helpful, can still be defeated, so simply growing the stack in a different direction is not a real solution.
That sounds like a trivial subset of a certain thesis project I did In a nutshell... if you are running Windows I have bad news: malware downloaded via Firefox is still malware. And if you want real security for shit you download, the OS has to have some form of MAC system (Yes, most mean this as SELinux, but it usually means nastier policies than come with most distros)
Opteron 865 chip...
If you want to build a 4/8 way machine (which is the only reason to buy from the 8x series) $1500 is not a bad price for a chip at all, and $2149 for the dual-core is only ~40% markup! If you want cheap.. buy a normal PC, after all the extra CPU's won't make your games faster and many of the server boards that take these chips don't even bother with high-speed graphics ports since they're designed to be servers. Opterons are cheap (err.. inexpensive) compared to Itaniums or other 64 bit architectures out there.
And Tiger was on display. Although the Apple guys were tight lipped about whether it was official or not (don't fire anyone Steve they didn't spill the beans!)
Even more interesting from my perspective was that from the talks I had with them, their server line and the X-raid stuff is starting to garner a lot more interest in government areas that were previously closed to anything related to Apple. I'd seen their stuff online, but once you get to see it first-hand and see the prices it's difficult to see why this stuff is so freakin' cool.
Slashdot Mirror
I hate to break it to ya, but in a low-level language like C, doing proper bounds checks and data sanitization required for security does not help performance (although it doesn't harm it much either, and should of course always be done)
There is a lot of bloated code out there, but the bad news for people who always post "just write better code!" is that the truly processor-intensive stuff (like image processing, 3D games) is already pretty well optimized to take advantage of modern hardware.
There's also the definition of what "good code" actually is. I could write a parallelized sort algorithm that would be nowhere near as fast as a decent quicksort on modern hardware. However, on hardware from 10 years from now with a big number of cores, the parallelized algorithm would end up being faster. So which one is the 'good' code?
As usual, real programming problems in the real world are too complex to be solved by 1-line Slashdot memes.
Hey... I'm actually replying to your sig, I'm studying for that thing right now and in another month I'll be through the MPEP. I'm in freakin' lawschool and I've never seen so many regs before in my life! (Back to chugging through 700... ooh public use proceedings!)
Oh, and more on-topic, this is sort of interesting since Crazy Ted would normally be the guy who you'd expect would support anything with the right buzzwords in it. While I'm somewhat dubious of giving all the spectrum up to just one company at a discount price, there is something to be said for having those frequency bands available. The technology exists to allow emergency services to cut-through when necessary, but the rest of the time there is no reason the bandwidth should not be available for commercial use.
Those are called "dependent claims" where the first claim (claim 1 in this case) is the major claim and the dependencies all add an extra "limitation" to the claim. Example: Say I make a semiconductor circuit that is novel as my invention and then I say: The same circuit described in claim 1, wherein said circuit is manufactured using gallium arsenide. Now, the dependent claim is narrower than the original which just described the basic circuit since I'm saying the invention is now also manufactured using gallium arsenide. The claims you have spotted are actually narrowing the main claim to more detailed searches. This is a popular technique since the main independent claim is often shot down by the examiner, but one of the dependent claims (that is strictly narrower) can be elected to replace it if the narrower claim actually avoids prior art. Also, most Slashdot stories about patents imply that 1 patent covers the whole Internet or something dumb like that. In real life, the USPTO (and courts) generally keep the scope narrower. Just because this patent describes a method for doing geo-aware searches does not mean that every geo-aware search is covered, companies work around patents every single day.
You also have to remember, that it is not simply the claims that matter, but rather the disclosure of the actual subject matter in the patent that work. I can claim to cure cancer, but if my disclosed method is to throw ketchup packets at the cancer patient, then somebody else who actually cures cancer will have nothing to fear from my patent even if the claims are the same. If Verizon is using a technique that is substantially different from what is disclosed (or 'taught') by this patent, then it has nothing to fear, simply 'claiming' a technology is necessary but not sufficient to show infringement.
To those of you including the story poster who cavalierly call this "obvious", you have to remember that it is not the fact that it might be obvious today it was what was obvious in 1996.... so before you say "Google already does this!" Just remember these guys had the idea and applied for the patent in 1996... 2 years before Google even freakin' existed. Finding obviousness requires a careful reading of the patent and the prior art. It reminds me of a story about some digital photography patents that Kodak got in the late 1980's that some moron on this site called 'obvious' because his camera (from 2006) had the same features that were in the patent.....
As for the trolls who own the patent now, they can suck it, but at the same time, if the actual disclosures that are actually described in this patent are being used by Verizon, they should pay. If you were the lone inventor and some big company came and took your idea and never paid you for it, you'd probably want to be paid too.
Once again someone who does not understand "net neutrality". Note the regardless of provider in the summary. Unless Time Warner is actively degrading service from other providers while simultaneously not doing anyything to degrade its own services, this is not a violation of net neutrality. Remember kids, net neutrality doesn't mean you get everything you want for free, it means the people who own the pipes cannot leverage there monopoly/oligopoly to advantage their own higher-level services against other players who have already paid for access.
I don't know if I'd believe either source fully, but bear in mind the Inq's article is a photo from Computex, where lots of products that are not officially for sale yet are being shown. If I took everything I saw at Computex as something I could get immediately, then I'd be busy comparing Barcelona vs. Penryn servers with DDR3 RAM, and that ain't happenin' for at least 4 months.
100% agree that there is no such thing as 100% protection. I think both SELinux and AppArmor are great things (I did my MS thesis (woefully out of date) on Domain & Type enforcement which is one of the major systems (along with RBAC & Bell-Lepadula/Biba) in Mandatory Access Control (MAC). The SELinux approach is (usually) a more 'pure' variety in that it encompasses the entire system, all of the namespaces in the system in one setup. When I say 'namespace' think of that scene in the Matrix when Neo can't open his mouth to make a phone call..... Tell me Mr. HAcker, how are you going to steal my passwords when you can't even name the /etc/shadow file? SELinux will allow policies where even the root user (under certain contexts) cannot screw with the system. This can make administration harder like in some SELinux setups you literally have to login as root from the physical console to have full access, su'ing to root or SSHing in as root will not get the same privileges. In the most extreme cases, an SELinux policy could literally require you to reboot the box off of a rescue CD to get full access to certain files. The controls are extremely fine grained and very powerful, but potentially cumbersome.
AppArmor's main approach is somewhat less broad. It is more like putting certain applications into a MAC container to limit what an application can do, no matter who the user using the application is. A great example of this that most Slashdot readers should look into is putting the browser into a safety container. I've been using Linux since right before 2.4 came out, and I can't count the number of times I've heard 'Linux is more secure because even if your account gets hacked the system isn't hacked' While there is certainly truth to that from the perspective of the full system, it fails to mention that the only data I actually give a rat's ass about is the data in my account, I can always get the rest of the crap from CD/downloading! AppArmor can help fix this by saying: Hey Firefox, just because you are running as user CajunArson, you DON'T get to do everything CajunArson can do, we will only let you operate on some files, and you can't get full access to his data, you can't fork/exec any ol' program that CajunArson can, and in general you are limited to doing what you are supposed to do: Browse the Web. The underlying concepts are still based on the MAC used by SELinux, but the implementation, while not as air-tight theoretically, is also easier to adjust. If there is something I really need firefox to do that the profile will not allow, AppArmor makes the process of tweaking the security easier than SELinux in general (although RedHat could be working on better SELinux tools to fix that).
Sorry for the long post, but remember: the next time someone says Linux is more secure than Windows, remember that things like SELinux and AppArmor really are what make it better, not just because it has a mean looking penguin!
For the love of God and all that's holy will someone mod this 'Funny' instead of Informative? I get the joke, but there's always somebody who won't!
(Then again... maybe people who won't oughta make a 10 disk RAID 0, hell mod it insightful sucka!)
Not to mention that Slashdot (even Zonk) Covered this LAST YEAR.
But that's OK, I'm sure Slashdot gave insightful and cogent coverage of real events that actually matter to geeks on this site, you know, like the Release of a new major version of GCC
Oh wait.... that (like a bunch of other actually interesting stories) would be in the aptly-named, sir not appearing on this website category due to it not making enough banner revenue.
You can do that now with a virtual machine image (see the wiki). I have been able to boot it in qemu and even developed my own game for it using straight-up python & pygtk. However, my game can also run on any box that has python & pygtk, it is not taking advantage of any OLPC-specific software or hardware. One advantage of having everybody in a single physical location is that things like the built-in networking and cameras can be tested out.
A little OT, but I think that the interface is generally pretty good, but at least so far in the beta builds the file-selection dialogs for opening up text & drawings are still the (absolutely atrocious) Gnome defaults that are made even worse because the limited screen real estate on OLPC means the fields are too small to even see properly. Making a simplified and OLPC-friendly file dialog would be a major improvement.
The issue is not one server per OS, it is one customer per OS instance in a hosted environment. Linux would do the same thing, after all just because it can have multiple regular users doesn't mean that customers who want root access will be willing to share one system. The virtualization allows this.
> independent event, therefore they have nothing to do with each other and you can't add up their probablities.
Take a coin with a 50/50 chance of turning up heads. Each flip is independent of all the others. Now, what is the chance that for 100 flips EVERY flip will come up tails with 0 flips coming up heads?
(0.5) ^ 100 = 7.8 * 10^-31 (0 for any chance this side of hell of not getting a heads)
If the chance of a hit is only 5% (meaning a miss is 95%):
(0.95) ^ 100 = 0.0059205292203339975 (0.59% chance of a miss, or about a 99.4% chance of a hit)
Killing the missile only requires 1 hit. The parent may be optimistic in some ways, but he is completely right with his figures, and you need to go back to probability 101.
Good point, but you can run Parallels (and a bunch of other commercial & open source VM's) on Linux too, so virtualization is still an option without the Mac part (and is probably the most reliable way to test).
Oh yeah, because when it comes to anything nuclear only evil right-wing loons EVER scare monger in any way.
BadAnalogyGuy... an apt name for your bad analogy :)
The problem with your logic is that you are assuming the security of the system is
really more based around not being able to figure out and access most system-level
services. The issue there is that if the OS is setup properly, the ACLs and other
security checks in place should catch attempts at manipulating files/network sockets/
registry keys/etc. I know that bashing Windows security is in vogue around here, but
to be perfectly blunt there is no real difference between the security services offered
by Windows and those offered by Linux*, namely that non-root users should get limited access and
superusers have the run of the machine. You can argue that Linux gets patches out faster when
bugs are found, but the basics of the models are not really different.
If there really is a vulnerability in such a service, the existence of a convenient API will not
substantially reduce the security, as it stands now the blackhat community is more than capable of messing with things at the binary level like you mentioned. The existence of open API's to system
components could actually help security since a consistent set of interfaces would probably encourage better design and better testing, plus it would not allow the developers to pull stupid stunts that happen when they know nobody can interface with the program.
* SELinux, Apparmor, and even my master's thesis on mandatory access controls with Domain & Type
Enforcement do give Linux a big leg up, but unfortunately they are not as widely deployed as they should be.
After having been in a real control center (and I'm talking about a real FAA center, not the control tower at Podunk regional) I can tell you that they use a fully digital customized GUI to track planes and everthing is tracked electrnically... with thermal printers that print out the paper strips you mentioned because...
the old system sits right next to each workstation and every controller is still fully trained and proficient in building takeoff & landing ladders. In the event of a major emergency where the computers all choked they can safely handle every plane the old fashioned way. There is something to be said for having a low-tech backup.
Money is evil. It makes people do horrible things.
Good, then my recomendation to you is to quit your job so you are not polluted by any of this 'money' (and no going on welfare either!)
In fact since you care so much, you should actively go around to the HP workers who were not laid off and tell them to quit their jobs too to prevent them from being corrupted by money as well.
Yeah but I'm sure that Bill & Co would have no problem with you paying MS for 10 server licenses and then dropping Linux on them (at least not as much of a problem as you buying from Sun). Sorta like Ford wouldn't mind you buying 2 Mustangs, running them off a cliff, then refurbishing an old Camaro.
Ahh crap... there are some brackets in that last post you can't see... I meant: next[Object] where [Object] is a descriptive name of the type of object I'm iterating over.
That's easy... first all my iterators are 'I' based (just a personal preference) Secondly, as I was taught by me Jedi Masters in undergrad I use iterators with names like 'II', 'JJ', 'KK'...
The reason is, in some cases where somebody else was dumb enough to put in a 'j' or 'k' variable, the iterator will stand out which helps with overall readability. Now that I'm using python heavily, I tend to stick to the II, JJ... style for numeric loops. But for walking through collections or dictionaries I've started to gravitate towards a next style where is descriptive of the type of thing I'm iterating through.
I still have fond memories of screwing around with Turbo Pascal on those (even at the time) ancient IBM floppy-PC things we were stuck with in high school. At the time Java was still called Oak, and many PC's would not be happy with even a C compiler for speed. Pascal was a major step up in power and performance from the BASIC we had done, and even though I've forgotten most of it, I did learn one lesson I still use today: useDescriptiveVariableNamesPlease (Ok, a little extreme, but I can't remember the last time I used 'x' as a variable name... joy)
Bzzztt.... wrong, Thankyou for playing. As I learned firsthand when coding buffer overflows in a security class, it is a simple, easy, and wrong assumption to think that the stack growing down is the main reason you can do buffer overflows. The main reason is that you are allowed to write where you're not supposed to, not matter what direction the stack grows. Hint: Remember what a stack is exactly... a buffer overflow can just as easily write up into another function's space and execute the overflow from there.
It actually turns out that a bunch of the random relocation and offset tricks while helpful, can still be defeated, so simply growing the stack in a different direction is not a real solution.
That sounds like a trivial subset of a certain thesis project I did In a nutshell... if you are running Windows I have bad news: malware downloaded via Firefox is still malware. And if you want real security for shit you download, the OS has to have some form of MAC system (Yes, most mean this as SELinux, but it usually means nastier policies than come with most distros)
Opteron 865 chip...
If you want to build a 4/8 way machine (which is the only reason to buy from the 8x series) $1500 is not a bad price for a chip at all, and $2149 for the dual-core is only ~40% markup! If you want cheap.. buy a normal PC, after all the extra CPU's won't make your games faster and many of the server boards that take these chips don't even bother with high-speed graphics ports since they're designed to be servers. Opterons are cheap (err.. inexpensive) compared to Itaniums or other 64 bit architectures out there.
AAAGGGH!!! Ok... last line....
it's not difficult to see why this stuff is so freakin' cool
Long day walking the floor at FOSE
And Tiger was on display. Although the Apple guys were tight lipped about whether it was official or not (don't fire anyone Steve they didn't spill the beans!)
Even more interesting from my perspective was that from the talks I had with them, their server line and the X-raid stuff is starting to garner a lot more interest in government areas that were previously closed to anything related to Apple. I'd seen their stuff online, but once you get to see it first-hand and see the prices it's difficult to see why this stuff is so freakin' cool.