Neither should you hand a programmer pen and paper and tell them to code. Set them down at the devel environment, with access to all the man pages/language reference you normally have, and let them code. Forcing them to work in an unfamiler environment just because it's an interview is silly, and will probably lose you many qualified applicants.
Depends on how trivial the code should be. "Write a function that reverses a C string in place" should be OK with no references to the man pages, up on a white board. In the past I have asked exactly that question, given the interviewee a xterm with vi or emacs running and let them at it.
On the whiteboard I would forgive simple syntax mistakes and the like. There don't need to be any function calls (a lot of people call strlen, which is fine, but not needed). I'm looking for things like "did you malloc a buffer you don't need, and then forget to free it, or worse yet return it?". If they did the online version, did they test it? With both even and odd length strings? A zero length one? A single byte?
A lot of people who claimed to know C couldn't get the syntax right for the function (given a compiler, I expect one to be able to compile edit compile until you at least get syntactically correct code!).
More people didn't know what "in-place" means (hint, if you aren't sure what you are being asked to code, ask for a clarification).
Still others merely used a poor algo, like malloc'ing a second buffer, copying the string in reverse to that buffer, and then moving it back to the first buffer. Those people are minimally qualified. If they do well on other questions the may still get an offer.
Remarkably few made one pass over the string to find the length, and then a single extra pass to do the reverse. Those are the people I was looking for:-)
The thing to remember when interviewing is any environment you give them will be unfamiliar. They will be under a whole lot of pressure (esp. now, the three people I have interviewed since my multi-month unemployment have received more simpathey from me, but not easier questions). Don't base the whole outcome on a single question.
Seriously don't base it all on a logic puzzle. They may have heard it before. Two flash lights, five people blah blah. Why are manhole covers round? So on... You may end up with a drooling idiot that red the same interviewing books (or logic puzzles...with answers!), or who got asked those same questions last interview and at least was smart enough to find the answers later!
I do show potential maintance programmers a buggy line of code and ask them to spot the bug, or short functions with obvious bugs. But these are clear bugs (like if (a or not a) then x), and not the whole interview.
4.2% is bad, but not for the reason most people think; with only 4.2% unemployment, it's hard for the economy to grow, because most of that 4.2% are the hard-core untrainable.
I doubt it. Not for the reason most people think either:-)
Oh, I believe there may be more then 4.2% of the population that is untrainable for jobs. I don't believe the unemployment rate counts many of those people. The unemployment rate tracks job seekers, so people who have given up (my wife for example) and aren't looking for work anymore are not counted as unemployed.
A lot of those people are the untrainable, and I believe most active job seekers are trainable (or pre-trained) for something.
Calculating the unemployment statistic this way has its advantages (decent measure of how many people are competing for any given opening), and disadvantages (doesn't show how many people really are out of work).
I'm no economist, but I bet the "ideal" unemployment rate is somewhere between 5% and 7%. Remember, 5% unemployment doesn't mean 5% starvation due to months of being out of work; it means 5% are out of a job some time during a given time period. That includes anybody who leaves one job before they find another, and then finds a new job two weeks later that pays more.
That's not the same unemployment number that gets published. I got counted as unemployed for a few months because after getting layed off I marched down to the unemployment office and signed up to get my money back (in VA at least the unemployment pay pretty much came out of your paycheck, and you can never get back more then you gave in). I have some friends who are too proud/stupid to do the same, so they aren't unemployed, they just have no job. I also know people who quit work out of disgust and are without jobs, and are not being reported as unemployed (they aren't eligible for unemployment insurance benefits, as the quit).
P.S. yes, I did find another job pretty quick. Actually I had my first offer (no stock, but more cash then my last) within a week or two, but it took three months to find a job I really wanted. I think if you have the same skills it took to get a job in 1992, you can get one again now. Well not quite the same skills (SunOS 4 knolage won't get you anywhere unless you call it Solaris and forget the "1"), but a similar set.
Go into any American fast-food restaurant or convenience store right now, and it's quite likely that you'll be dealing with idiots who can't even work the cash register without their manager present. If they treat you like crap, they won't get in trouble, because the manager knows he'll have trouble replacing them.
That may be pretty true, but I think it is more a matter of they can't get better for the money. Fast food service has been crappy for as long as I can remember. That includes a few times of high unemployment. Why? Well I'm guessing that the service can be crappy and the place keeps pulling in money, so enough money is offered only to get a minimum level of service. If they payed enough to get bright cheerful people they would have to pay as much as a real restaurant, which would drive the prices of the "food" up to close to real food, and fewer people would go eat McProtoplasam when they could pay almost the same for real food.
When will the care industry stop trying to make vehicles more like mobile homes? They spend all that time and money in crash tests, but then turn around and add distractions that can only be detrimental. Certainly people can do without these features while they're commutting from place to place.
I would assume these things would be pretty safe if used by a passenger, and perhaps useful to the passenger as well. The MP3 player ought to be more safe then a CD player as one should be able to have it run much much longer without repeats, so you won't be as likely to change the "CD" at the wrong time.
Probably also useful and mostly safe when stopped dead in traffic, at least as long as you put it in neutral and pull up the parking break. A paper back works well then too though.
Sooner than later, we're going to start clogging the courts with lawsuits involving people in accidents where these toys were involved. Cell phones included. When the time comes, I say they do the same thing they did with the tobacco industry. Slap them with a hugh lawsuit. It's not like anyone can't see it coming.
Hasn't it already? Isn't that why the USA didn't get nav systems in cars until years after european models?
Of course, the people using these devices are equally as guilty.
Or more so, the people are the ones using the toys at a unsafe time or in an unsafe manner (or who just plain got unlucky).
Any idea if they count the power station emissions and the environmental cost of replacing lead acid cells every couple of years for electric vehicles?
They don't. I don't think the envromental cost of the batteries is all that significant, but the economic cost may be (it is about half the cost of the EV1, and has to be done every three years or so).
Even the best gasoline engines in cars are in the range of 20-25% efficient (ie: at best 25% of the fuel is converted into usable energy... the rest is waste.)
Including the Honda, which mostly just runs the gas to charge the batt, and as an assist when you really need the extra shove?
As a special case there was a cross country "race" where minimum fuel use was the key issue. A gas car won. A normal stock gas car. Driven by the then-editor of Car and Driver. Of corse he was drafting behind a truck on the whole trip...
Yeah -- the hypemasters forget that there's more to a car than just running it, but they forget on both ends. They forget about production and transmission of gasoline too...
Yep, I did overlook moving (and cracking) the gas.
... and they forget about creation and disposal of parts and fluids... the electric car has very few moving or replacable parts... the batteries are about the only problematic ones. Compare that to all the crap in a combustion engine.
Electric cars still have breaking systems (the ones that stop you), more complex ones because they try to recapture the energy. Alternators (as part of the break systems), wiper systems, and a host of other parts. All of which have broken at one time or another in at least on car I've owned.
I think electric cars can do without a transmission, but I'm not sure all do. They generate a lot of torque, so some electric cars may choose to reduce that. Electric cars have extra parts -- two or four electric motors that are way bigger then any electric motor a gas car has! Or maybe only one, but then you get the full glory of a differential and the rest of a traditional drive train (no timing belt though).
When I was in collage I did my own car work, many of the parts I replaced had nothing to do with the gas motor. Of corse a few were because VW hadn't discovered electricity:-) (if you don't get the joke the VW Rabbit used vacuum to do a lot of control functions modern cars use electronics for).
However with the possible exception of the battery I don't think any parts of the car contribute anywhere close to 1% of the pollution that the fuel does. They do contribute to how reliable people feel the car is, and that will help influence whether you can sell the things or not, but they pollution represented by one change of the transmition fluid isn't noticeable next to the gas that took you 100,000 miles.
Anyway... you said it "probably" polutes less... just thought I'd clue you in a bit.
I'm still not convinced. I'm not convinced either way though. Electric cars could well pollute less, depending on the source of the eletrictricty, and the real cost of making gas. Would be nice to know though.
It would be good if the law actually did know. Whatever this law rates is going to shape how low emission cars are designed, not reality. If something makes the car (+ support systems) pollute less, but this law doesn't recognize it, then it is unlikely to happen. If it makes the car + support systems pollute less, but the law sees it is more, then it will not happen. I don't dislike it because it bashes my precious gas cars, I don't like it because it might bash something better then electric cars.
... so we build more nuclear?
Well, that seems a bit unlikely, we haven't built a new one since the late 70s. It doesn't look like we will do it again anytime soon. (and yes, I think nuke power can be pretty good)
We use superconducting transmission lines? We've got more efficient cars.
So? Build a more efficient oil cracker and you get more efficient cars. Oh, and cheaper winter heating. And cheaper electricity. And cheaper plastic army men.
CA, and some other states have a low or zero emission requirement. Anyone that sells more then X cars must sell some small percent that have very little or no emissions.
In my opinion the law is flawed in that electricity is assumed to have zero emissions, rather then a guess at the emissions required to produce the electricity (which may be more then some extreamly efficient gas cars). The Honda gas/electric car for example is assumed to pollute more then the EV1 even though it probably pollutes less.
Anyway the Fuel Cells may well be looked at as a way to meet the low/zero emission laws, and not as a replacement for gas. Of corse if people like the fuel cell cars then that may change. Well, like them for the price they can be produced. The EV1 was liked by a fair number of people (it had a ton of torque), but GM leased it for about $30k, it cost them more like $60k to make them. People would have to like them a whole lot to pay $60k for them!
Actually the law is more flawed then that, but I don't generally like new (or old!) laws anyway.
P.S. yes I do find it ironic that CA has "electric car laws", and is sticking to them in the face of an electricity crisis, but the electric car laws don't actually require electric cars (they are strongly tilted towards them though)
Cannot focus the beam, as the reflector is inside the LED itself
One of the very first lights reviewed in this article does focus the LED much like a normal flash light. It is true that very few others do though.
The "white" light, while impressive and cool, is not that great for night-time viewing. It can ruin your night vision, and does not display contrast as well as the yellow light. (of course, no one wants to put a yellow LED in their flashlight, even if they exist, because it's not "cool")
The white is definitely easier to read by though, at least for me. It does reduce your night vision though. Works well for finding cables under a desk in a dim office though.
P.S. I'm sure I have seen yellow LED lights, they might just be micro light sized though. You can definitely get the red ones full size. Good for preserving night vision. I don't really like the way red ones make things look though.
So.. my advice is to find a local outdoors retailer that has these lights, or better yet -- look for a flashlight freak like me that has these lights, borrow them, and try them out before you plonk down $20+.
If $20 is a lot of money, definitely borrow first. If it isn't march right out and buy a Proton and put it on your key chain. Proudly declare your flashlight geeakery. Maybe later you can buy a real LED light too:-) I haven't gotten anything bigger then the CCTrek, it is good to read by, and my wife uses it to watch the dog in the backyard. It probably has almost saved it's own cost in bulbs and batteries yet. It would be a bad hiking light though.
Re:Games: XFree86 with DRI, or Linux FBDev?
on
XFree 4.1.0 Out
·
· Score: 4
Wouldn't it be easier for the XFree folks if they
didn't have to worry about making video drivers, and instead it
was all taken care of by the kernel? IMO, the only driver they
should develop is the fbdev version.
Sure, if the fbdev code was accelerated "enough" and supported
all the primitives for 3D and whatever else they want, then it
would be easier. If or course fbdev was on all the OSes they wanted
XFree86 to work on. None of that appears to be true.
Now they could divert that effort in making and extending graphics
drivers from X to fbdev itself, but that would limit the OS choice
and be a whole lot harder. Writing kernel code is very
painful compared to writing user land code. Actually it isn't the
writing that is so hard, but the debugging. My relatively few
kernel modifications have taken about 4 to 5 times longer then I
had guessed to debug, and I had already bumped the number up because
I thought I knew how hard it would be...
Plus XFree86 is used by a lot more then just Linux, and I believe
many of the XFree86 commiters are not Linux-only users (in fact
the only XF86 commiter I personally know is a rabid anti-Linux
zealot). So I doubt they would want to abandon support for OSes
that didn't have a usable fbdev.
One small point in this
arguments favor is that they have a fbdev driver, and have continued
work on non-fbdev drivers.
So it seems to be the lesser of N evils to essentially have a
user land device driver of inordinate complexity.
but if you'll read the blinking article, you'll see that the sqatters aren't "demand[ing] guaranteed jobs from government," they're asking the government to force their former employer to hand over the back pay it owes them, and to punish that US-based employer
I don't know that they want guaranteed jobs, but they want the old ones back:
the workers have transformed their claim to $10 million in unpaid wages and refusal to accept forced resignations into a national issue.
Emphasis added, otherwise a direct quote from the CNN article. I totally agree that they should receive pay for any period they worked, I don't know enough to say anything about getting their job back.
The US has more people in prison, by percentage, then Stalin did in the former USSR.
The US drug war is pretty damn bad, however Stalin killed a whole whole whole lot more people then we have arrested (so far), let alone killed. Directly at least. If drugs were legal a lot of current drug related and organized crime death would probably be significantly reduced.
It would be nice, though, if Journaling Versus Soft Updates: Asynchronous Meta-data Protection in File Systems were made available to everyone, not just Usenix members.
I don't really think the Usenix membership is worth $50/year to get the lame newsletter, access to the proceedings is pretty valuable, and their conferences are quite good. In addition to learning about soft updates the 1999 conference taught me a lot about how select sucks, how to make it suck less, and that not all of CA is a warm paradise.
The previous FFS was ass slow because it basically didn't cache writing to the disk (we're talking non-smartdrive DOS FAT16 speed here).
Sure they did. They write-back cached data writes to disk. They write-through cached metadata disk writes (and blocked other writes until metadata writes completed). That would leave your filesystem in a mostly consistent state, and not suck too hard in the event of a power failure. The other choices are ignore the possibility of filesystem damage from power failures (or panics), I think Linux's EXT2 did that, or maybe just did it by default, or to log metadata changes (XFS does that, and I heard EXT3 does too, but I'm not sure).
Softupdates carefully orders disk writes, and can if needed reconstruct the proper intermediate state for a metadata block. It has the performance of a totally async filesystem (i.e. somewhat higher then a logging system), but the stability of a logging system (i.e. better then the previous sync filesystem). It is also the major foundation for filesystem checkpoints and in-the-background fscks (possibly coming in FreeBSD 5.0).
The other change they made (dirperf) had to do with directory block placement, I think the old algo attempted to put them close to the datafiles, and with larger caches this is no longer a win, and has become a loss. I haven't read any papers on it or anything, so I don't know a whole lot about it.
Don't get me wrong, I've been using OpenBSD for my firewall for 2 years now and it's great. It just seems like this took a long, long time to get into a release.
OpenBSD is secure in part because they are conservative in adopting new features. Two years ago softupdates was pretty new, and leaving it out let FreeBSD, BSD/OS, Solaris, and NetBSD experience the teething pain (as a BSD/OS beta user at the time softupdates was rolled in, I felt some of the pain, but it wasn't too bad, never had any data loss from it, unlike soft-read-only which I think was killed).
So, they basically wrecked the extensibility of the architecture so a completely theoretical untested performance hack for the x86 architecture *might* go faster... however much faster is unknown, since this is totally untested.
I don't see how it is x86 specific. It is specific to CPUs that use caches, which is pretty much all non-embedded CPUs, and many of the embedded ones. I would imagine this would not be faster on something like the Terra, which is a non-cached CPU, but since it relies on proper management of 1000s of hardware level threads, I don't think Linux is ready to run there at all. Even on those systems it should be faster then indirecting through a pointer, faster by exactly one memory access (the pointer).
I do agree that it is untested (in terms of benchmarking). I don't think it has entirely wrecked extensibility. One needs to modify that file to add a filesystem, so you can't do it through a run-time loaded module...unless you use the generic void*.
I'll go for "that is really really ugly", and maybe even "does that make a noticeable difference when you are probably going to schedule a disk I/O?", and even "I'm glad FreeBSD doesn't do that". There is no way I'll buy "it's x86 specific" though.
Re:What are the ethical implications here?
on
BoyCott Advance
·
· Score: 3
The authors have no rights. They signed them away when they agreed to perform work for hire. The "author's baby" argument is purely emotional, and does not make sense.
For some games. For other games the author may well not have signed away all rights. When I use to work at Microprose (at, not for, I was in the same building, doing CoinOP games for what was in theory some sort of spin off) people still did bring in independently written games and negotiate some of the resale profits for themselves. Of corse the games tended have all graphics and sound replaced, and a lot of extra debugging, and sometimes game code slapped in by the Microprose folks, but the original author still got a per-box cut.
And that ain't the only thing. A lot of game companies are pretty small, and profit share, or have employee stock ownership. Some of the big ones do as well.
Even the giants that don't really do any of that do still have room in the annual salary review for you to say "I was a big part of Jane's F-16, and it sold X copies, so your raise had better be at least Y% or I'll go work for FOOCORP", and yes that X is altered based on exactly how many copies are bought, or not.
Don't delude yourself, even at MEGAGAMECORP there is a team of real people behind each game, and if the game was any good they worked real hard on it (except for the team slacker - and at least he got the short end of the stick during the nerf fights). Their future at MEGAGAMECORP depends in large part on how well the game does. Even if they did it as "work for hire" and have no legal direct ownership.
Good point, BUT it does it reduce the likely hood that Transmeta would independently implement x86-64, doesnt it?
I don't think so. The way AMD implements x86-64 isn't low power. As far as I know it isn't working either (not as in it is behind schedule, but as in it hasn't taped out). Transmeta last year got (as far as I know) one of their existing CPUs to implement the x86-64 instruction set so AMD could start working on system level code (reference system BIOSes, and one hopes GCC, and open source OSes).
As far as I know transmeta has only licensed the x86-64 instruction set (and I would assume any applicable patents). I could be wrong, since the article doesn't say one way or the other. I'm guessing because doing it the other way would make transmeta a 2nd source for the x86-64, and there would have been a press release about that.
Re:What are the ethical implications here?
on
BoyCott Advance
·
· Score: 2
Let's say I kinda like playing one Playstation game now and then but would never buy a console plus the game just for that. Who loses anything if I play the game in an emulator?
On the other hand, what if you are wrong? What if only having access to that Playstation game at your friends house finally wears at you, and you go out and buy a playstation (they are cheep now after all!) and the game? I mean a lot of people are wrong about themselves. Lots of people that don't think they can quit drinking can. Lots of people who think they can quit smoking can't. What makes you think you really know what games you will and won't buy if you don't illegally copy them?
On the gripping hand, maybe you never would buy the game, but you illegally copy it. Then your wife/mother/girlfriend catches you, and makes you buy it. Then clearly your illegal act has made the copyright holder (and 8 middle men) a few cents.
On the....hind paw...maybe it isn't about the money. Maybe it is about the rights of the authors of the program? Didn't they sweet blood? Don't they have the right to say who can play the game, and who should take a hike?
I'm sure I could come up with a few more viewpoints....but I have to eat breakfast, and fire up Hitchhikers on my Z-machine...
The Real Time Scheduler does not really make Linux an RTOS because in and of itself it does not provide kernel pre-emption - the ability for the kernel to interrupt kernel-space code to deal with incoming events that _must_ be processed. This is a requirement of a 'proper' hard-RTOS because such an OS must be able to guarantee a response time, and if it cannot interrupt kernel code the OS scheduler may be stuck waiting for kernel code to return before it can go on to deal with the input.
As a minor nit real time kernels do not require kernel pre-emption. The require a bounded maximum interrupt latency time. In theory the bound can even be high (100+ms, or hours even). In practice the bound has to be low just like you said. In practice kernel pre-emption is the simplest way to do it (one could also use a true micro kernel that only passes messages, and does that really fast, making all of the "real work" done in premptable user level code).
There is also the difference between hard and soft real time. Soft real time like a video game can't handle going above the stated latency very much or the animation will stutter and the user will become displeased and play a different game, but it can handle once in a while blowing the stated latency. Hard real time can't handle missing the promised latency, a computerized fuel injector might be a good example of this. If it misses, even just once it could inject fuel at the wrong time, and might blow out a delicate gasket and cause $1000 of damage to your engine (this may also be a bad example, I'm not sure how tight the timings really are for CFJ).
So - that means there are basically two competitors for x86 chips. That means that basically this move HAS consolidated the market, and that their less competition, and therefore less innovation, and more harm could and will be done to the consumer.
Has transmeta licensing a new CPU (or peripherals) bus reduced competition? Or has it increased it slightly because now you could more easily swap out the two CPUs? (or maybe just use the same high speed peripherals)
Has transmeta licensing the x86-64 instruction set reduced competition, or does it give you a second source for CPUs that can run 64bit x86 code?
You forget that I was criticizing the statement, not necessarily the story at hand.
Well I did start off on that topic, agreeing that slashdot appears inconsistant, and then saying maybe in this case it isn't really. Then I wondered off and commented about the story, and then couldn't resist poking fun at the iTanic, and how utterly lame the x86-64'x REX prefix is.
Are you daft?
A bit, yes. Couldn't you tell?
Can't we get back onto topic though? When is AMD going to do something about those orbital mind control lasers?
Logitech could have put in good encryption, and talked up the weakness of their competitors. One press release per weak about how your competitors are betraying the public can drum up a lot of business.
Are there any competitors in that space (RF keyboards)? I'm not exactly in the market for a wireless keyboard, and if I were it's likely that IR would do it for me.
Also as I said before, mentioning security will remind people that they have no idea if it is secure. After all anything claiming to be secure in the past seems to have had later announcements about how it's not exactly as secure as first claimed... (and no, not everything does, but it happens enough that I expect lots of folks have that impression)
Wrong. Lots of work has been done to stuff good encryption in tiny CPUs. Think smart cards. In particular, ciphers that use multiple LFSRs require miniscule amounts of silicon.
Ok, if they spin their own silicon they might be able to do it, I don't own one of those things, so I can't check to see if it is all off the shelf parts, or has any custom ICs, or even FPGAs. I'm assuming these small area designs have been openly published and withstood attack? Or are small area designs of real cyphers...
Yeah, running a wire between them for a moment when it's first installed is *so* hard...
Sure. First it costs money to put the wire there. Then it costs money if people screw it up, or think they did and call the 800 number. You need long term storage to hold the key (FLASH, NVRAM, whatever), and if it is battery backed you will need that cable again in a few years, or there is another 800 call.
WEP was designed by a microcephalic crack-smoking monkey.
And you think Logitech has a shortage of crack smoking monkeys?
It is poor entirely because it's designers had essentially no understanding of cryptosystem design, and they didn't bother to have it reviewed by experts.
The documents were out for public and private review for many many months. Experts did have at it. It at least got changed from a clearly worthless 4-bit key to something that looks valuable (but isn't).
Yes, price isn't why WEP sucks, but I think price is why WEP was at least attempted.
I don't know about you, but from what I've seen in every other instance, Slashdot vehemently opposes industry consolidation and mergers (witness AOL/TW and MS). I guess less competition is only bad when you don't like the company.
Well SlashDot is pretty inconsistent (for example the far greater the normal number of Patent defenders for TiVo -- I love the product, but I still don't like the patent system).
However this may not be all that inconsistent. The AOL/TW merger was arguably the biggest dial-up ISP merging with a very large media conglomerate. Microsoft and anyone is the biggest software company plus, well, a little bug:-) In this case it is the second biggest x86 CPU seller (AMD has what, 30% of the market?) plus one of the smallest (I would guess less then 1%).
Plus this isn't even a merger, it is just "we will license an instruction set and bus". Nobody bitched when the PCI bus was wildly adopted (nobody I noticed at least), but slashdot wasn't around then. Nobody seemed to bitch when the clones adopted MMX either...
Now I think x86-64 is a huge kludge. Maybe not as bad as the iTanic, but pretty grimly crufty. I would much rather see a migration to the Alpha, or SPARC, but that doesn't seem likely. Transmets's adoption makes it more likely that x86-64 will take off, which isn't something I'm thrilled by. Unless the only other choice is really the IA64.
Who really wants an instruction prefix to switch 64bitness on and off and select a register bank for each instruction? Well not a register bank, one for the source and another for the dest. Feh.
It's amazing how many ways this could have been done right, and it is still wrong.
Not really. Anything that increases the cost has to increase sales. Will the lack of a checkbox that says "uses random crypto thingie so it must be safe" lose some sales? Maybe. Some people clearly wouldn't buy it because of that. Then again some people would see that and be reminded that it is a problem, and not want it. Some people will see it and demand that they know how it works so they can be convinced it is secure. And above all, it is going to drive prices up. You won't be able to shoehorn much encryption into the tiny CPU that decides keystrokes and drives a little RF and emulates the original keyboard controller.
Plus it is hard to imagine anything simple that works out of the box, unless you key the base station to the keyboard from the factory. Otherwise you could have a man in the middle attack (which would be harder then the existing attack, but still...)
I mean look at the problems 802.11's WEP has, and it is on a $100 and up device!
Slashdot Mirror
Depends on how trivial the code should be. "Write a function that reverses a C string in place" should be OK with no references to the man pages, up on a white board. In the past I have asked exactly that question, given the interviewee a xterm with vi or emacs running and let them at it.
On the whiteboard I would forgive simple syntax mistakes and the like. There don't need to be any function calls (a lot of people call strlen, which is fine, but not needed). I'm looking for things like "did you malloc a buffer you don't need, and then forget to free it, or worse yet return it?". If they did the online version, did they test it? With both even and odd length strings? A zero length one? A single byte?
A lot of people who claimed to know C couldn't get the syntax right for the function (given a compiler, I expect one to be able to compile edit compile until you at least get syntactically correct code!).
More people didn't know what "in-place" means (hint, if you aren't sure what you are being asked to code, ask for a clarification).
Still others merely used a poor algo, like malloc'ing a second buffer, copying the string in reverse to that buffer, and then moving it back to the first buffer. Those people are minimally qualified. If they do well on other questions the may still get an offer.
Remarkably few made one pass over the string to find the length, and then a single extra pass to do the reverse. Those are the people I was looking for :-)
The thing to remember when interviewing is any environment you give them will be unfamiliar. They will be under a whole lot of pressure (esp. now, the three people I have interviewed since my multi-month unemployment have received more simpathey from me, but not easier questions). Don't base the whole outcome on a single question.
Seriously don't base it all on a logic puzzle. They may have heard it before. Two flash lights, five people blah blah. Why are manhole covers round? So on... You may end up with a drooling idiot that red the same interviewing books (or logic puzzles...with answers!), or who got asked those same questions last interview and at least was smart enough to find the answers later!
I do show potential maintance programmers a buggy line of code and ask them to spot the bug, or short functions with obvious bugs. But these are clear bugs (like if (a or not a) then x), and not the whole interview.
I doubt it. Not for the reason most people think either :-)
Oh, I believe there may be more then 4.2% of the population that is untrainable for jobs. I don't believe the unemployment rate counts many of those people. The unemployment rate tracks job seekers, so people who have given up (my wife for example) and aren't looking for work anymore are not counted as unemployed.
A lot of those people are the untrainable, and I believe most active job seekers are trainable (or pre-trained) for something.
Calculating the unemployment statistic this way has its advantages (decent measure of how many people are competing for any given opening), and disadvantages (doesn't show how many people really are out of work).
That's not the same unemployment number that gets published. I got counted as unemployed for a few months because after getting layed off I marched down to the unemployment office and signed up to get my money back (in VA at least the unemployment pay pretty much came out of your paycheck, and you can never get back more then you gave in). I have some friends who are too proud/stupid to do the same, so they aren't unemployed, they just have no job. I also know people who quit work out of disgust and are without jobs, and are not being reported as unemployed (they aren't eligible for unemployment insurance benefits, as the quit).
P.S. yes, I did find another job pretty quick. Actually I had my first offer (no stock, but more cash then my last) within a week or two, but it took three months to find a job I really wanted. I think if you have the same skills it took to get a job in 1992, you can get one again now. Well not quite the same skills (SunOS 4 knolage won't get you anywhere unless you call it Solaris and forget the "1"), but a similar set.
That may be pretty true, but I think it is more a matter of they can't get better for the money. Fast food service has been crappy for as long as I can remember. That includes a few times of high unemployment. Why? Well I'm guessing that the service can be crappy and the place keeps pulling in money, so enough money is offered only to get a minimum level of service. If they payed enough to get bright cheerful people they would have to pay as much as a real restaurant, which would drive the prices of the "food" up to close to real food, and fewer people would go eat McProtoplasam when they could pay almost the same for real food.
I would assume these things would be pretty safe if used by a passenger, and perhaps useful to the passenger as well. The MP3 player ought to be more safe then a CD player as one should be able to have it run much much longer without repeats, so you won't be as likely to change the "CD" at the wrong time.
Probably also useful and mostly safe when stopped dead in traffic, at least as long as you put it in neutral and pull up the parking break. A paper back works well then too though.
Hasn't it already? Isn't that why the USA didn't get nav systems in cars until years after european models?
Or more so, the people are the ones using the toys at a unsafe time or in an unsafe manner (or who just plain got unlucky).
The Godfather DVD Collection scheduled for reales October 9th 2001. Pre-order at will :-)
They don't. I don't think the envromental cost of the batteries is all that significant, but the economic cost may be (it is about half the cost of the EV1, and has to be done every three years or so).
Including the Honda, which mostly just runs the gas to charge the batt, and as an assist when you really need the extra shove?
As a special case there was a cross country "race" where minimum fuel use was the key issue. A gas car won. A normal stock gas car. Driven by the then-editor of Car and Driver. Of corse he was drafting behind a truck on the whole trip...
Yep, I did overlook moving (and cracking) the gas.
Electric cars still have breaking systems (the ones that stop you), more complex ones because they try to recapture the energy. Alternators (as part of the break systems), wiper systems, and a host of other parts. All of which have broken at one time or another in at least on car I've owned.
I think electric cars can do without a transmission, but I'm not sure all do. They generate a lot of torque, so some electric cars may choose to reduce that. Electric cars have extra parts -- two or four electric motors that are way bigger then any electric motor a gas car has! Or maybe only one, but then you get the full glory of a differential and the rest of a traditional drive train (no timing belt though).
When I was in collage I did my own car work, many of the parts I replaced had nothing to do with the gas motor. Of corse a few were because VW hadn't discovered electricity :-) (if you don't get the joke the VW Rabbit used vacuum to do a lot of control functions modern cars use electronics for).
However with the possible exception of the battery I don't think any parts of the car contribute anywhere close to 1% of the pollution that the fuel does. They do contribute to how reliable people feel the car is, and that will help influence whether you can sell the things or not, but they pollution represented by one change of the transmition fluid isn't noticeable next to the gas that took you 100,000 miles.
I'm still not convinced. I'm not convinced either way though. Electric cars could well pollute less, depending on the source of the eletrictricty, and the real cost of making gas. Would be nice to know though.
It would be good if the law actually did know. Whatever this law rates is going to shape how low emission cars are designed, not reality. If something makes the car (+ support systems) pollute less, but this law doesn't recognize it, then it is unlikely to happen. If it makes the car + support systems pollute less, but the law sees it is more, then it will not happen. I don't dislike it because it bashes my precious gas cars, I don't like it because it might bash something better then electric cars.
Well, that seems a bit unlikely, we haven't built a new one since the late 70s. It doesn't look like we will do it again anytime soon. (and yes, I think nuke power can be pretty good)
So? Build a more efficient oil cracker and you get more efficient cars. Oh, and cheaper winter heating. And cheaper electricity. And cheaper plastic army men.
CA, and some other states have a low or zero emission requirement. Anyone that sells more then X cars must sell some small percent that have very little or no emissions.
In my opinion the law is flawed in that electricity is assumed to have zero emissions, rather then a guess at the emissions required to produce the electricity (which may be more then some extreamly efficient gas cars). The Honda gas/electric car for example is assumed to pollute more then the EV1 even though it probably pollutes less.
Anyway the Fuel Cells may well be looked at as a way to meet the low/zero emission laws, and not as a replacement for gas. Of corse if people like the fuel cell cars then that may change. Well, like them for the price they can be produced. The EV1 was liked by a fair number of people (it had a ton of torque), but GM leased it for about $30k, it cost them more like $60k to make them. People would have to like them a whole lot to pay $60k for them!
Actually the law is more flawed then that, but I don't generally like new (or old!) laws anyway.
P.S. yes I do find it ironic that CA has "electric car laws", and is sticking to them in the face of an electricity crisis, but the electric car laws don't actually require electric cars (they are strongly tilted towards them though)
One of the very first lights reviewed in this article does focus the LED much like a normal flash light. It is true that very few others do though.
The white is definitely easier to read by though, at least for me. It does reduce your night vision though. Works well for finding cables under a desk in a dim office though.
P.S. I'm sure I have seen yellow LED lights, they might just be micro light sized though. You can definitely get the red ones full size. Good for preserving night vision. I don't really like the way red ones make things look though.
If $20 is a lot of money, definitely borrow first. If it isn't march right out and buy a Proton and put it on your key chain. Proudly declare your flashlight geeakery. Maybe later you can buy a real LED light too :-) I haven't gotten anything bigger then the CCTrek, it is good to read by, and my wife uses it to watch the dog in the backyard. It probably has almost saved it's own cost in bulbs and batteries yet. It would be a bad hiking light though.
Sure, if the fbdev code was accelerated "enough" and supported all the primitives for 3D and whatever else they want, then it would be easier. If or course fbdev was on all the OSes they wanted XFree86 to work on. None of that appears to be true.
Now they could divert that effort in making and extending graphics drivers from X to fbdev itself, but that would limit the OS choice and be a whole lot harder. Writing kernel code is very painful compared to writing user land code. Actually it isn't the writing that is so hard, but the debugging. My relatively few kernel modifications have taken about 4 to 5 times longer then I had guessed to debug, and I had already bumped the number up because I thought I knew how hard it would be...
Plus XFree86 is used by a lot more then just Linux, and I believe many of the XFree86 commiters are not Linux-only users (in fact the only XF86 commiter I personally know is a rabid anti-Linux zealot). So I doubt they would want to abandon support for OSes that didn't have a usable fbdev.
One small point in this arguments favor is that they have a fbdev driver, and have continued work on non-fbdev drivers.
So it seems to be the lesser of N evils to essentially have a user land device driver of inordinate complexity.
I don't know that they want guaranteed jobs, but they want the old ones back:
Emphasis added, otherwise a direct quote from the CNN article. I totally agree that they should receive pay for any period they worked, I don't know enough to say anything about getting their job back.
The US drug war is pretty damn bad, however Stalin killed a whole whole whole lot more people then we have arrested (so far), let alone killed. Directly at least. If drugs were legal a lot of current drug related and organized crime death would probably be significantly reduced.
Sorry, forgot it is less then a year old. Try the 1999 paper Soft Updates: A Technique for Eliminating Most Synchronous Writes in the Fast Filesystem, I think you can get that one.
I don't really think the Usenix membership is worth $50/year to get the lame newsletter, access to the proceedings is pretty valuable, and their conferences are quite good. In addition to learning about soft updates the 1999 conference taught me a lot about how select sucks, how to make it suck less, and that not all of CA is a warm paradise.
I doubt that number was. For some real benchmarks you can look at Journaling Versus Soft Updates: Asynchronous Meta-data Protection in File Systems from the 2000 Usenix Procedings. In addition to having useful info in and of itself it has references to other information. You can also try McKusic's home pages he may have newer info that, and does have some info about the experimental checkpointing.
I don't know about dirperf though. Never seen a paper on it.
Sure they did. They write-back cached data writes to disk. They write-through cached metadata disk writes (and blocked other writes until metadata writes completed). That would leave your filesystem in a mostly consistent state, and not suck too hard in the event of a power failure. The other choices are ignore the possibility of filesystem damage from power failures (or panics), I think Linux's EXT2 did that, or maybe just did it by default, or to log metadata changes (XFS does that, and I heard EXT3 does too, but I'm not sure).
Softupdates carefully orders disk writes, and can if needed reconstruct the proper intermediate state for a metadata block. It has the performance of a totally async filesystem (i.e. somewhat higher then a logging system), but the stability of a logging system (i.e. better then the previous sync filesystem). It is also the major foundation for filesystem checkpoints and in-the-background fscks (possibly coming in FreeBSD 5.0).
The other change they made (dirperf) had to do with directory block placement, I think the old algo attempted to put them close to the datafiles, and with larger caches this is no longer a win, and has become a loss. I haven't read any papers on it or anything, so I don't know a whole lot about it.
OpenBSD is secure in part because they are conservative in adopting new features. Two years ago softupdates was pretty new, and leaving it out let FreeBSD, BSD/OS, Solaris, and NetBSD experience the teething pain (as a BSD/OS beta user at the time softupdates was rolled in, I felt some of the pain, but it wasn't too bad, never had any data loss from it, unlike soft-read-only which I think was killed).
I don't see how it is x86 specific. It is specific to CPUs that use caches, which is pretty much all non-embedded CPUs, and many of the embedded ones. I would imagine this would not be faster on something like the Terra, which is a non-cached CPU, but since it relies on proper management of 1000s of hardware level threads, I don't think Linux is ready to run there at all. Even on those systems it should be faster then indirecting through a pointer, faster by exactly one memory access (the pointer).
I do agree that it is untested (in terms of benchmarking). I don't think it has entirely wrecked extensibility. One needs to modify that file to add a filesystem, so you can't do it through a run-time loaded module...unless you use the generic void*.
I'll go for "that is really really ugly", and maybe even "does that make a noticeable difference when you are probably going to schedule a disk I/O?", and even "I'm glad FreeBSD doesn't do that". There is no way I'll buy "it's x86 specific" though.
For some games. For other games the author may well not have signed away all rights. When I use to work at Microprose (at, not for, I was in the same building, doing CoinOP games for what was in theory some sort of spin off) people still did bring in independently written games and negotiate some of the resale profits for themselves. Of corse the games tended have all graphics and sound replaced, and a lot of extra debugging, and sometimes game code slapped in by the Microprose folks, but the original author still got a per-box cut.
And that ain't the only thing. A lot of game companies are pretty small, and profit share, or have employee stock ownership. Some of the big ones do as well.
Even the giants that don't really do any of that do still have room in the annual salary review for you to say "I was a big part of Jane's F-16, and it sold X copies, so your raise had better be at least Y% or I'll go work for FOOCORP", and yes that X is altered based on exactly how many copies are bought, or not.
Don't delude yourself, even at MEGAGAMECORP there is a team of real people behind each game, and if the game was any good they worked real hard on it (except for the team slacker - and at least he got the short end of the stick during the nerf fights). Their future at MEGAGAMECORP depends in large part on how well the game does. Even if they did it as "work for hire" and have no legal direct ownership.
I don't think so. The way AMD implements x86-64 isn't low power. As far as I know it isn't working either (not as in it is behind schedule, but as in it hasn't taped out). Transmeta last year got (as far as I know) one of their existing CPUs to implement the x86-64 instruction set so AMD could start working on system level code (reference system BIOSes, and one hopes GCC, and open source OSes).
As far as I know transmeta has only licensed the x86-64 instruction set (and I would assume any applicable patents). I could be wrong, since the article doesn't say one way or the other. I'm guessing because doing it the other way would make transmeta a 2nd source for the x86-64, and there would have been a press release about that.
On the other hand, what if you are wrong? What if only having access to that Playstation game at your friends house finally wears at you, and you go out and buy a playstation (they are cheep now after all!) and the game? I mean a lot of people are wrong about themselves. Lots of people that don't think they can quit drinking can. Lots of people who think they can quit smoking can't. What makes you think you really know what games you will and won't buy if you don't illegally copy them?
On the gripping hand, maybe you never would buy the game, but you illegally copy it. Then your wife/mother/girlfriend catches you, and makes you buy it. Then clearly your illegal act has made the copyright holder (and 8 middle men) a few cents.
On the....hind paw...maybe it isn't about the money. Maybe it is about the rights of the authors of the program? Didn't they sweet blood? Don't they have the right to say who can play the game, and who should take a hike?
I'm sure I could come up with a few more viewpoints....but I have to eat breakfast, and fire up Hitchhikers on my Z-machine...
As a minor nit real time kernels do not require kernel pre-emption. The require a bounded maximum interrupt latency time. In theory the bound can even be high (100+ms, or hours even). In practice the bound has to be low just like you said. In practice kernel pre-emption is the simplest way to do it (one could also use a true micro kernel that only passes messages, and does that really fast, making all of the "real work" done in premptable user level code).
There is also the difference between hard and soft real time. Soft real time like a video game can't handle going above the stated latency very much or the animation will stutter and the user will become displeased and play a different game, but it can handle once in a while blowing the stated latency. Hard real time can't handle missing the promised latency, a computerized fuel injector might be a good example of this. If it misses, even just once it could inject fuel at the wrong time, and might blow out a delicate gasket and cause $1000 of damage to your engine (this may also be a bad example, I'm not sure how tight the timings really are for CFJ).
Has transmeta licensing a new CPU (or peripherals) bus reduced competition? Or has it increased it slightly because now you could more easily swap out the two CPUs? (or maybe just use the same high speed peripherals)
Has transmeta licensing the x86-64 instruction set reduced competition, or does it give you a second source for CPUs that can run 64bit x86 code?
Well I did start off on that topic, agreeing that slashdot appears inconsistant, and then saying maybe in this case it isn't really. Then I wondered off and commented about the story, and then couldn't resist poking fun at the iTanic, and how utterly lame the x86-64'x REX prefix is.
A bit, yes. Couldn't you tell?
Can't we get back onto topic though? When is AMD going to do something about those orbital mind control lasers?
Are there any competitors in that space (RF keyboards)? I'm not exactly in the market for a wireless keyboard, and if I were it's likely that IR would do it for me.
Also as I said before, mentioning security will remind people that they have no idea if it is secure. After all anything claiming to be secure in the past seems to have had later announcements about how it's not exactly as secure as first claimed... (and no, not everything does, but it happens enough that I expect lots of folks have that impression)
Ok, if they spin their own silicon they might be able to do it, I don't own one of those things, so I can't check to see if it is all off the shelf parts, or has any custom ICs, or even FPGAs. I'm assuming these small area designs have been openly published and withstood attack? Or are small area designs of real cyphers...
Sure. First it costs money to put the wire there. Then it costs money if people screw it up, or think they did and call the 800 number. You need long term storage to hold the key (FLASH, NVRAM, whatever), and if it is battery backed you will need that cable again in a few years, or there is another 800 call.
And you think Logitech has a shortage of crack smoking monkeys?
The documents were out for public and private review for many many months. Experts did have at it. It at least got changed from a clearly worthless 4-bit key to something that looks valuable (but isn't).
Yes, price isn't why WEP sucks, but I think price is why WEP was at least attempted.
Well SlashDot is pretty inconsistent (for example the far greater the normal number of Patent defenders for TiVo -- I love the product, but I still don't like the patent system).
However this may not be all that inconsistent. The AOL/TW merger was arguably the biggest dial-up ISP merging with a very large media conglomerate. Microsoft and anyone is the biggest software company plus, well, a little bug :-) In this case it is the second biggest x86 CPU seller (AMD has what, 30% of the market?) plus one of the smallest (I would guess less then 1%).
Plus this isn't even a merger, it is just "we will license an instruction set and bus". Nobody bitched when the PCI bus was wildly adopted (nobody I noticed at least), but slashdot wasn't around then. Nobody seemed to bitch when the clones adopted MMX either...
Now I think x86-64 is a huge kludge. Maybe not as bad as the iTanic, but pretty grimly crufty. I would much rather see a migration to the Alpha, or SPARC, but that doesn't seem likely. Transmets's adoption makes it more likely that x86-64 will take off, which isn't something I'm thrilled by. Unless the only other choice is really the IA64.
Who really wants an instruction prefix to switch 64bitness on and off and select a register bank for each instruction? Well not a register bank, one for the source and another for the dest. Feh.
Not really. Anything that increases the cost has to increase sales. Will the lack of a checkbox that says "uses random crypto thingie so it must be safe" lose some sales? Maybe. Some people clearly wouldn't buy it because of that. Then again some people would see that and be reminded that it is a problem, and not want it. Some people will see it and demand that they know how it works so they can be convinced it is secure. And above all, it is going to drive prices up. You won't be able to shoehorn much encryption into the tiny CPU that decides keystrokes and drives a little RF and emulates the original keyboard controller.
Plus it is hard to imagine anything simple that works out of the box, unless you key the base station to the keyboard from the factory. Otherwise you could have a man in the middle attack (which would be harder then the existing attack, but still...)
I mean look at the problems 802.11's WEP has, and it is on a $100 and up device!
Really? So if I go to the local computer store and buy RedHat Linux for $45, or cheepbytes slackware for $2.95, it ain't a free OS?
Linus Torvalds a fraud! Linux unfree! Details at 11:00.
Or is the issue more complex then that?