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

 



Forgot your password?
typodupeerror
×

Comment Re:You Don't Know What You're Talking About (Score 1) 1073

I am having trouble understanding your post. The parts you quoting appear basically unrelated to your responses.

Basically your post demonstrates a failed understanding that there are many marriage laws at the federal level. To say "Good! The US should stay out of it." makes about as much sense as saying "We should have no federal laws regarding marriage." This includes laws like federal tax laws being applied to married couples.

To recap, the federal government had to weigh in one way or another because they had a large amount of legislation that refers to "marriage." And the opposing sides in this issue actually view either ruling as the federal government sticking its nose in people's personal business. The anti-gay marriage crowd saw DOMA as the status quo and will likely view this overturning of DOMA as the federal government getting involved with dictating what is and isn't a marriage. Conversely the status quo was unacceptable to a small group.

Ethically this is a black and white issue and DOMA should have been overturned. But saying the federal government should butt out is not so cut and dried. Your post seemed to say it's just a marriage certificate and "News flash: gay couples live as married couples whether you like it or not." This is completely the wrong way to look at this, they were not receiving the same benefits as heterosexual married couples and saying "gay couples live as married couples" shows you don't understand the significance of DOMA being overturned. Now surviving spouse benefits will apply to one member of a gay couple same as it would to a member of a heterosexual couple. And that's just one of many things that heterosexual couples were enjoying that homosexual couples could not.

Comment You Don't Know What You're Talking About (Score 2) 1073

Anyway, this is great. People think that preventing gay marriage is somehow taking a stand against homosexuality or something. News flash: gay couples live as married couples whether you like it or not.

You clearly have not been following this issue. This wasn't just about a marriage certificate. This was also about the thousand or so federal laws that applied only to heterosexual couples now also applying to homosexual couples that are married.

Now they can truly be viewed as equal couples in the eyes of the federal government and, most importantly, receive the same exact treatment -- good or bad -- in the federal legislation for married couples.

The only thing banning the marriage certificate does is punish them for being gay.

What rock have you been living under for the past decade?

Comment On Project Cauã (Score 0) 26

First I praise you for your work and your goals -- they are refreshing compared to "please investors." But one of the keywords in your goals statements for Project Cauã is "capitalistic" as in "do all of this in a capitalistic, sustainable way, with little or no money coming from government." This mildly confuses me. I don't see FOSS as directly contradictory to capitalism but your goal of "triple or quadruple the number of FOSS developers in the world" seems, well, a little more public domain oriented than private industry, ownership and other tenants of capitalism. To put my question bluntly, why even pay petty lip service to capitalism when your goals of reducing electronic landfills, free-of-charge wireless and increasing user security are just not monetarily rewarded by the free market? These goals are about empowering people and protecting our future environment, how precisely does that align with capitalism? I understand how your job creation might benefit the economy but I don't understand how you're going to actually create these jobs. What companies are you talking to that have positions for these jobs? Most countries can't even pay to create jobs -- I'm sure several leaders would gladly put down billions of dollars if it meant magically creating productive and sustainable jobs, what is Project Cauã doing differently?

Comment At the Risk of Disgust for Defending the IRS ... (Score 5, Insightful) 356

Did they think it was a for-profit scam, or did they just not understand the approach?

