I do believe that they're most likely statically linking the drivers on those players, which constitutes an extention of the Linux kernel. There's a sort of exemption for dynamically loaded modules, in that it's been stated that it's considered to be "okay" for binary only modules, but there will be no considerations given for preserving any of the module to kernel interfaces so your module can break at any revision of the kernel. The problem with modules are that while they allow flexibility in the ammount of support provided in the kernel, they bulk up a kernel that only needs ONE set of specific device drivers loaded. In that context, it makes a BUNCH of sense to make them statically linked in the kernel.
Now, do you see the issue here? The vendors are statically linking Sigma Solutions' driver into their kernel versions. Direct violation of the GPL- period.
Uh, dude, if you're using VM-Ware to run Linux, you're going about it the hard way. Not to mention you don't get things like 3D acceleration, etc. and it runs a hell of a lot slower.
And, NO, I don't try to force people to use Linux- but a LOT of Windows people try the other way around by way of sending Word attachments, etc.
You might want to take this clue: You didn't NEED to reply to my comment. You didn't even NEED to start the thread. You like Windows. FINE. I'm not going to berate you over it, but if you don't like the editorial slant, you CAN go elsewhere. If not, well, deal with the slant then. You don't see ME going and whining about the OBVIOUS bias on ZD Net sites or any of the Windows specific tech sites, etc. Why should I cut YOU any slack on that regard?
It's down even lower on the totem pole than Linux for the same reasons. I negligently forgot about that option because it's just not used all that often around me.
Are they hypothetical exploits (as in doable, but in practice, hard to execute an attack with...) or are they holes big enough to pass a tractor-trailer truck through length-wise?
Many of the IE exploits, while they're proportionate to the overall userbase, are disturbingly of the "BAD" (as in Igor's sense of the term in Ghostbusters) variety.
And slanted in the exact manner you're WHINING about? If you don't like the sound, change the channel- or at least ignore the noise. It's not a hard thing to not bother reading further or commenting on a subject you don't agree with the editorial commentary on, you know...
XP, or, Linux. Linux still has the appearance to many of being complex and difficult to use, even though that's largely not the case (it's not difficult, it's different) for most distributions.
When you buy a PC, what OS is bundled with it?
XP.
When you buy software, what OS is it generally designed for these days?
XP.
You didn't make a choice other than to accept what was forced upon you- just like all the other good little consumers.
Blocking ports isn't always an answer (in my not so humble opinion, they're not an answer ever- it's a band-aid...) so you REALLY should fix the buffer overflow and other issues instead of side-stepping the problem. Of course, if the best that someone can do is block a port because of financial considerations or relative difficulty (I'd believe BOTH in the case of Microsoft...) then that says volumes to me about the company in question- and they'd not get my dollars in return.
Funny that, I use Linux almost exclusively on the computers in my house and at work...
...it would have been found by the Black-hat soon afterwards. The software is as it is, if a potential or real exploit can be found by anyone, it's going to be found in the first place no matter who finds it first.
I would rather be told by a White/Grey-hat cracker even if the parties responsible for the software know at the same time than find out the hard way through Black-hat activity.
Like others that have posted, I don't care one whit about the "reputation" of a company or a group doing a piece of afflicted software. I want to know about the problem so I can offline the machine or the software- or, at the very least make an INFORMED decision about it's continued useage.
Damn, damn, damn, we're going to have to wait for the time when he's up for Election- there isn't any process at the Federal level as the Constitution doesn't provide for it.
People, go look at this tally of yeas and nays- if your Representative in Congress voted YES to this atrocity, they need to be removed from office in the next election. It doesn't matter if they didn't know about the extra provisions, they shouldn't have voted on it if they didn't agree 100% with 100% of the contents. Do what it takes to make people understand this. Do what it takes to make people vote for anyone else. Do what it takes to get people in those polls.
They're more fundamental than that. A buffer overflow allows you to execute code in ring 0 that would otherwise not be ran. This isn't the same thing as something like MS Blaster and it's ilk. Now, those were found the same way as the buffer overflow exploits, but they could have been even more easily found via an audit of the source code. Under Open Source, the code's looked at by MANY people- it's likely to be found and corrected. In Closed Source, it's not so likely and it's more likely that a code leak will result in someone else doing an audit and finding weaknesses and exploiting them.
There's tons of others. It made a big splash on the tech news circles- and then was apparently promptly forgotten for some unknown reason. Strictly speaking, MS has already had one of their critical breaches they talk about and they couldn't have instituted a scheme like they're talking about in the timeframe from when this was discovered to now (i.e. It pretty much had to be in place or largely so because of the scope and scale of the effort in question...).
I do believe the issue isn't just code compromise (i.e. putting back doors in...), but in the case of the closed source, finding exploits and backdoors. I need only point to the rationale that MS gave for not disclosing pieces of their source code- it would endanger National Security. Now, either that was a dodge, in which case, Allchin should be doing time in at least Club Fed for lying to a Judge, or it's the God's truth. If it's the God's truth, being in the open is going to reveal most of those things and get them zoomed right off the bat- if it's closed, only the people working on it know about the code (well, and anyone that manages to see it without them looking...) so you don't have as many people looking over the code in question so you end up with things like MS Blaster which caused a packet storm from Hell on the Internet.
Didn't those Russian hackers get ahold of some of their "highest" value data, namely the entire source tree for one of their operating system versions?
I can't use their damn stuff- I run Linux. Unless it's on ALL the mainstream OSes (and Linux is one of them these days), then it's not fair for everyone.
You're comparing apples to oranges, not to mention that your info's a little off...
1) A Nehemiah core C3 runs really close to the same performance of a comparably clocked Celeron, with the same general power consumption of a Samuel2 core (For those that don't know, part of how VIA's chip originally got it's low power is that the FPU was underclocked by a factor of 1/2). It's a nice chip overall, but it's not really intended (nor are they USING it that way) for scientific or gaming applications even though you can use it for that. The C3's winning usages is in something like a media PC, workgroup servers, and embedded systems where you need low power consumption, relatively low cost, and relatively high performance compared to other x86 embedded solutions.
2) The Crusoe and similar chips are very fast executing VLIW CPUs (very much like the Itanium...) that have code morphing that translates x86-32 instructions into comparable sets of instructions for the VLIW CPU- in fact it's very good at doing this sort of thing. The reason it's less desirable with a desktop or gaming application is that you're exceeding the VLIW code cache regularly, meaning you have to keep recompiling the x86 instructions into the native VLIW ones. For a scientific application, the same task gets executed time and time again and usually ends up with most, if not all, of the code in the pre-morphed code cache. At that point, you're now in the high-performance domain with very little power consumption. The Crusoe in this application would consume less power than the G5 and run just as fast. (Check the article that you're commenting on...)
Do some thinking outside of the box here, what's good or great on a desktop machine isn't always the optimal choice for supercomputing clusters or HA clusters. Depends on a bunch of factors, including what you're going to be running on the systems in question and what kind of environmental conditions you're going to be facing.
...that they offered the position in the first place. Folks, if they can't afford you, they shouldn't have been interviewing you or extending offers. A layoff like that means they needed the person but didn't have the money to pay them.
Saying he was hired for developing "software" is overbroad and there is precedent indicating that you have to be specific (and "software" isn't specific in the slightest...) about the class of work in question. In this case, unless he was hired to do software doing things like Netflix Fanatic, Apple's not within their rights to pursue this.
"I still write in 16 bit assembly because the BIOS still runs in 16 bit mode. It would be nice if AMD broke backward compatibility for once and started off with 64 bit firmware so I could at least write 64 bit assembly. The mixed-mode stuff (16 and 32 bit) that I would have to do for OS programming is getting ridiculous..."
Uh... You might want to check out the architechture spec on the AMD64 IA. It's not got ANY 16-bit or 8-bit backwards x86 compatibility.
Saying that they're in the business of making software doesn't really hold up to scrutiny. What KIND of software? If it's not in the same line of business, it's definitely NOT theirs. If it is, but is something that they'd not have done (and this CAN be proven pretty well...) then it's also not theirs.
I got one of my previous employers to explicitly declare seven different projects as being not covered, even on company time, because they were Open Source projects that I was working on when they hired. Combine that with the "my time is mine, not theirs" added in for good measure and I consider that a win.
If they're distributing it as a binary distribution, the source code offer/distribution requirement APPLIES.
I do believe that they're most likely statically linking the drivers on those players, which constitutes an extention of the Linux kernel. There's a sort of exemption for dynamically loaded modules, in that it's been stated that it's considered to be "okay" for binary only modules, but there will be no considerations given for preserving any of the module to kernel interfaces so your module can break at any revision of the kernel. The problem with modules are that while they allow flexibility in the ammount of support provided in the kernel, they bulk up a kernel that only needs ONE set of specific device drivers loaded. In that context, it makes a BUNCH of sense to make them statically linked in the kernel.
Now, do you see the issue here? The vendors are statically linking Sigma Solutions' driver into their kernel versions. Direct violation of the GPL- period.
Uh, dude, if you're using VM-Ware to run Linux, you're going about it the hard way. Not to mention you don't get things like 3D acceleration, etc. and it runs a hell of a lot slower.
And, NO, I don't try to force people to use Linux- but a LOT of Windows people try the other way around by way of sending Word attachments, etc.
Think about it.
You might want to take this clue: You didn't NEED to reply to my comment. You didn't even NEED to start the thread. You like Windows. FINE. I'm not going to berate you over it, but if you don't like the editorial slant, you CAN go elsewhere. If not, well, deal with the slant then. You don't see ME going and whining about the OBVIOUS bias on ZD Net sites or any of the Windows specific tech sites, etc. Why should I cut YOU any slack on that regard?
It's down even lower on the totem pole than Linux for the same reasons. I negligently forgot about that option because it's just not used all that often around me.
How devastating are they?
Are they hypothetical exploits (as in doable, but in practice, hard to execute an attack with...) or are they holes big enough to pass a tractor-trailer truck through length-wise?
Many of the IE exploits, while they're proportionate to the overall userbase, are disturbingly of the "BAD" (as in Igor's sense of the term in Ghostbusters) variety.
And slanted in the exact manner you're WHINING about? If you don't like the sound, change the channel- or at least ignore the noise. It's not a hard thing to not bother reading further or commenting on a subject you don't agree with the editorial commentary on, you know...
XP, or, Linux. Linux still has the appearance to many of being complex and difficult to use, even though that's largely not the case (it's not difficult, it's different) for most distributions.
When you buy a PC, what OS is bundled with it?
XP.
When you buy software, what OS is it generally designed for these days?
XP.
You didn't make a choice other than to accept what was forced upon you- just like all the other good little consumers.
Blocking ports isn't always an answer (in my not so humble opinion, they're not an answer ever- it's a band-aid...) so you REALLY should fix the buffer overflow and other issues instead of side-stepping the problem. Of course, if the best that someone can do is block a port because of financial considerations or relative difficulty (I'd believe BOTH in the case of Microsoft...) then that says volumes to me about the company in question- and they'd not get my dollars in return.
Funny that, I use Linux almost exclusively on the computers in my house and at work...
...it would have been found by the Black-hat soon afterwards. The software is as it is, if a potential or real exploit can be found by anyone, it's going to be found in the first place no matter who finds it first.
I would rather be told by a White/Grey-hat cracker even if the parties responsible for the software know at the same time than find out the hard way through Black-hat activity.
Like others that have posted, I don't care one whit about the "reputation" of a company or a group doing a piece of afflicted software. I want to know about the problem so I can offline the machine or the software- or, at the very least make an INFORMED decision about it's continued useage.
Damn, damn, damn, we're going to have to wait for the time when he's up for Election- there isn't any process at the Federal level as the Constitution doesn't provide for it.
People, go look at this tally of yeas and nays- if your Representative in Congress voted YES to this atrocity, they need to be removed from office in the next election. It doesn't matter if they didn't know about the extra provisions, they shouldn't have voted on it if they didn't agree 100% with 100% of the contents. Do what it takes to make people understand this. Do what it takes to make people vote for anyone else. Do what it takes to get people in those polls.
Burgess voted YES for this damned thing.
How does one try to get a recall on a Rep- this one just pretty much broke his Oath of Office by passing this one.
They're more fundamental than that. A buffer overflow allows you to execute code in ring 0 that would otherwise not be ran. This isn't the same thing as something like MS Blaster and it's ilk. Now, those were found the same way as the buffer overflow exploits, but they could have been even more easily found via an audit of the source code. Under Open Source, the code's looked at by MANY people- it's likely to be found and corrected. In Closed Source, it's not so likely and it's more likely that a code leak will result in someone else doing an audit and finding weaknesses and exploiting them.
A quick Google search ("russian hackers microsoft") comes up with:
0 52.txt
http://www.newsmax.com/articles/?a=2000/10/27/180
There's tons of others. It made a big splash on the tech news circles- and then was apparently promptly forgotten for some unknown reason. Strictly speaking, MS has already had one of their critical breaches they talk about and they couldn't have instituted a scheme like they're talking about in the timeframe from when this was discovered to now (i.e. It pretty much had to be in place or largely so because of the scope and scale of the effort in question...).
I do believe the issue isn't just code compromise (i.e. putting back doors in...), but in the case of the closed source, finding exploits and backdoors. I need only point to the rationale that MS gave for not disclosing pieces of their source code- it would endanger National Security. Now, either that was a dodge, in which case, Allchin should be doing time in at least Club Fed for lying to a Judge, or it's the God's truth. If it's the God's truth, being in the open is going to reveal most of those things and get them zoomed right off the bat- if it's closed, only the people working on it know about the code (well, and anyone that manages to see it without them looking...) so you don't have as many people looking over the code in question so you end up with things like MS Blaster which caused a packet storm from Hell on the Internet.
I went a similar direction just a moment ago in reply to someone, but this is sooo much better.
They still missed the mark...
It's security is as strong as white tissue paper.
Didn't those Russian hackers get ahold of some of their "highest" value data, namely the entire source tree for one of their operating system versions?
I can't use their damn stuff- I run Linux. Unless it's on ALL the mainstream OSes (and Linux is one of them these days), then it's not fair for everyone.
You're comparing apples to oranges, not to mention that your info's a little off...
1) A Nehemiah core C3 runs really close to the same performance of a comparably clocked Celeron, with the same general power consumption of a Samuel2 core (For those that don't know, part of how VIA's chip originally got it's low power is that the FPU was underclocked by a factor of 1/2). It's a nice chip overall, but it's not really intended (nor are they USING it that way) for scientific or gaming applications even though you can use it for that. The C3's winning usages is in something like a media PC, workgroup servers, and embedded systems where you need low power consumption, relatively low cost, and relatively high performance compared to other x86 embedded solutions.
2) The Crusoe and similar chips are very fast executing VLIW CPUs (very much like the Itanium...) that have code morphing that translates x86-32 instructions into comparable sets of instructions for the VLIW CPU- in fact it's very good at doing this sort of thing. The reason it's less desirable with a desktop or gaming application is that you're exceeding the VLIW code cache regularly, meaning you have to keep recompiling the x86 instructions into the native VLIW ones. For a scientific application, the same task gets executed time and time again and usually ends up with most, if not all, of the code in the pre-morphed code cache. At that point, you're now in the high-performance domain with very little power consumption. The Crusoe in this application would consume less power than the G5 and run just as fast. (Check the article that you're commenting on...)
Do some thinking outside of the box here, what's good or great on a desktop machine isn't always the optimal choice for supercomputing clusters or HA clusters. Depends on a bunch of factors, including what you're going to be running on the systems in question and what kind of environmental conditions you're going to be facing.
...that they offered the position in the first place. Folks, if they can't afford you, they shouldn't have been interviewing you or extending offers. A layoff like that means they needed the person but didn't have the money to pay them.
Saying he was hired for developing "software" is overbroad and there is precedent indicating that you have to be specific (and "software" isn't specific in the slightest...) about the class of work in question. In this case, unless he was hired to do software doing things like Netflix Fanatic, Apple's not within their rights to pursue this.
Uh... You might want to check out the architechture spec on the AMD64 IA. It's not got ANY 16-bit or 8-bit backwards x86 compatibility.
Saying that they're in the business of making software doesn't really hold up to scrutiny. What KIND of software? If it's not in the same line of business, it's definitely NOT theirs. If it is, but is something that they'd not have done (and this CAN be proven pretty well...) then it's also not theirs.
I got one of my previous employers to explicitly declare seven different projects as being not covered, even on company time, because they were Open Source projects that I was working on when they hired. Combine that with the "my time is mine, not theirs" added in for good measure and I consider that a win.