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

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×

Comment: Re:Are Computer Crooks Renting Out Your PC? (Score 2) 208

by setagllib (#35776302) Attached to: Are Computer Crooks Renting Out Your PC?

The article itself mentions that many of these machines belong to businesses, where Linux has a higher share. And while servers are more difficult to attack in general (well, they don't have Adobe Flash or Reader...) they make better targets, and servers are where Linux is the higher profile target. Its heterogeneity and timely security updates save it a lot there. We can expect more effort given to attacking Linux over time, but for sure it will *take* more effort.

Comment: Re:Wasn't Windows 95 and 98 built from the ground (Score 1) 106

by setagllib (#31744984) Attached to: "Midori" Concepts Materialize In<nobr> <wbr></nobr>.NET

Managed code by its nature can work WITHOUT memory protection at all.

How did you think the "management" worked? Either you trap each pointer access manually (and maintain all of that state and overhead), or you use a memory management unit to do it for you (and accept the cost of traps and context switches).

The very best that a VM runtime can do is infer that a class of access is impossible and thus exclude traps for it. This only works in extremely limited circumstances, and still requires code to be correct. It in fact makes profiling really difficult - and performance is the whole problem in the first place.

Comment: Re:Not Really (Score 5, Interesting) 349

by setagllib (#29822813) Attached to: Windows 7 On Multicore &mdash; How Much Faster?

I disagree - user-mode code, whether it's separated into threads or processes, still relies very heavily on kernel scheduling decisions. It may sound simple enough, but if you study the decisions the kernel has to make (such as which thread to wake first, from a set of 8 all waiting on the same semaphore), you can find lots of ways to get it wrong. We now take it for granted because thousands of man-years have been spent on solutions.

Comment: Re:GCD also replaces most synchronization / lockin (Score 2, Insightful) 205

by setagllib (#29774915) Attached to: Apple's Grand Central Dispatch Ported To FreeBSD

If you're creating a serial queue anyway, you no longer have parallelism. If you have multiple serial queues, you may as well have had multiple threads with no interlocking between them. This is just yet another API to do what competent parallel system programmers have been doing since the first thread.

Comment: Re:People who write in textbooks... (Score 1) 247

by setagllib (#29576519) Attached to: In Trial, Kindles Disappointing University Users

I agree. The best students I know don't even buy the books, let alone write in them, because they're actually using the material in practice (hobby, job, overkilling lab work, etc.) and internalise it better than note-taking and highlighting ever could. They look lazy until you see what they can actually do.

The universe is an island, surrounded by whatever it is that surrounds universes.

Working...