I'm very pro-open source but it appears that the fear from the Internal Revenue Service was that companies were figuring out ways to dodge taxes by moving developers to 501(c)(3) or 501(c)(6) organizations and then paying them in "donations" after the software was released thereby avoiding some federal and state income taxes to what normally would be their regular employees. Basically you would be setting up an educational or scientific group of your own developers, you would be able to pay them less due to 501(c) income tax leveraging and at the end of the day you'd still get your commercial software designed for you under an Open Source license. This, of course, by and large does not happen nor is there any evidence of it (I'd imagine very few open source developers even get paid for it) but was it really so wrong for the IRS to watch out for it? Even if they're not engaging of what the IRS would call "non-linear compensation" you might still be able to pay developers as employees of the 501(c) their regular wages with far less tax.

I mean, are we going to sit here and bitch and moan about corporate tax avoidance in our country and then freak out when the IRS investigates if Open Source groups are being abused in the same manner?

Is it really that wrong for the IRS to identify points of abuse and to look out for them? My gut says they should be able to identify and investigate but perhaps I just can't imagine how they would abuse that ability if they present a legitimate reason. Seems like they had a legitimate reason to watch for unlawful activity, unless I'm missing something?

Comment They Can't Even Hand Out Fines Effectively (Score 5, Insightful) 260

The Chinese can't even effectively fine polluters and now there's talk of capital punishment for polluting? What next? Decimate school children when their class average isn't up to par because the instructor's scolding has no effect?

There are several key problems here that are the real underlying problems: 1) the Chinese government is not unified in their vision of the environment and I'm talking differences spanning across provincial & federal levels as well as between federal ministries. 2) they collectively refuse to accept that their abuse of natural resources is part of their winning equation against other capitalist nation states and, as a consequence, no one can talk about how this will hurt their bottom line even though several parts of the government realize it (we pay them to import our pollution). 3) there is widespread corruption at all levels which is why fining is ineffective -- it's so bad that I'm sure if capital punishment is meted out, it will be given to the fork lift operator who dumped those pig carcasses in the river after his supervisor told him to "make them disappear or you'll disappear." No one up the chain will be held accountable and if they are, they need only grease some local wheels and they can consider themselves shielded.

It's disgusting and it's why I tell people where they can shove it when they complain that the EPA is destroying jobs. It's not perfect but we have to cling to things that kind of work when so many other "solutions" are abysmal failures.

The Chinese government is threatening to kill polluters but they can't see that they're part of and dependent on and benefiting from a system of habitual polluting. Increasing the impact of the punishment is a poor and maybe even more detrimental substitution for actually bringing to justice the true criminals up and down their ranks.

Comment If Life Wasn't So Busy, My Own (Score 5, Informative) 335

How Will You Replace Google Reader?

(Disclaimer: I'm going to use the term 'bandwidth' universally instead of the more correct 'latency' or 'throughput' so normal people can hopefully understand this post) The biggest problem I have with every alternative I have tried is that they are built with the most annoying design flaws. They are so painful to me that I am certain these flaws will be look back upon as the geocities of our modern day web development.

When I fire up an alternative, the responsiveness that was in Google Reader just isn't there. And it always seems like the alternatives require you to hit "refresh" on their interface and then what happens? It apparently makes a call out to every single RSS feed to get updates. On the surface this may seem like standard HTTP way of thinking about things. But it makes for a shit user experience. I have thousands of RSS feeds. Thousands. And if I hit refresh in this paradigm, my browser makes 1,000+ HTTP GET requests. It's not a lot of data but if even one of those requests is slow, it's usually blocking on ceding control back to me.

So let's iterate improvements on here that will get us back to Google Reader style responsiveness, shall we? Well, one of the simplest improvements I can see is to do these requests asynchronously with nonblocking web workers. You can attach each of them to the div or construct that each feed is displayed in and only have them work when that feed is visible (for instance if I am collapsing/expanding folders of feeds). You can grey out the feed until the request comes back but if another request returns first, it is parsed and inserted and activated to my vision. That way if cnn.com comes back faster than NASA's Photograph of the Day, I can read while waiting for my images.

But the core problem is that I'm on my home computer on a residential cable modem and, let's face it, Cox sucks. So what I think Google was doing was sacrificing their bandwidth to actually "reverse" the request from client to server. And, in doing so, they could package up all your updates and ship them out in one request (probably compressed). So, this is how I would approach that. Instead of doing a heart beat HTTP GET to check for RSS updates, I'd build a WebSocket and instead of requesting information, the client (browser) would be listening for information. The event/listener paradigm here would save both the user and the RSS host a lot of bandwidth but it would cost the host of the feed reader service some of that bandwidth (although much less). So basically the client JavaScript would load the page just like normal but instead of continually sending HTTP GET requests, a WebSocket would merely inform the server which feeds are active and listen for updates coming in from the server.

On the downside, this greatly complicates the server side. You need to have one be-all end-all "cache" or storage of all incoming feeds that any user is subscribed to. And for each of these feeds, you need to have a list of the users subscribed to it. And now your server will need to maintain the HTTP GET requests to cnn.com and NASA in order to get updates. When it gets an update, there's two ways you could handle it (user queues are complicated so I won't suggest that) but the most basic way is to send it right out to everyone on that subscription list who has an active WebSocket session established with their account. If a new WebSocket session is established, they simply get the last N stories from their subscriptions (Google included pagination backwards binned by time). To alleviate even more bandwidth from you, you could store it on the client side with HTML5 Web Storage and then the first thing the Web Socket does is find the last date on the last stored element and send that across to the server to establish the session. The server responds with any updates past that time. And from there your WebSocket is merely listening and inserting elements into the page when they arrive.

