You seem to be confusing the benefits of NAT with what it was designed to do or what other security features are available. I guess I can't help you with this either.
I never said it had anything to do with security. I said it has security benefits. If you can't understand the difference than I can't really help you beyond that.
Security is a process. If that process is made easier for some users by using NAT, then it's a benefit. Home users can't manage firewalls effectively. NAT is a good method (even if flawed) to protect some classes of users. Is it perfect? No. But that's why you also have other protections at other layers (host-based firewall, virus scanners, etc.)
Incorrect. NAT does have a security benefit. Unless ports are opened, there is no direct inbound access into the backend subnet. Yes, firewalls exist and can protect IPv6, but having a NAT simplifies security for most home users.
In one sense I disagree of the need for solid Linux skills. The rise of short term systems (in general, DevOps) means that you don't need to be concerned with the inner workings of the system and you just use something like chef to configure the system on an as-needed basis. You won't care how long the system is stable because it'll only be around for a few hours. After that it's destroyed only to be recreated later on. You can build entire systems without even enabling SSH and having interactive access.
On the other hand, there is still a need for qualified people since not everyone has bought into DevOps. They want systems that exist for years with little to no unexpected downtime. I see this as a bit of a pendulum swinging back at some point. Not sure when.
Saying no to google is like saying no to a card catalog. That's all Google (search) is - a way to look information up. Determining how to find information is a very useful skill.
I don't think it was their intent - it's just how things progressed.
In return for getting a monopoly in a town, the cable company set up local access channels, gave free cable TV to schools and town offices, likely gave free Internet to all those areas too. The money to pay those things needs to come from somewhere - either you pay more taxes or you pay more on the cable bill. We're now at the point where all these things have been established for years and the cable companies have contracts with towns granting them monopoly status for the length of the contract. My town now has competition since I can choose between Comcast and FIOS but you can't realistically have a brand new cable company come in and offer service - there's limited amount of space on telephone poles. Maybe we move to a model where Comcast offers the physical layer as some sort of Ethernet-like protocol and customers get to choose their Internet/Cable/phone from one of multiple providers.
Now that his series from the 90s is on Netflix, I noticed that he used Metric for all his measurements. Moving metric would eventually cut the number of wrenches/sockets I need in half and require fewer trips to the toolbox (@$%$# metric....#$$# nope imperial...)
I was really just throwing out drives and times. I had name-brand systems that were in a RAID 0 to consolidate two drives (the drive contents were expendable since this was just scratch space) and they ran for many years with few failures.
I suspect not, since his point seemed to be that you shouldn't be using RAID 0 for data that you care about anyway.
I meant, what if there was a bug in the RAID 5 code that caused similar corruption? This is equivalent (almost) to blaming the victim. Yes, you did risky behavior, but the problem wasn't caused because of the risky behavior.
You can't remove drives from a ZFS pool - once they're in (even if you have free space on other drives), the number of drives can't go down. Which really bothers me. With LVM you can evacuate data off of drives and shrink the pv. LVM in itself isn't a filesystem, but if you think of a pool as an LVM volume the functionality is somewhat similar.
RAID 0 is only as unstable as its least stable component. In this case it's most likely a drive failure, and most drives are fairly long MTBFs. The chances of a disk failure increase as a function of time and number of drives deployed. A two-drive RAID 0 will be more stable than a five-drive RAID 0 which will be more stable than a 10 drive RAID 0 that's three years old. In the case of higher RAID levels, you can remove a single (or multiple) drive failure as the point of failure. In this case, the point of failure is the kernel, so it's perfectly legitimate to consider this a really bad problem. Would you say the same thing if the bug affected RAID 1 or RAID 5?
I have 4 drives in a RAID 10, so two RAID 1 arrays of two drives each combined together in a RAID 0. I did it mostly because I can add new drive at any time and just chain them onto the RAID 0.
The first claim makes my "rant" — about the need to use a reverse of the usual burden-of-proof principle for Executive government officials — on-topic and otherwise appropriate.
Trying to prove a negative? And you're wondering why I'm rolling my eyes at you?
Slashdot Mirror
NAT was not designed with security in mind. The security it does offer is a side effect.
Oof. I've never seen that, but can imagine it happens with more regularity than would be good.
If they only used NAT? Sure, but I didn't say that.
You seem to be confusing the benefits of NAT with what it was designed to do or what other security features are available. I guess I can't help you with this either.
I never said it had anything to do with security. I said it has security benefits. If you can't understand the difference than I can't really help you beyond that.
*facepalm*
Try explaining DHCP, MAC addresses, and static assignments to the average person. Good luck
Exactly why NAT has some security benefits. Set it and leave it alone as a part of other security processes at the OS layer.
Security is a process. If that process is made easier for some users by using NAT, then it's a benefit. Home users can't manage firewalls effectively. NAT is a good method (even if flawed) to protect some classes of users. Is it perfect? No. But that's why you also have other protections at other layers (host-based firewall, virus scanners, etc.)
*facepalm* Ok, you go with whatever you think.
It is a security benefit. It might not be the intended purpose, but that doesn't change the fact.
Incorrect. NAT does have a security benefit. Unless ports are opened, there is no direct inbound access into the backend subnet. Yes, firewalls exist and can protect IPv6, but having a NAT simplifies security for most home users.
In one sense I disagree of the need for solid Linux skills. The rise of short term systems (in general, DevOps) means that you don't need to be concerned with the inner workings of the system and you just use something like chef to configure the system on an as-needed basis. You won't care how long the system is stable because it'll only be around for a few hours. After that it's destroyed only to be recreated later on. You can build entire systems without even enabling SSH and having interactive access.
On the other hand, there is still a need for qualified people since not everyone has bought into DevOps. They want systems that exist for years with little to no unexpected downtime. I see this as a bit of a pendulum swinging back at some point. Not sure when.
Saying no to google is like saying no to a card catalog. That's all Google (search) is - a way to look information up. Determining how to find information is a very useful skill.
I don't think it was their intent - it's just how things progressed.
In return for getting a monopoly in a town, the cable company set up local access channels, gave free cable TV to schools and town offices, likely gave free Internet to all those areas too. The money to pay those things needs to come from somewhere - either you pay more taxes or you pay more on the cable bill. We're now at the point where all these things have been established for years and the cable companies have contracts with towns granting them monopoly status for the length of the contract. My town now has competition since I can choose between Comcast and FIOS but you can't realistically have a brand new cable company come in and offer service - there's limited amount of space on telephone poles. Maybe we move to a model where Comcast offers the physical layer as some sort of Ethernet-like protocol and customers get to choose their Internet/Cable/phone from one of multiple providers.
I think it says that because he doesn't have a realistic shot at the candidacy.
Now that his series from the 90s is on Netflix, I noticed that he used Metric for all his measurements. Moving metric would eventually cut the number of wrenches/sockets I need in half and require fewer trips to the toolbox (@$%$# metric....#$$# nope imperial...)
Slashdot still doesn't offer https support.
If you have an opinion (especially "that's stupid!"), be sure to back it up with facts before you open your mouth.
It's going to be good for lawyers and shareholders. But yeah, that's about it.
I understand that you think "we would respond differently if this were RAID 5" is a sign of hypocrisy or something. But it's not really that.
Yes it is, and that's a very short sighted approach. I hope you're not a developer.
I was really just throwing out drives and times. I had name-brand systems that were in a RAID 0 to consolidate two drives (the drive contents were expendable since this was just scratch space) and they ran for many years with few failures.
I suspect not, since his point seemed to be that you shouldn't be using RAID 0 for data that you care about anyway.
I meant, what if there was a bug in the RAID 5 code that caused similar corruption? This is equivalent (almost) to blaming the victim. Yes, you did risky behavior, but the problem wasn't caused because of the risky behavior.
You can't remove drives from a ZFS pool - once they're in (even if you have free space on other drives), the number of drives can't go down. Which really bothers me. With LVM you can evacuate data off of drives and shrink the pv. LVM in itself isn't a filesystem, but if you think of a pool as an LVM volume the functionality is somewhat similar.
RAID 0 is only as unstable as its least stable component. In this case it's most likely a drive failure, and most drives are fairly long MTBFs. The chances of a disk failure increase as a function of time and number of drives deployed. A two-drive RAID 0 will be more stable than a five-drive RAID 0 which will be more stable than a 10 drive RAID 0 that's three years old. In the case of higher RAID levels, you can remove a single (or multiple) drive failure as the point of failure. In this case, the point of failure is the kernel, so it's perfectly legitimate to consider this a really bad problem. Would you say the same thing if the bug affected RAID 1 or RAID 5?
I have 4 drives in a RAID 10, so two RAID 1 arrays of two drives each combined together in a RAID 0. I did it mostly because I can add new drive at any time and just chain them onto the RAID 0.
The first claim makes my "rant" — about the need to use a reverse of the usual burden-of-proof principle for Executive government officials — on-topic and otherwise appropriate.
Trying to prove a negative? And you're wondering why I'm rolling my eyes at you?