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

 



Forgot your password?
typodupeerror

Comment: Re:Try this experiment (Score 2) 196

by dwmw2 (#39392201) Attached to: Ask Slashdot: Getting Feedback On Programming?
Hm, I'd have said that if s/he succeeds then you're almost certainly guilty of overcommenting your code. A lot of good code is completely self-explanatory. You really don't want to litter it with pointless comments that just detract from the value of the comments that should have been there.

Nobody needs to see comments like:

/* Add one to the count */
count++;

Yet without that kind of thing, it would be hard to reimplement the code from the comments alone. (Yes, if you have decent JavaDoc-style comments describing each function, and you have small self-contained functions, then perhaps they could reimplement each function from scratch just by knowing its arguments and behaviour — they don't need the contents of each function at all. But that's not quite the same thing.)

Comment: Common mistakes to avoid (Score 1) 300

by dwmw2 (#37155994) Attached to: Ask Slashdot: Best Wi-Fi Solution For a Hotel?

Two things:

Firstly, make sure that if you have a captive portal, a guest staying for a reasonable period of time will only have to accept the terms and conditions, log in or whatever *once*. If I put my phone on the hotel wireless, I expect it to *stay* on the hotel wireless, and automatically register to the VoIP server whenever I'm in the building. I do *not* expect it to keep breaking every few hours until I fire up a web browser on the phone. It's almost as annoying on my PC — when I'm away from home in a hotel with timezone differences, there are often work-related IMs or IRC conversations which happen during my "night", and if a broken hotel network cuts me off during the night and forces me to re-login, that *really* hampers my productivity.

If a hotel has a captive portal which doesn't *remember* the fact that I've logged in and accepted the T&Cs, I will *refuse* to stay there on my next trip.

Secondly, we are well into the 21st century now. It is entirely unacceptable to provide a newly designed and installed system without IPv6 connectivity. It's not even as if IPv6 is *hard*, so there's no excuse.

Comment: Re:gratis but not free (Score 1) 332

by dwmw2 (#32412578) Attached to: Where Do You Go When Google Locks You Out?

The guy didn't even manage to put capital letters at the beginning of his sentences. I'm reluctant to read too much into the fact that he didn't capitalise 'free'. Especially as I've never heard of this 'free' vs. 'Free' convention, which doesn't make much sense to me. Most people just use 'gratis' and 'libre' which is far less ambiguous.

So no, I don't think that timmarhy was talking about 'gratis but non-libre software'; I think he was spouting a common misconception about Free Software, which I attempted to correct. No righteous indignation; just an observation.

Comment: Re:gratis but not free (Score 5, Insightful) 332

by dwmw2 (#32405600) Attached to: Where Do You Go When Google Locks You Out?

I think you've misunderstood the term 'Free Software'. The word 'Free' in Free Software is used to refer to *freedom*, not the cost.

So with software the situation is actually the other way round to the way you present it. If you are using Free(dom) Software, then you have the source and can do whatever you need with it and you aren't held hostage by someone else's actions. If you're using non-Free Software, *then* you seriously shouldn't complain when it blows up in your face.

Using non-Free Software (even if it's gratis) often starts out as the 'cheap option' -- not necessarily in terms of cost, but in terms of local knowledge and training and effort. But it often ends up costing more, because of its inherent limitations and because you can't actually *fix* it to meet your requirements, or even get bug-fixes for it without having to replace it wholesale with a new version.

Comment: Missing the point. (Score 1) 182

by dwmw2 (#31808916) Attached to: Why Responsible Vulnerability Disclosure Is Painful and Inefficient

I like the analogy with the neighbour's headlights, but it's kind of missing the point. Why do you *care* whether your neighbour leaves his headlights on? By all means be helpful and let him know, but it's no skin off your nose if he's going to be an idiot about it and his car won't start in the morning.

Which brings us back to the original situation. Why do you care? It's because you have *chosen* to make a mission-critical service depend on a piece of software which you cannot just fix for yourself, so you're beholden to a third party for fixes. A third party who, in your case as in many similar cases, is too incompetent and/or unwilling to help you.

Getting into that situation in the first place does not strike me as being particularly responsible.

The only problem with being a man of leisure is that you can never stop and take a rest.

Working...