Of course, after you valiantly save your RSS providers from death by a thousand cuts, you yourself face that same fate. And now you know why Google scheduled a turn off of Reader ...

Submission + - Death of Trees Correlated with Human Cardiovascular & Respiratory Disease (pbs.org)

eldavojohn writes: PBS's NewsHour interviewed Geoffrey Donovan on his recent research published in the American Journal of Preventative Medicine that noted a correlation between trees (at least the 22 North American ash varieties) and human health: 'Well my basic hypothesis was that trees improve people's health. And if that's true, then killing 100 million of them in 10 years should have an effect. So if we take away these 100 million trees, does the health of humans suffer? We found that it does.' The basis of this research is Agrilus planipennis, the emerald ash borer, which has systematically destroyed 100 million trees in the eastern half of the United States since 2002. After accounting for all variables, the research found that an additional 15,000 people died from cardiovascular disease and 6,000 more from lower respiratory disease in the 15 states infected with the bug compared with uninfected areas of the country. While the exact cause and effect remains unknown, this research appears to be reinforcing data for people who regularly enjoy forest bathing as well as providing evidence that the natural environment provides major public health benefits.

Comment Enough with the toy languages like C & C++ (Score 5, Insightful) 72

It's time for people to stop with this pretending to write computer games nonsense.

HTML5 is not a suitable development environment. Javascript is not a suitable development environment. Your web browser is not a suitable development environment. HTML5 is vaporware. HTML is designed to display TEXT.

Please re-read those sentences until you get it through your head. If you want to write a computer game, start with a real programming language:

1. C 2. C++

I recommend C so you don't get distracted by all the horse**** theory around OOP.

If you need a graphics engine, fine. Get one. Then code the game in a real development environment on a real computer (not a fiddly mobile device) on the metal. It will be hard, but the results will be worth it. If you can't bring yourself to do this, then you have no business programming or writing computer games.

P.S. I'm not interested in Javascript DOOM or whatever the "gew-gaw of the week" is, and I've been programming computers for 37 years, so I'm not interested in your tech credentials either. Either code the game or don't code the game, but knock it off with this artificial development nonsense.

That is all.

It's time for people to stop with this pretending to write computer games nonsense.

C/C++ is not a suitable development environment. VI is not a suitable development environment. Emacs is not a suitable development environment. C++14 is vaporware. C++ is designed to focus on OBJECTS, not GAMES.

Please re-read those sentences until you get it through your head. If you want to write a computer game, start with a real instruction set:

1. ARM (ARMv7 not ARMv8)
2. x86-64

I recommend ARM so you don't get distracted by all the horse**** bloat around CISC.

