As someone who has shot film and digital side-by-side, yes. Film isn't just "disposable digital sensor rolls." Each kind of film has unique working characteristics. To quote Pascal Dangin from this New Yorker article:

I'll elaborate on that "ten dollars' worth of someone's ideas" bit: It's very loosely akin to being able to choose from a set of experienced digital post-processing artists, each with a distinct look. Film companies put a lot of money into tuning the characteristics of each line of film, whether color or black and white, for the desired results.

That's an amazingly ignorant statement. Computers and the software that runs on them are just tools. These tools are evaluated based on a collection of merits. Licensing concerns are just one of many factors that influence decisions to adopt a particular software system. Compatibility, up-front costs, ongoing costs, and suitability to task are some important others.

In many cases there exists exactly zero FOSS software systems that satisfy certain application needs. We're not talking about boring stuff like MS Office vs. Open Office, either (and even that can't pass muster in many organizations). Examples of verticals where FOSS systems are weak or nonexistent include: scientific software systems (very hit or miss; some outstanding FOSS projects in scientific verticals and some huge voids), machine control, color-managed print workflows, just off the top of my head. There's a world of other examples. In some cases, open source solutions exist but simply aren't up to the standards of the competition and the organization's needs.

In the end, it's never really a matter of "FOSS or die". It's always a positive choice to solve the problems that need solving, using the available tools. If FOSS tools aren't even available, then they aren't a choice. Even when they are available, they may not measure up as the best choice, at least to anyone who isn't playing FOSS zealot.

What on earth are you talking about? You're making up a random argument ("without copyright protection and enforcement") that has nothing to do with the summary or TFA. Those discuss the reprehensible and inefficient tactics of suing members of the general public for file-sharing, and warping of the law to suit the tastes of large rightsholders (e.g. the US' DMCA and similar). No mention is made of eliminating copyright or of not enforcing against corporations (who damn well should know better).

As far as revenue in the real world, many independent artists and small labels (often a single individual) have cropped up in recent years who are successfully selling non-DRM'ed downloadable music to the general public, either directly or via intermediaries (c.f. Amazon, Beatport, iTunes, etc., etc.). For the small artists, I expect they are likely doing vastly better than they ever would through a traditional recording company contract.

Note that the phrase in question will be both translated and summarized from the text of the law. I wouldn't read too much into it without a look at the original.

Also note: without some such clause, ISPs might be legally barred from useful and necessary activities such as addressing ongoing DDOS attacks.

And therein lies the rub. The problem is that pub/sub message queues are neither simple nor scalable as the problem size increases. From the WP article you cited:

You pretty much don't get a larger organization than the public internet, assuming that a service becomes popular enough. I've seen these problems myself in one particular large internet company I worked for. Message queue systems are great tools, but there are a ton of practical problems in implementing an event/push based system broadly.

On the up-side, companies like Twitter can (must) take advantage of the fact that they don't need an all-singing, all-dancing pubsub solution. There may be approaches that will work well with the proper problem constraints, much as how eventually-consistent systems can gain advantages over always-consistent solutions when the problem domain permits that.

Heh, interesting. I first ran across using a turkey carver with foam for precision cuts in acoustic foam for use in recording studio type environments. Useful both for aesthetics (creating non-rectangular shapes for the space) and acoustic control (segmenting larger pieces to obtain the desired percentage coverage of a wall).

Interesting to find that foam cutting technique being used in a different context.

Let's not forget the glory that is the LyX editor:

LyX is delightful for those who want a nice cross-plaform GUI editor, structure in their documents, as well as strong control over presentation, but want structure rather than presentation foremost in their everyday editing experience.

Watch your step there, friend! There are apparently two journals with that name, quite different from one another.

The traditional academic journal, apparently out of UT Austin's philosophy department: Apeiron: A Journal for Ancient Philosophy and Science

Then the online journal: Apeiron, Studies in Infinite Nature.

This paper was published in the UT academic journal, not the (somewhat questionable looking) online journal.

Beyond that, I have no experience with the UT publication or its track record.

No kidding. GOOG's market cap is about $153.53B right now, while VIA.B's is $21.42B. Google has about $26B in cash and short term investments. Viacom has $358M. Google's gross profit is >3x Viacom's.

Fine, I'm forgoing the mod points I've already spent in this thread, since there's so much damn cluelessness about the "value" of overwork.

