Depending on compiler options, some code that isn't completely valid (no overflow/underflow/etc.) can end up logically completely different when you turn on optimization.
We frequently discover a bug and need to fix it without upversioning the whole package (which could result in other incompatibilities with the rest of the system).
So we track down the code for the version we're using, get it building from source with suitable config options, and then fix the bug. In the simple case the bugfix is present in a later version and we can just backport it. In the tricky case you need to get familiar enough with the code to fix it (and hopefully in a way that the upstream maintainers will accept).
./configure, make, make install assumes you're building on the target machine. Many times you want to build on one machine and deploy on another. Even now, there are a lot of packages that don't work properly when cross-compiling. So you end up hardcoding config files, overriding options, patching the source/Makefiles, etc.
Also, in our environment we need to isolate the build system from the host environment to avoid contamination from the host libraries, and we need to version-control the build system so that we can go back and build the same product we built three years ago for the purposes of fixing a bug for a paying client.
So while open-source helps a lot, many times it takes significant effort to bring in some arbitrary package and build it from source.
Otherwise, it might be possible to create something that is simultaneously a valid image file *and* valid PHP (or SQL, or whatever) code and bypass any checks that you add to validate the file.
An 8-core Xeon (not i7) is not a mid-range desktop. Nor is "enough RAM to load my entire system drive into", or an SSD system drive.
Even now, those are all higher-end in the general scheme of things. More common on enthusiast machines, sure, but far from "mid-range" in a business system.
this is no different than arbitrage has been for centuries, only faster. Baron von Rothschild used this to make money on the defeat of Napoleon at Waterloo, since his messengers were hours faster than the official royal messengers
Just because it has been done for centuries doesn't necessarily mean it is right, or just.
In these days of connected everything, why should they need to go through someone with a seat on the exchange? Why can't the seller post their bid, and the buyer accept it, with no middlemen other than the exchange itself?
What part of "...these features are not fully supported under Red Hat Enterprise Linux Subscription Level Agreements, may not be functionally complete, and are not intended for production use." didn't make sense?
Why were you using a technology preview feature in production when they explicitly say not to?
I suspect that socially maladjusted males feel a lot more free to be creepy about booth babes than cosplayers in equally revealing costumes. Something about the fact that they're being paid to work there seems to make creepy guys feel like they have the right to hit on them constantly.
(And I say that as a male programmer who has seen way too many attractive women hit on constantly at conferences.)
I agree with the point that they're selling sex appeal, and I would certainly classify it along the continuum that has prostitution at one end. Swimsuit models (or even more so lingerie models) also fall along the same lines in my book.
I have a problem with your classification of marriage, however. While there *are* marriages or other relationships that are a way of converting sex to dollars, I do not believe this is true of all of them. A good marriage is a partnership, both partners contribute what they're best suited for. At one point in the marriage one partner might be contributing most financially, at other points the other one might take over. It's not just sex for money.
While it's an interesting idea, many phones can be used in multiple countries so you're talking a global database of valid IMEI numbers. Good luck getting that organized.
Also, a workable kill-switch would make it totally useless. If all we do is block cell connectivity it's still essentially an ipod or equivalent, so not entirely without value.
A phone that is being used one-handed is a really easy target for someone to grab on the run...much easier than trying to get someone's wallet or purse.
Slashdot Mirror
Depending on compiler options, some code that isn't completely valid (no overflow/underflow/etc.) can end up logically completely different when you turn on optimization.
We frequently discover a bug and need to fix it without upversioning the whole package (which could result in other incompatibilities with the rest of the system).
So we track down the code for the version we're using, get it building from source with suitable config options, and then fix the bug. In the simple case the bugfix is present in a later version and we can just backport it. In the tricky case you need to get familiar enough with the code to fix it (and hopefully in a way that the upstream maintainers will accept).
./configure, make, make install assumes you're building on the target machine. Many times you want to build on one machine and deploy on another. Even now, there are a lot of packages that don't work properly when cross-compiling. So you end up hardcoding config files, overriding options, patching the source/Makefiles, etc.
Also, in our environment we need to isolate the build system from the host environment to avoid contamination from the host libraries, and we need to version-control the build system so that we can go back and build the same product we built three years ago for the purposes of fixing a bug for a paying client.
So while open-source helps a lot, many times it takes significant effort to bring in some arbitrary package and build it from source.
Otherwise, it might be possible to create something that is simultaneously a valid image file *and* valid PHP (or SQL, or whatever) code and bypass any checks that you add to validate the file.
especially compared with clearcase....at least from a developer point of view
If you find a bug on a release, you fix it on the trunk, test it on the trunk for a while, then merge it out onto the (supposedly stable) release.
That way if it turns out the fix is bad, you haven't messed up the release more than it already is.
If they're running Win8 then I can kind of understand it. WinRT not so much...
An 8-core Xeon (not i7) is not a mid-range desktop. Nor is "enough RAM to load my entire system drive into", or an SSD system drive.
Even now, those are all higher-end in the general scheme of things. More common on enthusiast machines, sure, but far from "mid-range" in a business system.
this is no different than arbitrage has been for centuries, only faster. Baron von Rothschild used this to make money on the defeat of Napoleon at Waterloo, since his messengers were hours faster than the official royal messengers
Just because it has been done for centuries doesn't necessarily mean it is right, or just.
In these days of connected everything, why should they need to go through someone with a seat on the exchange? Why can't the seller post their bid, and the buyer accept it, with no middlemen other than the exchange itself?
To claim your fifth amendment rights to not incriminate yourself, they've decided you need to explicitly claim them.
Also, there's nothing stopping the person from just not saying anything at all and asking for a lawyer.
In this case the person answered *some* questions, then didn't answer one, and never explicitly took the fifth.
to power the location-finding mechanism when the main battery is dead
What part of "...these features are not fully supported under Red Hat Enterprise Linux Subscription Level Agreements, may not be functionally complete, and are not intended for production use." didn't make sense?
Why were you using a technology preview feature in production when they explicitly say not to?
The company I'm with uses both redhat and centos (as well as other paid and free linux vendors).
Sometimes you want the paid-for support of a RedHat license. Other times it's an unnecessary expense.
was disappointed when I couldn't find out anything about what she actually did that was interesting other than recreate existing processes
I suspect that socially maladjusted males feel a lot more free to be creepy about booth babes than cosplayers in equally revealing costumes. Something about the fact that they're being paid to work there seems to make creepy guys feel like they have the right to hit on them constantly.
(And I say that as a male programmer who has seen way too many attractive women hit on constantly at conferences.)
I agree with the point that they're selling sex appeal, and I would certainly classify it along the continuum that has prostitution at one end. Swimsuit models (or even more so lingerie models) also fall along the same lines in my book.
I have a problem with your classification of marriage, however. While there *are* marriages or other relationships that are a way of converting sex to dollars, I do not believe this is true of all of them. A good marriage is a partnership, both partners contribute what they're best suited for. At one point in the marriage one partner might be contributing most financially, at other points the other one might take over. It's not just sex for money.
While it's an interesting idea, many phones can be used in multiple countries so you're talking a global database of valid IMEI numbers. Good luck getting that organized.
Also, a workable kill-switch would make it totally useless. If all we do is block cell connectivity it's still essentially an ipod or equivalent, so not entirely without value.
A phone that is being used one-handed is a really easy target for someone to grab on the run...much easier than trying to get someone's wallet or purse.
so it's not quite so rare as you make it sound.
Just to add a couple options.
As far as I know it's not available in VMware Workstation.
If this isn't a troll, you're giving actual software developers a bad name.
The definition of obfuscation is to confuse, bewilder, or stupefy, or to make obscure or unclear.
In security, the normal rule is that the algorithm chosen should still be secure _even if the attacker knows what it is_.
On the other hand, passwords, crypto keys, etc. are all pieces of data that are secrets. This is a very different thing from obscure.
You shouldn't be programming a satnav or messing with a paper map while driving--pull over for that. Following a route on a satnav is fine.
There are many studies showing that the vast majority of people *suck* at multitasking.