No, but it does stop exploitable code from being used to set up un-signed executables to run on boot, etc. Sure, the code can be exploited in memory, but if you try and modify any executable on disk, the signature will break and the code won't run by default. Makes it much harder for a virus to set itself up permanently on the machine, and much more difficult to spread via infecting executables.
Given that the slow lane = 130-160km/h, middle lane is 160-200km/h and the left lane(s) are 200km/h+
Oh and yes, this can be done fairly safely. The germans and other europeans do it every day. Of course if you're driving some beat up old piece of shit, you shouldnt be in the fast lane, but if you're in a big beemer or merc it is no sweat.
Not really, given that I guarantee probably 70-80 percent of enterprises have at least one scanner or fax-to-email gateway that uses TIFF. And even if they switch that to PDF.... well, let's just say that if you compare the security history of PDF and TIFF, it's like a race in the special olympics, but TIFF would probably actually win.
Additionally, to delete a message within outlook you must click on it first. Which means if you have the preview window displayed, it will be parsed and displayed in the preview window.
I would suggest that probably 99.9% of the non-nerd population open emails from unrecognised strangers. Especially when you include those with a spoofed return address or other obfuscation.
Problem is, most email to fax gateways use either TIFF or PDF, and most of them are TIFF. Though PDF isn't any better (in fact, historically it is much worse, security wise) given that most people seem to use adobe reader to open them.
It's called code-signing, and every time someone suggests it, the/. crowd are up in arms about how you're not free to run what you want on your own computer, conveniently disregarding the idea that you can sign code yourself.
If time is an issue, subtract the time you spend installing Linux (or drivers) from OS X which is preinstalled and works out of the box.
Seriously, installing Xcode is a case of opening the app store, search, typing xcode, clicking install and then doing something else in the background. Like say, writing code in vi or Emacs like you would on Linux if that's your thing while the compiler installs.
We get it, you don't like OS X - that's fine. but the stuff you're whining about is really, really irrelevant.
I find it highly amusing that a Linux person is whinging about "that's not UNIX" when many of the most recent changes to Linux including stuff like system fly completely in the face of the "UNIX way" of doing things - simplicity of implementation above all else.
But hey, if you'd actually used any real UNIX systems you wouldn't have made that stupid comment about all unix systems including C compilers in the first place. Neither Solaris, SCO OpenServer, or AIX systems I have used (all more close to the original Unix than Linux) have included C compilers in the install out of the box. On most of them, the compilers were paid add-ons, unless you went for the third party option and installed GCC (which is even further removed from being part of the operating system than how apple supports Xcode as an optional component).
And yeah, we're not in exploration, but actual mining (digging ore out of the ground) so most of our applications are focused on mine design, production reporting, etc. I know a lot of that sort of stuff used to run on Unix (Vulcan, for one) and Alphas, but for the past decade or so it's been shifting pretty comprehensively to Windows.
Ahh, i was waiting for that. You also said "useful programming environment". Jury is ut on Python 3, even the Python documentation suggests it may not be a good idea.
Seriously, I'd LOVE to see intel enable multi-socket for broadwell mobile CPUs. Can you imagine - 2x quad core CPUs, 2x integrated intel graphics (some variant of SLI or similar GPU load sharing). 8 Cores. 16 threads. ~70-90w TDP. You could stick that shit in a laptop - when running on battery just turn off a socket. When running on AC, it would fly.
If you're referring to the Iris GT3e - the GT3e is a mobile part itself. And its part of the CPU, so it is competitive with GT650M in around HALF THE POWER. In other words, if intel were to enable it for multi-socket SMP, they could have a dual quad core system with two GT3e Iris Pro GPUs in a similar thermal/power envelope as the previous model machines with Ivy Bridge + Nvidia GT650M.
Not really, it's not. Intel have been making massive performance improvements in relative terms (2-4x previous generations for a couple of generations now), whereas Nvidia and AMD are making far smaller leaps in percentage terms. yes, they're still a long away ahead but the gap is closing gradually. And of course mobile (and thus performance PER WATT) is becoming a lot more important.
Slashdot Mirror
No, but it does stop exploitable code from being used to set up un-signed executables to run on boot, etc. Sure, the code can be exploited in memory, but if you try and modify any executable on disk, the signature will break and the code won't run by default. Makes it much harder for a virus to set itself up permanently on the machine, and much more difficult to spread via infecting executables.
Given that the slow lane = 130-160km/h, middle lane is 160-200km/h and the left lane(s) are 200km/h+
Oh and yes, this can be done fairly safely. The germans and other europeans do it every day. Of course if you're driving some beat up old piece of shit, you shouldnt be in the fast lane, but if you're in a big beemer or merc it is no sweat.
Preview turned on. Click message to delete it. Outlook parses it and displays in the preview window.
Not really, given that I guarantee probably 70-80 percent of enterprises have at least one scanner or fax-to-email gateway that uses TIFF. And even if they switch that to PDF.... well, let's just say that if you compare the security history of PDF and TIFF, it's like a race in the special olympics, but TIFF would probably actually win.
strcpy() and buffer overflows?
Additionally, to delete a message within outlook you must click on it first. Which means if you have the preview window displayed, it will be parsed and displayed in the preview window.
I would suggest that probably 99.9% of the non-nerd population open emails from unrecognised strangers. Especially when you include those with a spoofed return address or other obfuscation.
Problem is, most email to fax gateways use either TIFF or PDF, and most of them are TIFF. Though PDF isn't any better (in fact, historically it is much worse, security wise) given that most people seem to use adobe reader to open them.
Flaw in the image processing code.
It's called code-signing, and every time someone suggests it, the /. crowd are up in arms about how you're not free to run what you want on your own computer, conveniently disregarding the idea that you can sign code yourself.
And yes, it's the only real solution.
You mean, aside from the
etc.
"like systemd" (autocorrect)
If time is an issue, subtract the time you spend installing Linux (or drivers) from OS X which is preinstalled and works out of the box.
Seriously, installing Xcode is a case of opening the app store, search, typing xcode, clicking install and then doing something else in the background. Like say, writing code in vi or Emacs like you would on Linux if that's your thing while the compiler installs.
We get it, you don't like OS X - that's fine. but the stuff you're whining about is really, really irrelevant.
I find it highly amusing that a Linux person is whinging about "that's not UNIX" when many of the most recent changes to Linux including stuff like system fly completely in the face of the "UNIX way" of doing things - simplicity of implementation above all else.
But hey, if you'd actually used any real UNIX systems you wouldn't have made that stupid comment about all unix systems including C compilers in the first place. Neither Solaris, SCO OpenServer, or AIX systems I have used (all more close to the original Unix than Linux) have included C compilers in the install out of the box. On most of them, the compilers were paid add-ons, unless you went for the third party option and installed GCC (which is even further removed from being part of the operating system than how apple supports Xcode as an optional component).
he said bugfix/test, not release.
However, faster compile time means faster development and debugging.
Turn warnings off...
What's to say this isn't the plan?
Whether it is called a GPU or a CPU, if intel makes it and ships it, I don't think they particularly care.
And yeah, we're not in exploration, but actual mining (digging ore out of the ground) so most of our applications are focused on mine design, production reporting, etc. I know a lot of that sort of stuff used to run on Unix (Vulcan, for one) and Alphas, but for the past decade or so it's been shifting pretty comprehensively to Windows.
Yeah, the Netapp runs on a FreeBSD variant. however all the management, reporting (Oncommand, DFM, etc.) requires a Windows host.
Ahh, i was waiting for that. You also said "useful programming environment". Jury is ut on Python 3, even the Python documentation suggests it may not be a good idea.
Better option: just increase main memory bandwidth, and then everything gets better.
Seriously, I'd LOVE to see intel enable multi-socket for broadwell mobile CPUs. Can you imagine - 2x quad core CPUs, 2x integrated intel graphics (some variant of SLI or similar GPU load sharing). 8 Cores. 16 threads. ~70-90w TDP. You could stick that shit in a laptop - when running on battery just turn off a socket. When running on AC, it would fly.
Which benchmark?
If you're referring to the Iris GT3e - the GT3e is a mobile part itself. And its part of the CPU, so it is competitive with GT650M in around HALF THE POWER. In other words, if intel were to enable it for multi-socket SMP, they could have a dual quad core system with two GT3e Iris Pro GPUs in a similar thermal/power envelope as the previous model machines with Ivy Bridge + Nvidia GT650M.
Not really, it's not. Intel have been making massive performance improvements in relative terms (2-4x previous generations for a couple of generations now), whereas Nvidia and AMD are making far smaller leaps in percentage terms. yes, they're still a long away ahead but the gap is closing gradually. And of course mobile (and thus performance PER WATT) is becoming a lot more important.