If you need a punch card reader, fine. Get one. Then code the game on a real ENIAC (not a fiddly PC) in the vacuum tubes. It will be hard, but the results will be worth it. If you can't bring yourself to do this, then you have no business programming or writing computer games.

P.S. I'm not interested in C++ OOP or whatever "Stroustrup's latest fly-by-night language" is, and I've been programming computers for 1,337 years, so I'm not interested in your tech credentials either. Either code the game or don't code the game, but knock it off with this artificial C/C++ development nonsense.

That is all.

Comment Pretty Sure The Onion Got It Right (Again) (Score 2, Informative) 103

I'm pretty sure The Onion hit the nail on the head (as well as their actual review of it).

But this is coming from someone who's probably going to see Frances Ha tonight and is still trying to get his hands on a copy of Incendies so if you want to laugh and don't want to have to think ... watch it make millions.

Submission + - Book Review: Core HTML5 Canvas (corehtml5canvas.com)

eldavojohn writes: Core HTML5 Canvas is a book that focuses on illuminating HTML5 game development for beginning and intermediate developers. While HTML and JavaScript have long been a decent platform for displaying text and images, Geary provides a great programming learning experience that facilitates the canvas element in HTML5. In addition, smatterings of physics engines, performance analysis and mobile platform development give the reader nods to deeper topics in game development.

author David Geary
pages 723 pages
publisher Prentice Hall
rating 9/10
reviewer eldavojohn
ISBN 9780132761611
summary An introduction to game development in HTML5’s canvas that brings the developer all the way up to graphics, animation and basic game development.

This book is written with a small introduction to HTML and JavaScript. While Geary does a decent job of describing some of those foundational skill sets, I fear that a completely novice developer might have a hard time getting to the level required for this text. With that in mind, I would recommend this book for people who already have at least a little bit of HTML and JavaScript development in their background. This book may also be useful to veteran developers of an unrelated language who can spot software patterns easily and aren't afraid to pick up JavaScript along the way. You can read all of Chapter One of the book here if you want to get a feeling for the writing. Geary also has sample chapters available on his site for the book, corehtml5canvas.com and maintains the code examples on Github. If you already write games, this book is likely too remedial for you (especially the explanations of sprites and collision detection) and the most useful parts would be Geary's explanation of how to produce traditional game elements with the modern HTML5 standards.

I have very few negative things to say about this text – many of which may be attributed to personal preferences. This book is code heavy. It starts off with a sweet spot ratio for me. I found I spent about twenty to thirty percent of my time scanning over HTML and JavaScript snippets inserted occasionally into passages. However, by the last chapters, I found myself poring over lengthier and lengthier listings that made me feel like I was spending sixty to seventy percent of my time analyzing the JavaScript code. To be fair, the author does do a good job of simply referencing back to concepts learned in other chapters but I wouldn't mind a re-explanation of those topics or a more in depth analysis of how those concepts interoperate. I also feel that it is risky to put so much code into print as that greatly impacts the shelf life of an unchanging book. The book itself warns on page 51 that toBlob() was a new specification added to HTML5 between writing the book and the book being published. I feel like this would warrant much more English explaining what you're accomplishing and why so that the book does not age as much from being tightly coupled to a snapshot of the specifications.

The code listings in this book are wonderfully colored to indicate quickly to the eye what part of the JavaScript language each piece is. I'm not sure how many copies suffer from this but my book happened to have a problem on some of the pages whereby the comprising colors did not line up. Here is a good example and a bad example just a few pages apart.

