Well before sugar the bogeyman was salt, and before that fat... When they reduce the fat and salt, the food ends up tasting like crap so they add more things (including sugar) to compensate. Now there is a push to remove sugar too, so we'll no doubt end up with something much worse... The more they've been messing with our foods under the guise of making it healthier, the more people have been becoming obese.
Sugar, salt and fat occurs naturally in food, and we require some quantities of each. Instead of messing with the foods we've eaten for thousands of years, we should go back to original recipes with sensible quantities of all of the above, and do away with all this artificially engineered crap.
I doubt anything is being kept back by Intel, it's just that Intel target a higher common denominator... Binaries in centos or rhel are compiled for a generic amd64 cpu, and therefore can't take advantage of features present in newer processors. A gentoo install targeting the specific hardware being used to test would probably beat both of them.
Not so much, more the fact it can be embedded inside documents that are frequently sent around via insecure channels (ie email) and you have a huge security accident waiting to happen...
In most cases like this, excel is a very poor tool for the job but it just happens to be the only tool provided so they make do and eventually get so tied in to insecure and fragile practices that it's hard to get out again.
Isn't VAT charged in the member state where the retailer is based, irrespective of where the buyer is, assuming the goods are being shipped inside the EU.
Pai's staff said that states and other localities do not have jurisdiction over broadband because it is an interstate service and that it would subvert federal policy for states and localities to impose their own rules.
It's actually an international service, so by the same logic surely the federal government shouldn't have jurisdiction either?
I don't use ssh-agent, rather i use the ssh config to specify using another instance of "ssh -w" as a proxy in order to connect to specific hosts, that way the intermediary host is basically just used as a proxy and your local device still authenticates to the far host even if there are one or more intermediary hosts in the way.
Firewire was relatively popular until it got superseded by thunderbolt and usb3.. SCSI was better than the alternatives at the time, and didn't get replaced until the alternatives had caught up to it.
And if you have *ACCOUNT* lockout policies then you get a dos attack instead...
And brute force attacks can still succeed because you just try lots of usernames with a small number of the most common passwords.
Account lockouts are stupid, you want to block the source of the attack (as well as using stronger authentication than passwords on any externally facing system).
You'd setup up a VPN to use certs instead of passwords, which are much more difficult to brute force... Even if you successfully got access to the VPN, you'd then only have access to the RDP port which means you now have a second target to attack, so it adds an extra line of defence. And hopefully a competent sysadmin would notice VPN logins from unexpected locations.
Switching SSH to require keys and to reject password auth helps a lot...Although some very stupid brute force scripts will keep trying and cause unnecessary load... Some scripts are even aggressive enough to dos the ssh service.
There needs to be accountability for third party vendors who insist on insecure configurations like this... The trouble is most of their customers don't have the knowledge in house to realise how insecure it is. I've encountered a few vendors who made ridiculous demands like this and their response has always been "but our other customers dont have a problem".
They want 24/7 RDP or VNC access direct from the internet, won't use a vpn (which to be fair, having 100 clients each using a different vpn technology becomes very painful), use weak passwords and won't even supply a fixed source address that the connection would come from. And then the system they want access to won't be isolated from anything else, so it provides a trivial route into the network.
No part of the browser runs as root unless your stupid enough to explicitly do so... It runs as your user account, and then sandboxes things like javascript and plugins even further.
You know how to stop it? You don't. It will never stop. The only way to counter it is a well educated, independently and critically thinking population.
Well said and very true, however we'll never reach this state because an easily manipulated population is exactly what those in power want, they just want the exclusive ability to manipulate.
Yes, the election system is not fair to the voters because not everyone's vote is counted equally and that's the point he was making.
That said, everyone knows how the system works, and the system is fair to the candidates. They played the game within the established rules and trump won.
The problem could be solved by educating people to question what they read and do their own research when a subject matters rather than blindly believing what someone else tells them...
But an educated populace is not what the incumbents want, they like the idea of a populace that believes whatever propaganda they read, what they don't like is for anyone else to have the ability to put propaganda infront of large numbers of people.
Nothing wrong with a locked bootloader if it's easily unlocked.. These phones have a locked bootloader as a defence against accidental breakage or malware, you can unlock the bootloader easily if you choose to do so.
Android itself isn't the problem, it's the applications and customisations applied by google, handset makers and network operators. The stock open source Android (AOSP) is fine, and there are various community builds available.
Several of the top500 are using GPUs, but for calculations rather than displaying graphics. Having an active video display on a large cluster would be stupid, most supercomputer nodes won't have screens attached and while the power consumption of an idle display controller is pretty low its not 0, and multiplied by thousands of nodes its a terrible waste of power.
There was an "HPC" edition of windows 2003, and microsoft managed to sponsor a few places to build clusters using it that made it into the top500 list... I don't recall anyone ever using it of their own volition tho, only if microsoft were paying, and at least one of those clusters was a dual boot experiment which climbed 50 places in the ranking when booted to linux.
When you have unlimited, your more likely to make a casual call... If there is a per minute cost, especially a high one, you're more likely to think about the cost and not make the call unless its absolutely necessary. So if you switch from unlimited to per-minute, your usage is actually likely to decrease further.
There's no contradiction, we know for sure it uses *some* ports but do not know what other ports it *might* use. Your notion of blocking the known ports is flawed as it may well communicate via other as yet unknown ports.
See subject: Point me to a valid reputable security community source that shows more ports being used than what I listed.
I don't need to prove that more ports are being used, you need to prove that other ports are *NOT* being used in order to validate your claim that filtering at the network layer is effective.
Monitoring in/out communique from router logs external to the PC would tell fact of what ports it used easily beyond Intel's docs.
Monitoring the network traffic only shows the communication that actually takes place, not the communication that *could* take place. We don't know if any circumstances exist in which it could attempt other forms of communication. Sure the network router could log this traffic were it to take place, but we cannot be sure of all the triggers which would make it do so. That also assumes that the device only has wired connectivity, which is connected directly to your networking equipment. If the device has any form of wireless connectivity it could attempt communication with anything that's within range.
Unless we are 100% sure of all the possible network communication the device could perform, and what could potentially trigger it, a blacklist approach at the network gateway can never be truly effective.
We don't know, and a lack of knowledge is dangerous.
The manufacturer of the lock will keep records and can construct duplicate keys if they wanted to do so.
Brute force should be impractical with any encryption worth using... Security holes depend on the encryption or its implementation being flawed, and only a fool would choose a system with known flaws.
Slashdot Mirror
Well before sugar the bogeyman was salt, and before that fat...
When they reduce the fat and salt, the food ends up tasting like crap so they add more things (including sugar) to compensate. Now there is a push to remove sugar too, so we'll no doubt end up with something much worse... The more they've been messing with our foods under the guise of making it healthier, the more people have been becoming obese.
Sugar, salt and fat occurs naturally in food, and we require some quantities of each. Instead of messing with the foods we've eaten for thousands of years, we should go back to original recipes with sensible quantities of all of the above, and do away with all this artificially engineered crap.
I doubt anything is being kept back by Intel, it's just that Intel target a higher common denominator...
Binaries in centos or rhel are compiled for a generic amd64 cpu, and therefore can't take advantage of features present in newer processors. A gentoo install targeting the specific hardware being used to test would probably beat both of them.
Not so much, more the fact it can be embedded inside documents that are frequently sent around via insecure channels (ie email) and you have a huge security accident waiting to happen...
In most cases like this, excel is a very poor tool for the job but it just happens to be the only tool provided so they make do and eventually get so tied in to insecure and fragile practices that it's hard to get out again.
Isn't VAT charged in the member state where the retailer is based, irrespective of where the buyer is, assuming the goods are being shipped inside the EU.
Pai's staff said that states and other localities do not have jurisdiction over broadband because it is an interstate service and that it would subvert federal policy for states and localities to impose their own rules.
It's actually an international service, so by the same logic surely the federal government shouldn't have jurisdiction either?
I don't use ssh-agent, rather i use the ssh config to specify using another instance of "ssh -w" as a proxy in order to connect to specific hosts, that way the intermediary host is basically just used as a proxy and your local device still authenticates to the far host even if there are one or more intermediary hosts in the way.
Firewire was relatively popular until it got superseded by thunderbolt and usb3..
SCSI was better than the alternatives at the time, and didn't get replaced until the alternatives had caught up to it.
And if you have *ACCOUNT* lockout policies then you get a dos attack instead...
And brute force attacks can still succeed because you just try lots of usernames with a small number of the most common passwords.
Account lockouts are stupid, you want to block the source of the attack (as well as using stronger authentication than passwords on any externally facing system).
You'd setup up a VPN to use certs instead of passwords, which are much more difficult to brute force...
Even if you successfully got access to the VPN, you'd then only have access to the RDP port which means you now have a second target to attack, so it adds an extra line of defence. And hopefully a competent sysadmin would notice VPN logins from unexpected locations.
Over a network biometrics have to be converted to digital data, basically a key or a hash which can be attacked in the normal ways.
Also once compromised, biometrics remain compromised forever...
Switching SSH to require keys and to reject password auth helps a lot...Although some very stupid brute force scripts will keep trying and cause unnecessary load... Some scripts are even aggressive enough to dos the ssh service.
There needs to be accountability for third party vendors who insist on insecure configurations like this...
The trouble is most of their customers don't have the knowledge in house to realise how insecure it is. I've encountered a few vendors who made ridiculous demands like this and their response has always been "but our other customers dont have a problem".
They want 24/7 RDP or VNC access direct from the internet, won't use a vpn (which to be fair, having 100 clients each using a different vpn technology becomes very painful), use weak passwords and won't even supply a fixed source address that the connection would come from. And then the system they want access to won't be isolated from anything else, so it provides a trivial route into the network.
Shows the flaws of account lockouts if they permit someone to launch such a trivial denial of service against your organisation.
No part of the browser runs as root unless your stupid enough to explicitly do so...
It runs as your user account, and then sandboxes things like javascript and plugins even further.
You know how to stop it? You don't. It will never stop. The only way to counter it is a well educated, independently and critically thinking population.
Well said and very true, however we'll never reach this state because an easily manipulated population is exactly what those in power want, they just want the exclusive ability to manipulate.
Yes, the election system is not fair to the voters because not everyone's vote is counted equally and that's the point he was making.
That said, everyone knows how the system works, and the system is fair to the candidates. They played the game within the established rules and trump won.
The problem could be solved by educating people to question what they read and do their own research when a subject matters rather than blindly believing what someone else tells them...
But an educated populace is not what the incumbents want, they like the idea of a populace that believes whatever propaganda they read, what they don't like is for anyone else to have the ability to put propaganda infront of large numbers of people.
Nothing wrong with a locked bootloader if it's easily unlocked..
These phones have a locked bootloader as a defence against accidental breakage or malware, you can unlock the bootloader easily if you choose to do so.
Android itself isn't the problem, it's the applications and customisations applied by google, handset makers and network operators. The stock open source Android (AOSP) is fine, and there are various community builds available.
Several of the top500 are using GPUs, but for calculations rather than displaying graphics. Having an active video display on a large cluster would be stupid, most supercomputer nodes won't have screens attached and while the power consumption of an idle display controller is pretty low its not 0, and multiplied by thousands of nodes its a terrible waste of power.
There was an "HPC" edition of windows 2003, and microsoft managed to sponsor a few places to build clusters using it that made it into the top500 list...
I don't recall anyone ever using it of their own volition tho, only if microsoft were paying, and at least one of those clusters was a dual boot experiment which climbed 50 places in the ranking when booted to linux.
When you have unlimited, your more likely to make a casual call...
If there is a per minute cost, especially a high one, you're more likely to think about the cost and not make the call unless its absolutely necessary.
So if you switch from unlimited to per-minute, your usage is actually likely to decrease further.
With physical access there are many ways...
Open the case, extract the disk, load some malware onto it, put it back in?
There's no contradiction, we know for sure it uses *some* ports but do not know what other ports it *might* use. Your notion of blocking the known ports is flawed as it may well communicate via other as yet unknown ports.
See subject: Point me to a valid reputable security community source that shows more ports being used than what I listed.
I don't need to prove that more ports are being used, you need to prove that other ports are *NOT* being used in order to validate your claim that filtering at the network layer is effective.
Monitoring in/out communique from router logs external to the PC would tell fact of what ports it used easily beyond Intel's docs.
Monitoring the network traffic only shows the communication that actually takes place, not the communication that *could* take place. We don't know if any circumstances exist in which it could attempt other forms of communication. Sure the network router could log this traffic were it to take place, but we cannot be sure of all the triggers which would make it do so. That also assumes that the device only has wired connectivity, which is connected directly to your networking equipment. If the device has any form of wireless connectivity it could attempt communication with anything that's within range.
Unless we are 100% sure of all the possible network communication the device could perform, and what could potentially trigger it, a blacklist approach at the network gateway can never be truly effective.
We don't know, and a lack of knowledge is dangerous.
The manufacturer of the lock will keep records and can construct duplicate keys if they wanted to do so.
Brute force should be impractical with any encryption worth using...
Security holes depend on the encryption or its implementation being flawed, and only a fool would choose a system with known flaws.