In the pre-electronic days of documents, revising and adding to a document (a law, a regulation, etc.) was many ORDERS OF MAGNITUDE more expensive than now. It might take days to make a change to a document - and professional writers were involved in the reconcilation of the changes.
However, with word processors, every little narrow minded interest in Congress can get changes added or made to a document without anything to slow down the idiocy. The proliferation of laws has encouraged the bureaucrats to do the same thing to the rules and regulations the laws allow them to issue.
Ever look at books from the 1960s and before? They were SHORT. A novel was (maybe) 100 pages. These days, there's nothing preventing a writer from gassing on forever - 400 to 1000 pages of poorly reviewed writing.
Why would FreeBSD change from their existing system?
"/etc/rc.conf" - to set enable/disable/config variables.
"/etc/defaults/rc.conf" - for defaults and documentation of base system services
"/etc/rc.d", "/usr/local/etc/rc.d", etc. for the scripts
"/bin/rc.order" that builds a dependency graph of services based on comments in the scripts.
None of the nonsense of run levels and fixed numerical ordering as in the old SysVinit scheme.
The init scripts can be simple or complex, use shared "sh" source files (or not.)
Since the system already builds a dependency tree of services to start, it ought to be (relatively) possible to run init scripts in parallel - if the dependencies are laid out right.
I did something like that a long time ago as a first approximation of what I wanted - but I had to replicate it on every laptop & desktop in my household.
My goal was two-fold. I was using dial-up and I had young kids whom I didn't trust to not click on every link and button on a page. I wanted to prevent advertisements saturating my dial-up link and limit the amount of time spent cleaning up malware.
As I was using a *nix box as a home router (for dialup), I could use it's firewall functionality to block hosts and networks, and as I was using it also as a caching DNS server, I could also "poison" my view of the DNS too. Rather than using "localhost", I set up a pseudo-network on the *nix server that would always return an ICMP unreachable and had the domains point to that, as well as DNS servers that were being used by some of the shadier phishers/spamers/etc.
It works pretty well for EVERY device on my home network - game consoles, web cams, printers, blue-ray players, smart phones, iPods, as well as conventional laptops and desktops. It isn't something I can do with a conventional SOHO router, or even Linux based firmware on a SOHO router.
For a while, I tried using the SpamHouse DNS RBL stuff too, but it became hard to maintain. I thought about automating using the evidence generated by port-scanners attacking the SSH port on the linux box to add to the black lists too.
I don't have a complete solution yet for IPv6. DNS is a good first approximation for now.
I don't subscribe to cable TV or even watch broadcast TV anymore. And I don't even watch shows in the internet.
The effort of finding a show worth watching - and the suffering I would experience watching the advertisements that accompany these shows have discouraged me completely. Finding new shows on my own isn't worth the reward of some novel entertainment (discounted for the horrible, soul-crunching advertisements.)
Broadcast/Cable TV have lost to the internet - and the piss-poor internet service in the states make spending your time doing just about anything else more worthwhile.
At home, my main servers are FreeBSD. I fell in with FreeBSD because (at the time) it seemed more stable than Linux and performed better than Linux - but those are not the reasons I'd give for FreeBSD these days.
One thing I like about FreeBSD is that you can build completely from source - or use pre-built packages. I like having the access to the source - I've been carrying around a few local changes to the source for some time now - one to better support FreeBSD NFS exports syntax for ZFS, better "truncation" behavior for "sshd" and IPv6 addresses, a fixed version of "rc.order", and some changes to the/etc/rc.d/xxx system to make it easier to consolidate certain configurations on my home network. I also like FreeBSD for the way it handles networking - it seems a lot saner than the way Linux does, although I do like "iptables" chains very much under Linux. One of my FreeBSD servers is my home gateway router - with firewall features, DNS, OpenVPN, and a web server. It's also my endpoint for an IPv6 tunnel so I can play around with IPv6 routing. I've got a couple of used HP managed switches and I'm playing around with VLANs with it.
I've also got some machines running Ubuntu (for my kids to run minecraft servers on, and learn a little bit about server administration ad programming.)
My solutions and choices aren't necessarily suitable for you. FreeBSD is more unified than Linux is (there's really only 2 or three "distros" at one time - different versions really of the same, with a lot of overlap.) That has advantages and disadvantages in terms of finding solutions on the web.
At work, I take care of a service based on LFS (Linux From Scratch). Unfortunately, it's based on an old version of LFS and getting it upgraded is a nightmare because a lot of the decisions made after the original LFS build were never documented (and I'm a late-comer to it.)
My first introduction to *nix was a System-V machine running on a Motorola 68020-like processor - and after that, it was an AT&T workstation and a BSD 4.2 system.
I'd strongly suggest you just load some *nix on an old used desktop you don't need or can buy cheap - if your goal is to experience *nix in a server-like environment. Set up Apache as a web server. Set up Cups as a print server.
What happens when 50% of Users block advertisements?
Why, you have now have two kinds of users. The smart ones who block, and the dumb ones who don't.
The smart ones probably have more money to spend - but it'll be harder to extract money from them.
The dumb ones will have less money to spend - if for no other reason than they've spent it already on dumb ideas. But it'll be easier to get money out of them.
Agreed. I don't trust ad networks to not deliver zero-day attacks against my workstations, and the add networks speed up the process of delivering such attacks so much that it's only sensible to do what I can to block them.
That's not to say that a model where ads being delivered through the site wouldn't suffer from a similar lack of review - if anything, you can argue that concentrating the skills and experience to vet ads with specialists would make them more secure than scattering the work among a gazillion part-time website owners. But the increased demands on the site for distributing the ads (in terms of bandwidth, etc.) would encourage the website owners to put more pressure on the ad networks to perform due diligence.
I'd second this suggestion.
But you'll probably need to use dynamic DNS from some place like FREEDNS.AFRAID.NET to be able to locate your home server. I haven't done that (yet).
(note: At least one IPv6 tunnel broker DOES IPv6 DNS - but I'm not sure if you could leverage your HOME there.)
It took me a long time to even get a feature phone - and for the past half year I've had an iPhone.
I'm mostly satisfied with it. It does what I want. Phone calls. Alarm. Text messaging. Calendar. E-mail. Unfortunately, it's made it easier to use Twitter and Facebook - but I'm weaning myself from that.
One reason I switches to a smartphone was for a GPS device that might be able to help me for a single trip to NYC. Unfortunately, the "free" App that I used at first is no longer free, but I don't need it now either.
I wonder sometimes, that if I'd gotten an Android phone, I might have felt more obliged to use it as a personal/portable computing device and hack it, etc. rather than using it as an appliance as I do with the iPhone. I think that obligation would have left me a lot more dissatisfied.
Somehow, the difficulty of finding a useful App in the Apple iPhone App Store makes it easy for me to ignore them.
The University of Michigan foresaw the need for something like this back in the 1980s - more to have a common/unique login identifier than for e-mail, but e-mail addresses fall out of that, and the scaling issues inherent in it for something that covers three distinct campuses in Ann Arbor, Dearborn, and Flint.
UMich's policies about this have evolved a bit over the years - from being wildly open to being somewhat more restricted now, but the core philosophy is to let everyone choose their own uniqname (so long as it isn't in use by faculty, staff, registered group, alumni, etc.), and do the name to login/uniqname mechanism through a LDAP query. Currently we have in excess of 280,000 such unique names. LDAP did originate at the University of Michigan, as did COSIGN (a single-signon mechanism for web services.)
This has also helped for having a common authentication mechanism - so that only one group is responsible for managing IDs and passwords, rather than individual units and departments all over campus (not that a unit or department couldn't - but then they have the burden of managing the IDs and passwords, and have to deal with conflicts with the shared infrastructure. Most choose to use the shared infrastructure.)
BTW: Cosign as a solution for a single authentication domain is much easier (i.e.: cheaper) to manage than Shibboleth, but doesn't provide all the extra information that Shibboleth does.
I bought an early Apple Airport back in late 2007 and it's still good. But it's lived most of it's life on a UPS, and it's never been my broadband connection.
I recently started running a garage-sale Netgear WGR614 in my garage to try and give me better coverage for my back yard (and to give me an IPv6 capable wireless network when I want to play with one - the Airport and the WGR614 are on separate LANs.)
In the three years I've lived in my neighborhood (a 1950s era development), I've seen the number of SSIDs quadruple.
One thing I'm considering is running a bunch of second-hand APs at low power around my house. Low power so they don't interfere with each other, lots of them so that provide the coverage I want. Wiring them isn't a problem for me.
In the future, I'm going to try and limit my garage-sale purchases to APs I can load 3rd party software on.
In my experience with legacy code, most comments (if present) only bore a rather tenuous relationship to the code or the purpose of the code.
I've taken to treating comments as entertaining reading by the author(s) of the legacy code. Sometimes they foreshadow what's about to happen, sometimes they spoil the ending, sometimes they deceive, and sometimes they outright lie.
Code without comments IS a bit frustrating - but also freeing too. Without the comments adding chaos to the body of work, you can figure out what's going on without distraction.
I'm doing something like this myself - started on Comcast, went to AT&T DSL, and now I'm going back to Comcast. I've found my AT&T link to be very erratic, and now that they're trying to force Uverse on me, I've woken up from my consumer stupor and re-evaluating who does a better job at internet service.
I'm doing it from FreeBSD (My "F" in "FAMP".) I chose FreeBSD because I'd been using it at work, and because I liked a "distro" where I could be involved completely in the build process - or not. I have several modifications that I retain because they suit me, and the've been easy to maintain from FreeBSD 6 to FreeBSD 9. (It also gives me a ZFS based filesystem - which I'd like to think is handy, but have yet to actually take effective advantage of.)
My webserver serves up just static pages though. I didn't want to expose the server to possible compromises due to PHP flaws, or coding flaws (my own or some package or add-on.) That, and static web pages was good enough for my purposes - a kind of workstation and browser independent set of bookmarks.
I found myself constantly updating FreeBSD - but the server was doing little else, so that was no big deal. It gave me a very up-to-date system with all the latest security patches, etc.
I also use it as an OpenVPN server - and mount my home filesystems over the VPN when I'm at work or at some other wireless location (public library mostly - not big on internet cafes.)
One thing I really like about FreeBSD's host based firewall (it's also my NAT router) is that "ipfw" has "tables" - and I can dump huge numbers of networks into these tables without complicating the basic firewall ruleset. (I have some familiarity with Linux "iptables" - and miss that ability.)
On FreeBSD, I use a port called "ssh-guard" that manipulates my firewall rules to briefly block sites that try to login (and fail) too many times. You can do something similar in "iptables" (but I didn't write the rule-set that they use at work, and haven't really taken the time to memorize how it works.) Blocking "ssh" scans is kind of hopeless - most attacks these days are done by botnets rather than individual compromised machines, but it adds another thin layer to what should be a multi-layered approach to security.
I have configured the default entry on my webserver to throw up an error page - I've been thinking of harvesting IP addresses from THAT and adding those to my blocklists, but haven't taken the time to either do it or see if someone else has.
Mosh looked like an interesting solution to my own roaming issues - and most of my "roaming" is in-town between home and work and occasionally a public library or cafe. That, and when AT&T DSL drops my PPPoE connection and renegotiates my hope IP address at random times, sometimes several times an hour. (I live in the US - a kind of banana republic of residential networking.)
I've already got a reverse-roaming solution involving using OpenVPN to connect my laptop back to my home fileserver & printer and private IMAP server - but that's for my own convenience and my co-workers are amused.
I'm partially responsible for my own work environment - and it isn't a conventional Linux distribution (it's based on an early version of LFS). Which means that in some ways it's more secure because it doesn't include features we don't want or need (i.e.: reduced exposure surface.) But is a real pain to maintain. I've picked up the reins of other talented people - but the environment is old.
So I built Mosh. After upgrading the compiler. Patching/usr/include/endian.h. Upgrading Boost. Installing the Google Protocol thing. Installing libutempter. It took all afternoon! (I wanted to be able to share my work with other groups in our organization.)
And then I discovered Mosh wants a UTF-8 environment. Getting around that took the rest of the evening, and it depends on your shell. You can do it with "csh" - but "bash" is tricky. Then I had to patch libutempter. And patch libutempter. And patch libutempter. And patch libutempter. (My "ptsname()" call doesn't work - but neither does FreeBSD or MacOSX's.)
Anyway - mosh is SLOW. I can feel the buffer bloat it introduces.
It's interesting still. But I think a combination of OpenVPN, private networks, ssh, and even screen would work as well or even better.
Hmmm. Maybe I can use these studies to convince the used car salesmen that in-car phones are safety hazards and give me a discount - and that my ancient VW Passat is a better deal because it doesn't have these safety impairing features.
The Mackinac Bridge between Michigan's lower and upper peninsulas. The setting of this big, tall engineering marvel in the middle of a wild, flat environment is amazing. If you go up that way, check out the "Soo" (Sault St. Marie) naval locks between Lake Superior and Lake Huron.
These are more engineering than scientific marvels - but if you're generous with your science (and have the time to detour 4 hours north of the Ohio/Michigan border), you should be pleased.
Just don't drive a Yugo over that bridge in the fall.
A "Victory for Evolution"?
Only if a victory means that you steered the death-trap of a car you're riding high-speed in away from the edge of the mountain cliff. You're still going down-hill way to fast in a vehicle without brakes and there's oncoming traffic.
(And I'd love to quibble with the phrase "A Victory for Evolution" - that sounds on-par with "A Triumph for Purple".)
The IP packet doesn't contain MAC information. However, an IP packet on some media (ethernet, optical fiber, ATM, DSL) will likely contain some kind of MAC header - but only so that the two devices communicating can recognize each other.
When the IP packet is forwarded from one router to another, the original MAC information is not copied (or is removed), but the new MAC information appropriate for communication between those two routers is added.
The Internet is a network of (physical) networks. MAC addresses on different media could have different addressing (although the ethernet MAC header has been very convenient for most.)
Unless, of course, you're tunneling ethernet frames over IP (such as you might do if you were bridging ethernets over commodity IP service.)
Changing the anycast "endpoint" server should only matter for state-full protocols that last a "long" time. Most HTTP requests are relatively short, and most web pages HTML is sufficiently broken that the client (i.e.: the user clicking on the mouse) will just reload the page and try again.
Slashdot Mirror
Clearly, Sweden doesn't have the kind of problems that Norway has (see http://www.trollhunterfilm.com/ )
Although I don't imagine that Norway is locking up those miscreants.
Actually, the simple answer is word processors.
In the pre-electronic days of documents, revising and adding to a document (a law, a regulation, etc.) was many ORDERS OF MAGNITUDE more expensive than now. It might take days to make a change to a document - and professional writers were involved in the reconcilation of the changes.
However, with word processors, every little narrow minded interest in Congress can get changes added or made to a document without anything to slow down the idiocy. The proliferation of laws has encouraged the bureaucrats to do the same thing to the rules and regulations the laws allow them to issue.
Ever look at books from the 1960s and before? They were SHORT. A novel was (maybe) 100 pages. These days, there's nothing preventing a writer from gassing on forever - 400 to 1000 pages of poorly reviewed writing.
None of the nonsense of run levels and fixed numerical ordering as in the old SysVinit scheme.
The init scripts can be simple or complex, use shared "sh" source files (or not.)
Since the system already builds a dependency tree of services to start, it ought to be (relatively) possible to run init scripts in parallel - if the dependencies are laid out right.
I did something like that a long time ago as a first approximation of what I wanted - but I had to replicate it on every laptop & desktop in my household.
My goal was two-fold. I was using dial-up and I had young kids whom I didn't trust to not click on every link and button on a page. I wanted to prevent advertisements saturating my dial-up link and limit the amount of time spent cleaning up malware.
As I was using a *nix box as a home router (for dialup), I could use it's firewall functionality to block hosts and networks, and as I was using it also as a caching DNS server, I could also "poison" my view of the DNS too. Rather than using "localhost", I set up a pseudo-network on the *nix server that would always return an ICMP unreachable and had the domains point to that, as well as DNS servers that were being used by some of the shadier phishers/spamers/etc.
It works pretty well for EVERY device on my home network - game consoles, web cams, printers, blue-ray players, smart phones, iPods, as well as conventional laptops and desktops. It isn't something I can do with a conventional SOHO router, or even Linux based firmware on a SOHO router.
For a while, I tried using the SpamHouse DNS RBL stuff too, but it became hard to maintain. I thought about automating using the evidence generated by port-scanners attacking the SSH port on the linux box to add to the black lists too.
I don't have a complete solution yet for IPv6. DNS is a good first approximation for now.
I don't subscribe to cable TV or even watch broadcast TV anymore. And I don't even watch shows in the internet.
The effort of finding a show worth watching - and the suffering I would experience watching the advertisements that accompany these shows have discouraged me completely. Finding new shows on my own isn't worth the reward of some novel entertainment (discounted for the horrible, soul-crunching advertisements.)
Broadcast/Cable TV have lost to the internet - and the piss-poor internet service in the states make spending your time doing just about anything else more worthwhile.
There's more than a few edge conditions that I worry about - and that's without even thinking about malicious actors.
Some edge conditions:
Of malicious actors, I can think of:
One thing I like about FreeBSD is that you can build completely from source - or use pre-built packages. I like having the access to the source - I've been carrying around a few local changes to the source for some time now - one to better support FreeBSD NFS exports syntax for ZFS, better "truncation" behavior for "sshd" and IPv6 addresses, a fixed version of "rc.order", and some changes to the /etc/rc.d/xxx system to make it easier to consolidate certain configurations on my home network. I also like FreeBSD for the way it handles networking - it seems a lot saner than the way Linux does, although I do like "iptables" chains very much under Linux. One of my FreeBSD servers is my home gateway router - with firewall features, DNS, OpenVPN, and a web server. It's also my endpoint for an IPv6 tunnel so I can play around with IPv6 routing. I've got a couple of used HP managed switches and I'm playing around with VLANs with it.
I've also got some machines running Ubuntu (for my kids to run minecraft servers on, and learn a little bit about server administration ad programming.)
My solutions and choices aren't necessarily suitable for you. FreeBSD is more unified than Linux is (there's really only 2 or three "distros" at one time - different versions really of the same, with a lot of overlap.) That has advantages and disadvantages in terms of finding solutions on the web.
At work, I take care of a service based on LFS (Linux From Scratch). Unfortunately, it's based on an old version of LFS and getting it upgraded is a nightmare because a lot of the decisions made after the original LFS build were never documented (and I'm a late-comer to it.)
My first introduction to *nix was a System-V machine running on a Motorola 68020-like processor - and after that, it was an AT&T workstation and a BSD 4.2 system.
I'd strongly suggest you just load some *nix on an old used desktop you don't need or can buy cheap - if your goal is to experience *nix in a server-like environment. Set up Apache as a web server. Set up Cups as a print server.
What happens when 50% of Users block advertisements?
Why, you have now have two kinds of users. The smart ones who block, and the dumb ones who don't.
The smart ones probably have more money to spend - but it'll be harder to extract money from them.
The dumb ones will have less money to spend - if for no other reason than they've spent it already on dumb ideas. But it'll be easier to get money out of them.
Pick your mark.
Agreed. I don't trust ad networks to not deliver zero-day attacks against my workstations, and the add networks speed up the process of delivering such attacks so much that it's only sensible to do what I can to block them.
That's not to say that a model where ads being delivered through the site wouldn't suffer from a similar lack of review - if anything, you can argue that concentrating the skills and experience to vet ads with specialists would make them more secure than scattering the work among a gazillion part-time website owners. But the increased demands on the site for distributing the ads (in terms of bandwidth, etc.) would encourage the website owners to put more pressure on the ad networks to perform due diligence.
I'd second this suggestion.
But you'll probably need to use dynamic DNS from some place like FREEDNS.AFRAID.NET to be able to locate your home server. I haven't done that (yet).
(note: At least one IPv6 tunnel broker DOES IPv6 DNS - but I'm not sure if you could leverage your HOME there.)
I'm mostly satisfied with it. It does what I want. Phone calls. Alarm. Text messaging. Calendar. E-mail. Unfortunately, it's made it easier to use Twitter and Facebook - but I'm weaning myself from that.
One reason I switches to a smartphone was for a GPS device that might be able to help me for a single trip to NYC. Unfortunately, the "free" App that I used at first is no longer free, but I don't need it now either.
I wonder sometimes, that if I'd gotten an Android phone, I might have felt more obliged to use it as a personal/portable computing device and hack it, etc. rather than using it as an appliance as I do with the iPhone. I think that obligation would have left me a lot more dissatisfied.
Somehow, the difficulty of finding a useful App in the Apple iPhone App Store makes it easy for me to ignore them.
I just visited the WeMo web pages and couldn't find any technical information about what watt or amperage limits on it are.
I have a hard time believing that it can handle a 1500 watt heater.
The University of Michigan foresaw the need for something like this back in the 1980s - more to have a common/unique login identifier than for e-mail, but e-mail addresses fall out of that, and the scaling issues inherent in it for something that covers three distinct campuses in Ann Arbor, Dearborn, and Flint.
UMich's policies about this have evolved a bit over the years - from being wildly open to being somewhat more restricted now, but the core philosophy is to let everyone choose their own uniqname (so long as it isn't in use by faculty, staff, registered group, alumni, etc.), and do the name to login/uniqname mechanism through a LDAP query. Currently we have in excess of 280,000 such unique names. LDAP did originate at the University of Michigan, as did COSIGN (a single-signon mechanism for web services.)
This has also helped for having a common authentication mechanism - so that only one group is responsible for managing IDs and passwords, rather than individual units and departments all over campus (not that a unit or department couldn't - but then they have the burden of managing the IDs and passwords, and have to deal with conflicts with the shared infrastructure. Most choose to use the shared infrastructure.)
BTW: Cosign as a solution for a single authentication domain is much easier (i.e.: cheaper) to manage than Shibboleth, but doesn't provide all the extra information that Shibboleth does.
I bought an early Apple Airport back in late 2007 and it's still good. But it's lived most of it's life on a UPS, and it's never been my broadband connection.
I recently started running a garage-sale Netgear WGR614 in my garage to try and give me better coverage for my back yard (and to give me an IPv6 capable wireless network when I want to play with one - the Airport and the WGR614 are on separate LANs.)
In the three years I've lived in my neighborhood (a 1950s era development), I've seen the number of SSIDs quadruple.
One thing I'm considering is running a bunch of second-hand APs at low power around my house. Low power so they don't interfere with each other, lots of them so that provide the coverage I want. Wiring them isn't a problem for me.
In the future, I'm going to try and limit my garage-sale purchases to APs I can load 3rd party software on.
I do. But I treat the comments in the code before me as potentially treacherous.
In my experience with legacy code, most comments (if present) only bore a rather tenuous relationship to the code or the purpose of the code.
I've taken to treating comments as entertaining reading by the author(s) of the legacy code. Sometimes they foreshadow what's about to happen, sometimes they spoil the ending, sometimes they deceive, and sometimes they outright lie.
Code without comments IS a bit frustrating - but also freeing too. Without the comments adding chaos to the body of work, you can figure out what's going on without distraction.
I'm doing something like this myself - started on Comcast, went to AT&T DSL, and now I'm going back to Comcast. I've found my AT&T link to be very erratic, and now that they're trying to force Uverse on me, I've woken up from my consumer stupor and re-evaluating who does a better job at internet service.
I'm doing it from FreeBSD (My "F" in "FAMP".) I chose FreeBSD because I'd been using it at work, and because I liked a "distro" where I could be involved completely in the build process - or not. I have several modifications that I retain because they suit me, and the've been easy to maintain from FreeBSD 6 to FreeBSD 9. (It also gives me a ZFS based filesystem - which I'd like to think is handy, but have yet to actually take effective advantage of.)
My webserver serves up just static pages though. I didn't want to expose the server to possible compromises due to PHP flaws, or coding flaws (my own or some package or add-on.) That, and static web pages was good enough for my purposes - a kind of workstation and browser independent set of bookmarks.
I found myself constantly updating FreeBSD - but the server was doing little else, so that was no big deal. It gave me a very up-to-date system with all the latest security patches, etc.
I also use it as an OpenVPN server - and mount my home filesystems over the VPN when I'm at work or at some other wireless location (public library mostly - not big on internet cafes.)
One thing I really like about FreeBSD's host based firewall (it's also my NAT router) is that "ipfw" has "tables" - and I can dump huge numbers of networks into these tables without complicating the basic firewall ruleset. (I have some familiarity with Linux "iptables" - and miss that ability.)
On FreeBSD, I use a port called "ssh-guard" that manipulates my firewall rules to briefly block sites that try to login (and fail) too many times. You can do something similar in "iptables" (but I didn't write the rule-set that they use at work, and haven't really taken the time to memorize how it works.) Blocking "ssh" scans is kind of hopeless - most attacks these days are done by botnets rather than individual compromised machines, but it adds another thin layer to what should be a multi-layered approach to security.
I have configured the default entry on my webserver to throw up an error page - I've been thinking of harvesting IP addresses from THAT and adding those to my blocklists, but haven't taken the time to either do it or see if someone else has.
Mosh looked like an interesting solution to my own roaming issues - and most of my "roaming" is in-town between home and work and occasionally a public library or cafe. That, and when AT&T DSL drops my PPPoE connection and renegotiates my hope IP address at random times, sometimes several times an hour. (I live in the US - a kind of banana republic of residential networking.)
I've already got a reverse-roaming solution involving using OpenVPN to connect my laptop back to my home fileserver & printer and private IMAP server - but that's for my own convenience and my co-workers are amused.
I'm partially responsible for my own work environment - and it isn't a conventional Linux distribution (it's based on an early version of LFS). Which means that in some ways it's more secure because it doesn't include features we don't want or need (i.e.: reduced exposure surface.) But is a real pain to maintain. I've picked up the reins of other talented people - but the environment is old.
So I built Mosh. After upgrading the compiler. Patching /usr/include/endian.h. Upgrading Boost. Installing the Google Protocol thing. Installing libutempter. It took all afternoon! (I wanted to be able to share my work with other groups in our organization.)
And then I discovered Mosh wants a UTF-8 environment. Getting around that took the rest of the evening, and it depends on your shell. You can do it with "csh" - but "bash" is tricky. Then I had to patch libutempter. And patch libutempter. And patch libutempter. And patch libutempter. (My "ptsname()" call doesn't work - but neither does FreeBSD or MacOSX's.)
Anyway - mosh is SLOW. I can feel the buffer bloat it introduces.
It's interesting still. But I think a combination of OpenVPN, private networks, ssh, and even screen would work as well or even better.
Hmmm. Maybe I can use these studies to convince the used car salesmen that in-car phones are safety hazards and give me a discount - and that my ancient VW Passat is a better deal because it doesn't have these safety impairing features.
The Mackinac Bridge between Michigan's lower and upper peninsulas. The setting of this big, tall engineering marvel in the middle of a wild, flat environment is amazing. If you go up that way, check out the "Soo" (Sault St. Marie) naval locks between Lake Superior and Lake Huron.
These are more engineering than scientific marvels - but if you're generous with your science (and have the time to detour 4 hours north of the Ohio/Michigan border), you should be pleased.
Just don't drive a Yugo over that bridge in the fall.
A "Victory for Evolution"?
Only if a victory means that you steered the death-trap of a car you're riding high-speed in away from the edge of the mountain cliff. You're still going down-hill way to fast in a vehicle without brakes and there's oncoming traffic.
(And I'd love to quibble with the phrase "A Victory for Evolution" - that sounds on-par with "A Triumph for Purple".)
7.8 minutes of incarceration per. stolen credit card.
Assuming no time off for good behavior.
The IP packet doesn't contain MAC information. However, an IP packet on some media (ethernet, optical fiber, ATM, DSL) will likely contain some kind of MAC header - but only so that the two devices communicating can recognize each other.
When the IP packet is forwarded from one router to another, the original MAC information is not copied (or is removed), but the new MAC information appropriate for communication between those two routers is added.
The Internet is a network of (physical) networks. MAC addresses on different media could have different addressing (although the ethernet MAC header has been very convenient for most.)
Unless, of course, you're tunneling ethernet frames over IP (such as you might do if you were bridging ethernets over commodity IP service.)
I fear I agree with you - but I run /boot/kernel, not /boot/vmlinuz
Besides, I want to do things on my LAN/WAN interface that conventional solutions don't allow.
The MAC address isn't part of the IP packet.
Changing the anycast "endpoint" server should only matter for state-full protocols that last a "long" time. Most HTTP requests are relatively short, and most web pages HTML is sufficiently broken that the client (i.e.: the user clicking on the mouse) will just reload the page and try again.