Actually the indicator in the Steam hardware survey of a PIII would be lacking SSE2, currently Steam is showing 100% of computers surveyed as having both SSE2 and SSE3. Even then the vast majority are post Core2 even with support for SSE4.1 and SSE4.2. I honestly suspect this is a non-issue that affects primarily industrial applications, and honestly most of them are probably running XP without a care in the world. I was actually quite surprised by this story in the first place because I had been under the impression windows has required SSE2 since Vista.
For those not aware the vulnerability has already been patched as part of KB4016240 which is already been pushed out on windows update. The details of the issue are fully disclosed.
The case Texas v. White settled this over a century ago. No state in the union has the right to secede. Talk of secession is itself in violation of Title 1 of the Smith Act: Sedition as the only way to secede is via the violent overthrow of the United States government.
actually.... the old standby is that undefined behavior is just that:
Undefined behavior -- behavior, upon use of a nonportable or erroneous program construct,... for which the standard imposes no requirements. Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to having demons fly out of your nose.
That it's secure according to this headline.... which doesn't make sense at all, it's arguing that security by obscurity works... and it doesn't... Period
Many People seem to have the same misconception you've perpetuated here, that a reactor can be SCRAM'd just by dropping the rods into it. The fact of the matter is that a reactor has a MASSIVE latent heat of reaction (this doesn't tend to happen as much in military reactors because they are near weapons grade and thus have less radioactive by-products that need to decay). This heat MUST be dissipated or the core will melt. One way to get around this issue is to use a natural circulation reactor. Or to maintain an extra supply of coolent on a gravity feed.
The fact of the matter as the parent post makes is that insecure password storage is a far larger issue, many many sites just store the passwords plaintext in a DB. If you're lucky they are bothering to use SHA1 on them first (without a salt). The website owner feeling smart adds salts but is still using SHA1 and a single round of hashing (cracking complexity... trivial). A real smart one decides he's going to use multi-round hashing, and perhaps even a stronger hash or better algorithm designed to be slower HMACSHA512 etc. If you're really really lucky they'll be a professional and use a third party module for authentication that implements PBKDF2/PKCS#5 using a really slow hash.
But lets be honest folks... security is always priority number 2, just like it's Safety Second in a dangerous workplace
Actually no it's not... Linux has that already and it works just fine, anyone who has gone through the pain of getting flash player to work before the x64 port can tell you. This is actually more similar (albeit with more restrictions) to setting the /LARGEADDRESSAWARE:NO option on the linker in Visual C++. An option you'll notice that comes with a significant warning about interoperability. Microsoft solved this problem by making pointer handling the developer's job, this meant that they could continue to use x86-64 libraries without an issue but all malloc operations would return addresses that are safe to sign extend.
The benefit on windows is that you:
Use less ram on an x64 bit OS than a corresponding x86 application would, this is because you won't have x64 threads for each x86 thread you have going, and won't have to load the thunking DLLs
In theory could interop with x86 code since your pointers are safe, however this is not supported
1 - POSIX. If you want to develop for POSIX, Linux supports this out of the box.
As a developer that is precisely the problem, the only consistent API in Linux is POSIX, and compared to say... WIN32 Core (minwin) that's fine. But as MinWin is essentially just Linux with Busy-box running on it, you have POSIX and nothing else. But as a developer to justify developing for Linux I need a set of rich distribution independent API's that are universal across the entirety of GNU/Linux, and not specific to a particular build of a particular distribution. Without that I'm left chasing distro install numbers to justify what I'm going to develop for or I have to trust that some downstream developer isn't going to screw up my code (See the Debian OpenSSL incident).
So what am I saying? I'm saying that very choice and customization that makes Linux the OS that so many love and cherish is what is preventing desktop development outside the tightly coupled applications that come with the various shells. Fundamentally I don't think that is an issue that can be addressed. Perhaps each shell could agree to make a subsystem to allow their apps to run on the other... (much like QuickTime allows Itunes on Windows) but that would require a lot of development for little payoff so I don't see it happening.
It's not treason since the Indian government is not an enemy of the United States. Furthermore to be charged with treason there has to be two eye witnesses, "No Person shall be convicted of Treason unless on the testimony of two Witnesses to the same overt act, or on confession in open court."
More likely someone will get charged under the Espionage Act, which has no such requirements... assuming of course that the US Government was not complicit in this.
I honestly think this is a special case, the Indian Government was essentially threatening to ban them from that market. To the fan bois out there that are touting FOSS as the solution... you might want to go read some of the security blogs before you go and do that. You'll quickly realize that it doesn't matter if the OS manufacturers make backdoors or not. ALL OSs have major security holes, Windows has a codebase stretching back nearly 30 years, as does Linux, I can guarantee that both have bugs that can lead to privilege escalation, some of which can be executed with remarkable reliability, e.g. Stuxnet.
My primary concern here is that this violates the Foreign Corrupt Practices Act, as giving the Indian Government the backdoor constitutes a bribe.
The world was a different place in the early days of NT 4
Arguably true... but only for the monolithic win 9x series releases, which aren't relevant to this topic since the NT kernel was developed independently within Microsoft by Dave Cutler from DEC. It was Microsoft's first truly modern operating system. As many comm enters above me have mentioned NT originally did have functions such as font rendering in userspace due to its heavy hardware abstraction. As the pending issues with 9x loomed however MS could read the writing, on the wall; porting 9x to Unicode (it was ANSI throughout, a separate "Layer for Unicode" had to be used to run Unicode programs on 9x machines) as well as supporting newer hardware (AHCI, USB, true Plug and Play) was going to be nearly impossible (the attempt was called Windows ME). So Microsoft began with NT4 to prep for the mass migration from 9x. Since the average consumer at the time didn't want to drop $3k for a workstation that would be able to run the NT model correctly, Microsoft made some compromises to the OS for the sake of speed.
No, it wasn't. NT4 was released in 1996. By that time, many people here on/. had been exploiting bugs like that for 10 or 20 years already. Granted, mostly for fun or to cheat in (single-player) games, but still...
NT4 already had a security architecture. There was a different place available (basically anywhere outside ring0) and it should have been put there, and it definitely should have been obvious to anyone with three grams of brains that stuff like this doesn't belong into ring0.
You however are making the assumption that everybody in Microsoft talks to each other. A most incorrect assumption. The reality is most likely that WinDiv (The division responsible for the OS) made the assumption that fonts would not be loaded from insecure sources, e.g. Word documents. The Office division however faced the problem of what do you do when some user uses a font that is not on another users system? So they made the decision to allow the embedding of fonts into the file format, along with a bunch of other really bad decisions in hindsight (remember the Melissa virus?) that would have been caught if they had had the same security reviews as WinDiv did. To compound the problem, Office used unpublished and most likely unhardened APIs (it probably still does in parts) that allowed it the capabilities to do things like on the fly font loading something that wasn't exposed to the rest of us until Windows 2000 (NT 5.0). My point being that at the time it WAS a safe decision as far as WinDiv was concerned. Should they have been a little more careful with those unpublished APIs... yes they should have, it would have prevented a lot of anti-trust issues, but they weren't. So here we are with yet another security bug.
... but many places do have laws like that (Boulder, CO has a limit of four unrelated people under one roof), mind you they are intended to prevent people from running brothels... but still
I wish we had a score six to mod this too. As a.NET developer I agree that devs who only know.NET or Java or PHP etc. are a liability, we recently interviewed someone with extensive.NET experience, looked to be a good candidate too, and then we asked him about exception handling. He responded that anything that can throw should be wrapped in a try/catch block this answer was fine... although of concern. However what caused us to see other candidates was his reasoning "Because that's the way we've always done it where I work," a statement revealing how much he fundamentally didn't understand about what he was working with. While he was a perfectly fine technical coder he was under no circumstances an engineer. I think this is what the critically misguided CEO meant, however I still wouldn't work for someone that decides any technology is a liability, every technology has its purpose and to discount that as he has done is just idiotic
Honestly.... this argument is stupid, Group Policy arose because on Windows everything is a COM object with an ACL and it was neigh impossible to manage to provide even a modicum of security without some sort of system policy at a high level. Linux of course doesn't need this because it operates in a fundamentally different manner where everything is a file and the file system permissions (group based) determine if a is executable or not. Thus the Linux kernel doesn't need to know what specific COM+ handler needs to be loaded, but rather if a file is a supported executable format or not, and what to do from there. Both systems have fundamental advantages, Linux is deceptively simple leading to a power on the command line that is daunting for many users. Whereas Windows can be easy worked with to extend using COM and the registry (The registry was never designed to hold most of the crap that people shove in there... it was designed to be a central repository of information for COM objects).
If anything this model shows MS's lack of foresight into the importance of networking and their focus on the single standalone box.
Sadly this is due to COM+ registration, every single file type that has a program association (including exe in which case the association is the loader) is registered to tell windows what to do with it.
.NET CLR takes care of some of these issues... but doesn't sadly change the overall system. The fact that so few devs take advantage of application manifests to lock down their programs and use Side by Side to specify the precise dependencies allows virus writers to simply bypass the OS and aim for third party apps
no.... but there should be one about mis-quotes... like the one in the original post, moore's law is about the performance per PRICE point not about performance
Using thin clients in an enterprise or small to medium business environment gives you a lot of benefits to the long term bottom line. From a security perspective, you cut the "attack surface" of your network very sharply - from dozens if not hundreds or even thousands of desktops that each need antivirus, security updates, administration, and security monitoring, down to a handful of servers that you can lock down pretty tightly. From a support perspective, you are no longer managing all those desktops, you are now managing a handful of servers.
BULLSHIT From that statement alone I can only surmise that you have never ever worked in IT, the client is ALWAYS part of the equation, a thin client still has firmware and connectivity issues. Not to mention that rolling out any sort of network upgrade goes from being a minor project, to a critical time sensitive operation. Furthermore there is some benefit to having the infrastructure distributed, if your central server fails (and it will) then you're entire company can continue to work locally while you repair or rebuild.
Now, once you've gotten your THICK client computer, running your THIN client setup (wait... is it Windows 7? Is that thin client possible? Or is it "thin" client possible?).
Technically with Windows 7 enterprise you can set up a client to boot from a VHD (I have seen this implemented as this is how Windows deployment services works), and in-fact to use network licenses of software(office etc.) however I've never actually seen this implemented. That said you could in theory go for a medium client? if that is a term? where the software is run locally but is based on network licenses. Personally I wouldn't want to try it, but that's me
Re:Terrible, terrible and juvenile summary.
on
New IE Zero Day
·
· Score: 1
I had a friend that worked at MS... he said that the most common browser there wasn't IE... but firefox. So to me this is really the MS devs being selfish and wanting firefox to support h.264 content for HTML 5
There is one and ONLY one reason the DRM code wasn't released to Mono, and that reason is called the MPAA. The MPAA is scared shitless of linux and open source, which is why both the flash and silverlight DRM modules have never been released. So if you want to complain complain about that.
I talked to the IT department at my company recently about this... all of our infrastructure supports IPv6... only one little bit that doesn't... our upstream provider... so until ViaWest gets their act together... we won't have IPv6.
... Where IANA is the king and owns all of the IP space... granting it to its dukes (RIRs).. who in-turn grant plots to the earls (ISPs).... who inturn grant blocks to everybody else...
Slashdot Mirror
Actually the indicator in the Steam hardware survey of a PIII would be lacking SSE2, currently Steam is showing 100% of computers surveyed as having both SSE2 and SSE3. Even then the vast majority are post Core2 even with support for SSE4.1 and SSE4.2. I honestly suspect this is a non-issue that affects primarily industrial applications, and honestly most of them are probably running XP without a care in the world. I was actually quite surprised by this story in the first place because I had been under the impression windows has required SSE2 since Vista.
Three if you want to make this more fun they forgot about shakes that already existed from nuclear physics.
For those not aware the vulnerability has already been patched as part of KB4016240 which is already been pushed out on windows update. The details of the issue are fully disclosed.
The case Texas v. White settled this over a century ago. No state in the union has the right to secede. Talk of secession is itself in violation of Title 1 of the Smith Act: Sedition as the only way to secede is via the violent overthrow of the United States government.
actually.... the old standby is that undefined behavior is just that:
That it's secure according to this headline.... which doesn't make sense at all, it's arguing that security by obscurity works... and it doesn't... Period
Many People seem to have the same misconception you've perpetuated here, that a reactor can be SCRAM'd just by dropping the rods into it. The fact of the matter is that a reactor has a MASSIVE latent heat of reaction (this doesn't tend to happen as much in military reactors because they are near weapons grade and thus have less radioactive by-products that need to decay). This heat MUST be dissipated or the core will melt. One way to get around this issue is to use a natural circulation reactor. Or to maintain an extra supply of coolent on a gravity feed.
Sometimes I wish we could mod up beyond 5
The fact of the matter as the parent post makes is that insecure password storage is a far larger issue, many many sites just store the passwords plaintext in a DB. If you're lucky they are bothering to use SHA1 on them first (without a salt). The website owner feeling smart adds salts but is still using SHA1 and a single round of hashing (cracking complexity... trivial). A real smart one decides he's going to use multi-round hashing, and perhaps even a stronger hash or better algorithm designed to be slower HMACSHA512 etc. If you're really really lucky they'll be a professional and use a third party module for authentication that implements PBKDF2/PKCS#5 using a really slow hash.
But lets be honest folks... security is always priority number 2, just like it's Safety Second in a dangerous workplace
Actually no it's not... Linux has that already and it works just fine, anyone who has gone through the pain of getting flash player to work before the x64 port can tell you. This is actually more similar (albeit with more restrictions) to setting the /LARGEADDRESSAWARE:NO option on the linker in Visual C++. An option you'll notice that comes with a significant warning about interoperability. Microsoft solved this problem by making pointer handling the developer's job, this meant that they could continue to use x86-64 libraries without an issue but all malloc operations would return addresses that are safe to sign extend.
The benefit on windows is that you:
1 - POSIX. If you want to develop for POSIX, Linux supports this out of the box.
As a developer that is precisely the problem, the only consistent API in Linux is POSIX, and compared to say... WIN32 Core (minwin) that's fine. But as MinWin is essentially just Linux with Busy-box running on it, you have POSIX and nothing else. But as a developer to justify developing for Linux I need a set of rich distribution independent API's that are universal across the entirety of GNU/Linux, and not specific to a particular build of a particular distribution. Without that I'm left chasing distro install numbers to justify what I'm going to develop for or I have to trust that some downstream developer isn't going to screw up my code (See the Debian OpenSSL incident).
So what am I saying? I'm saying that very choice and customization that makes Linux the OS that so many love and cherish is what is preventing desktop development outside the tightly coupled applications that come with the various shells. Fundamentally I don't think that is an issue that can be addressed. Perhaps each shell could agree to make a subsystem to allow their apps to run on the other... (much like QuickTime allows Itunes on Windows) but that would require a lot of development for little payoff so I don't see it happening.
It's not treason since the Indian government is not an enemy of the United States. Furthermore to be charged with treason there has to be two eye witnesses, "No Person shall be convicted of Treason unless on the testimony of two Witnesses to the same overt act, or on confession in open court."
More likely someone will get charged under the Espionage Act, which has no such requirements... assuming of course that the US Government was not complicit in this.
I honestly think this is a special case, the Indian Government was essentially threatening to ban them from that market. To the fan bois out there that are touting FOSS as the solution... you might want to go read some of the security blogs before you go and do that. You'll quickly realize that it doesn't matter if the OS manufacturers make backdoors or not. ALL OSs have major security holes, Windows has a codebase stretching back nearly 30 years, as does Linux, I can guarantee that both have bugs that can lead to privilege escalation, some of which can be executed with remarkable reliability, e.g. Stuxnet.
My primary concern here is that this violates the Foreign Corrupt Practices Act, as giving the Indian Government the backdoor constitutes a bribe.
The world was a different place in the early days of NT 4
Arguably true... but only for the monolithic win 9x series releases, which aren't relevant to this topic since the NT kernel was developed independently within Microsoft by Dave Cutler from DEC. It was Microsoft's first truly modern operating system. As many comm enters above me have mentioned NT originally did have functions such as font rendering in userspace due to its heavy hardware abstraction. As the pending issues with 9x loomed however MS could read the writing, on the wall; porting 9x to Unicode (it was ANSI throughout, a separate "Layer for Unicode" had to be used to run Unicode programs on 9x machines) as well as supporting newer hardware (AHCI, USB, true Plug and Play) was going to be nearly impossible (the attempt was called Windows ME). So Microsoft began with NT4 to prep for the mass migration from 9x. Since the average consumer at the time didn't want to drop $3k for a workstation that would be able to run the NT model correctly, Microsoft made some compromises to the OS for the sake of speed.
No, it wasn't. NT4 was released in 1996. By that time, many people here on /. had been exploiting bugs like that for 10 or 20 years already. Granted, mostly for fun or to cheat in (single-player) games, but still...
NT4 already had a security architecture. There was a different place available (basically anywhere outside ring0) and it should have been put there, and it definitely should have been obvious to anyone with three grams of brains that stuff like this doesn't belong into ring0.
You however are making the assumption that everybody in Microsoft talks to each other. A most incorrect assumption. The reality is most likely that WinDiv (The division responsible for the OS) made the assumption that fonts would not be loaded from insecure sources, e.g. Word documents. The Office division however faced the problem of what do you do when some user uses a font that is not on another users system? So they made the decision to allow the embedding of fonts into the file format, along with a bunch of other really bad decisions in hindsight (remember the Melissa virus?) that would have been caught if they had had the same security reviews as WinDiv did. To compound the problem, Office used unpublished and most likely unhardened APIs (it probably still does in parts) that allowed it the capabilities to do things like on the fly font loading something that wasn't exposed to the rest of us until Windows 2000 (NT 5.0). My point being that at the time it WAS a safe decision as far as WinDiv was concerned. Should they have been a little more careful with those unpublished APIs... yes they should have, it would have prevented a lot of anti-trust issues, but they weren't. So here we are with yet another security bug.
Firefox is using:
Image (executables): 95,084K
Mapped File: 56,892K
Sharable Pages: 133,100k
Heap: 25,100K
Stack: 46,080K
Private Data (explicit mallocs): 205,280K
Page Table: 1,372K
Unusable (leftover area of explicitly allocated pages that were LESS than 64K): 9,440K
Only 10M unusable isn't bad on windows... (start inevitable trolling here) as the memory manager only allocates pages in increments on 64k
... but many places do have laws like that (Boulder, CO has a limit of four unrelated people under one roof), mind you they are intended to prevent people from running brothels... but still
I wish we had a score six to mod this too. As a .NET developer I agree that devs who only know .NET or Java or PHP etc. are a liability, we recently interviewed someone with extensive .NET experience, looked to be a good candidate too, and then we asked him about exception handling. He responded that anything that can throw should be wrapped in a try/catch block this answer was fine... although of concern. However what caused us to see other candidates was his reasoning "Because that's the way we've always done it where I work," a statement revealing how much he fundamentally didn't understand about what he was working with. While he was a perfectly fine technical coder he was under no circumstances an engineer. I think this is what the critically misguided CEO meant, however I still wouldn't work for someone that decides any technology is a liability, every technology has its purpose and to discount that as he has done is just idiotic
Honestly.... this argument is stupid, Group Policy arose because on Windows everything is a COM object with an ACL and it was neigh impossible to manage to provide even a modicum of security without some sort of system policy at a high level. Linux of course doesn't need this because it operates in a fundamentally different manner where everything is a file and the file system permissions (group based) determine if a is executable or not. Thus the Linux kernel doesn't need to know what specific COM+ handler needs to be loaded, but rather if a file is a supported executable format or not, and what to do from there. Both systems have fundamental advantages, Linux is deceptively simple leading to a power on the command line that is daunting for many users. Whereas Windows can be easy worked with to extend using COM and the registry (The registry was never designed to hold most of the crap that people shove in there... it was designed to be a central repository of information for COM objects).
If anything this model shows MS's lack of foresight into the importance of networking and their focus on the single standalone box.
Sadly this is due to COM+ registration, every single file type that has a program association (including exe in which case the association is the loader) is registered to tell windows what to do with it.
.NET CLR takes care of some of these issues... but doesn't sadly change the overall system. The fact that so few devs take advantage of application manifests to lock down their programs and use Side by Side to specify the precise dependencies allows virus writers to simply bypass the OS and aim for third party apps
no.... but there should be one about mis-quotes... like the one in the original post, moore's law is about the performance per PRICE point not about performance
Using thin clients in an enterprise or small to medium business environment gives you a lot of benefits to the long term bottom line. From a security perspective, you cut the "attack surface" of your network very sharply - from dozens if not hundreds or even thousands of desktops that each need antivirus, security updates, administration, and security monitoring, down to a handful of servers that you can lock down pretty tightly. From a support perspective, you are no longer managing all those desktops, you are now managing a handful of servers.
BULLSHIT From that statement alone I can only surmise that you have never ever worked in IT, the client is ALWAYS part of the equation, a thin client still has firmware and connectivity issues. Not to mention that rolling out any sort of network upgrade goes from being a minor project, to a critical time sensitive operation. Furthermore there is some benefit to having the infrastructure distributed, if your central server fails (and it will) then you're entire company can continue to work locally while you repair or rebuild.
Now, once you've gotten your THICK client computer, running your THIN client setup (wait... is it Windows 7? Is that thin client possible? Or is it "thin" client possible?).
Technically with Windows 7 enterprise you can set up a client to boot from a VHD (I have seen this implemented as this is how Windows deployment services works), and in-fact to use network licenses of software(office etc.) however I've never actually seen this implemented. That said you could in theory go for a medium client? if that is a term? where the software is run locally but is based on network licenses. Personally I wouldn't want to try it, but that's me
and now the obligatory link to college humor: browsers and the modes of transportation they resemble
I had a friend that worked at MS... he said that the most common browser there wasn't IE... but firefox. So to me this is really the MS devs being selfish and wanting firefox to support h.264 content for HTML 5
There is one and ONLY one reason the DRM code wasn't released to Mono, and that reason is called the MPAA. The MPAA is scared shitless of linux and open source, which is why both the flash and silverlight DRM modules have never been released. So if you want to complain complain about that.
I talked to the IT department at my company recently about this... all of our infrastructure supports IPv6... only one little bit that doesn't... our upstream provider... so until ViaWest gets their act together... we won't have IPv6.
oh I know... but it's fun to make fun of it this way... since it is very superficially identical to the feudal land-granting system
... Where IANA is the king and owns all of the IP space... granting it to its dukes (RIRs).. who in-turn grant plots to the earls (ISPs) .... who inturn grant blocks to everybody else...