There's another reason why packet-level is nice; tunneling doesn't survive putting your laptop to sleep for any length of time. We use an SSH-based VPN for work, and it works swell, but it means I tend to lug my laptop around the apartment with the clamshell open:(.
Section 6.12 of the HTML 4.01 Recommendation [HTML 4.01] lists some link types that may be used by authors to make assertions about linked Web resources. These include alternate, stylesheet, start, next, prev, contents, glossary, and others. Although the HTML 4.01 specification does not specify definitive rendering or behavior for these link types, user agents should interpret them in useful ways. For instance, the start, next, prev, and contents link types may be used to build a table of contents, or may be used to identify the print order of documents, etc.
I agree with many of the points these guys make, but the one I've quote above (about link behavior) is emblematic of how disconnected W3C recommendations are from real problems. "link" has been around for years, but it's so vaguely defined as to be useless. Lynx used it to associate an e-mail address with a web page, but that wasn't consistently implemented (or defined in a spec), so there was no incentive to add it to a web page (since it would only work with one, lightly used browser, and there was no good UI way to even use the e-mail address anyway).
Saying things like "hey, implement this in 'useful' ways" may as well be the same as saying, "hey, we have this cool idea for defining web structure, so every browser should come up with some incompatible way to turn that into user interface." But the thing is, we don't want to have unpredictable UIs at the whim of the browser designer -- we want our web app to behave the same on every browser. In this one recommendation, they've just committed the same sin that they're complaining about in every other recommendation, which is the crazy proliferation of browser behaviors in the face of "standards."
Y'know, I'm 27, and I've published two books, spent four years doing the PhD thing at CMU, and I'm currently one of the founding members of a successful (read: profitable) Internet software consulting firm. I haven't changed the world (yet), but I'd say I'm doing OK. And I think you're completely off-base.
I spend between 40-50 hours a week "working." That means, in the office, explicitly thinking about design, or code, or management issues. And the thing is, I get the stuff done I want to get done. And then I spend the rest of that time making sure I'm still an actual viable person: being with family, exploring the world, and learning new things. ("playing.")
Sure, when I get a bug up my ass, I can spend 60-70 hours hacking during a week, and it can be an extremely invigorating experience; but what the hell is the point of trying to actually sustain that? It's the time I spend "playing" that makes me more interesting, and that leaves me with more to contribute when I'm "working."
The "let's make 'em think they're playing and that they live here so that they'll work 70 hours a week for us" management mentality is bullshit. It must be nice that you can keep finding young kids who don't know any better and think that's what they need to do. I'm comfortable knowing that I'm a stupendous enough badass that I don't need to put up with that shit, and I can still live a dynamic and fulfilling (and very well-paying) life. It's possible to achieve and get shit done and not burn yourself out to do it.
Software Project Survival Guide
on
Death March
·
· Score: 1
The death march is an avoidable scenario (and one that should be avoided at all costs). Check out the Software Project Survival Guide by Steve McConnell if you want a good book on handling the development process.
There's another issue here besides frequency hopping and spread spectrum. While wireless ethernet is not exactly the same protocol as wired ethernet, it does share one significant property: if there's a transmission failure, it backs off and retries. The amount of time between retries increases randomly but exponentially. Why? On a wired network, it's to prevent two machines sending colliding packets from trying again at the same time (and colliding again). If you're using a wireless spectrum that only has other wireless ethernet users on it, the same holds true. Unfortunately, if you have other users of the spectrum that don't play by these rules, ethernet gets screwed, since it backs off politely while the other user (like telephones) just continue to blast data on through. Since the other never backs off, ethernet continues to wait longer and longer for an interference-free window.
Slashdot Mirror
Unix? Laptop? PowerBook.
There's another reason why packet-level is nice; tunneling doesn't survive putting your laptop to sleep for any length of time. We use an SSH-based VPN for work, and it works swell, but it means I tend to lug my laptop around the apartment with the clamshell open :(.
Saying things like "hey, implement this in 'useful' ways" may as well be the same as saying, "hey, we have this cool idea for defining web structure, so every browser should come up with some incompatible way to turn that into user interface." But the thing is, we don't want to have unpredictable UIs at the whim of the browser designer -- we want our web app to behave the same on every browser. In this one recommendation, they've just committed the same sin that they're complaining about in every other recommendation, which is the crazy proliferation of browser behaviors in the face of "standards."
I spend between 40-50 hours a week "working." That means, in the office, explicitly thinking about design, or code, or management issues. And the thing is, I get the stuff done I want to get done. And then I spend the rest of that time making sure I'm still an actual viable person: being with family, exploring the world, and learning new things. ("playing.")
Sure, when I get a bug up my ass, I can spend 60-70 hours hacking during a week, and it can be an extremely invigorating experience; but what the hell is the point of trying to actually sustain that? It's the time I spend "playing" that makes me more interesting, and that leaves me with more to contribute when I'm "working."
The "let's make 'em think they're playing and that they live here so that they'll work 70 hours a week for us" management mentality is bullshit. It must be nice that you can keep finding young kids who don't know any better and think that's what they need to do. I'm comfortable knowing that I'm a stupendous enough badass that I don't need to put up with that shit, and I can still live a dynamic and fulfilling (and very well-paying) life. It's possible to achieve and get shit done and not burn yourself out to do it.
The death march is an avoidable scenario (and one that should be avoided at all costs). Check out the Software Project Survival Guide by Steve McConnell if you want a good book on handling the development process.
There's another issue here besides frequency hopping and spread spectrum. While wireless ethernet is not exactly the same protocol as wired ethernet, it does share one significant property: if there's a transmission failure, it backs off and retries. The amount of time between retries increases randomly but exponentially. Why? On a wired network, it's to prevent two machines sending colliding packets from trying again at the same time (and colliding again). If you're using a wireless spectrum that only has other wireless ethernet users on it, the same holds true. Unfortunately, if you have other users of the spectrum that don't play by these rules, ethernet gets screwed, since it backs off politely while the other user (like telephones) just continue to blast data on through. Since the other never backs off, ethernet continues to wait longer and longer for an interference-free window.