Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Comment: Re:Salary versus cost of living in each city (Score 2) 136

by m.dillon (#48895213) Attached to: By the Numbers: The Highest-Paying States For Tech Professionals

Well, not necessarily true. You are ignoring the costs to maintain the home, a myrid of utilities you have to pay every month that renters often don't, insurance, and property taxes. I'm a home owner but I don't think there is such a huge gap between owning and renting. A lot of older owners are faced with having to sell their homes after retirement and moving somewhere cheaper when they would rather stay where they are. It's more like a safety net and less like a nest-egg, frankly.

That said, I prefer to own.


Comment: Might be difficult (Score 1) 428

by m.dillon (#48895049) Attached to: Ask Slashdot: Where Can You Get a Good 3-Button Mouse Today?

Mice are so mass-market these days that it is hard to find one that actually performs properly. I've gone through a lot of mice over the years, always preferring the hardwired mice over the wireless (dead battery == unhappy), but in the last round I simply couldn't find a wired mouse that worked well. Everything being sold was wireless.

Of late, many of the mice I've tried have simply been too big and bulky, stretching my fingers and generally uncomfortable.

I wound up going with a Microsoft Sculpt 1569 wireless mouse (w/ Nano Transceiver). The Logitech M325 wireless also works but its middle-button-scroll wheel isn't ratcheted. These small mice are nice, my thumb and two right fingers hang over the edge and stay relaxed.

Also I recommend buying a non-rechargable alkaline AA for it, which will last 6 months. The rechargable NiMH batteries usually only last 1-2 months before they have to be replaced/recharged due to nominal leakage, which is too annoying (though I suppose one could buy low-leakage NiMHs).

The middle button scroll wheel isn't a problem. Most of them can also be clicked left and right which IS a problem because it's trivial to accidently click left or click right when you are just trying to push down on it as a middle button. So I disable the mouse-wheel left/right action entirely via:

xinput set-button-map Mouse1 1 2 3 4 5 6 7 0 0 10 11

For the transceiver I find that (obviously) the closer it is to the mouse the better. The best solution is to buy a keyboard that has a USB extension on its right or left side and plug the transceiver into that. Then the transceiver is right next to the mouse with no extra cabling. The Razer (mechanical) gaming keyboards are my favorite... very heavy so they don't move around and have the same feel as the old IBM mechnical keyboards had. 80 WPM is a breeze on them.


Comment: The thing I remember about EISA? (Score 1) 189

by m.dillon (#48877089) Attached to: User Plea Means EISA Support Not Removed From Linux

I remember that every time I changed a card out the machine took 30 minutes to reconfigure itself, because some doochebag of a programmer wrote the #$%#$% configurator that all the vendors used. An operation that could have been done in 5 seconds if written properly. That was the first ... and last EISA machine I ever bought.


Comment: Mmmmm (Score 1) 79

by m.dillon (#48778593) Attached to: OpenBSD Releases a Portable Version of OpenNTPD

DragonFly has had its own ntp-only client for years, dntpd. Not sure why this is suddenly becoming a topic now.

In terms of portability, every operating system has different sysctls or system calls for manipulating the clock. There is no single standard for setting the frequency drift correction, step, or slide operations to correct the time. And part of the problem is that most of these APIs are deficient in one way or another and make it difficult for the ntp client to run the corrections without generating feedback which messes up further corrections.

Beyond that, the code is fairly straight-forward.


Comment: Re:Good for the EFF (Score 2) 220

by m.dillon (#48770309) Attached to: EFF: Apple's Dev Agreement Means No EFF Mobile App For iOS

You know, Apple has given out over $25B (billion, with a B) to its iOS developers since its inception. You don't have to like all the terms, frankly, but in the real world being too altruistic isn't going to do you any favors. Apple puts a premium on the security of its devices and has to continuously juggle the sensibilities of dozens large companies.

History is littered with open-source programmers with so little business sense they wind up living in a RV park their whole lives and retiring with zero savings. Or worse.


Comment: Re:Principles vs Practicality (Score 1) 220

by m.dillon (#48770211) Attached to: EFF: Apple's Dev Agreement Means No EFF Mobile App For iOS

This isn't really correct. HTML5 apps aren't even remotely as smooth as a native iOS app, particularly when it comes to scrolling and window moves. I have a few on my ipad. Developers will use them in a pinch but pretty much just until they are able to get a native app approved.


Comment: Lots of moving parts (Score 4, Informative) 449

by m.dillon (#48719219) Attached to: How We'll Program 1000 Cores - and Get Linus Ranting, Again

There are lots of moving parts here. Just adding cores doesn't work unless you can balance it out with sufficient cache and main memory bandwidth to go along with the cores. Otherwise the cores just aren't useful for anything but the simplest of algorithms.

The second big problem is locking. Locks which worked just fine under high concurrent loads on single-socket systems will fail completely on multi-socket systems just from the cache coherency bus bandwidth the collisions cause. For example, on an 8-thread (4 core) single-chip Intel chip having all 8 threads contending on a single spin lock does not add a whole lot of overhead to the serialization mechanic. A 10ns code sequence might serialize to 20ns. But try to do the same thing on a 48-core opteron system and suddenly serialization becomes 1000x less efficient. A 10ns code sequence can serialize to 10us or worse. That is how bad it can get.

Even shared locks using simple increment/decrement atomic ops can implode on a system with a lot of cores. Exclusive locks? Forget it.

The only real solution is to redesign algorithms, particularly the handling of shared resources in the kernel, to avoid lock contention as much as possible (even entirely). Which is what we did with our networking stack on DragonFly and numerous other software caches.

Some things we just can't segregate, such as the name cache. Shared locks only modestly improve performance but it's still a whole lot better than what you get with an exclusive lock.

The namecache is important because for something like a bulk build where we have 48 cores all running gcc at the same time winds up sharing an enormous number of resources. Not just the shell invocations (where the VM pages are shared massively and there are 300 /bin/sh processes running or sitting due to all the Makefile recursion), but also the namecache positive AND negative hits due to the #include path searches.

Other things, particularly with shared resources, can be solved by making the indexing structures per-cpu but all pointing to the same shared data resource. In DragonFly doing that for seemingly simple things like an interface's assigned IP/MASKs can improve performance by leaps and bounds. For route tables and ARP tables, going per-cpu is almost mandatory if one wants to be able to handle millions of packets per second.

Even something like the fork/exec/exit path requires an almost lockless implementation to perform well on concurrent execs (e.g. such as /bin/sh in a large parallel make). Before I rewrote those algorithms our 48-core opteron was limited to around 6000 execs per second. After rewriting it's more like 40,000+ execs per second.

So when one starts working with a lot of cores for general purpose computing, pretty much the ENTIRE operating system core has to be reworked verses what worked well with only 12 cores will fall on its face with more.


Comment: Don't like'm for near-sidedness (Score 1) 464

by m.dillon (#48718771) Attached to: Ask Slashdot: Are Progressive Glasses a Mistake For Computer Users?

I've been near-sided all my life, and as I get older my vision has slowly become even more near-sided. I've tried progressives but frankly my prescription is already strong enough that I have to go with plastic multi-layered lens and the distortion at the edges is noticeable with just the normal lenses. Progressives? Total fail.

What I do instead is simply ask my doctor to soften the prescription a bit. So my distance viewing isn't quite as good (and I couldn't read small text on a T.V. screen from 10 feet away either)... but my viewing of a computer screen is still in very good focus and, most importantly, I do get any eye strain.

And I'm looking at a screen 60+ hours a week (and have been since I was 14).


Comment: Don't get a USB printer, get a networked printer (Score 1) 190

by m.dillon (#48712075) Attached to: Ask Slashdot: Best Options For a Standalone Offline Printing Station?

Get a printer that runs over WIFI. For example, the Canon MX922. Then it doesn't matter where the computer OR the printer is in the house... it can just be any of the computers in the house. There might be better compatibility with linux drivers with an HP printer though (if running linux). MACs need the appropriate driver. Windows just has it typically.

I've had nothing but trouble connecting USB printers to any open-source OS. It just isn't reliable. I wound up using my windows game box as the print server but the nice thing about a WIFI printer is that any computer in the house can talk to it directly as long as it understands what kind of printer it is and has the appropriate driver.


Comment: Re:Here's One Idea: (Score 4, Informative) 312

by m.dillon (#48706693) Attached to: Ask Slashdot: What Should We Do About the DDoS Problem?

Unfortunately all this will accomplish is that you will lock yourself out of legitimate sites, because a lot of the DDOSing out there uses spoofed IP addresses. So now all the DDOSer has to do is spoof, say, google.com's primary IPs and you lock yourself out of google when you block the IPs.

Until network providers start validating source IPs from their non-transit customers and require their transit customers to validate source IPs for non-transit packets, there's basically no solution that will work.


Comment: Generally speaking (Score 1) 275

by m.dillon (#48647275) Attached to: Dish Pulls Fox News, Fox Business Network As Talks Break Down

Generally speaking, major owners of multiple networks such as Fox often try to force distributors (cable networks, dish, etc) to bundle all of their networks. Kind of an all-or-nothing approach. Otherwise networks like Fox News just wouldn't get distributed at all. It doesn't have a large enough following.

This is slowly changing as peoples viewing habits change. People are watching less T.V. these days and that is shifting the cost model such that the 'junk' channels are now more of a drag on profits vs the relatively few channels that people still really care about.


Comment: Re:Traffic Furniture (Score 3, Informative) 611

by m.dillon (#48603217) Attached to: Waze Causing Anger Among LA Residents

Yes, this works extremely well in Berkeley too. There are neighborhoods on both sides of Ashby (hwy 13) and along various other routes, but the streets are relatively quiet because traffic furniture either prevents entry from Ashby or directs the flow such that there's no point using them for the commute. And they don't inconvenience the residents either. For a resident or for local travel, entering and exiting only adds a few seconds. For a commuter, trying to use residential streets just doesn't work.

The barriers seem to be favored over speed bumps. Over the years the speed bumps have been made softer (15 mph bumps now instead of 5 or 10 mph bumps), and are generally concentrated only in areas that simply cannot be blocked off for fire and other safety reasons.


Money is its own reward.