Bah. Remember it's just a website. It doesn't actually matter in the grand scheme of things. If you just keep on trying to post stuff that you think you would want to read and which is Insightful and/or Informative, and do so on many topics, you'll get modded up overall. Remember, don't pursue holy wars or such stuff, not because they're likely to get modded down, but because virtually nobody actually wants to read that sort of thing anyway.
But if I changed anything, I'd make it so that Funny does get some Karma. Much less than for the other up-mods (smart is better than smart-ass) but still some. Someone who can consistently make me laugh out loud should get some sort of appreciation for it...
What the ID followers want is a return to that using the logic "I don't understand it so it must be God's work."
I was under the impression that they went a little bit further than that, going to "I don't understand it, so it cannot possibly ever be understood by anyone and must be God's work". It is that denial of future understanding that gets right up the nose of anyone with a proper scientific background. By contrast, real science operates on a succession of "informed best guesses" and there's always the possibility of a theory being superceded (and it's really cool when that happens too).
I write code that gets ported to some very odd architectures indeed, and nearly everything these days is IEEE-754 for float, especially when the values go to memory. Things get odder when you're purely in registers and using doubles, but neither of those are the case here.
I'd still love some analysis of whether this hack is such a good win on a modern processor; it's not beyond the bounds of possibility that a good FPU/compiler/libm might be able to beat the hack starting from idiomatic code...
It's the traffic levels that control what sort of junction is best. If the traffic is heavy, you don't use a roundabout. Instead, you use either lights or (if you can afford it) a multi-level intersection; lights are very common for that level of traffic in the UK simply because land is unholy expensive, so only the busiest junctions of all are likely to have over- or underpasses, but the balancing equation yields different answers elsewhere. There is also a level of traffic where roundabouts work better than lights (because they make it more likely for no non-speeding traffic to have to stop).
Of course, below that level of traffic lights (and a suitable sensor) work better again, until you get down to the level where a Stop or Give Way/Yield sign is all that's needed. (I've seen junctions where there weren't even those, but usually only when I was in severe danger of getting lost on a jaunt out in the countryside.)
There was saturation advertising (every spot except for the small-ads) of the 360 in the Metro free newspaper this morning. I wondered why, and the PS3 and Wii releases explain it quite thoroughly...
Things that have caused trouble for me in the past:
- GUIs (there isn't really a standard; perhaps wxWidgets?)
There's no possible standard way to produce a GUI that "works right" (i.e. how Joe Ordinary User expects on each platform) portably across all platforms. The problem is that different platforms have thoroughly different UI metaphors for things like modal vs. non-modal dialogs and stuff like that. Make your app work right on one platform and it will clunk on another. Your best choice is probably to develop different GUIs for different platforms, and that's hardly what you'd call portable...
But really, if a language was designed to be threading from the beginning, I think we'd be seeing some more useful constructs like coroutines.
Not necessarily. The language in question might instead be using message-passing primitives for its thread model, which has the advantage of being able to scale much more. But that's a really different model to the "shared memory" model that most programmers think that threading requires. (Of course, since it's really just "processes lite" it is something that Unix coders will know how to exploit already.)
Why on earth does MySQL have a 24 bit integer datatype?
Probably because the other 8 bits are used to indicate that it is a 24-bit integer, so that the whole thing (type and value) fits into a 32-bit word. Another possibility is that it allows for packing a table a bit tighter at the expense of slowing access a bit, a trade-off that wins by allowing you to hold more of the database tables in the OS's buffer cache. Databases do horrible things like these.
(I've written 4 papers in TeX, and still don't know how to make it sans serif)
Assuming that you're really using LaTeX, you're looking for \usepackage{helvetica} or something like that (it depends on which font you're actually seeking to use). If you know the three-letter font code, you can also do \renewcommand{\rmdefault}{fontcode} (it's 'phv' for Helvetica).
If [automated testing] became common practice in the open-source world, the code quality would improve.
Trust me, it would help a lot if more closed-source software also did automated testing. I've seen a fair bit of closed code in my time (unfortunately under a Non-Vomit Agreement) that was a disgusting hairball and would have benefitted not from being made open, but from being buried at an unmarked rural crossroads with a stake through its heart.
The many-eyeballs approach doesn't guarantee good code (alas!) but it does stop at least some of the worst practices.
As a member of one of the OSS teams contacted, most of what Coverity found in our project were not actual bugs but rather places where the software wasn't smart enough to guess the preconditions on a function right. So they were more places where ill-advised maintenance might well have introduced a bug in the future. (Maybe the other spots were also like this, but we decided to clarify the code in all places anyway so the coverity problems were all cleansed.)
It should, however, be remembered that coverity does not and cannot find all bugs. It is just a more advanced form of Lint that catches a class of errors that is otherwise annoying to track down; a nice extra tool, not a magic bullet.
If you come around [a terminal server] that does only telnet, scream and run.
Actually no, it can still be perfectly OK if the terminal server is only ever plugged into a physically separate private network whose only connection to the outside world is a (heavily defended) ssh-enabled host. Indeed, physically separate networks are *more* secure than ssh because they can't be cracked remotely. In such a setup, ssh is the weakpoint! (Not that it's weak, you know, it's just way more exposed than everything else.)
Re:The problem with guis is they don't work
on
GUIs Get a Makeover
·
· Score: 1
For an expert user, GUIs slow you down.
That's not true, not when the application has well-designed keyboard shortcuts. Of course, getting those right and arranging them so they are discoverable by users (helping them advance to expert-hood) is not easy in itself...
Or instead, you could do what a reasonable person would do, and stay out of places likely to have cigarette smoke.
Like the sidewalk directly outside my place of work? There's always someone out there smoking it seems, so I'm supposed to avoid that? How? I'm not going to just cower at home! All I want is to not smell smoke, since it makes me feel sick. Is that so much to ask?
Hey, Big Tobacco! If you want the majority of people off your back, just come up with a way of getting totally rid of second-hand smoke (it's been done before). Do that, and I for one am happy to leave you to kill your customers in peace.
I think one of the greatest mistakes the credit/debit card companies/banks made was the compulsary PIN entering at point-of-sale.
So cover the keypad when typing in the PIN. Duh! Even the only-slightly paranoid should do that.
But this brings up another point: how hard is it to clone one of those chip-and-PIN cards anyway? I'd hope that it would be at least somewhat difficult, ideally with an on-chip crypto engine that doesn't let its private key go "off chip". Such a system would be really hard to use in an unauthorized way, especially without in-depth technical training, and the thieves would go elsewhere.
Slashdot Mirror
I'm thinking about replacing all that with some stuff I downloaded off the Internet. After all, that's a system of tubes...
Bah. Remember it's just a website. It doesn't actually matter in the grand scheme of things. If you just keep on trying to post stuff that you think you would want to read and which is Insightful and/or Informative, and do so on many topics, you'll get modded up overall. Remember, don't pursue holy wars or such stuff, not because they're likely to get modded down, but because virtually nobody actually wants to read that sort of thing anyway.
But if I changed anything, I'd make it so that Funny does get some Karma. Much less than for the other up-mods (smart is better than smart-ass) but still some. Someone who can consistently make me laugh out loud should get some sort of appreciation for it...
I'd still love some analysis of whether this hack is such a good win on a modern processor; it's not beyond the bounds of possibility that a good FPU/compiler/libm might be able to beat the hack starting from idiomatic code...
Of course, below that level of traffic lights (and a suitable sensor) work better again, until you get down to the level where a Stop or Give Way/Yield sign is all that's needed. (I've seen junctions where there weren't even those, but usually only when I was in severe danger of getting lost on a jaunt out in the countryside.)
So this is what spin doctors do all day!
There was saturation advertising (every spot except for the small-ads) of the 360 in the Metro free newspaper this morning. I wondered why, and the PS3 and Wii releases explain it quite thoroughly...
What's scary is that about 90% of them are arguably appropriate taggings.
Trust me, it would help a lot if more closed-source software also did automated testing. I've seen a fair bit of closed code in my time (unfortunately under a Non-Vomit Agreement) that was a disgusting hairball and would have benefitted not from being made open, but from being buried at an unmarked rural crossroads with a stake through its heart.
The many-eyeballs approach doesn't guarantee good code (alas!) but it does stop at least some of the worst practices.
As a member of one of the OSS teams contacted, most of what Coverity found in our project were not actual bugs but rather places where the software wasn't smart enough to guess the preconditions on a function right. So they were more places where ill-advised maintenance might well have introduced a bug in the future. (Maybe the other spots were also like this, but we decided to clarify the code in all places anyway so the coverity problems were all cleansed.)
It should, however, be remembered that coverity does not and cannot find all bugs. It is just a more advanced form of Lint that catches a class of errors that is otherwise annoying to track down; a nice extra tool, not a magic bullet.
It's not a problem. Use "+1 Informative" for that instead.
I've also always regarded Perl as the swiss army knife of scripting languages too.
1 2 3 4 5? That's amazing! That's the same combination as my luggage!
(Memo to self: change combination on luggage...)
Hey, Big Tobacco! If you want the majority of people off your back, just come up with a way of getting totally rid of second-hand smoke (it's been done before). Do that, and I for one am happy to leave you to kill your customers in peace.
But this brings up another point: how hard is it to clone one of those chip-and-PIN cards anyway? I'd hope that it would be at least somewhat difficult, ideally with an on-chip crypto engine that doesn't let its private key go "off chip". Such a system would be really hard to use in an unauthorized way, especially without in-depth technical training, and the thieves would go elsewhere.
Well, it's harrrrd to say, Jim lad, but it's probably to do with ninjarrrs...
Not an octopus, a centipede.