This was infrequent but quite distracting as the code became more and more predominant. Lastly, Geary briefly introduces the reader to amazing performance tools (jsPerf in Chapter 1 and again Browserscope in Chapter 4) early on and demonstrates how to effectively exercise it on small pieces of JavaScript. In the particular example he shows how subtle differences in handling image data can affect the performance inside different browsers (even different versions of the same browser as I'm sure the JavaScript engines are repeatedly tweaked). Since games are always resource intensive, I wondered why the author didn't take these examples to the next level and show the reader how to write unit tests (not really covered in the book). That way each of these functions could be extracted to a common interface where it would be selectively chosen based on browser identification. While this might be unnecessary for images, it would be a nod toward addressing the long pole in the tent when you look to squeeze cycles out of your code. Oddly, as more concepts are established and combined, these performance exercises disappear. I understand this book was an introduction to these side quests with a focus on game development but this was one logical step I wish had been taken further (especially in Chapter 9: The Ungame).

About a year ago, I started a hobby project to develop a framework for playing cards in the browser on all platforms. The canvas element would be the obvious tool of choice for accomplishing this goal. Unfortunately I began development using a very HTML4 attitude with (what I now recognize) was laughable resource management. This book really helped me further along in getting that hobby project to a more useable state.

The first chapter of the book introduces the reader to the basics of HTML5 and the canvas element. The author covers things like using clientX and clientY for mouse events instead of x and y. A simple clock is built and shows how to correctly use the basic drawing parts of the HTML5 specification. For readers unfamiliar with graphics applications, a lot of ground is covered on how you programmatically start by constructing an invisible path that will not be visually rendered until stroke() or fill() is called. The chapter also covers the basic event/listener paradigm employed by almost anything accepting user input. Geary explains how to properly save and restore the surface instead of trying to graphically undo what was just done.

An important theme through this book is how to use HTML elements alongside a canvas. This was one of the first follies of my “everything goes in canvas” attitude. If you want a control box in your application, don't reinvent the partially transparent box with paths and fills followed by mouse event handling over your canvas (actually covered in Chapter 10) – simply use an HTML div and CSS to position it over your canvas. Geary shows how to do this and would have saved me a lot of time. Geary discusses and shows how to manage off-screen canvases (invisible canvases) in the browser which comes in mighty handy when boosting performance in HTML5. The final parts of Chapter One focus on remedial math and how to correctly handle units of measure when working in the browser.

Chapter Two shows the reader how to build a rudimentary paint application with basic capabilities. It does a great job of showing how to expand on the basic functions provided by HTML5 and covers a little bit of the logic behind the behavior. Geary goes so far as to show the reader how to extend some of the core components of HTML5 like CanvasRenderingContext2D with an additional function. He also cautions that this can lead to pitfalls in JavaScript. This chapter does an excellent job of exploiting and enumerating core drawing functionality to achieve the next level in using these lines and objects for a desired user effect. Prior to reading this chapter, I hadn't viewed clip() in the correct light and Geary demonstrates the beginnings of its importance in building graphics. In Chapter Three, text gets the same extensive treatment that the basic drawing elements did in Chapter Two. In reading this chapter, it became apparent hat HTML5 has a lot of tips and tricks (perhaps that comes with the territory of what it's trying to achieve) like you have to replace the entire canvas to erase text. Being a novice, I'm not sure if the author covered all of such things but I was certainly appreciative for those included.

Chapter Four was an eye opener on images, video and their manipulation in canvas. The first revelation was that drawImage() can also render another canvas or even a video frame into the current canvas. The API name was not indicative to me but after reading this chapter, it became apparent that if I sat down and created a layout of my game's surface, I could render groups of images into one off-screen canvas and then continually insert that canvas into view with drawImage(). This saved me from considerable rerendering calls. The author also included some drag and drop sugar in this chapter. The book helped me understand that sometimes there are both legacy calls to old ways of doing things and also multiple new ways to accomplish the same goal. When you’re trying to develop something as heavy as a game, there are a lot of pitfalls.

