Is this one of those soft "pledges" that's not worth the paper it's written on, or is this something legally binding?
Any attempt by the MPEG-LA to renege on this grant (a massive public announcement within this industry) would be blocked by Estoppel (at least in legal systems which have that concept). Plus MPEG-LA has the additional deterrent that the backlash would be exactly what they're trying to avoid, only worse: it would promote market fear of H.264 for web use, forcing one of the format's competitors to rise to the forefront.
I'd bet that you could use that many megapixels to seriously boost dynamic range by averaging several adjacent pixels into one.
Simply put: no. Software "averaging" may smooth out noise, but it will not add information that was not present in the first place. Missing dynamic range at the hardware is just not there to be recovered in software. In digital camera sensors, dynamic range is limited by saturation of the sensor's photosites. Once a photosite has collected enough photons, it registers maximum charge -- information about any further photons collected at that photosite during the exposure is lost. In fact, adding more photosites per unit area increases the per-photosite noise and chip areal overhead. Noise reduces dynamic range at the low end, and less charge capacity per photosite reduces dynamic range at the high end.
As another poster notes, you might change the effective exposure received by each photosite (perhaps by Bayer-array like neutral-density filtering). Or you can do what Fuji did with the S3 pro: make a matrix of photosites of different sizes/sensitivites to improve dynamic range. Fuji's sensor, while nice, has hardly taken over the digital imaging world.
On a more constructive note, Ctein wrote up a nice exposition on The Online Photographer about both near-term sensor technologies entering production and long-term avenues for advancement in digital imaging technology.
Yes, there are times when a "no-sql" solution is better than SQL, and the vector is pretty much that point where you realize that storing files in databases makes sense like hauling bales of hay in sports cars does.
It's more than that: it's also for every case where the lookup logic is NOT handled by the database. Consider when queries are fielded by a separate service, such as a dedicated search engine (e.g. Solr/Lucene), leaving the database is relegated to just primary key lookup for full records/documents. At that time the benefits and tradeoffs offered by the various NoSQL solutions suddenly become a LOT more interesting, because that's what these tools specialize in.
This has already been done. The first I personally encountered such was in a then-new university building in the mid-90's. It had security panels at various points with individual illuminated LED display buttons. When not active, each button face was a rather enigmatic black. On the first press, the panels would "wake up", make (I kid you not) a sci-fi show warbling sound and scrambling animation on each keyface, then present a set of shuffled digits on the various keys. Each press reshuffled the displays.
This made perfect sense, since back in the 80's a sysadmin for the local university showed me the "breathe on the keypad" trick to see what keys are being pressed by users. Forget fancy Photoshop or IR imaging tricks...
Given how incongruous the randomizing keypads were at the time, part of me always suspected that they weren't actually security panels but part of a long-running installation art piece. The cameras wouldn't have been even a bit out of place.;-)
article does not say that it's the human body's only defense against cancer?
Or perhaps more interestingly: is the Rb gene the newt's only defense against cancer? Specifically, have newts developed alternative cancer defenses that support Rb suppression during regeneration?
Sniping is not a problem, it is a solution. You have to be a fairly naive eBay bidder to reveal your bid limit before bidding is essentially over. If you place a plain bid, you are vulnerable to 1) bidding wars from weak-willed folks (i.e. human beings) who don't set a personal bidding limit and 2) those who will "data mine" by incrementally upping their bid until they beat the top bidder, while at the same time trying to limit their upside risk. From a bidder's perspective, a snipe is ideal: it encourages you to do your research and set a firm bid limit up-front. I find this to be a vastly more relaxing way of bidding, since I've done my homework beforehand and avoid the temptation of stupid bidding wars. Likewise, it doesn't expose your bid (or even your intention to bid) until the last moment.
Frankly, I think sniping should be the standard bid mechanism for eBay auctions. I suspect that they'd never do it because it would reduce revenue by some amount.
Even Gates wasn't fully on top of things BUT he was at least in the same ballpark.
Note that MS under Gates' watch had successful (and ruthless) business practices to make sure that MS made heaping tons of money, even without being a major market innovator. It was often easier to let others innovate, then use a combination of financial might, second-mover advantage, and sometimes a bit 'o market leverage to move in and take over.
I'm frankly a bit shocked at how much this news item echoes Ballmer's earlier pathetic whinging about iPod and then iPhone. It's unacceptable that a major corporate CEO should sound like such a broken record when the message being repeated is "failure!"
To provide some concete figures here, 4x5 large format film (the smallest format considered "large") can be drum-scanned to produce images in the 200-300 megapixels equivalent range. Quadruple that for 8x10 film. Ultra-large format (ULF) formats are even larger, up to 20x24 inch film. Folks working with hybrid (analog/digital) processes with ULF mostly don't bother with full drum-scan resolution. Even for very large prints, there's just a stupidly large amount of information. And the real dynamic range and highlight behavior for black and white film blows all current digital sensors out of the water.
I had to laugh at that gigapixel photo of Obama's inaguration -- all sorts of artifacts along the stitch boundaries. A single wide-angle 8x10 (or hell, 8x20) image would have blown it away.
was there actually anything about Kodachrome that made it unique (in a good way)
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:
Dangin’s latest invention is a proprietary software package called Photoshoot. (He employs six full-time programmers at Box.) Its aim is to imbue digital photography with a specific sensibility—an opinion about the way pictures should look—of the sort that film once offered. “I am doing this because of necessity, because I believe the way that digital photography is done today is so wrong,” Dangin said one day. “Photography as we knew it, meaning film and Kodak and all that, was a very subjective process. With film images you had emotions. You used to go out and buy film like Fuji, because it was more saturated, or you liked Agfa because it gave you a rounded color palette.” With a ten-dollar roll of film, he explained, you were essentially buying ten dollars’ worth of someone’s ideas. “Software, right now, is objective. ‘Let the user create whatever he wants.’ Which is great, but it doesn’t really produce good photography.”
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.
If it is not free or simply licensed, just do not use it.
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:
As noted above, while pub/sub scales very well with small installations, a major difficulty is that the technology often scales poorly in larger ones.
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.
things like using the turkey carver to carve up the leg foam
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.
[...] TeX itself is low-level, and when you use a package like LaTeX it becomes far more user-friendly.
Let's not forget the glory that is the LyX editor:
LyX is a document processor that encourages an approach to writing based on the structure of your documents (WYSIWYM) and not simply their appearance (WYSIWYG).
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.
Unfortunately for the plaintiffs, this time they seem to have picked an opponent who is very hard to beat in a war of attrition.
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.
Repeat after me: people who don't want to learn programming will make lousy programmers.
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".
Isn't this kind of thinking that lead us to why we have the security holes, shoddy programming, and bloat-ware today? People just want to code and not to learn the ins and outs required to craft a well-heeled, tuned, and functioning program or application?
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:
green parliamentarians who believe that ITER is too costly and too speculative to warrant support. Rather than spending money on nuclear fusion, the greens would like to see ITER's funding spent on near-term renewable energy sources.
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.
The screen has print level resolution and, as a graphic designer, that simply blows my mind.
I recall seeing a demo of an IBM Roentgen[1] display back in 2001 at SIGCHI. This display was color 200ppi display with a 16.3" diagonal, developed with telemedicine uses in mind (including remote examination of patient x-ray results). IBM was showing off museum-quality archival scans of famous artwork, absolutely readable footnotes in serifed text with 4 point (physical) font size, and ridiculously unreadable icons and text in Windows.;-) This display was, likewise, completely mind-blowing at the time.
I knew it would be a long time for that tech to trickle down into the mainstream, but I never thought then that it'd be in handheld form first.
[1] Named for Wilhelm Roentgen who won the Nobel Prize for producing and detecting x-rays.
Slashdot Mirror
Is this one of those soft "pledges" that's not worth the paper it's written on, or is this something legally binding?
Any attempt by the MPEG-LA to renege on this grant (a massive public announcement within this industry) would be blocked by Estoppel (at least in legal systems which have that concept). Plus MPEG-LA has the additional deterrent that the backlash would be exactly what they're trying to avoid, only worse: it would promote market fear of H.264 for web use, forcing one of the format's competitors to rise to the forefront.
I'd bet that you could use that many megapixels to seriously boost dynamic range by averaging several adjacent pixels into one.
Simply put: no. Software "averaging" may smooth out noise, but it will not add information that was not present in the first place. Missing dynamic range at the hardware is just not there to be recovered in software. In digital camera sensors, dynamic range is limited by saturation of the sensor's photosites. Once a photosite has collected enough photons, it registers maximum charge -- information about any further photons collected at that photosite during the exposure is lost. In fact, adding more photosites per unit area increases the per-photosite noise and chip areal overhead. Noise reduces dynamic range at the low end, and less charge capacity per photosite reduces dynamic range at the high end.
As another poster notes, you might change the effective exposure received by each photosite (perhaps by Bayer-array like neutral-density filtering). Or you can do what Fuji did with the S3 pro: make a matrix of photosites of different sizes/sensitivites to improve dynamic range. Fuji's sensor, while nice, has hardly taken over the digital imaging world.
On a more constructive note, Ctein wrote up a nice exposition on The Online Photographer about both near-term sensor technologies entering production and long-term avenues for advancement in digital imaging technology.
Yes, there are times when a "no-sql" solution is better than SQL, and the vector is pretty much that point where you realize that storing files in databases makes sense like hauling bales of hay in sports cars does.
It's more than that: it's also for every case where the lookup logic is NOT handled by the database. Consider when queries are fielded by a separate service, such as a dedicated search engine (e.g. Solr/Lucene), leaving the database is relegated to just primary key lookup for full records/documents. At that time the benefits and tradeoffs offered by the various NoSQL solutions suddenly become a LOT more interesting, because that's what these tools specialize in.
This has already been done. The first I personally encountered such was in a then-new university building in the mid-90's. It had security panels at various points with individual illuminated LED display buttons. When not active, each button face was a rather enigmatic black. On the first press, the panels would "wake up", make (I kid you not) a sci-fi show warbling sound and scrambling animation on each keyface, then present a set of shuffled digits on the various keys. Each press reshuffled the displays.
This made perfect sense, since back in the 80's a sysadmin for the local university showed me the "breathe on the keypad" trick to see what keys are being pressed by users. Forget fancy Photoshop or IR imaging tricks...
Given how incongruous the randomizing keypads were at the time, part of me always suspected that they weren't actually security panels but part of a long-running installation art piece. The cameras wouldn't have been even a bit out of place. ;-)
article does not say that it's the human body's only defense against cancer?
Or perhaps more interestingly: is the Rb gene the newt's only defense against cancer? Specifically, have newts developed alternative cancer defenses that support Rb suppression during regeneration?
git cherry-pick newt/5f5c3c4f
Sniping is not a problem, it is a solution. You have to be a fairly naive eBay bidder to reveal your bid limit before bidding is essentially over. If you place a plain bid, you are vulnerable to 1) bidding wars from weak-willed folks (i.e. human beings) who don't set a personal bidding limit and 2) those who will "data mine" by incrementally upping their bid until they beat the top bidder, while at the same time trying to limit their upside risk. From a bidder's perspective, a snipe is ideal: it encourages you to do your research and set a firm bid limit up-front. I find this to be a vastly more relaxing way of bidding, since I've done my homework beforehand and avoid the temptation of stupid bidding wars. Likewise, it doesn't expose your bid (or even your intention to bid) until the last moment.
Frankly, I think sniping should be the standard bid mechanism for eBay auctions. I suspect that they'd never do it because it would reduce revenue by some amount.
demonstrates Oracle's commitment to openness...
[Pause for evil laughter omitted]
...and will provide Dell and HP customers with new levels of support...
Even Gates wasn't fully on top of things BUT he was at least in the same ballpark.
Note that MS under Gates' watch had successful (and ruthless) business practices to make sure that MS made heaping tons of money, even without being a major market innovator. It was often easier to let others innovate, then use a combination of financial might, second-mover advantage, and sometimes a bit 'o market leverage to move in and take over.
I'm frankly a bit shocked at how much this news item echoes Ballmer's earlier pathetic whinging about iPod and then iPhone. It's unacceptable that a major corporate CEO should sound like such a broken record when the message being repeated is "failure!"
How about "Rob Pike Decries Complexity of Java, C++" instead?
|Rob Pike| >> |Google Engineer|
To provide some concete figures here, 4x5 large format film (the smallest format considered "large") can be drum-scanned to produce images in the 200-300 megapixels equivalent range. Quadruple that for 8x10 film. Ultra-large format (ULF) formats are even larger, up to 20x24 inch film. Folks working with hybrid (analog/digital) processes with ULF mostly don't bother with full drum-scan resolution. Even for very large prints, there's just a stupidly large amount of information. And the real dynamic range and highlight behavior for black and white film blows all current digital sensors out of the water.
I had to laugh at that gigapixel photo of Obama's inaguration -- all sorts of artifacts along the stitch boundaries. A single wide-angle 8x10 (or hell, 8x20) image would have blown it away.
was there actually anything about Kodachrome that made it unique (in a good way)
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:
Dangin’s latest invention is a proprietary software package called Photoshoot. (He employs six full-time programmers at Box.) Its aim is to imbue digital photography with a specific sensibility—an opinion about the way pictures should look—of the sort that film once offered. “I am doing this because of necessity, because I believe the way that digital photography is done today is so wrong,” Dangin said one day. “Photography as we knew it, meaning film and Kodak and all that, was a very subjective process. With film images you had emotions. You used to go out and buy film like Fuji, because it was more saturated, or you liked Agfa because it gave you a rounded color palette.” With a ten-dollar roll of film, he explained, you were essentially buying ten dollars’ worth of someone’s ideas. “Software, right now, is objective. ‘Let the user create whatever he wants.’ Which is great, but it doesn’t really produce good photography.”
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.
If it is not free or simply licensed, just do not use it.
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.
Simple pub/sub message queues [...]
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:
As noted above, while pub/sub scales very well with small installations, a major difficulty is that the technology often scales poorly in larger ones.
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.
things like using the turkey carver to carve up the leg foam
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.
[...] TeX itself is low-level, and when you use a package like LaTeX it becomes far more user-friendly.
Let's not forget the glory that is the LyX editor:
LyX is a document processor that encourages an approach to writing based on the structure of your documents (WYSIWYM) and not simply their appearance (WYSIWYG).
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.
Unfortunately for the plaintiffs, this time they seem to have picked an opponent who is very hard to beat in a war of attrition.
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.
Repeat after me: people who don't want to learn programming will make lousy programmers.
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".
Isn't this kind of thinking that lead us to why we have the security holes, shoddy programming, and bloat-ware today? People just want to code and not to learn the ins and outs required to craft a well-heeled, tuned, and functioning program or application?
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.
that doesn't have any new functionalities
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?
Anti-nuclear environmentalist organizations
The above statement appears to be ad-hominem nonsense. Quoth TFA:
green parliamentarians who believe that ITER is too costly and too speculative to warrant support. Rather than spending money on nuclear fusion, the greens would like to see ITER's funding spent on near-term renewable energy sources.
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.
The screen has print level resolution and, as a graphic designer, that simply blows my mind.
I recall seeing a demo of an IBM Roentgen[1] display back in 2001 at SIGCHI. This display was color 200ppi display with a 16.3" diagonal, developed with telemedicine uses in mind (including remote examination of patient x-ray results). IBM was showing off museum-quality archival scans of famous artwork, absolutely readable footnotes in serifed text with 4 point (physical) font size, and ridiculously unreadable icons and text in Windows. ;-) This display was, likewise, completely mind-blowing at the time.
I knew it would be a long time for that tech to trickle down into the mainstream, but I never thought then that it'd be in handheld form first.
[1] Named for Wilhelm Roentgen who won the Nobel Prize for producing and detecting x-rays.