For everyone who thinks habitual working hours over a sustainable 35-45 hour pace (which varies by individual) is a good thing, go read Tom DeMarco's book Slack. He neatly debunks the pointy-haired boss myths (and gullible, guiltable workaholic engineer myths) regarding overwork. Some examples: very quickly after working at maximum sustainable pace, your work output per hour starts to drop. Eventually, you've been pulling 60 hours or more for just a few weeks and you're not really getting any more done than you would have at your sustainable pace. For severe overwork, you're getting a LOT less done. Also, "undertime" becomes endemic at high workloads -- that need to "just pop out for a few hours" during working hours to deal with all of that life-stuff that's being neglected.

The larger points of the book surround how a concept of "slack" is vital to the success of any individual, team, and/or company that depends on knowledge work. This "slack" is an ingredient which supplies the ability to quickly respond to changing requirements, to seize opportunities, and to handle market shifts. One of my favorite distinctions that DeMarco draws in the book is between an organization's efficiency and effectiveness. In this context, efficiency is roughly defined as "how fast are we moving towards some goal?" while effectiveness is defined as "are we moving towards the right goal?" Many organizations optimize solely for efficiency -- moving forward at a breakneck pace -- and sacrifice effectiveness in so doing. The organizational ship becomes hard to steer, and often times ends up at the wrong goal.

Heck, Barbara Liskov (2008 ACM Turing Award winner) has a great quote on this topic... IIRC, to the effect of how she felt guilty for times when she worked less, until she realized that she was always more productive and energized during those times.

Fine then: the statement above is garden-variety developer egocentric stupidity. TFS' statement is right, these folks want to get their work done, but the specific tools are irrelevant. The qualities of those tools for the task are the only things that matter.

It's insulting and stupid to propose that those looking to program and leverage an *Arduino* for their personal projects are somehow slackers uninterested in learning. Maybe they're just interested in learning what they want to, not what you want them to. I've walked the path of deep knowledge of programming, CS, etc. I've put my thousands and thousands of hours in. It's a good one for those who enjoy it, but it's not the end-all, be-all for all people.

Lots of people "want to learn", but at the same time they don't have that "ten thousand hours to mastery" to invest in a new domain (here, programming/CS). There's a spectrum here: on one end, the deep knowledge of an experienced programmer. On the other, those who want and need to access the power of programming but don't want to be burdened with oceans of complexity and specialized domain knowledge. I'll apply an existing term, "end-user programming", for this.

The most successful end-user programming environment by far is the spreadsheet. It provides simple, tabular model and some fairly rich programming capabilities within its scope. Another great example is the Max/MSP/Jitter environment for real-time audio/video signal processing -- very popular in the computer music and visuals world. Labview-based systems (which includes the Lego Mindstorms stuff) are another great example. Each of these environments is rich enough to allow programming, learning, and exploration. And all provide environments that are tailored to specific problem domains.

There's a place in the middle, often called by programmers "tools for the task", where a programmer doesn't have to bend over backwards to address certain hairy problem domains. Libraries, frameworks, and programming languages can all meet these needs in their various ways -- even to the extreme that it transforms what some people consider the nature of "programming".

Repeat after me: programming languages and frameworks do not make developers dumber. It's this kind of thinking that forces every developer-user of a complicated system to be continually faced with issues outside of their domain of expertise, or even just the current problem focus. *That's* what causes these problems.

For example, when doing embedded programming some years back, I noted that team members working on codec optimization were starting to crank out bad, broken ad-hoc synchronization logic to take advantage of some unique parallel hardware. Their specialties ran into numerical analysis and implementing low-level numerical optimizations, not into synchronization algorithms. I could take these folks and run them through an OS class, and walk them through the inevitable sea of mistakes...

Or I could do what I did: I created a framework that abstracted away all of the platform synchronization concerns. They did their jobs neatly and cleanly by writing a class that contained some shared state and implementing just two virtual methods that embodied the parallel work. They were much happier, and the whole team was much happier because there was now *one* place to look for synchronization bugs. This was quickly hammered out into a very stable foundation for the other teams' work.

Allowing our programming languages, libraries, and frameworks to do the heavy lifting so we humans can focus on the real problems we want to solve pretty much describes the history of real progress in software development.

I've seen this sentiment expressed a few places, most of which don't appear to be trolls. I'm admittedly a bit surprised that folks (esp. here) don't get "much faster processor, more storage, better display, better camera" as features. WTF are people expecting? An eggbeater that pops out of the dock port?

The above statement appears to be ad-hominem nonsense. Quoth TFA:

ITER is terribly expensive. Combined with a substantial risk that the project could fail to produce valuable results, it seems that asking hard questions and investigating alternatives for that investment is a wise move.