I work for a small contracting company. A degree is definitely seen as an asset, but we've seen enough idiots at university that we recognize it's not everything. A technical college is an asset too, as are certs, but honestly people smart enough to figure things out for themselves are hard enough to find that if we see that we'll hire you either way.
OTOH, plenty of people make it through school without developing an aptitude for problem solving, so that's definitely not enough. It's probably going to have an impact on your starting pay though.
> What happens if NAT is used all over the place? You could imagine a bunch of > subnets that use one address to the outside world but have hundreds or > thousands of machines internally.
It *is* used all over the place. It's even used on an ISP-wide scale (expect that to become more common in the west). NAT delayed IP address exhaustion for a few years, a few years ago. The current rate of IP usage is what's happening *with* widespread use of NAT.
> There's a lot to be said for NAT from a security point of view too. Since you > need to open up holes manually for incoming services, incoming connections > for anything else will be blocked which makes it impossible for people to > exploit most security flaws on the machines behind the router.
You can get all of that from a stateful firewall that blocks inbound connections by default.
> Reading between the lines it seems like IPv6 was a revolutionary solution to > running out of address space. NAT was an evolutionary one. As usual the > market has picked the evolutionary solution and more purist types are whining > about it.
NAT isn't a solution at all, it's a way to delay the inevitable. It has successfully done that, into approximately 2011-2012. What it doesn't do is change the fundamental problem, it's not possible to use it *enough* to hold off exhaustion indefinitely.
Breaking end-to-end connectivity isn't the primary concern. This has already largely happened with NAT, and will continue to happen to a certain extent with IPv6 because we'll be using stateful firewalls. We can deal with this for most home users.
The problem is that NAT still consumes IPs, and other hosts like servers really do need to be reachable. The market prefers NAT now because exhaustion hasn't happened yet, and as the last few months have demonstrated, the market is remarkably good at ignoring problems for as long as possible.
Purist types *are* whining about it. But pragmatic types like me are also concerned that people like you seem to think NAT is something we can use later as a solution, when we've already been using it for years as a way to buy time.
> But you did not say why, other than "designing a rich API is hard". It is also > hard to get the last corruption bug out of a program that is more complex than > necessary, as a combined LVM+filesystem surely must be. So given two hard > tasks, only one of which yields a component that can be shared, I favor the > hard API design task.
It's not just designing the rich API, it would also require porting everything to it and dealing with all the corruption bugs that would no doubt result from such an effort -- *nothing* is in a state where it could use the proposed volume manager efficiently. If you really want to reuse BTRFS as a volume manager for other filesystems, make yourself a filesystem image file on top of BTRFS.
> I've repeatedly proposed something, only to find that ZFS already implements > it: Define one layer which is solely responsible for storing your bare > primitives, like a sequence of data. It is the FS-level equivalent of > malloc/free.
That sounds like the extent allocation mechanism in BTRFS as well.
> Then, implement everything else on top of that layer. Databases could sit > directly on the layer -- no reason they need to pretend to create files. > Filesystems would sit on that layer, implementing structures like directories > and POSIX file permissions.
I am unconvinced of the utility of this idea: Partly because I don't think the performance impact of going through the POSIX API is that bad when you're going to have to hit the extent allocation either way, partly because I think it's dumb to create another persistent storage abstraction with another set of permissions when we've already got two in widespread use (POSIX, SQL).
If you want the FS-level equivalent of malloc/free, make a directory and start putting files in it. I'm not sure what advantages your idea provides over that method that would be worth the complexity of another API.
The next gen filesystems discussed here (ZFS and BTRFS) are both open source (the latter is also released under the GPL for compatibility with Linux), and both are backed by big companies (Sun and Oracle, respectively). Linux would not be where it was today if it weren't for big companies committing big bucks to developing open source software.
> But hey maybe I'm missing something, why not improve or create a replacement for LVM instead of including volume management in the filesystem?
Maybe. But it would be a lot harder.
Think about LVM snapshots for example. LVM allocates a chunk of the disk for your filesystem, and then a chunk of disk for your snapshot. When something changes in the parent filesystem, the original contents of that block are first copied to the snapshot. But if you've got two snapshots, it has to be copied to two places, and each snapshot needs its own space to store the original data. Because ZFS/BTRFS/etc are unified, they can keep the original data for any number of snapshots by the simple expedient of leaving it alone and writing the new data someplace new.
LVMs can grow/shrink filesystems, but filesystems deal with this somewhat grudgingly. LVM lacks a way to handle dynamic allocation of blocks to filesystems in such a way that they can give them back dynamically when they're not using them. ZFS/BTRFS/etc can do this completely on the fly. LVMs rely on an underlying RAID layer to handle data integrity, but most RAID doesn't do this very well. BTRFS is getting a feature that allows it to handle seeky metadata differently than data (eg, use an SSD as a fast index into slow but large disks).
It is conceivable that an advanced volume manager could be created that does all these things and all the rest (eg checksumming) just as well... but I think the key point is that this isn't something you can do without a *much* richer API for filesystems talking to block devices. They'd need to be able to free up blocks they don't need anymore, and have a way to handle fragmentation when both the filesystem and the volume manager would try to allocate blocks efficiently. They'd need substantially improved RAID implementations, or they'd need to bring the checksumming into the volume manager. I'm not saying it can't be done, but doing it as well as ZFS/BTRFS/etc when you're trying to preserve layering would be very tough. At a minimum you'd need new or substantially updated filesystems and a new volume manager of comparable complexity to ZFS/BTRFS/etc. I understand the preference for a layered approach, but I just don't think it's competitive here.
So either you'll keep getting router advertisements on your network indefinitely, or your computers will have to keep requesting for it (instead of eventually giving up- which is what happens now).
Correct. New computers can use router solicitations to get this information immediately, router advertisements can be used once the initial prefix delegation is complete (eg, the public prefix to use is know) and periodically thereafter to prevent autoconfig addresses for expiring.
I'm curious why you seem to regard this as a big deal.
Next question: What url does Joe Public enter on his browser to get to the router config page, so that he can enter the username and password in order to get access to the ISP's network?
I like the mDNS method personally.
Reserved by RFC or not,.local is sufficiently common for mDNS that it's basically unusable for any other purpose.
I got a/48 from Hurricane Electric, I used OpenVPN to become my own tunnel broker. Probably the most useful thing so far for me has been making machines behind NATs accessible without having to get ports forwarded (this is often a pain if the eg someone doesn't remember their router's password).
This could obviously be done with RFC1918 addresses on v4, but it's hard to pick a range there because someone somewhere will end up being incompatible with it.
> Without a NAT, how does a "NoNAT router" know what public IP range to give via DHCP (or other means) to Joe User's WinXP/Mac box, BEFORE it manages to get that public IP range from the ISP?
Before it connects to the ISP you'll be using link-local addresses. The router will then get a prefix from the ISP via DHCP prefix delegation and begin sending router advertisements so internal computers can configure themselves with public addresses (though they retain their link-local addresses).
You can get a similar level of security by using a stateful firewall. The main security advantage to NAT is really the property of limiting inbound packets to those that are associated with existing connections, and that's what you get with a stateful firewall. You don't have to have disjoint address spaces to get this feature.
I think having to do it with that frequency is a legit complaint. Say there's CARP and everything works fine -- I'm still spending time on upgrades more often than I'd like.
Feature-neutral security updates for more than a year would be welcome.
Re:Mebbe I should try it some time
on
OpenBSD 4.4 Released
·
· Score: 5, Informative
> What does Linux take from BSD? All those vendor supplied drivers? The userland? The vast array of high quality filesystems?
The overwhelmingly dominant SSH implementation?
Re:Mebbe I should try it some time
on
OpenBSD 4.4 Released
·
· Score: 3, Insightful
They're significantly behind Linux in many areas, but don't mistake optimization for specific workloads as obsolescence. Performance sucks once you hit userspace, but most OpenBSD machines spend almost all their time in the kernel, routing and firewalling, tasks for which they are quite competitive with Linux.
Wiiware/virtual console adds enormously to the value of the system. Casual gamers like me can download something cheap if we're bored for an afternoon.
None of them are the equal of full Wii game, let alone a PS3/360 game... but they're fun, they're cheap, and they're convenient. That does a lot for the value of the system, under any definition of "value" I care to use.
The thing to remember about optical drives is that mass distribution of a pressed disk is vastly cheaper than flash memory or anything like it. It's not nearly enough to have blank flash memory that's as cheap as a blu-ray title, you need orders of magnitude beyond that to be viable for distribution. Flash isn't there yet, and may never be there.
If you're thinking about what physical technology will overtake optical in the future, you're missing the point. Physical media will be whatever happens to be convenient, distribution will be by download. And it still might go away one day, if the company shuts down the DRM servers or something.
Proper forwarding should rewrite the SMTP envelope sender (leaving the "From" header intact). There's just no other way to do it that doesn't break with SPF and other things these days.
Yes, that means the new sender address will have to be valid. Yes, that means it'll look like spam is coming from your domain if your forwarding service is easy to abuse. You might also want to preserve what's happened in headers for future reference and debugging uses, and rewrite the SMTP envelope sender to something that makes obvious which forwarding address caused the forwarded message to be sent.
E-mail is easy to get wrong. Don't try this at home.
I took similar steps when we had 10 people on a DSL for web and VoIP.:)
Doing QoS both up and down, we make VoIP top priority, then interactive SSH, DNS, and empty ACK packets, and then everything else. My boss didn't think it would work (he subscribes to the notion that inbound QoS is impossible, or he used to at any rate), but the results spoke for themselves.
PF offers several schedulers, but I've found the fancy ones aren't really useful on smaller connections (even a single 1500 byte packet can cause significant latency on a 768 kbps connection). I did tweak it so the VoIP and DNS/SSH queues didn't use RED, since we assume these services will never be bandwidth bound.
RED basically drops packets with an increasing probability as the queue fills up, allowing it to throttle and still mitigate fluctuations in traffic, where a standard queue would just fill up and then do nothing but add latency. That's great for web and e-mail, but bad for VoIP or DNS or whatever.
We've now got a dedicated wireless backhaul between us and the datacenter, so we too aren't terribly concerned any longer.:)
No, it shouldn't. QoS only works on egress. You can't do any meaningful ingress QoS. All you can do is stop packets from coming past the router. That doesn't address the real problem which is that the ISP link is maxed out. In fact, if you start dropping TCP data that's in a lower priority queue than your UDP voice, it will cause even further issues as the sender will retransmit those lost TCP packets.
You can indeed do ingress QoS. It's not as good as egress, but it's a very good approximation that provides perfectly adequate results in most situations. In response to packet loss, TCP and other protocols throttle themselves. You're helpless if someone wants to DoS you, but in almost any circumstances short of that, you'll be okay.
What you do is figure out your real-world downstream speed, then set your downstream speed to somewhat less than that (say 80%) to allow for a bit of overflow from TCP retransmits and higher priority traffic. Give the higher priority traffic a big queue that doesn't drop packets (eg no RED), and you'll get very good results unless someone is really out to get you.
The inability to QoS ingress traffic is very widely accepted, but what people neglect to consider is that we can use an approximation. A lot of problems never get solved beyond workable approximations. You're not going to get a network suitable for hard realtime data, but it'll be good enough for VoIP.
Next, people complain about Linux usability? apt-get install mplayer k3b, etc? It is not harder, just different. In fact, having all of the software most people need in one place makes Linux easier for most people in many ways, specifically the way that possible-Bill rants about here. The hilarious part is that people keep giving the command line for doing this as an argument it's not hard. Suggesting that most people resort to the command line is an automatic fail.
What's particularly hilarious is that you don't even need the command line, there's a perfectly easy GUI. All you're doing is revealing that you're fine with the expectation that people should use the command line for standard stuff like installing supported apps.
It runs on 4 x quad core. Which is about just 4X the CPU power a normal user could have right now. A 4X speed improvement isn't probably that far away. They may be hoping to reach a point where a dedicated video card is no longer needed. With the required performance level being so near, adding some extra support to the CPU may be enough. The eventual goal is to use large numbers of minimal x86 cores, I think they can increase the performance for a specialized workload quite a bit.
Slashdot Mirror
I work for a small contracting company. A degree is definitely seen as an asset, but we've seen enough idiots at university that we recognize it's not everything. A technical college is an asset too, as are certs, but honestly people smart enough to figure things out for themselves are hard enough to find that if we see that we'll hire you either way.
OTOH, plenty of people make it through school without developing an aptitude for problem solving, so that's definitely not enough. It's probably going to have an impact on your starting pay though.
> What happens if NAT is used all over the place? You could imagine a bunch of
> subnets that use one address to the outside world but have hundreds or
> thousands of machines internally.
It *is* used all over the place. It's even used on an ISP-wide scale (expect that to become more common in the west). NAT delayed IP address exhaustion for a few years, a few years ago. The current rate of IP usage is what's happening *with* widespread use of NAT.
> There's a lot to be said for NAT from a security point of view too. Since you
> need to open up holes manually for incoming services, incoming connections
> for anything else will be blocked which makes it impossible for people to
> exploit most security flaws on the machines behind the router.
You can get all of that from a stateful firewall that blocks inbound connections by default.
> Reading between the lines it seems like IPv6 was a revolutionary solution to
> running out of address space. NAT was an evolutionary one. As usual the
> market has picked the evolutionary solution and more purist types are whining
> about it.
NAT isn't a solution at all, it's a way to delay the inevitable. It has successfully done that, into approximately 2011-2012. What it doesn't do is change the fundamental problem, it's not possible to use it *enough* to hold off exhaustion indefinitely.
Breaking end-to-end connectivity isn't the primary concern. This has already largely happened with NAT, and will continue to happen to a certain extent with IPv6 because we'll be using stateful firewalls. We can deal with this for most home users.
The problem is that NAT still consumes IPs, and other hosts like servers really do need to be reachable. The market prefers NAT now because exhaustion hasn't happened yet, and as the last few months have demonstrated, the market is remarkably good at ignoring problems for as long as possible.
Purist types *are* whining about it. But pragmatic types like me are also concerned that people like you seem to think NAT is something we can use later as a solution, when we've already been using it for years as a way to buy time.
We're going through a /8 about every month. Even if several of these are freed up it doesn't push the exhaustion date back very far.
> But you did not say why, other than "designing a rich API is hard". It is also
> hard to get the last corruption bug out of a program that is more complex than
> necessary, as a combined LVM+filesystem surely must be. So given two hard
> tasks, only one of which yields a component that can be shared, I favor the
> hard API design task.
It's not just designing the rich API, it would also require porting everything to it and dealing with all the corruption bugs that would no doubt result from such an effort -- *nothing* is in a state where it could use the proposed volume manager efficiently. If you really want to reuse BTRFS as a volume manager for other filesystems, make yourself a filesystem image file on top of BTRFS.
> I've repeatedly proposed something, only to find that ZFS already implements
> it: Define one layer which is solely responsible for storing your bare
> primitives, like a sequence of data. It is the FS-level equivalent of
> malloc/free.
That sounds like the extent allocation mechanism in BTRFS as well.
> Then, implement everything else on top of that layer. Databases could sit
> directly on the layer -- no reason they need to pretend to create files.
> Filesystems would sit on that layer, implementing structures like directories
> and POSIX file permissions.
I am unconvinced of the utility of this idea: Partly because I don't think the performance impact of going through the POSIX API is that bad when you're going to have to hit the extent allocation either way, partly because I think it's dumb to create another persistent storage abstraction with another set of permissions when we've already got two in widespread use (POSIX, SQL).
If you want the FS-level equivalent of malloc/free, make a directory and start putting files in it. I'm not sure what advantages your idea provides over that method that would be worth the complexity of another API.
Huh?
The next gen filesystems discussed here (ZFS and BTRFS) are both open source (the latter is also released under the GPL for compatibility with Linux), and both are backed by big companies (Sun and Oracle, respectively). Linux would not be where it was today if it weren't for big companies committing big bucks to developing open source software.
> But hey maybe I'm missing something, why not improve or create a replacement for LVM instead of including volume management in the filesystem?
Maybe. But it would be a lot harder.
Think about LVM snapshots for example. LVM allocates a chunk of the disk for your filesystem, and then a chunk of disk for your snapshot. When something changes in the parent filesystem, the original contents of that block are first copied to the snapshot. But if you've got two snapshots, it has to be copied to two places, and each snapshot needs its own space to store the original data. Because ZFS/BTRFS/etc are unified, they can keep the original data for any number of snapshots by the simple expedient of leaving it alone and writing the new data someplace new.
LVMs can grow/shrink filesystems, but filesystems deal with this somewhat grudgingly. LVM lacks a way to handle dynamic allocation of blocks to filesystems in such a way that they can give them back dynamically when they're not using them. ZFS/BTRFS/etc can do this completely on the fly. LVMs rely on an underlying RAID layer to handle data integrity, but most RAID doesn't do this very well. BTRFS is getting a feature that allows it to handle seeky metadata differently than data (eg, use an SSD as a fast index into slow but large disks).
It is conceivable that an advanced volume manager could be created that does all these things and all the rest (eg checksumming) just as well... but I think the key point is that this isn't something you can do without a *much* richer API for filesystems talking to block devices. They'd need to be able to free up blocks they don't need anymore, and have a way to handle fragmentation when both the filesystem and the volume manager would try to allocate blocks efficiently. They'd need substantially improved RAID implementations, or they'd need to bring the checksumming into the volume manager. I'm not saying it can't be done, but doing it as well as ZFS/BTRFS/etc when you're trying to preserve layering would be very tough. At a minimum you'd need new or substantially updated filesystems and a new volume manager of comparable complexity to ZFS/BTRFS/etc. I understand the preference for a layered approach, but I just don't think it's competitive here.
So either you'll keep getting router advertisements on your network indefinitely, or your computers will have to keep requesting for it (instead of eventually giving up- which is what happens now).
Correct. New computers can use router solicitations to get this information immediately, router advertisements can be used once the initial prefix delegation is complete (eg, the public prefix to use is know) and periodically thereafter to prevent autoconfig addresses for expiring.
I'm curious why you seem to regard this as a big deal.
Next question: What url does Joe Public enter on his browser to get to the router config page, so that he can enter the username and password in order to get access to the ISP's network?
I like the mDNS method personally.
Reserved by RFC or not, .local is sufficiently common for mDNS that it's basically unusable for any other purpose.
I got a /48 from Hurricane Electric, I used OpenVPN to become my own tunnel broker. Probably the most useful thing so far for me has been making machines behind NATs accessible without having to get ports forwarded (this is often a pain if the eg someone doesn't remember their router's password).
This could obviously be done with RFC1918 addresses on v4, but it's hard to pick a range there because someone somewhere will end up being incompatible with it.
> Without a NAT, how does a "NoNAT router" know what public IP range to give via DHCP (or other means) to Joe User's WinXP/Mac box, BEFORE it manages to get that public IP range from the ISP?
Before it connects to the ISP you'll be using link-local addresses. The router will then get a prefix from the ISP via DHCP prefix delegation and begin sending router advertisements so internal computers can configure themselves with public addresses (though they retain their link-local addresses).
You can get a similar level of security by using a stateful firewall. The main security advantage to NAT is really the property of limiting inbound packets to those that are associated with existing connections, and that's what you get with a stateful firewall. You don't have to have disjoint address spaces to get this feature.
I think having to do it with that frequency is a legit complaint. Say there's CARP and everything works fine -- I'm still spending time on upgrades more often than I'd like.
Feature-neutral security updates for more than a year would be welcome.
> What does Linux take from BSD? All those vendor supplied drivers? The userland? The vast array of high quality filesystems?
The overwhelmingly dominant SSH implementation?
They're significantly behind Linux in many areas, but don't mistake optimization for specific workloads as obsolescence. Performance sucks once you hit userspace, but most OpenBSD machines spend almost all their time in the kernel, routing and firewalling, tasks for which they are quite competitive with Linux.
Meh. It's still worthwhile if it creates a disincentive for Apple to do this.
Wiiware/virtual console adds enormously to the value of the system. Casual gamers like me can download something cheap if we're bored for an afternoon.
None of them are the equal of full Wii game, let alone a PS3/360 game... but they're fun, they're cheap, and they're convenient. That does a lot for the value of the system, under any definition of "value" I care to use.
The thing to remember about optical drives is that mass distribution of a pressed disk is vastly cheaper than flash memory or anything like it. It's not nearly enough to have blank flash memory that's as cheap as a blu-ray title, you need orders of magnitude beyond that to be viable for distribution. Flash isn't there yet, and may never be there.
If you're thinking about what physical technology will overtake optical in the future, you're missing the point. Physical media will be whatever happens to be convenient, distribution will be by download. And it still might go away one day, if the company shuts down the DRM servers or something.
I don't care if you have the address honey.bunny77@hotmail.de, just stop applying for jobs with it.
heh... people that mention Comcast in their blogs is probably a pretty good approximation for people that are complaining about Comcast.
Proper forwarding should rewrite the SMTP envelope sender (leaving the "From" header intact). There's just no other way to do it that doesn't break with SPF and other things these days.
Yes, that means the new sender address will have to be valid. Yes, that means it'll look like spam is coming from your domain if your forwarding service is easy to abuse. You might also want to preserve what's happened in headers for future reference and debugging uses, and rewrite the SMTP envelope sender to something that makes obvious which forwarding address caused the forwarded message to be sent.
E-mail is easy to get wrong. Don't try this at home.
I took similar steps when we had 10 people on a DSL for web and VoIP. :)
Doing QoS both up and down, we make VoIP top priority, then interactive SSH, DNS, and empty ACK packets, and then everything else. My boss didn't think it would work (he subscribes to the notion that inbound QoS is impossible, or he used to at any rate), but the results spoke for themselves.
PF offers several schedulers, but I've found the fancy ones aren't really useful on smaller connections (even a single 1500 byte packet can cause significant latency on a 768 kbps connection). I did tweak it so the VoIP and DNS/SSH queues didn't use RED, since we assume these services will never be bandwidth bound.
RED basically drops packets with an increasing probability as the queue fills up, allowing it to throttle and still mitigate fluctuations in traffic, where a standard queue would just fill up and then do nothing but add latency. That's great for web and e-mail, but bad for VoIP or DNS or whatever.
We've now got a dedicated wireless backhaul between us and the datacenter, so we too aren't terribly concerned any longer. :)
You can indeed do ingress QoS. It's not as good as egress, but it's a very good approximation that provides perfectly adequate results in most situations. In response to packet loss, TCP and other protocols throttle themselves. You're helpless if someone wants to DoS you, but in almost any circumstances short of that, you'll be okay.
What you do is figure out your real-world downstream speed, then set your downstream speed to somewhat less than that (say 80%) to allow for a bit of overflow from TCP retransmits and higher priority traffic. Give the higher priority traffic a big queue that doesn't drop packets (eg no RED), and you'll get very good results unless someone is really out to get you.
The inability to QoS ingress traffic is very widely accepted, but what people neglect to consider is that we can use an approximation. A lot of problems never get solved beyond workable approximations. You're not going to get a network suitable for hard realtime data, but it'll be good enough for VoIP.
It's easier to explain to someone remotely, but it's harder for them to figure out themselves, it's something most people can only parrot.
An interface they can figure out themselves is a far more compelling argument.
The command line is something you and I might use to discuss it, but it's got no place in end user advocacy.
What's particularly hilarious is that you don't even need the command line, there's a perfectly easy GUI. All you're doing is revealing that you're fine with the expectation that people should use the command line for standard stuff like installing supported apps.