I've used them for a couple of years now, after I realized that the Maltron wasn't a solution (worst built keyboard I've ever used. The layout and key-feel was wonderful, but it broke easily, looked so cheap my manager always bugged me about it, and wouldn't work properly under linux becuase of crazy things they did with the symcodes).
I've used several of them (when I wear one out I get a new one, usually because ash from cigarettes gets into the keyboard because I smoke by it) and I've never had problems. I love mine. What problems have you had with the key action? I've always loved it.
I've been using nothing but Kinesis Ergo keyboards for a while now (http://www.kinesis-ergo.com) and not only has it almost completely resolved my RSI problems, but I'm also both faster AND more accurate than I have been with any other keyboard.
Since my fingers don't move as much and they don't move in such odd ways, just about the only time I have to hit the backspace key is when I change my mind about what I have to type, not just because I hit the wrong key. BIG productivity gain there.
I was FAST with an ordinary keyboard, compared to the general population (about 80-100wpm burst when coding). I'm past 120wpm with the kinesis burst rate, and people always look at my fingers when I sit down to type something because they seem like they're moving so fast.
So there you go. Faster and more ergo. It's not as radical as something like the KeyBowl, but it's a good alternative.
First, what precisely are you trying to benchmark? Just saying you're trying to benchmark a driver isn't very interesting or specific at all, and won't get you far. Are you trying to measure total query throughput? Total user/query concurrency? Transactional performance? Time to First Row (i.e. query latency)? Time to Commit (i.e. transactional latency)? Under what workloads? Highly normalized relational data? Star/Snowflake schemas? Nothing but updates? Queries? Insertions? 2-way joins? 10-way-joins? So if you don't know what you're testing for, you're not going to do a very good job of testing it. Figure out what your benchmark is testing, and then find one which matches that, don't just go looking for a benchmark.
The TPC is very correct in stating that a benchmark is not about one particular component. You can't test them in complete isolation. You must look at how a whole system performs under a specific workload. So it's actually pretty difficult to measure one component in isolation. If you're testing just the driver, you need to compare the drivers against the same workload, same schema, same data, same database. You can't test the WebLogic Type-4 Driver for Sybase with the Open Source Postgres Type-2 Driver. And since different databases are optimized for different things, you'll need to bear that in mind (this is something you'll probably know, but it's important for constructing a benchmark for your application).
Next is the issue of actually publishing benchmark results. First of all, you cannot publish a full TPC benchmark without it being audited. You can use their data, use their queries, but you cannot publish comprehensive numbers (such as QphD or QthM) because it's not permitted by the TPC. Look at how academic research papers in the database field do it. If they're doing query performance, they give you comparative numbers on the various queries, and maybe put it together into some artificial number, but they don't attempt to give a result. If you're looking at the TPC benchmarks, that's a very important consideration.
Now you get to the issue of publishing a result on ANY database. Not going to happen. Database vendors don't allow anybody to publish any benchmarks of their software under any circumstances, not even for academic reasons. The only people who get around that are people working for the companies, such as the IBM Almaden research people. You can't publish the results very easily, and have your advisor look into what you can use and/or publish. You might be stuck with Postgres or MySQL only.
And finally, there's the issue of what TPC-C is. Nobody ever does TPC-C in Java, nobody ever does it with JDBC. Have you read a full disclosure report for an audited run before? Not just the executive summary, the FULL disclosure report. They don't use Java. Hell, they don't use SQL. They code things directly to a low-level API which is completely native, and completely in C. Because here's a big insight which the TPC and RDBMS vendors will never tell you: TPC-C is designed to indicate how quickly an RDBMS can act just like a mainframe. That isn't very fast at all, so they have to "cheat" by taking SQL out of the picture. Read their client code. It's all native C library calls.
So with this we come to my recommendation: Use the TPC-W benchmark, for the following reasons:
That's what people use JDBC for. JDBC isn't used for TPC-C or TPC-H or TPC-Q workloads. It's used for web workloads. Why not try the benchmark used to simulate web workloads with a technology designed for web pages?
You can always play with the parameters. Don't like the reliance on static pages? Take them out entirely. Talk directly to the middle tier. Or reduce them in percentages to the point where they don't factor highly in the mix. If you can't get this tuned to where you see a performance difference, then the results are simple: JDBC performance doesn't matter. That's a pretty good result in itself.
You can also just take the bits out you care about. Are you willing to munge your own source code? Then extract the database code from TPC-W and run that.
You might also want to look at SQL3AP. It's good for measuring raw concurrency, but is a completely artificial benchmark with no relation to the real-world.
Much like any other Ask Slashdot, we're not provided with sufficient information to give you any real information at all. But hopefully this helps. If you care, email for more information.
In all likelihood the on-board OS which is handling requests is ON the hard drives themselves, which means that if you just gank the hard drives and put in new ones, it won't know what to do and will just be broken.
If, however, the hard drives are JUST data (i.e. firmware OS) then there's a pretty good chance that it assumes that it's got pre-formatted hard drives. Unless you format them, there's a very good chance that again, it's a no-go and you'll break everything.
And then finally, even if you were to know that you needed to format them, in what format? Do you know the FS format for them? If not, how exactly do you intend to get them ready?
Remember, this isn't something which has a boot prompt to which you can just install linux. It's an embedded system. Unless you're willing to really play, you're not going to figure out that much by just breaking the things.
Since this came up in several responses, when I say "two mice" I mean "two pointers," in the spirit of the original question. Everything is able to support two mice driving the same pointer. The issue is having two pointers. All my comments after the first paragraph are with respect to the issue of two pointers.
What applications would support that? In order to get any actions from the second pointer supported, you'd have to change the event hierarchy and structure, and nothing currently supports that.
What's the point of having two pointers if you can only click on things with one?
Someone else pointed out that on Win2K (and the old-skool macs with ADB, the precursor to USB) you can have multiple mice connected, with one pointer. That's pretty much going to be the limit of what you're able to support, but only part of it is going to be the mouse hardware itself. I know that on the mac in the bad old days, the pointer movement was actually handled by the hardware itself (i.e. the OS passed an XOR map to the graphics hardware, and the hardware passed interrupts to both the OS to handle events AND the graphics card to draw the pointer). I know that currently many of the GDI calls on windows are handled in hardware (i.e. no software rendering for some things). I suspect that there's some wizardry going on there, but I'm not sure. You think that's going to be something which is easy to figure out?
Quite a bit more is going to be the software itself. Particularly on a system which was never designed to handle multiple mice, do you think that code like the X server is necessarily able to handle multiple mice doing things simultaneously? Also, if I remember correctly (but it's been some time since I did raw Xlib programming), the X protocol assumes ONE mouse. Which means that there's no way for the X server to talk to the applications and tell them that it was the second mouse that did something (i.e. no differentiation possible). You'd have to rewrite portions of X to get the second mouse active. Even if the X server and/or hardware was able to distinguish between the two types of mouse interrupts, AND show two different pointers, what about the applications?
I know that most of the software which is happening on the front end is built to be single-threaded (for example, almost all of KDE is based on Qt, and one of the major problems I have with Qt is the crazy way it handles simultaneous events in a single-threaded model). Let's start assuming that it's possible for your application to start receiving two simultaneous mouse events. Will every bit of software be able to handle it? Not necessarily.
And then let's say that you get to the point where all the hardware, X Servers, widget toolkits and window managers are able to handle it by queueing the requests. Mouse events happen MUCH more quickly than keyboard events, so even if your application is designed to be fast enough to handle a keyboard event with reasonable speed, is it fast enough to handle multiple clicks simultaneously? What about mouseover events?
So you're looking to rewrite the X protocol, your X Server, and then spend about 6 months debugging every application you use. And that's assuming that you get the hardware to handle multiple pointers.
So I have two perspectives: I was one of the WebLogic developers, and I've been in a company using WLS (WebLogic Server) on Linux for a while now.
Many of the WLS engineers run on Linux. One of the first things I did at BEA was to give Windows the boot and do all development on Linux. There were some issues involved (mostly with getting Oracle's drivers to install themselves), but I loved doing java development on Linux. So do several other WLS engineers.
Then there's the issue of some of the native code which WLS uses to get real performance out of Java. That has variously been supported and non-supported under Linux, basically based on whether the linux-loving engineers had kept up with the Linux port. We've tried to get it running in our use of it here now, and I don't think we've had a ton of luck with it.
If you were to take you.jar files and move them from linux to windows or vice versa, it should work (i.e. your user-provided.jar files). And if you just take the weblogic.jar files, they'll work as well (remember, if you download the 100% pure java version of WLS, it just ships as a platform-independant zip file).
How many people do you know who are going to "accidentally" recompile and install a new kernel? Or how many people do you know who are going to attempt it without proper knowledge, produce a FAILED version, and then call tech support with teh standard "which is the 'any' key?" question?
I think a much better statement to this effect is that people won't be able to know how to do something which they know under Windows. But even there, how many people do you think are going to install FreeBSD and complain because they don't know what's going on?
I was working at a fairly large (> 1500 employee) software firm. I was working in a division of people who had been acquired in a takeover. Everybody got VERY rich off of that. But management in the headquarters started making some boneheaded moves (let me quote the VP of engineering for the division: "Some of you who have been acquired should remember who did the acquiring").
Of course, people started leaving like mad. It was getting pretty bad for a while. Morale was low, other people were actually talking to headhunters when they called.
The official response: All exit interviews had to be forwarded to the VP Engineering and new questions had to be asked. No effort was made to preemptively keep people from leaving, they just asked people (who of course wouldn't answer truthfully) WHY they were leaving. How ridiculous!
Dude, that's from an Anthrax song, and relates to the whole PMRC fiasco as you noted. However, it has nothing to do with federal statutes on obscenity, or even the NSI standards for domain names. For an example, go to www.death.com to see.
I've heard the same song, and I quite liked it. But the words of Anthrax do not an NSI policy make.
And since in California you no longer have to state your reasons for why you want an absentee ballot, more and more people are doing it. (previously, only people who couldn't make it to a polling place were granted absentee ballots. Now, anyone who doesn't feel like going [like lazy me who just wants to vote 2 weeks early] can vote absentee).
I, in fact, have never seen the inside of a polling place. I have no idea what they look like. I've never voted anything but absentee.
California has a lot of absentee ballots already, and things are going up from there. So while in Florida it might be just a tiny fraction, in California it's up past 5% if I remember correctly, and growing every election. That's not a tiny fraction anymore.
The beauty of San Francisco is that it consists of a number of neighborhoods, each with a fairly individual character of its own, more like London (with Hampstead, Clerkenwell, SOHO, Chelsea, etc.) than New York (where it all blends together more or less).
SOMA is in a difficult position, in that it's the only real place for the Financial District to expand into. It can't really expand to the north, because that's where some of the "neighborhoods" are. It can't expand to the west, becuase of Nob Hill and the ghettos. To the east is Water. Where else is it going to go?
Besides, SOMA never HAD a character. It was where people who couldn't afford the financial district were, if they were companies (i.e. they were warehouses).
I live in the Castro. Even though rents are going up and things are gentrifying, we still have our own character as a neighborhood. Lots of bars (if you're into gay bars), cute and nice restaurants, little shops, it's a great time. I love it here, and I would never want to move.
Noe Valley, Glen Park, Cole Valley, hell, even Hayes Valley and the Sunset have their nice characters as little neighborhoods.
There's a place for SOMA, but if you consider SOMA as a proxy for the rest of San Francisco you're missing out on what San Francisco has to offer.
First, don't go with an outsourcing firm. They're lame, don't bother. You really want to own the boxen (or lease them) and arrange for your own network.
So with that in mind, the real issue is one of reliability. Consider the following factors:
Cooling. Yes, it's been said, but it's very important. I'm at a software company, and even if we were to have the ability to control our cooling needs (and we don't at the moment, which is a major limiting factor), you'd be amazed at the kind of heat you'll put out. I've seen rooms where the cooling failed, and it's not pretty. Colo facilities have cooling situations that would make you drool, and they're redundant.
Redundant Links. For the price of one link, at a competant colo facility, you get several links to several backbones. One goes down, you're fine. Two go down, you're still fine. Even if you get dual T-1s or dual T-3s on your own, unless you actually lay your own fiber, you're probably dealing with your local RBOC owning the cable itself. So there's still a central point of failure. If the problem is with Sprint and you have an MCI link, you're fine. But if the problem is with SBC/PacBell, you lose regardles of how redundant the links you have to your office are. People often forget this.
Security. Ever had a janitor accidentally pull out a cable of any kind? I have. That won't happen at a colo facility.
Someone's there 24-7. At the colo we're using, let's say we get a page at 3:30am which says that our firewall has died. I can actually call the colo staff, and have one of them walk to our rack, pull ether from one box and into another, and go back to sleep. This is actually a big advantage.
Power redundancy. This is another big issue. Let's say you have a power outage in your office. Fine, your servers are on a UPS. Is your phone company's routers? Who knows. Let's say the outage lasts a while. Then everyone loses. Unless you spend a fortune figuring out everything in your setup which is power dependant (don't forget the A/C! If you have a power outage and your A/C goes, you might start burning CPUs in a matter of an hour or so), and making it redundant, what about one block away where your phone company is?
In short, the real issue with a colo is truly reliability. You could spend all your time and money setting up a comparable situation to a colo facility in your own office, but why bother? It'll just cost you more, and those are sunk costs which your CFO won't be happy about.
Yahoo! and eBay don't host themselves. I know at least Yahoo is located at several Exodus centers, but they have dedicated rooms.
Particularly when you're dealing with an Akamai situation, you need to be physically distributed, and that's what they're getting by being all over the place.
This doesn't actually help you if they have a search warrant. If they do, you can get your lawyer there, but there's nothing they can do beyond making sure anything taken is within the scope of the warrant.
Your advice is for when they start to QUESTION you. The only words you EVER need to remember are "I want my lawyer."
I highly recommend the HumanScale FreedomChair. My whole office has them, and they're great chairs. The back and seat is made of this hard-ish gel stuff (it's better than it sounds) which stays cool regardless of how long you sit. And the fabric is this Neoprene fabric which wicks away moisture. So it's got the cool, non-sweaty Back capabilities of the Aeron, but it's actually soft.
They're a little more than the Aeron, but if you're looking in that price range an extra $50-$100 isn't going to kill you.
The FSF didn't produce Debian, the Debian group did. They aren't associated with the FSF in any way, they're a self-regulating community of developers.
Your retinal pattern (feel like changing the pattern of blood vessels and nerves at the back of your eye?).
Your fingerprints (feel like grafting on someone else's finger-skin or burning the skin on your fingertips?).
Your hand geometry (feel like breaking every bone in your hand?).
Your facial geometry (and this doesn't count your skin hanging on it) (feel like breaking your jaw, your cheekbones, your forehead?).
If anything, this makes such a scheme much more secure than existing plans. You can easily forge a signature, and with the right changes you can match a photograph pretty well. But anything else requires significant body mechanics changes, which are very very difficult to do.
The US Immigration has actually created the INSPASS program, which uses a card and your hand geometry to allow you to walk through immigration at many US airports (San Francisco has it, I know). It's a concept which is coming to more and more uses in governments.
What's wrong with a little Eiffel? Or some Algol even? What's wrong with COBOL for that matter?
He's right. Learning some things will definitely help the way you think about things. The incredibly strong typing of something like pascal will definitely kick your *ss if you've been doing nothing but C for a while, and I think that's actually a Good Thing. Learning Eiffel if you already know smalltalk is a very different experience.
Even something like Algol will probably change your views and get you closer to the hardware in many respects (not that you can get Algol to run on most machines anymore....;-)
What about Ada? Programming by Contract really will teach you something serious about how you actually interact with the rest of your application, and while you'll curse it ("I KNOW what I'm trying to do and it's correct, dammit!") you'll be happier for learning it. Older, but happier.
And as long as the languages keep coming, there'll pretty much never be a chance to really run out.
Actually, no you can't. Try emigrating from the US to another first-world (or even second-world) country. Since everybody's essentially closed their borders entirely to make sure that you don't let in the third-world people, they've also closed them to everyone else.
Let's say I wanted to move to a moderately socialist country (let's say Denmark). I can't. While I could move out of the US, I couldn't move into anywhere else. Free flow of immigrants has essentially stopped throughout the world. Face it, you're stuck here.
Even if you COULD leave it, without getting citizenship elsewhere (which takes a long time) you can't really renounce your US citizenship (if you ever want to end up stateless [i.e. having no citizenship] you're crazy) if you're being practical at all. And if you're a US citizen, there are scads of laws which apply to you whether you're abroad or at home (such as bribing elected officials and paying US income taxes). So even if you leave it, unless you sever all ties to the US, you're not really gone.
So you can't just have a "Love it or leave it" mentality. Because you CAN'T leave it. So you have to attempt to effect change inside the US.
So one of the things which is interesting is that the owners of such art have taken to being VERY clever in keeping people from really enjoying it.
First, you have to actually know what they have enough to uniquely identify it. That may be more difficult than it seems. I can't remember how the registry works, but it isn't that great.
Next, they can arrange the time within reason. You work during the day? How about going to see something 400 miles away from your home at 8am on a Wednesday? Probably not that convenient for you.
Finally, you don't have the right to see it in its proper light or anything. So they can (and have) move a painting from the wall, lay it on a corner of the floor of an unlit barn. You might see it a little, but probably not enough to give it its full mastery.
While I agree with the principle of letting people see the art in exchange for keeping it out of the inheritance taxes, the loopholes have destroyed the spirit of the law there.
Uhm, I don't think he's arguing that at all. I think what he's stating, and probably rightfully so, is that people are better at choosing charitable organizations than the government.
The effect of the inheritance tax is to encourage people to keep money out of the hands of government. You'd have to be one of those REALLY inbred Old Money types to not have the knowledge to really keep Uncle Sam from keeping most of your money when you die. The money goes to charitable foundations, which are most certainly NOT part of government.
So the money stays AWAY from government. That's the point of the screed. Keep government from touching it at all.
Slashdot Mirror
I've used several of them (when I wear one out I get a new one, usually because ash from cigarettes gets into the keyboard because I smoke by it) and I've never had problems. I love mine. What problems have you had with the key action? I've always loved it.
Since my fingers don't move as much and they don't move in such odd ways, just about the only time I have to hit the backspace key is when I change my mind about what I have to type, not just because I hit the wrong key. BIG productivity gain there.
I was FAST with an ordinary keyboard, compared to the general population (about 80-100wpm burst when coding). I'm past 120wpm with the kinesis burst rate, and people always look at my fingers when I sit down to type something because they seem like they're moving so fast.
So there you go. Faster and more ergo. It's not as radical as something like the KeyBowl, but it's a good alternative.
The TPC is very correct in stating that a benchmark is not about one particular component. You can't test them in complete isolation. You must look at how a whole system performs under a specific workload. So it's actually pretty difficult to measure one component in isolation. If you're testing just the driver, you need to compare the drivers against the same workload, same schema, same data, same database. You can't test the WebLogic Type-4 Driver for Sybase with the Open Source Postgres Type-2 Driver. And since different databases are optimized for different things, you'll need to bear that in mind (this is something you'll probably know, but it's important for constructing a benchmark for your application).
Next is the issue of actually publishing benchmark results. First of all, you cannot publish a full TPC benchmark without it being audited. You can use their data, use their queries, but you cannot publish comprehensive numbers (such as QphD or QthM) because it's not permitted by the TPC. Look at how academic research papers in the database field do it. If they're doing query performance, they give you comparative numbers on the various queries, and maybe put it together into some artificial number, but they don't attempt to give a result. If you're looking at the TPC benchmarks, that's a very important consideration.
Now you get to the issue of publishing a result on ANY database. Not going to happen. Database vendors don't allow anybody to publish any benchmarks of their software under any circumstances, not even for academic reasons. The only people who get around that are people working for the companies, such as the IBM Almaden research people. You can't publish the results very easily, and have your advisor look into what you can use and/or publish. You might be stuck with Postgres or MySQL only.
And finally, there's the issue of what TPC-C is. Nobody ever does TPC-C in Java, nobody ever does it with JDBC. Have you read a full disclosure report for an audited run before? Not just the executive summary, the FULL disclosure report. They don't use Java. Hell, they don't use SQL. They code things directly to a low-level API which is completely native, and completely in C. Because here's a big insight which the TPC and RDBMS vendors will never tell you: TPC-C is designed to indicate how quickly an RDBMS can act just like a mainframe. That isn't very fast at all, so they have to "cheat" by taking SQL out of the picture. Read their client code. It's all native C library calls.
So with this we come to my recommendation: Use the TPC-W benchmark, for the following reasons:
That's what people use JDBC for. JDBC isn't used for TPC-C or TPC-H or TPC-Q workloads. It's used for web workloads. Why not try the benchmark used to simulate web workloads with a technology designed for web pages?
You can always play with the parameters. Don't like the reliance on static pages? Take them out entirely. Talk directly to the middle tier. Or reduce them in percentages to the point where they don't factor highly in the mix. If you can't get this tuned to where you see a performance difference, then the results are simple: JDBC performance doesn't matter. That's a pretty good result in itself.
You can also just take the bits out you care about. Are you willing to munge your own source code? Then extract the database code from TPC-W and run that.
You might also want to look at SQL3AP. It's good for measuring raw concurrency, but is a completely artificial benchmark with no relation to the real-world.
Much like any other Ask Slashdot, we're not provided with sufficient information to give you any real information at all. But hopefully this helps. If you care, email for more information.
Kirk Wylie
If, however, the hard drives are JUST data (i.e. firmware OS) then there's a pretty good chance that it assumes that it's got pre-formatted hard drives. Unless you format them, there's a very good chance that again, it's a no-go and you'll break everything.
And then finally, even if you were to know that you needed to format them, in what format? Do you know the FS format for them? If not, how exactly do you intend to get them ready?
Remember, this isn't something which has a boot prompt to which you can just install linux. It's an embedded system. Unless you're willing to really play, you're not going to figure out that much by just breaking the things.
Since this came up in several responses, when I say "two mice" I mean "two pointers," in the spirit of the original question. Everything is able to support two mice driving the same pointer. The issue is having two pointers. All my comments after the first paragraph are with respect to the issue of two pointers.
What's the point of having two pointers if you can only click on things with one?
Quite a bit more is going to be the software itself. Particularly on a system which was never designed to handle multiple mice, do you think that code like the X server is necessarily able to handle multiple mice doing things simultaneously? Also, if I remember correctly (but it's been some time since I did raw Xlib programming), the X protocol assumes ONE mouse. Which means that there's no way for the X server to talk to the applications and tell them that it was the second mouse that did something (i.e. no differentiation possible). You'd have to rewrite portions of X to get the second mouse active. Even if the X server and/or hardware was able to distinguish between the two types of mouse interrupts, AND show two different pointers, what about the applications?
I know that most of the software which is happening on the front end is built to be single-threaded (for example, almost all of KDE is based on Qt, and one of the major problems I have with Qt is the crazy way it handles simultaneous events in a single-threaded model). Let's start assuming that it's possible for your application to start receiving two simultaneous mouse events. Will every bit of software be able to handle it? Not necessarily.
And then let's say that you get to the point where all the hardware, X Servers, widget toolkits and window managers are able to handle it by queueing the requests. Mouse events happen MUCH more quickly than keyboard events, so even if your application is designed to be fast enough to handle a keyboard event with reasonable speed, is it fast enough to handle multiple clicks simultaneously? What about mouseover events?
So you're looking to rewrite the X protocol, your X Server, and then spend about 6 months debugging every application you use. And that's assuming that you get the hardware to handle multiple pointers.
Still seem worth it?
Many of the WLS engineers run on Linux. One of the first things I did at BEA was to give Windows the boot and do all development on Linux. There were some issues involved (mostly with getting Oracle's drivers to install themselves), but I loved doing java development on Linux. So do several other WLS engineers.
Then there's the issue of some of the native code which WLS uses to get real performance out of Java. That has variously been supported and non-supported under Linux, basically based on whether the linux-loving engineers had kept up with the Linux port. We've tried to get it running in our use of it here now, and I don't think we've had a ton of luck with it.
If you were to take you .jar files and move them from linux to windows or vice versa, it should work (i.e. your user-provided .jar files). And if you just take the weblogic.jar files, they'll work as well (remember, if you download the 100% pure java version of WLS, it just ships as a platform-independant zip file).
I think a much better statement to this effect is that people won't be able to know how to do something which they know under Windows. But even there, how many people do you think are going to install FreeBSD and complain because they don't know what's going on?
Of course, people started leaving like mad. It was getting pretty bad for a while. Morale was low, other people were actually talking to headhunters when they called.
The official response: All exit interviews had to be forwarded to the VP Engineering and new questions had to be asked. No effort was made to preemptively keep people from leaving, they just asked people (who of course wouldn't answer truthfully) WHY they were leaving. How ridiculous!
I've heard the same song, and I quite liked it. But the words of Anthrax do not an NSI policy make.
I, in fact, have never seen the inside of a polling place. I have no idea what they look like. I've never voted anything but absentee.
California has a lot of absentee ballots already, and things are going up from there. So while in Florida it might be just a tiny fraction, in California it's up past 5% if I remember correctly, and growing every election. That's not a tiny fraction anymore.
SOMA is in a difficult position, in that it's the only real place for the Financial District to expand into. It can't really expand to the north, because that's where some of the "neighborhoods" are. It can't expand to the west, becuase of Nob Hill and the ghettos. To the east is Water. Where else is it going to go?
Besides, SOMA never HAD a character. It was where people who couldn't afford the financial district were, if they were companies (i.e. they were warehouses).
I live in the Castro. Even though rents are going up and things are gentrifying, we still have our own character as a neighborhood. Lots of bars (if you're into gay bars), cute and nice restaurants, little shops, it's a great time. I love it here, and I would never want to move.
Noe Valley, Glen Park, Cole Valley, hell, even Hayes Valley and the Sunset have their nice characters as little neighborhoods.
There's a place for SOMA, but if you consider SOMA as a proxy for the rest of San Francisco you're missing out on what San Francisco has to offer.
So with that in mind, the real issue is one of reliability. Consider the following factors:
- Cooling. Yes, it's been said, but it's very important. I'm at a software company, and even if we were to have the ability to control our cooling needs (and we don't at the moment, which is a major limiting factor), you'd be amazed at the kind of heat you'll put out. I've seen rooms where the cooling failed, and it's not pretty. Colo facilities have cooling situations that would make you drool, and they're redundant.
- Redundant Links. For the price of one link, at a competant colo facility, you get several links to several backbones. One goes down, you're fine. Two go down, you're still fine. Even if you get dual T-1s or dual T-3s on your own, unless you actually lay your own fiber, you're probably dealing with your local RBOC owning the cable itself. So there's still a central point of failure. If the problem is with Sprint and you have an MCI link, you're fine. But if the problem is with SBC/PacBell, you lose regardles of how redundant the links you have to your office are. People often forget this.
- Security. Ever had a janitor accidentally pull out a cable of any kind? I have. That won't happen at a colo facility.
- Someone's there 24-7. At the colo we're using, let's say we get a page at 3:30am which says that our firewall has died. I can actually call the colo staff, and have one of them walk to our rack, pull ether from one box and into another, and go back to sleep. This is actually a big advantage.
- Power redundancy. This is another big issue. Let's say you have a power outage in your office. Fine, your servers are on a UPS. Is your phone company's routers? Who knows. Let's say the outage lasts a while. Then everyone loses. Unless you spend a fortune figuring out everything in your setup which is power dependant (don't forget the A/C! If you have a power outage and your A/C goes, you might start burning CPUs in a matter of an hour or so), and making it redundant, what about one block away where your phone company is?
In short, the real issue with a colo is truly reliability. You could spend all your time and money setting up a comparable situation to a colo facility in your own office, but why bother? It'll just cost you more, and those are sunk costs which your CFO won't be happy about.Particularly when you're dealing with an Akamai situation, you need to be physically distributed, and that's what they're getting by being all over the place.
Your advice is for when they start to QUESTION you. The only words you EVER need to remember are "I want my lawyer."
They're a little more than the Aeron, but if you're looking in that price range an extra $50-$100 isn't going to kill you.
Here's the historical note.
The FSF didn't produce Debian, the Debian group did. They aren't associated with the FSF in any way, they're a self-regulating community of developers.
- Your retinal pattern (feel like changing the pattern of blood vessels and nerves at the back of your eye?).
- Your fingerprints (feel like grafting on someone else's finger-skin or burning the skin on your fingertips?).
- Your hand geometry (feel like breaking every bone in your hand?).
- Your facial geometry (and this doesn't count your skin hanging on it) (feel like breaking your jaw, your cheekbones, your forehead?).
If anything, this makes such a scheme much more secure than existing plans. You can easily forge a signature, and with the right changes you can match a photograph pretty well. But anything else requires significant body mechanics changes, which are very very difficult to do.The US Immigration has actually created the INSPASS program, which uses a card and your hand geometry to allow you to walk through immigration at many US airports (San Francisco has it, I know). It's a concept which is coming to more and more uses in governments.
He's right. Learning some things will definitely help the way you think about things. The incredibly strong typing of something like pascal will definitely kick your *ss if you've been doing nothing but C for a while, and I think that's actually a Good Thing. Learning Eiffel if you already know smalltalk is a very different experience.
Even something like Algol will probably change your views and get you closer to the hardware in many respects (not that you can get Algol to run on most machines anymore....;-)
What about Ada? Programming by Contract really will teach you something serious about how you actually interact with the rest of your application, and while you'll curse it ("I KNOW what I'm trying to do and it's correct, dammit!") you'll be happier for learning it. Older, but happier.
And as long as the languages keep coming, there'll pretty much never be a chance to really run out.
My list would include:
I missed that show. Was it a travelling exhibition? A Beeb documentary? Something on Carlton??
Actually, no you can't. Try emigrating from the US to another first-world (or even second-world) country. Since everybody's essentially closed their borders entirely to make sure that you don't let in the third-world people, they've also closed them to everyone else.
Let's say I wanted to move to a moderately socialist country (let's say Denmark). I can't. While I could move out of the US, I couldn't move into anywhere else. Free flow of immigrants has essentially stopped throughout the world. Face it, you're stuck here.
Even if you COULD leave it, without getting citizenship elsewhere (which takes a long time) you can't really renounce your US citizenship (if you ever want to end up stateless [i.e. having no citizenship] you're crazy) if you're being practical at all. And if you're a US citizen, there are scads of laws which apply to you whether you're abroad or at home (such as bribing elected officials and paying US income taxes). So even if you leave it, unless you sever all ties to the US, you're not really gone.
So you can't just have a "Love it or leave it" mentality. Because you CAN'T leave it. So you have to attempt to effect change inside the US.
First, you have to actually know what they have enough to uniquely identify it. That may be more difficult than it seems. I can't remember how the registry works, but it isn't that great.
Next, they can arrange the time within reason. You work during the day? How about going to see something 400 miles away from your home at 8am on a Wednesday? Probably not that convenient for you.
Finally, you don't have the right to see it in its proper light or anything. So they can (and have) move a painting from the wall, lay it on a corner of the floor of an unlit barn. You might see it a little, but probably not enough to give it its full mastery.
While I agree with the principle of letting people see the art in exchange for keeping it out of the inheritance taxes, the loopholes have destroyed the spirit of the law there.
The effect of the inheritance tax is to encourage people to keep money out of the hands of government. You'd have to be one of those REALLY inbred Old Money types to not have the knowledge to really keep Uncle Sam from keeping most of your money when you die. The money goes to charitable foundations, which are most certainly NOT part of government.
So the money stays AWAY from government. That's the point of the screed. Keep government from touching it at all.