Chapter Five concentrates on animations in HTML5 and first and foremost identifies a problem I had struggled with in writing a game: don’t use setInterval() or setTimeout() for animations. These are imprecise and instead the book guides the reader with instructions on letting the browser select the frame rate. Being a novice, the underlying concepts of requestAnimationFrame() had eluded me prior to reading this book. Geary’s treatment of discussing each browser’s nuances with this method may someday be dated text but helped me understand why the API call is so vital. It also helps you build workarounds for each browser if you need them. Blitting was also a new concept to me as was the tactic of double buffering (which the browser already does to canvas). This chapter is heavy on the hidden caveats to animation in the browser and builds on these to implement parallax and a stopwatch. The end of this chapter has a number of particularly useful “best practices” that I now see as crucial in HTML5 game development.

Chapter Six details sprites and sprite sheets. Here the author gives us a brief introduction to design patterns (notably Strategy, Command and Flyweight) but it’s curious that this isn’t persisted throughout the text. This chapter covers painters in good detail and again how to implement motion and timed animation via sprites with requestNextAnimationFrame(). This chapter does a great job of showing how to quickly animate a spritesheet.

Chapter Seven gives the user a brief introduction to implementing simple physics in a game engine like gravity and friction. It’s actually just enough to move forward with the upcoming games but the most useful section of this chapter to me was how to warp time. While this motion looks intuitive, it was refreshing to see the math behind ease-in or ease-out effects. These simple touches look beautiful in canvas applications and critical, of course, in modeling realistic motion.

Naturally the next thing needed for a game is collision detection and Chapter Eight scratches the surface just enough to build our simple games. A lot of fundamental concepts are discussed like collision detection before or after the collision happens. Geary does a nice job of biting off just enough to chew from the strategies of ray casting, the separating axis theorem (SAT) and minimum translation vector algorithms for detecting collisions. Being a novice to collision detection, SAT was a new concept to me and I enjoyed Geary’s illustrations of the lines perpendicular to the normal vectors on polygons. This chapter did a great job of visualizing what the code was achieving. The last thing this chapter tackles is how to react or bounce off during a collision. It provided enough for the games but it seemed like an afterthought to collision detection. Isn’t there a possibility of spin on the object that could influence a bounce? These sort of questions didn’t appear in the text.

And Chapter Nine gets to the main focus of this book: writing the actual game with all our prior accumulated knowledge. Geary calls this light game engine “the ungame” and adds things like multitrack sound, keyboard event handling and how to implement a heads-up display to our repertoire. This chapter is very code heavy and it confuses me why Geary prints comments inlined in the code when he has a full book format to publish his words in. The ungame was called as such because it put together a lot of elements of the game but it was still sort of missing the basic play elements. Geary then starts in on implementing a pinball game. It may sound overly complicated for a learning text but as each piece of the puzzle is broken down, the author manages to describe and explain it fairly concisely. While this section could use more description, it is basically just bringing together and applying our prior concepts like emulating physics and implementing realistic motion. The pinball board is merely polygons and our code there to detect collisions with the circle that is the ball. It was surprisingly how quickly a pinball game came together.

Chapter Ten takes a look at making custom controls (as mentioned earlier about trying to use HTML when possible). From progress bars to image panners, this chapter was interesting and I really enjoyed the way the author showed how to componentize and reuse these controls and their parts. There’s really not a lot to say about this chapter, as you may imagine a lot of already covered components are implemented in achieving these controls and effects.

Geary recognizes HTML5’s alluring potential of being a common platform for developing applications and games across desktops and mobile devices. In the final chapter of the book, he covers briefly the ins and outs of developing for mobile — hopefully without having to force your users to a completely different experience. I did not realize that native looking apps could be achieved on mobile devices with HTML5 but even with that trick up its sleeve, it’s hard to imagine it becoming the de facto standard for all applications. Geary appears to be hopeful and does a good job of getting the developer thinking about the viewport and how the components of their canvas are going to be viewed from each device. Most importantly, it’s discussed how to handle different kinds of input or even display a touch keyboard above your game for alphabetic input.

