Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Re:you have the source (Score 1) 566

MOV with an immediate value is even worse! Outlaw them all!

Having said that - sometimes the kernel does have a right to prevent user space applications shooting themselves in the foot (e.g. trapping out-of-bounds memory accesses), it is possible to make an argument that - if the intel generator were to proved to be compromised - that the kernel should intervene and prevent it.

Do you think a kernel that can intercept and correct FDIV calls on broken chips should let userspace blindly just receive unwanted results from said instruction?

In the rdrand case, the userspace program wants a random number. If rdrand is buggy, and does not return that, then how is that different from the FDIV case?

Comment Re:you have the source (Score 1) 566

And if you want to prevent the kernel from ever being started that way just compile it out by disabling this Kconfig option with make-menuconfig, or similar:

                def_bool y
                prompt "x86 architectural random number generator" if EXPERT
                    Enable the x86 architectural RDRAND instruction
                    (Intel Bull Mountain technology) to generate random numbers.
                    If supported, this is a high bandwidth, cryptographically
                    secure hardware random number generator.

No need to delve into C at all.

Comment Re:They're worth it in a startup (or company start (Score 2) 356

Agree. I have a similar perspective. I was once hired to do the work of half a dozen people. I had to once explain to my boss's boss's boss that my negative productivity (as measured by "metrics") was because I was *undoing* the work of half a dozen people. The negative productivity programmer does exist, and can be lethal in quantity.

Comment Re:Yes (Score 1) 356

So very wrong.

One guy *can* be worth 10 numbnuts, but GPP explicitly said "average" not "bottom of the heap". The source you link to even supports the fact that the top of the heap are only about two and a bit times as productive as the average. Add to that the fact that prima donnas can be positively damaging to anything apart from their own personal pet projects, and the "Rockstar" really isn't that great a deal at all. The only thing one 150k a year guy is good for is one-man projects.

I'm lucky to work with a bunch of right-hand-side-of-the-bell-curve engineers who all like cooperating and sharing information, and are never afraid to ask for additional input - nobody thinks of themself as, or wants to be, a rockstar, and that's about the best scenario you can hope for.

Comment Re:Eggs, Basket (Score 2) 552

His laptop breaking brought about 0.0001% of the actual work on linux to a halt, if that. Every linux developer continued developing as normal. Every code reviewer continued reviewing code as normal. Every subsystem maintainer kept maintaining their subsystem as normal. Every automatic test built robot kept automatically doing build tests as normal. People who desperately needed the patches that Linus was going to push put, if they really were that desperate, would have just pulled them from linux-next, or the relevant subsystem maintainer's tree, or, *most likely*, would already have them!

Comment Re:Really? (Score 5, Informative) 552

Are you attempting to claim the prize for the person with the least understanding of the Distributed Source Code Control System in use?

There was absolutely no code on his system that wasn't on between dozens and thousands of other systems depending on its age.

Just read TFA: "I had pushed out _most_ of my pulls today". His "pulls" are code that is *elsewhere*. He's just a conduit (and gatekeeper) between a few dozen elsewheres and a server with a fat pipe. And by the construction of the system, it really shouldn't matter how those pulls ordered. (If there'll be a merge conflict one way round, there'll be a merge conflict in other permutations too.)

Comment Re:someone's gotta start the show (Score 1) 175

However, if you look at even successful IT companies, well established ones, you'll find that 90% of their individual projects fail (many fail to even make it to mark it, some flop once they're there). If the startup is focussed on one single thing, then its failure rate is just the same as any other company's, it's just that the whole company fails when that single product/service fails.

I guess I should be happy that I'm at about 2/15 success rate, it's just a shame that the technically better products weren't the ones that were a hit in the market.

Slashdot Top Deals

Disk crisis, please clean up!