Slashdot is powered by your submissions, so send in your scoop


Forgot your password?

Comment Re:Current evidence does not support reasonable do (Score -1, Offtopic) 666

I'm having difficulty coming up with a rational explanation that doesn't include the stronger person being a predator who engineered a situation where they expected to face no consequences for their actions

There is no "rational" explanation here. Either the man is a rapist -- irrational behavior -- or the woman is a liar and an abuser -- irrational behavior. If we go looking for rationality in a situation where we know one or both persons involved behaved irrationally, we're going to have trouble.

It does happen that smaller women physically attack larger men. (Though I have no knowledge of the size or strength of the people involved here -- I'm assuming your characterization of Weidman as "physically weaker" is based on some knowledge.) And it does happen that women make false allegations of rape. Did these things happen here? I don't know. But either way it does point up an important real-world security rule: don't be alone and unobserved with someone you don't trust.

Comment Re: awesome (Score 1) 99

OK. I made one "typo" (well, "though-o"). I mean fission power, rather than fusion, would be enough to get us out to the Oort clouds.

OTOH, the icy moons of Jupiter have too high a gravity to be an attractive choice. You'd need specially designed equipment. Those are no minor masses. Still, there are plenty of icy asteroids beyond Jupiter's orbit.

WRT the Oort clouds...there's a lot of stuff there, but it's rather thinly spread. So figure long transition times between "stops". Probably not practical until we are building habitats the size of cities.

For that matter, it's not wise to focus too tightly on one particular approach. Consider a habitat that's in the shape of a long tube, and that grows by building onto the ends. Perhaps a couple of miles in diameter, though different sections could have different diameters. And spinning, for gravity. Given a long enough tube you can make bends through some pretty sharp angles without causing much stress, though I would design it so that different sections could be safely decoupled, and replaced, removed, or inserted.You'd probably want an occasional non-rotating section. Transport if via electric train, though, so you'd want the sections to be pretty long, to avoid excessive transfers, unless you run the trains in an evacuated tube in the center. Occasionally you'd want an extension to run either straight in or straight out. Power collected at locations near the sun. How far could you find building material to reach? Now use one of the "straight out" constructs as a linear accelerator to launch vehicles to the stars. You should easily have an accelerator 100's of miles long in a vacuum all the way. I'd be a bit hesitatnt, however, about using it to catch incoming freight, even presuming it was designed to do so. Also, you don't want a really high launch velocity, because that would make interstellar material act like really heavy penetrating projectiles. Even a few grams impacting at over 0.5c would be unsurvivable. And though such things are rare, you'd be transiting a HUGE amount of space. So what you want to launch would be habitats designed to eventually go into orbit around some other star. They'd need fission power sufficient to make the trip, with a bit of leeway to allow them to start mining at the arrival end. And they'd need to be travelling at not too far above the local speed of debris, so that they could either dodge it, capture it, or survive the impact. (Lead shielding for impact survival, as the impact would be "supersonic" so crystal strength would be much less important than mass.)

This approach would certainly let us reach the Oort clouds, and live there as long as power held out, but I doubt that there's much fissionable mass available there, so stopping there doesn't seem viable. (Controlled fusion would, of course, change things *quite* significantly, though just how would depend on the machinery required to control it.)

Given a nearly closed ecology there are many approaches to living in space, and which is chosen is more a social choice than an engineering one. (OTOH, there are a lot of ways that just wouldn't work, without "magic technology".)

Comment Re:Innocent until blogged about (Score 1) 666

Probably not worth prosecuting. He won't be a repeat offender in their country, since he was going home soon. She was also going home, so they wouldn't have the only witness in country to testify.

I'd suspect even with a mountain of evidence, including video of the event happening, they would have let them leave, or possibly make him leave the country early.

Comment Re:Innocent until blogged about (Score 1) 666

    I'm sure they both tripped on the stairs, or at least someone will try to claim it.

    I suspect this guy will end up dead to the world. Probably not physically, but when the government has a deceased record, he's less likely to have a valid drivers license and passport.

    I'm glad she got away. I wish more was done by the local authorities. Since they're both home, there's no chance he'd be prosecuted for it. Well, unless he should accidentally end up back in Poland without a passport or any identification.

    [goes off to search for "live animal" air freight shipping from Argentina to Poland, and the delivery address of the jail]

Comment Re:He May Be Dead (Score 1) 98

Citrix very much reminds me of using a desktop computer to connect via dialup to a 300bps machine. I'm using my fast, good computer as a dumb terminal to a slow crappy computer. Except that typically the manufacturer of the 300bps machine knew their interface was slow and would at least try to design the applications to make that as unobtrusive as possible.

Comment So They Don't Understand It Either? (Score 1) 305

It really isn't that hard. You're looking for someone who takes pride in the quality of their work and ideally actually enjoys doing it. You may also be looking for someone who will work well on your team, or who can be fantastic as a lone gunman with relatively little micro-management. The brain teasers work pretty well because it's pretty easy to spot someone who will just give up without thinking about the problem. They also do a good job of finding the people who aren't really paying attention to you during the interview. If you're a bad interviewer, you think you're looking for someone who can answer the questions correctly and just look at that and not their entire thought process as they try to solve the problem. Do they break the problem down into solvable components? If they get off track, will they pay attention to the hints you give them to get them back on track? Do they try to bullshit their way through with a non-answer (In which case you should refer them to marketing or management.)

If you know what you're looking for, you don't even really need a brain teaser. The old design-a-trivial-function along with some basic questions about data structures or design patterns will weed out most of the really bad candidates. Ten seconds into "design a function on the whiteboard," I already know if it's going to go badly or not. If they're just crapping code onto the whiteboard, it's going badly. In ten seconds I've pulled back the veil of all the buzz words they used to get through HR to the interview and can see exactly how they're going to work under pressure. I'll take a high school dropout who actually takes the time to make sure he understands the question and shows me he can design a solution over a PhD who tries to BFI his way through.

Comment Re:I've come out of hiding just to say... (Score 1) 98

Years later it's still clearly nothing more than a nasty hack.

Sometimes a hack is what you need, and it's the difference between being able to accomplish the goal, and not being able. But key is "years later." Now Citrix is irrelevant, but 20 years ago it let you do things which otherwise simply couldn't be done, and "p0wned" is largely a non-issue when talking about machines not connected to the Internet.

Let's say it's 1994 and you have a legacy MS-DOS application where porting it to Linux or whatever isn't an option. The application talks a lot to a database, and it's fast enough over 10M ethernet. But your medical practice has a satellite office a few miles away, and for a shitload of money, you can get a 56K link. (Yes, these numbers all sound so quaint today, but that's the whole point.) You're not going to have 8 users running that app doing its database queries sharing a 56k link. The patients will die of old age in the waiting room if you do that.

But you put a Citrix box at the main office, which is OS/2 2.0 plus Citrix's hacks, an 8-serial-port digiboard, plugging into a serial multiplexer which plugs into your synchronous mode USR Courier plugged into the 56k link. At the satellite office the other Courier plugs into the demultiplexer and serial lines go to the terminals, and there you go. You've got 8 users at dumb terminals running an MS-DOS legacy app which is really running at the main office where it can easily query the database fast enough. And it works.

Of course it's a hack. But it's a hack that lets you tell the client Yes, we'll take your money and make it work and you'll be able to see patients. That's better than telling them No, it can't be done. Don't you agree?

Ten years later, you might say "screw Citrix, just run dosbox on some Linux machine instead, and connect by ssh over an IP link (or the Internet itself)" and dude, I would totally agree with you. But no fair, you're in the wrong decade, unless you have dosbox working on Linux and talking to Netware servers in 1994 -- and you don't. Believe me, I know, I looked, and you just don't have that in 1994. Or forget dosbox, just port your shitty legacy app to Linux, right? *sigh* Once again, you have my agreeing with you in principle, but it's 1994 and you're trying to sell Linux and you've been pleading for years that we ought to work on getting our app no-longer-dependent on unportable proprietary libraries (and compilers!), and .. holy shit do I NOT miss those days. OMG do I love my new job. Sometimes I forget how much I love my new job and how much crap I'm not dealing with anymore. :-) Fuck you, 1990s. I don't ever want to see the fucking 1990s again. If I'm ever walking down the street and the 1990s are there .. I don't know if I can be held responsible for what happens.

Comment Comparison (Score 5, Insightful) 305

I've just gone through interviews at Google and Apple.

At Google, I was asked mainly theoretical questions - big-O, maths/stats, etc. And one "real" architecture/design question at the end. There were 5 interviewers and maybe 7 questions, sometimes 2 per interviewer but usually just 1 that lasted the whole hour. According to my recruiter before the decision, it was maybe 50/50 that I'd get an offer, and I did very well on the real-system design question (by inference, not so well on the others :). I didn't get the job.

At Apple, I had a seven-hour interview with seven interviewers. There were many many questions, far too many to easily remember categories, but they were all focussed on things I might end up doing, or problems that I might end up encountering. I got the job. I guess I do better with "real world" issues than the "consider two sets of numbers, one is ... the other is ...) type.

I have the self-confidence^W^W arrogance to believe I'm an asset to pretty much any company out there, but interview processes are nothing more than a gamble. Sure you can weed out the obvious under-qualified applicants, but frankly (unless the candidate is lying, and in the US that's a real no-no, in the UK padding your CV seems to be sort of expected...) that sort of candidate ought to have been pre-vetoed by the recruiter before getting to the interview.

I've yet to see the interview that guarantees a good candidate will do well. It's all about preparation: can you implement quicksort or mergesort right now, without looking it up ? The algorithm takes about 20 lines of code... Some interviews will require you to have knowledge like that; others are more concerned with how you collaborate with other candidates; still others are concerned with your code quality (I've seen a co-interviewer downmark a candidate for missing a ; at the end of a coding line. I wasn't impressed ... by the co-interviewer. But that's another story); still others are ... you get my point. Whether you do well or not can depend more on the cross-intersectional area of the interviewers style and your own credo than any knowledge you may or may not have.

So go in there expecting to be surprised, prepare what you can, be prepared to do wacky things to please "the man" interviewing you. For a good candidate, over a large number of interviews, you'll do well. The problem is that we often want a specific job, and we get depressed by the first dozen or so failed interviews. There's nothing more you can do than pick yourself up and try again. It's instructive to note that second-interviews at companies often go better than first-interviews, possibly because you're forewarned about the style a bit more, and therefore a bit better prepared...

Slashdot Top Deals

ASCII a stupid question, you get an EBCDIC answer.