Questionable, at the very least. If he had friends who smoked pot, who he hung out with while they smoked it, who he was close enough with to trust them enough to get in the car with them driving high, he'd have picked up, at the very least, the basic terminology required to argue intelligently on the topic.
I believe I, at the very least, hinted at that when I said "or the manufacturer doesn't make parts available". If you think for a moment that HP et al aren't checking the hardware identifiers of MXM modules the same way they check hardware identifiers on wi-fi cards (I had an HP that refused to boot with a wi-fi card not on their "approved" list, instead halting before POST with an error about an unsupported card; I later learned that HP isn't the only one doing this), you're quite mistaken. That means, if you want a new graphics card, you have to get it through your laptop's manufacturer; if they don't make the parts available, well, that's that and good luck. Try eBay if all you need is to replace a bad one, but if you're looking to upgrade, well, sorry Jack.
A cynic would say they're removing overclocking as it'll impact on their plans to release slightly faster versions of the same chip later this year...
That would almost make sense if we were talking about desktops, where the user can replace the GPU. That's typically not an option in a laptop; even if the GPU is designed to be replaceable, it's oft not designed to be upgradeable, or the manufacturer doesn't make parts available. And I say almost because anyone who cares about having the fastest laptop GPU on the block enough that they overclock their laptop GPU will run out and buy one of the new models that has a GPU that comes from the factory running at the same cockspeed their current GPU is overclocked to, so they can overclock it further; bonus points if it's clocked faster from the factory. The people for whom this will be an issue are the very same people who'd be giving nVidia their money either way.
That was remote content, not remote execution. Think of it more like taking calculateBulletTrajectory() and offloading it's task to the game server. Sure, you can tap the FIRE button without being connected to the server, but your game will likely crash, since it won't know which way the bullet is heading. I'd have suggested something a little less lag-sensitive than calculating the trajectory of the fast-moving object you just carefully aimed and set into motion, but you and I both know that gaming companies would want to offload the most critical part of their game, so it had to be just right in order to not destroy gameplay.
On the other hand, if they did that... Imaging the funky paths people could make their bullets take by writing their own game servers. The local game not having the code to calculate the trajectory means the local game can no longer validate the input it's getting for where a bullet should be. That could actually be fun and I encourage the studios to try it, but only once.
Yes, that's better, but if your competition makes it easier for them to get up and running, the average incompetent user will use your competition. That brings us back to no password or a simple default.
but even a weak security measure is better than none at all
At least the vendors put *some* thought into security. These systems are intended to be accessed via other systems which often have a numeric keypad as their only source of input, so it actually makes sense that the password would be so limited; it's stronger than your ATM PIN, which is really only secure because it's backed by somewhat robust intrusion detection (fail your PIN 3 times, ATM keeps the card, attack stops).
Mind you, there are ways around that, but it's enough to stop most attackers, as the dumb ones won't know how to get around it and the smart ones won't be willing to put forth the expense unless they're 100% positive they can get more out of the account than it will cost them to get at it; but we already know it's much more difficult to stop a targeted attack like that. Given the seeming success of the ATM PIN, a simple 6 digit passcode, rate limiting, and reporting failed logins would be more than adequate to protect this system, perhaps coupled with a blacklist; we don't know that the additional features don't exist, since the station owner couldn't be assed to enable the passcode, which is the first step in making any of that even remotely useful; even more likely is that the devices ship with a huge "CONNECT TO INTERNAL NETWORK ONLY" label, which was also ignored.
IMO shipping with *no* default password is safer than shipping with, say, the same default on all devices or a default based on the device's serial number, which seems to be the norm lately; at least then you *know* it's not actually protected. Default passwords provide a false sense of security to people who don't realize that everyone and their mother has the means to find out what that password is; it's the equivalent to no password at all, without the benefit of being so obviously insecure.
Damn, sad to hear that... WindowPain would have been a better fit. That or Glasscutter since, you know, it lets pretty much anyone cut a huge hole in Windows.
Well, of course! All the hackers use Linux and other Open Source software because they don't want to be vulnerable to the same exploits they're using! Damn Linux!:P
To be fair, if the manufacturers of the devices you have in your house are as competent as the manufacturers of the devices compromised here, it would be mostly your fault if they got hacked; the station owners never set up the passcodes. I say mostly because the manufacturer did limit it to a 6 digit numeric code, but even a weak security measure is better than none at all; presumably, these also report failed logins, which would have alerted the owner to a problem before the hackers got in, but how useful is that when the owner doesn't require a login in the first place?
The thing is, while Windows is getting better about this, no doubt in part due to people shouting "Linux does the better than we do and we're losing market share", Linux seems to be getting worse about it, no doubt in part due to people shouting "Windows doesn't care about this and it's not hurting their market share". It's a matter of perspective, and the views of people firmly entrenched in one camp will necessarily be the opposite of the views of those entrenched in the opposing camp. That's not to say that either camp is right or wrong, either; Linux did handle configuration better than Windows and Windows didn't care about keeping the filesystem clean, and both camps made their realizations around the same time and the Windows team set out to fix the problem, while the Linux team set out to create it. So, here we are, with Windows machines now easier to configure than Linux was 5 years ago and Linux machines now more of a pain in the ass than Windows was 5 years ago.
I'm happy for the Windows camp, I really am; they may bitch about their GUI, but things aren't really any better for Linux users, aside fro ma GUI being largely irrelevant to a Linux sysadmin; meanwhile, the Windows admins now seem to have the easier job.
Personally, I jumped to OSX for the desktop about 4 years ago and haven't looked back except when I've needed to test something on Windows or Linux, and I'm more and more tempted to move to BSD for my servers.
Linux is mature enough that people are now trying to fix things that really aren't broken and they are breaking them in the process.
On one hand, that means it's well-tested. On the other hand, it means it was well-tested until someone decided the well-tested bits should be replaced for... well... what reason, exactly? Systemd makes BSD look very attractive on the server.
I like CentOS too, but CentOS 7 will have systemd for reasons I don't understand.
It's based on RedHat, which now has systemd. CentOS doesn't make decisions, they take RedHat's old packages and release them as the new CentOS, then continue maintaining them with RedHat's current patches. On one hand, some might complain that the packages are old, they're from the previous release of RedHat, while on the other hand, it means that CentOS users haven't had to deal with systemd yet while RedHat users have. The knife cuts both ways.
You won't get an answer. Supporters of systemd are all either too ashamed of themselves to admit they were wrong, or too snowed to know it but not quite sure why they like it. It's like crack, most of us know not to use it, some of us still will, and of those who do, some will be able to walk away, but most will end up stuck on it whether they like it or not. Sadly, I'm in the latter group.
Well, systemd uses its own binary logging format; if systemd isn't working, good luck reading it. Yes, I know I can use syslog in addition to systemd's own logging; well, I could, if systemd would start it. And even if/when it does, if systemd's bad behavior occurs before syslog starts, it's on systemd's log but not syslog's, which, again, means it's only useful when systemd is behaving, which, if it were, would render the whole point null.
Slashdot Mirror
Questionable, at the very least. If he had friends who smoked pot, who he hung out with while they smoked it, who he was close enough with to trust them enough to get in the car with them driving high, he'd have picked up, at the very least, the basic terminology required to argue intelligently on the topic.
I believe I, at the very least, hinted at that when I said "or the manufacturer doesn't make parts available". If you think for a moment that HP et al aren't checking the hardware identifiers of MXM modules the same way they check hardware identifiers on wi-fi cards (I had an HP that refused to boot with a wi-fi card not on their "approved" list, instead halting before POST with an error about an unsupported card; I later learned that HP isn't the only one doing this), you're quite mistaken. That means, if you want a new graphics card, you have to get it through your laptop's manufacturer; if they don't make the parts available, well, that's that and good luck. Try eBay if all you need is to replace a bad one, but if you're looking to upgrade, well, sorry Jack.
A cynic would say they're removing overclocking as it'll impact on their plans to release slightly faster versions of the same chip later this year...
That would almost make sense if we were talking about desktops, where the user can replace the GPU. That's typically not an option in a laptop; even if the GPU is designed to be replaceable, it's oft not designed to be upgradeable, or the manufacturer doesn't make parts available. And I say almost because anyone who cares about having the fastest laptop GPU on the block enough that they overclock their laptop GPU will run out and buy one of the new models that has a GPU that comes from the factory running at the same cockspeed their current GPU is overclocked to, so they can overclock it further; bonus points if it's clocked faster from the factory. The people for whom this will be an issue are the very same people who'd be giving nVidia their money either way.
Which corporation are you describing, again?
So you think you should shoplift as much as possible from grocery stores? Hint: They'll just all increase prices to make you pay more
No, they'll make you and me pay more. The shoplifter's price doesn't change.
So are most companies, and this will continue to be the case for as long as we allow corporations (or any other type of company) to be people.
You thought his code would be any better than his lyrics? (yes, I know who M.C. Escher is... I just prefer to imagine him as a rapper)
That was remote content, not remote execution. Think of it more like taking calculateBulletTrajectory() and offloading it's task to the game server. Sure, you can tap the FIRE button without being connected to the server, but your game will likely crash, since it won't know which way the bullet is heading. I'd have suggested something a little less lag-sensitive than calculating the trajectory of the fast-moving object you just carefully aimed and set into motion, but you and I both know that gaming companies would want to offload the most critical part of their game, so it had to be just right in order to not destroy gameplay.
On the other hand, if they did that... Imaging the funky paths people could make their bullets take by writing their own game servers. The local game not having the code to calculate the trajectory means the local game can no longer validate the input it's getting for where a bullet should be. That could actually be fun and I encourage the studios to try it, but only once.
Is that your goto solution for preventing reverse engineering?
If you have an uptime lasting longer than 4 decades, call your sysadmin.
You're replying to someone who's never coded in C and, therefore, does not understand what you're talking about. Don't bother.
Such indentation is important
and irrelevant to this discussion.
Yes, that's better, but if your competition makes it easier for them to get up and running, the average incompetent user will use your competition. That brings us back to no password or a simple default.
but even a weak security measure is better than none at all
At least the vendors put *some* thought into security. These systems are intended to be accessed via other systems which often have a numeric keypad as their only source of input, so it actually makes sense that the password would be so limited; it's stronger than your ATM PIN, which is really only secure because it's backed by somewhat robust intrusion detection (fail your PIN 3 times, ATM keeps the card, attack stops).
Mind you, there are ways around that, but it's enough to stop most attackers, as the dumb ones won't know how to get around it and the smart ones won't be willing to put forth the expense unless they're 100% positive they can get more out of the account than it will cost them to get at it; but we already know it's much more difficult to stop a targeted attack like that. Given the seeming success of the ATM PIN, a simple 6 digit passcode, rate limiting, and reporting failed logins would be more than adequate to protect this system, perhaps coupled with a blacklist; we don't know that the additional features don't exist, since the station owner couldn't be assed to enable the passcode, which is the first step in making any of that even remotely useful; even more likely is that the devices ship with a huge "CONNECT TO INTERNAL NETWORK ONLY" label, which was also ignored.
IMO shipping with *no* default password is safer than shipping with, say, the same default on all devices or a default based on the device's serial number, which seems to be the norm lately; at least then you *know* it's not actually protected. Default passwords provide a false sense of security to people who don't realize that everyone and their mother has the means to find out what that password is; it's the equivalent to no password at all, without the benefit of being so obviously insecure.
Damn, sad to hear that... WindowPain would have been a better fit. That or Glasscutter since, you know, it lets pretty much anyone cut a huge hole in Windows.
Well, of course! All the hackers use Linux and other Open Source software because they don't want to be vulnerable to the same exploits they're using! Damn Linux! :P
To be fair, if the manufacturers of the devices you have in your house are as competent as the manufacturers of the devices compromised here, it would be mostly your fault if they got hacked; the station owners never set up the passcodes. I say mostly because the manufacturer did limit it to a 6 digit numeric code, but even a weak security measure is better than none at all; presumably, these also report failed logins, which would have alerted the owner to a problem before the hackers got in, but how useful is that when the owner doesn't require a login in the first place?
You're defending it as though I was complaining. I wasn't.
The thing is, while Windows is getting better about this, no doubt in part due to people shouting "Linux does the better than we do and we're losing market share", Linux seems to be getting worse about it, no doubt in part due to people shouting "Windows doesn't care about this and it's not hurting their market share". It's a matter of perspective, and the views of people firmly entrenched in one camp will necessarily be the opposite of the views of those entrenched in the opposing camp. That's not to say that either camp is right or wrong, either; Linux did handle configuration better than Windows and Windows didn't care about keeping the filesystem clean, and both camps made their realizations around the same time and the Windows team set out to fix the problem, while the Linux team set out to create it. So, here we are, with Windows machines now easier to configure than Linux was 5 years ago and Linux machines now more of a pain in the ass than Windows was 5 years ago.
I'm happy for the Windows camp, I really am; they may bitch about their GUI, but things aren't really any better for Linux users, aside fro ma GUI being largely irrelevant to a Linux sysadmin; meanwhile, the Windows admins now seem to have the easier job.
Personally, I jumped to OSX for the desktop about 4 years ago and haven't looked back except when I've needed to test something on Windows or Linux, and I'm more and more tempted to move to BSD for my servers.
The Metro tiles are an improvement in that regard!
Larger targets?
Came here to say this, see that you already did.
Linux is mature enough that people are now trying to fix things that really aren't broken and they are breaking them in the process.
On one hand, that means it's well-tested. On the other hand, it means it was well-tested until someone decided the well-tested bits should be replaced for... well... what reason, exactly? Systemd makes BSD look very attractive on the server.
I like CentOS too, but CentOS 7 will have systemd for reasons I don't understand.
It's based on RedHat, which now has systemd. CentOS doesn't make decisions, they take RedHat's old packages and release them as the new CentOS, then continue maintaining them with RedHat's current patches. On one hand, some might complain that the packages are old, they're from the previous release of RedHat, while on the other hand, it means that CentOS users haven't had to deal with systemd yet while RedHat users have. The knife cuts both ways.
You won't get an answer. Supporters of systemd are all either too ashamed of themselves to admit they were wrong, or too snowed to know it but not quite sure why they like it. It's like crack, most of us know not to use it, some of us still will, and of those who do, some will be able to walk away, but most will end up stuck on it whether they like it or not. Sadly, I'm in the latter group.
Well, systemd uses its own binary logging format; if systemd isn't working, good luck reading it. Yes, I know I can use syslog in addition to systemd's own logging; well, I could, if systemd would start it. And even if/when it does, if systemd's bad behavior occurs before syslog starts, it's on systemd's log but not syslog's, which, again, means it's only useful when systemd is behaving, which, if it were, would render the whole point null.
Follow?