This was a delightful book that will help readers understand the finer points of developing games in HTML5’s canvas element. While it doesn’t get you to the point of developing three dimensional blockbuster games inside the browser, it does bite off a very manageable chunk for most readers. And, if you’re a developer looking to get into HTML5 game design, I heavily recommend this text as an introduction.

Comment Think About It This Way (Score 5, Insightful) 656

The verdict is: it's important.

I have two resumes in front of me. I need someone who can write some fairly complicated software. Are they writing the kernel to an operating system? No. But they'll be making complexity decisions between a server and a client. Not exactly new or novel but important to me and my clients.

So I look at one resume and the guy has suffered through integration by parts, linear algebra, differential equations and maybe even abstract algebra. The other guy went to a programming trade school where those are not taught. The trade school likely taught inheritance, pointers, typecasting, and all that good stuff just like the Bachelor's of Science degree would.

Now do my solutions need integration by parts, linear algebra and differential equations? Absolutely not. But if I'm going to pick between the two, I'm going to take the applicant that solved more difficult problems in order to make it to a class. Few people actually care about those concepts deep in their hearts -- and I'm sure neither of my prospective employees did. But in that same vein, no rational developer is going to care at all that my client likes to be able to drag and drop files instead of doing file navigation to find the files he wants. But I want the applicant who's going to do the inane stuff that he doesn't personally view as important.

Challenge yourself. Take the math courses. Take the logic courses. Take the statistics and combinatorics courses. Take the finite automata courses. Prove to yourself that there are no obstacles in your way. They are a great expense of time now but they are a huge investment in yourself -- no matter how pointless they appear to you.

If I had understood what I was doing, maybe I wouldn't mind so much.

You should attack this problem two different ways: 1) increase the amount of time you allot to your own personal enrichment in these topics/courses (three hours is very little time if you are approaching new concepts in math) and 2) seek outside instruction as it's also possible you have a professor who doesn't understand what they're doing either (the teaching, not the subject matter).

Comment Hammond Versus Barrett (Score 1) 192

The more I read about what these guys were doing--and I mean the stuff they've admitted to, not just been accused of--the more I think they are getting what they deserve. Breaking into someone's network to get at information that the public should know is political. Breaking into someones network and racking up charges on personal credit card numbers is criminal. They're like the idiots that smash store windows during street protests.

I agree they are not the good guys. But I also think it's important to mete out justice based on who was doing what. I hope in street protests when windows are smashed that the vandals are correctly identified and brought to justice. Similarly, I hope they find who are responsible for the credit card thefts but it appears Hammond is not and there are reports he did not benefit personally from this intrusion:

Barrett Brown of Dallas, Texas is expected to stand trial starting this September for a number of charges, including one relating to the release of Stratfor subscribers’ credit card numbers. He faces a maximum of 100 years in prison.

More here.

Comment Post Facto Economic Impact -- Not Productivity (Score 4, Insightful) 87

Switching to GIMP, my productivity is about to go through the roof!

It's not about productivity, it's about economic impact. The article is kind of tongue in cheek poking fun of BSA's erroneous numbers manipulation to show that "properly licensed software" contributes oh so much to the economy. For clear reasons, your switch to GIMP from (presumably) a proprietary software alternative wouldn't move you from one column to the other unless you were to somehow pirate GIMP. While pirating GIMP is possible, you'd like just install it legally by downloading it with references to the GPLv3 license. Whether or not you believe it, GIMP with a copy of the GPLv3 is actually properly licensed software -- putting it in the column of the nebulous cloud of software that the BSA claims inflates our world economy to staggering heights.

To try to quantify the "productivity" of GIMP versus something else like photoshop would likely be subjective, nebulous and not 1 to 1. This isn't about productivity, it's about piracy. The author is pointing out how much of the mad moneys comes from open source software and all but accuses the BSA of co-opting that figure to appear to be their own work.

Slashdot Top Deals

"A car is just a big purse on wheels." -- Johanna Reynolds

Working...