Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×

Comment The future is inevitable (Score 1) 471

by trawg (#43134443) Attached to: Seattle Bar Owner Bans Google Glass, In Advance

Recording devices are going to be ubiquitous soon - if they're not already with mobile phones.

Sure, Google Glasses are different in that they're on your head and ready to record a little more subtly, but if it's not them, it's going to be something else.

Reactionary policies like this won't really address the problem - technology is fundamentally changing how privacy works.

Citizens need to be made aware of the issue from both sides - when it's OK to record someone, and when they need to be conscious of the fact that they might be being recorded.

They need to be aware of the technical advances (e.g., face recognition combined with social network trawling) and cognisant of the risks. Even today, in a (mostly) Google Glasses free world, people should be aware of the fact that what they're doing might be recorded by someone, somewhere.

Behaviour will need to change to adapt to the new technology - just like it already has to some large degree because of things social networks and ubiquitous digital cameras. Know your rights to privacy, but be aware that a lot of them end when you step outside.

Comment Re:Great (Score 2) 112

by trawg (#43102129) Attached to: Version 2.0 Released For Open Skype Alternative Jitsi

You can tie them together in your own free open source PBX.. such as Asterisk.

We do this. My sysadmins gave me Jitsi when I asked about getting a phone at home. It was dead easy to set up; I just run my VPN client, fire up Jitsi and I can make calls using my headset painlessly and easily. In fact I prefer making calls from home now because I can use my awesome gaming headset instead of the crappy handset I have on my desk phone; it's easier to hear people and I can type/take notes while I talk.

Comment Re:Musk (Score 2) 609

by trawg (#42907453) Attached to: NY Times' Broder Responds To Tesla's Elon Musk

Personally, I don't think reporters get called enough on their BS. I am not a big Elon Musk fan (he came across like a baby after the "Top Gear" situation), but his response in this situation raised my opinion of him a couple of notches.

Hmm. FWIW I was up until the Tesla event, a very casual Top Gear watcher. I enjoyed watching it - I know nothing about cars at all - but took it as an entertaining, fact-based car show. I assumed that everything that they did, while very funny, was done in a relatively factual way - but from what I've heard the Tesla thing was basically outright deceptive.

Maybe it becomes more obvious if you watch a lot of Top Gear but I would have watched that episode casually and assumed the car ran out of juice and was rubbish as a result. It wouldn't have crossed my mind that it was just entertainment, which is (as I understand) what the judge said in the case - everyone KNOWS it's just for fun so who gives a shit what they say?

I never really watched it for real information - I'm not going to be dropping hundreds of thousands of dollars on a car, ever - but I assumed the stuff they said was based on reality at least in some way. Knowing the Tesla thing was basically a total fabrication has made me much less interested in watching the show.

Comment Valve, or the publishers? (Score 2) 384

by trawg (#42759169) Attached to: Valve Sued In Germany Over Game Ownership

People here in Australia often bitch about Valve because of the regionalised pricing of video games - it's not uncommon for some games to cost almost 2x as much as they do in the USA (given the strong value of our dollar).

However, it's not Valve that sets the prices for the games - it's the publisher.

In this case I don't know if Valve are just honoring requirements set by the publishers, or if this just a part of their platform. Either way, I think Steam would be a much tougher sell to publishers if one of the features they provided to gamers was the ability to sell your account at a discounted price to someone else.

(If you want to sell games on Steam, my advice would be to separate out game purchases into different email accounts. Then you can sell the email account and the associated games. I'm sure it's still against T&Cs to do that - and it's a giant pain in the ass - but at least it means you can buy and sell Steam games in discrete chunks.)

Comment Re:dumb (Score 1) 184

by trawg (#42210453) Attached to: McAfee Arrested In Guatemala

I long ago changed my preferences on Slashdot so that anything moderated Funny gets ignored - just went looking for the setting but I can't find it in options any more so not sure where to direct you. But it means all those jokes are just removed from browsing the comments and it makes it much more bearable.
Australia

Submission + - Dealing with the "Australia Tax" on Video Games (ausgamers.com)

Submitted by
trawg
trawg writes: "In the throes of another holiday shopping season, with the year's top video game launches still setting records above all other entertainment mediums, gamers down under are still paying more than anyone else in the world, with many publishers adding an "Australia tax" to their latest tiles. We take a look at the factors and forces responsible for the disparity in retail prices for games in Australia relative to other developed nations, and as a solution suggest that consumers should support developers and publishers that don't discriminate, and import, and circumvent the products of those that do."
Book Reviews

Submission + - Book Review: Version Control with Git, 2nd Edition (oreilly.com)

Submitted by
kfogel
kfogel writes: "First, the main thing: two thumbs up, and maybe a tentacle too, on Version Control with Git, 2nd Edition by Jon Loeliger and Matthew McCullough (O'Reilly Media, 2012). If you are a working programmer who wants to learn more about Git, particularly a programmer familiar with a Unix-based development environment, then this is the book for you, hands down (tentacles down too, please).

But there's a catch. You have to read the book straight through, from front to back. If you try to skip around, or just read the parts you feel you need, you'll probably be frustrated, because — exaggerating, but only slightly — every part of the book is linked to every other part. Perhaps if you're already expert in Git and merely want a quick reminder about something, it would work, but in that case you're more likely to do a web search anyway. For the rest of us, taking the medicine straight and for the full course is the only way. To some degree, this may have been forced on the authors by Git's inherent complexity and the interdependency of its basic concepts, but it does make this book unusual among technical guides. A common first use case, cloning a repository from somewhere else, isn't even covered until Chapter 12, because understanding what cloning really means requires so much background.

Like most readers, I'm an everyday user of Git but not at all an expert. Even this everyday use is enough to make me appreciate the scale of the task faced by the authors. On more than one occasion, frustrated by some idiosyncrasy, I've cursed that Git is a terrific engine surrounded by a cloud of bad decisions. The authors might not put it quite so strongly, but they clearly recognize Git's inconsistencies (the footnote on p. 47 is one vicarious acknowledgement) and they gamely enter the ring anyway. As with wrestling a bear, the question is not "Did they win?" but "How long did they last?"

For the most part, they more than hold their own. You can sometimes sense their struggle over how to present the information, and one of the book's weaknesses is a tendency to fall too quickly into implementation-driven presentation after a basic concept has been introduced. The explanation of cloning on p. 197 is one example: the jump from the basics to Git-specific terminology and repository details is abrupt, and forces the reader to either mentally cache terms and references in hope of later resolution, or to go back and look up a technical detail that was introduced many pages ago and is suddenly relevant again[1]. On the other hand, it is one of the virtues of the book that these checks can almost always be cashed: the authors accumulate unusual amounts of presentational debt as they go (in some cases unnecessarily), but if you're willing to maintain the ledger in your head, it all gets repaid in the end. Your questions will generally be answered[2], just not in the order nor at the time you had them. This isn't a book you can read for relaxation; give it your whole mind and you shall receive enlightenment in due proportion.

The book begins with a few relatively light chapters on the history of Git and on basic installation and local usage, all of which are good, but in a sense its real start is Chapters 4-6, which cover basic concepts, the Git "index" (staging area), and commits. These chapters, especially Chapter 4, are essentially a design overview of Git, and they go deep enough that you could probably re-implement much of Git based just on them. It requires a leap of faith to believe that all this material will be needed throughout the rest of the book, but it will, and you shouldn't move on until you feel secure with everything there.

From that point on, the book is at its best, giving in-depth explanations of well-bounded areas of Git's functionality. The chapter on git diff tells you everything you need to know, starting with an excellent overview and then presenting the details in a well-thought-out order, including an especially good annotated running example starting on p. 112. Similarly, the branching and merging chapters ensure that you will come out understanding how branches are central to Git and how to handle them, and the explanations build well on earlier material about Git's internal structure, how commit objects are stored, etc. (Somewhere around p. 227 my eyes finally glazed over in the material about manipulating tracking branches: I thought "if I ever need this, I know where to find it". Everyone will probably have that reaction at various points in the book, and the authors seem to have segregated some material with that in mind.) The chapter-level discussions on how to use Git with Subversion repositories, on the git stash command, on using GitHub, and especially on different strategies for assembling multi-source projects using Git, are all well done and don't shirk on examples nor on technical detail. Given the huge topic space the authors had to choose from, their prioritizations are intelligently made and obviously reflective of long experience using Git.

Another strength is the well-placed tips throughout the book. These are sometimes indented and marked with the (oddly ominous, or is that just me?) O'Reilly paw print tip graphic, and sometimes given inline. Somehow the tips always seem to land right where you're most likely to be thinking "I wish there were a way to do X"; again, this must be due to the author's experience using Git in the real world, and readers who use Git on a daily basis will appreciate it. The explanation of --assume-unchanged on p. 382 appeared almost telepathically just as I was about to ask how to do that, for example. Furthermore, everything they saved for the "Advanced Manipulations" and "Tips, Tricks, and Techniques" chapters is likely to be useful at some point. Even if you don't remember the details of every tip, you'll remember that it was there, and know to go looking for it later when you need it (so it might be good to get an electronic copy of the book).

If there's a serious complaint to be made, it's that with a bit more attention the mental burden on the reader could have been reduced in many places. To pick a random example, in the "Branches" chapter on p. 90, the term "topic branch" is defined for the first time, but it was already used in passing on p. 68 (with what seems to be an assumption that the reader already knew the term) and again on pp. 80-81 (this time compounding the confusion with an example branch named "topic"). There are many similar instances of avoidable presentational debt; usually they are only distractions rather than genuine impediments to understanding, but they make the book more work than it needs to be. There are also sometimes ambiguous or not-quite-precise-enough statements that will cause the alert reader — which is the only kind this book really serves — to pause and have to work out what the authors must have meant (a couple of examples: "Git does not track file or directory names" on p. 34, or the business about patch line counts at the top of p. 359). Again, these can usually be resolved quickly, or ignored, without damage to overall understanding, but things would go a little bit more smoothly had they been worded differently.

Starting around p. 244 is a philosophical section that I found less satisfying than the technical material. It makes sense to discuss the distinction between committing and publishing, the idea that there are multiple valid histories, and the idea that the "central" repository is purely a social construct. But at some point the discussion starts to veer into being a different book, one about patterns for using Git to manage multi-developer projects and about software development generally, before eventually veering back. Such material could be helpful, but then it might have been better to offer a shallower overview of more patterns, rather than a tentative dive into the "Maintainer/Developer" pattern, which is privileged here beyond its actual prominence in software development. (This is perhaps a consequence of the flagship Git project, the Linux kernel, happening to use that pattern — but Linux is unusual in many ways, not just that one.)

The discussion of forking and of the term "fork", first from p. 259 and reiterated from p. 392, is confusing in several ways. It first uses the term as though it has no historical baggage, then later takes that historical baggage for granted, then finally describes the baggage but misunderstands it by failing to distinguish clearly between a social fork (a group of developers trying to persuade users and other developers to abandon one version and join another), which is a major event, and a feature fork (that is, a branch that happens to be in another repository), which is a non-event and which is all that sites like GitHub mean by forking. The two concepts are very different; to conflate them just because the word "fork" is now used for both is thinking with words, and doesn't help the reader understand what's going on. I raise this example in particular because I was surprised that the authors who had written so eloquently about the significance of social conventions elsewhere would give such an unsatisfactory explanation of this one.

Somewhat surprisingly, the authors don't review or even mention the many sources of online help about Git, such as the #git IRC channel at Freenode, the user discussion groups, wikis, etc. While most users can probably find those things quickly with a web search, it would have been good to point out their existence and maybe make some recommendations. Also, the book only covers installation of Git on GNU/Linux and MS Windows systems, with no explicit instructions for Mac OS X, the *BSD family, etc (however, the authors acknowledge this and rightly point out that the differences among Unix variants are not likely to be a showstopper for anyone).

But this is all carping. The book's weaknesses are minor, its strengths major. Any book on so complicated a topic is bound to cause disagreements about presentation strategy and even about philosophical questions. The authors write well, they must have done cubic parsecs of command testing to make sure their examples were correct, they respect the reader enough to dive deeply into technical details when the details are called for, and they take care to describe the practical scenarios in which a given feature is most likely to be useful. Its occasional organizational issues notwithstanding, this book is exactly what is needed by the everyday Git user who wants to know more — and is willing to put in the effort required to get there. I will be using my copy for a long time.

Footnotes

[1] One of my favorite instances of this happened with the term "fast-forward". It was introduced on p. 140, discussed a little but with no mention of a "safety check", then not used again until page 202, which says: "If present, the plus sign indicates that the normal fast-forward safety check will not be performed during the transfer." If your memory is as bad as mine, you might at that point have felt like you were suddenly reading the owner's manual for an early digital wristwatch circa 1976.

[2] Though not absolutely always: one of the few completely dangling references in the book is to "smudge/clean filters" on p. 294. At first I thought it must be a general computer science term that I didn't know, but it appears to be Git-specific terminology. Happy Googling.

[3] (This is relegated to a floating footnote because it's probably not relevant to most readers.) The book discusses other version control systems a bit, for historical perspective, and is not as factually careful about them as it is about Git. I've been a developer on both CVS and Subversion, so the various incorrect assertions, especially about Subversion, jumped out at me (pp. 2-3, p. 120, pp. 319-320). Again, this shouldn't matter for the intended audience. Don't come to this book to learn about Subversion; definitely come to it to learn about Git.

[4] As long as we're having floating footnotes, here's a footnote about a footnote: on p. 337, why not just say "Voltaire"?

[5] Finally, I categorically deny accusations that I gave a positive review solely because at least one of the authors is a fellow Emacs fanatic (p. 359, footnote). But it didn't hurt."

Comment Re:Lawsuits (Score 1) 101

by trawg (#41626513) Attached to: Dotcom's New Site "Megabox" Almost Ready

One approach that might work is to focus instead on newcomers - all the people with a band practicing in the garage or writing music in their bedroom.

We have a great place here in Australia for this - http://www.triplejunearthed.com/ . It has launched the career of many artists.

It is provided by the ABC, our state-owned media broadcaster, as part of their youth radio network Triple J. It is a fantastic service. I've gotten a lot of free music from them and exposure to really awesome bands.

Comment Re:PHP (Score 1) 113

by trawg (#41566489) Attached to: The Computer Science Behind Facebook's 1 Billion Users

Oh yes, please tell me all about the computer geniuses that wrote the PHP scripts that power facebook!

Well, I know PHP bashing is all the rage, so how about the computer geniuses at Facebook that wrote HipHop, their PHP-to-binary compiler?

I think it is a pretty cool technical thing (and according to their stats it dropped their CPU usage by some significant figure) - and even better, they open sourced it. Like they do with a lot of their stuff.

Comment Re:Comparing 2 different things... (Score 1) 513

by trawg (#41432467) Attached to: iOS 6 Adoption Tops 25% After Just 48 Hours

Erm ... The difference between light and day isn't much

Oops. Was either supposed to read "light and dark" or "night and day" but the message got confused between my brain and my hands somewhere.

But what differences are we talking about?

They say stability and UI speed - the two colleagues I work with that have Galaxy Nexuses both had regular problems with what they call general stability and complained regularly about the UI being slow and laggy to respond.

Apparently JB fixed all that stuff up to such a degree that the device went from a regular struggle to use to a much more pleasant experience.

As I posted elsewhere the Galaxy S upgrade path is even easier, though not OTA. Plug the phone into the computer, Kies pops up a message and says and upgrade is ready, and one click later you're upgraded without any configs getting clobbered, and even the carrier customisations were applied. And the Galaxy S users make up a MASSIVE portion of the Android userbase.

Again I'd be fascinated to see numbers on how many of those users actually ever bothered to upgrade. I had to install Kies on my machine to do something with a friend's S2 once (can't remember - run it as a USB disk? Something that I thought it was silly to have to install other software for, anyway) and found the whole thing to be the fairly typical crappy software experience.

I would guess that without OTA upgrades - or without actually tying the phone to the machine for its day to day use, like iPhone does w/ iTunes integration - you'd see much lower upgrade compliance. I know the numbers for Android show they're generally all over the place but there's just so many factors that just kill the OS upgrade path dead it's hard to know what they should focus on.

I really want an S3; I like the look of the phone and I love the idea of shoving another purchase of it in Apple's stupid face - but I can't bring myself to get a phone where I'm stuck waiting for someone else to decide when I should get OS updates (regardless of how good they are) and I'm not interested in self-updating via jailbreaking or whatever - so the Nexus is again the path for me.

Comment Re:Comparing 2 different things... (Score 1) 513

by trawg (#41426499) Attached to: iOS 6 Adoption Tops 25% After Just 48 Hours

Actually it seems you're just running around with your eyes closed. Nexus users simply get a notification when an update is available and the update works in 2 clicks, one to download and one to reboot the phone after the download is finished.

What percentage of Android users are Nexus users though? I am, but almost everyone else I know with an Android doesn't have a Nexus.

I'm looking to buy a Galaxy Nexus to upgrade from my dated Nexus One (..which still does almost everything I want) specifically because I know it is the only path to smooth Android upgrades. Most civilians don't know that and don't understand why it is important - they just end up at the mercy of their carrier or device manufacturer.

FWIW, everyone I know on a Galaxy Nexus said the difference between ICS and JB is like light and day - YMMV!

Comment Re:Electronic Subsitutions Not Suitable for Indust (Score 1) 372

by trawg (#41308973) Attached to: FAA Permits American Airlines To Use iPads In Cockpit "In All Phases of Flight"

As a professional researcher, it's much more reliable to use the paper version of manuals and hardware documentation.

As a professional researcher, you should have no problems citing a study that backs up the claim that it is more reliable to use paper version than electronic versions! :)

Comment Re:Not suspicious (Score 1) 527

by trawg (#41297115) Attached to: Following FEMA's Zombie Preparedness Plan Could Land You On Terrorist List

Very interesting. Are there concerns with the safety of self-canned food? I remember reading in maybe early high school science about problems with early canned food attempts, with various toxins getting into the food (maybe it was just the type of cans they were using or something..?)

The site you linked has some general info but just wondering if you had any experience or concerns with that aspect of it.

Slashdot Top Deals

DEC diagnostics would run on a dead whale. -- Mel Ferentz

Close