Robert Broglia's popular series of emulators for Android all support using a Wii controller -- or a Wii Classic Controller -- because they're just Bluetooth devices and the pairing is straightforward.
Yes, I was probably a little bit imprecise. Film and digital sensors give more shades than the human eye can distinguish *within the range available on the display technology*. That is, if zero is between the blackest ink we have, and n is the whitest paper, we can print two different shades between 0 and n which can't be distinguished by a human. But start looking at the darkest darkness, or the brightest light, and sure, neither film nor digital can compete.
But our blackest ink isn't black and our whitest paper isn't white, so we have to do tone-mapping.
Also, although the human eye can handle all these shades, it can't do it without adjusting, and that takes time.
?So what's the point of trying to capture, process, and project brightness values greater than our eyes+brain can process? Was there any point in going past 15 or 16-bit colour?
For the first two, so that we can make artistic decisions in remapping to the smaller range we can project.
I know a little bit about it, and even I'm not going anywhere near it, what is going to change that makes regular Joe give up his known and easily understandable concept of cash for some magic complicated fairy dust that you need a math education to figure out if it's a scam or not?
Just because Regular Joe can't find a use for it, doesn't mean it's of no use to anyone. Already drug dealers and their customers have found it useful. Whether you and I find that morally offensive or not, it's still a practical use. I can well imagine people in third-world countries and oppressive regimes using it to transfer money abroad in circumstances where mainstream methods are too expensive or forbidden by the authorities.
The dynamic range of consumer digital cameras exceeds that of the human eye -- that is an area we see as uniform black, or uniform white, will contain detail we can't see.
The dynamic range of film - especially black & white film - is much wider still. That's why digital still photographers feel the need to achieve "HDR" (high dynamic range) by superimposing multiple shots at different exposures.
But what's the point of capturing a dynamic range that the human eye can't perceive? Well, you can bring it back into the human range in post-processing. The digital HDR folks use algorithmic processing to exaggerate edges, and bring out detail that the eye couldn't otherwise see. In the darkroom, a film photographer can choose which parts of the image to bring out.
Imagine a film negative of a photo taken from the outside of a cave on a sunny day. The dynamic range of negative film is so high that the picture can contain detail of rock shapes in the dark cave, *and* the sunlit vegetation outside. When printing in the darkroom, you can either expose it so that the detail in the dark cave is clear (and the outside is bleached out), or so the detail in the lit outside is clear (and the cave interior is black). Or, being creative, you can cast shadows while exposing the paper, to even things out and get detail in both.
For the final product, modern digital is always fine. CD audio is fine. Blu-Ray is fine. Digital cinema formats are fine. You only want higher dynamic range than that so that you have a bigger capture space to select from. Compare it with resolution. You don't need 15MP captures if you're only going to print 5x4 images -- until you decide you want to crop small parts of the image to print at that size.
The middle class will suffer too. If you currently live in a coastal city, you're going to have to either move (expensive) or fund flood defences (expensive).
OK, to some extent I'm just stating RMS's position, not my own here. I do use non-free software, and I don't sweat too much about it.
However, I do get frustrated when software goes wrong -- or could just benefit from minor new features -- and I can't do anything about it.
I do, actually, expect to be able to repair a toaster. Fortunately most toasters (assuming a simple toaster that's not microprocessor controlled) are simple enough that you don't *need* a circuit diagram -- you can just look at the circuit itself. There is no "compiler" which (as a side effect of its primary function) obfuscates the design. I suppose that's analogous to software written in a non-compiled language.
You might be upset (or maybe you've got used to it!) if a toaster manufacturer went out of their way to make the toaster non-user-serviceable, so you had to go to the manufacturer for repairs, rather than get your own soldering iron out, or going to an independent electrical repair shop. I gather petrol-heads are have been hit by this issue recently -- and have sought legislation to prevent it.
... and Hans Reiser murdered his wife, but that's quite orthogonal to the quality of his code, and by all accounts ReiserFS is an excellent piece of work.
I too abhor ESR's gun nut, extreme libertarian views. But The Cathedral And The Bazaar was an insightful piece that really did launch a valuable movement. Fetchmail isn't a major achievement, but it's stable and useful, and no doubt a better product for ESR's community-driving than it would have been if he'd coded it all alone.
And don't lump ESR and RMS together - RMS is driven by principle, ESR is driven by pragmatism. RMS believes it's better to use bad software than non-free software. ESR believes open source leads to processes that produce high quality software.
Linus, I think, is on the pragmatic side, and not married to the GPL. I don't think he put a great deal of thought into choosing the license for Linux -- he wanted to share it, he had no intention of it being more than a hobbyist thing, at first. By the time Linux proved to be a potential big deal, there were so many contributors, that getting permission from all of them to alter the license would be all-but-impossible. Note that Linus chose to adopt the proprietary BitKeeper SCM system, before he wrote Git; Git is GPL - so he must be happy with that license for his own work.
I'm pretty sure there was a story somewhere about an "escort agency" accepting bitcoins, and I find it entirely plausible. They're easy to accept. They can be exchanged for "real" currency.
In the demo of Ubuntu for phones, a Samsung S3 is running Android and Ubuntu *at the same time*.
I don't know whether Android is hosting Ubuntu, or Ubuntu is hosting Android, or some third piece of software is hosting both. But the end result is that you plug your phone into an HDMI monitor, operate an Ubuntu desktop on the monitor using a bluetooth keyboard/mouse, and use Android on the handset at the same time. The Ubuntu stuff had hooks into Android so there were desktop apps that interacted with your Android contacts etc.
Fairly neat. I got the impression that it wasn't all as open-source as I'd like it to be -- ain't that the Android way?
Shouldn't jump back in such scenario. Progress bars display percentage of _work_ done, not of time remaining.
It could still go backwards, because you often only have an estimate of work to be done.
To put it in the real world, let's say I'm a menial office worker, and I've been given the task of filing the contents of 10 shoe boxes full of correspondence. I open the first box, it's got about 20 letters in it. After I've filed 10 letters, I tell my boss I'm 5% done - 10 letters out of an estimated 200.
The next 8 boxes also contain 20 letters, on average, so at the end of the 9th box, I tell my boss I'm 90% done.
Then I open the 10th box, and it's got 180 letters in it. So I tell my boss "Yeah, sorry about this, it turns out there were more letters than I thought; actually I'm only 50% done".
Now, in this scenario, if my boss really wanted accurate progress reports, I should have peeked in all the boxes before starting, to make a better estimate of the work to be done. But that's not always possible.
I suppose it depends what you mean by "useful distance". I can imagine situations in homes or small offices where line-of-sight over quite short distances would be useful. I've had situations in some of my homes where I wanted something faster than WiFi, cable was messy, trunking/channeling was impractical. What if you could bridge those gaps with a pair of LED trancievers, the sensors focussed on the array of transmitters using a lens?
Emacs has had a built in web browser for almost as long as there has been a web to browse.
The first web browsers were console mode, including Tim Berners Lee's WorldWideWeb. Lynx was the primary text-mode browser for years, and if the/. webmasters have been behaving themselves, and kept proper fallbacks for non-JS browsers, you should still be able to use it for/. today.
I am not an Emacs user, but I can recite the Emacs user's response to all of this.
Emacs takes a long time to start up - but once it's running, you don't close it for ages.
Emacs *does* embrace the UNIX methodology of running lots of small applications together -- but Emacs is the host for all these small programs. Let Emacs be your shell - and from there spawn all the seds, greps and sorts you want.
On my year out from university in the early 90s, I worked for a big IT multinational. We didn't have direct internet access from the office. To reach my university's newsgroups, I had to telnet across the Atlantic to a gateway machine, log into that, then from there telnet back across the Atlantic to a university server, and run the tin newsreader there. There was a minimum lag of a couple of seconds, and every few minutes there would be a lag of 20 seconds or more, during which all my keypresses would buffer up.
That's where I learned vi, probably to a higher standard than I've retained. Under those circumstances vi cursor movement is a real boon. You do not want to hit the arrow button 20 times to move 20 characters. You want to type '20', or '3w' to move 3 words, etc.
On about three occasions I've sat down to do an Emacs tutorial, but it never makes sense. I forget which key is "Meta" and which is "Ctrl"; I forget the long command names; I give up and return to the safety of vi. There's always been `screen` for running multiple shells in a terminal.
I don't tell other people what editor to use. I've just never wrapped my head around Emacs, while Vi made sense pretty much straight away.
My Samsung S2 (so, last gen) has a video editing app as standard.
It's pretty basic - string together a series of videos or stills from the gallery - stuff you've filmed on your phone, or imported in - add transition effects and a soundtrack - tell it to render then upload it to YouTube. But it works. It's more intuitive than iMovie; it would be fine for the video equivalent of the holiday photo album.
Closed-source abandonware can't be rescued. Sure, you can keep hold of binaries, but it'll never see another bug fix or new feature. It'll never get ported to another OS. If a change to the OS breaks it, it'll stay broken -- short of editing the binary, which is a fairly rare skill.
Open source abandonware can be rescued. If a bug needs fixing, or you want a feature, you can make it happen -- either by hacking at it yourself, or by paying someone else to do it for you.
Yep. We knew Y2K was coming. We tested stuff. We fixed stuff. We got double-time for being on-call instead of partying like it's 1999. And because of all of that, it went smoothly.
The same thing will happen here. All it needs is for management to put people on the tasks.
the BIG PROBLEM which is a good 90%+ of the games are built around DirectX
I find it very hard to believe that any serious developer codes directly to DirectX. Anyone with any kind of foresight has half an eye on portability. If Linux isn't on their radar, PS3 and Wii are, or Android, or Mac, or [insert future platform].
So you put in an indirection layer. Basic software engineering. That's how the big boys release on all the consoles simultaneously. That's how the indie developers have Linux, PC and Mac ports.
A sensibly architected game will be pretty easy to port to Steam for Linux. Even if it's been coded directly for Windows, a developer can make something stable with Winelib and perhaps some code tweaks.
There's a chicken and egg situation, and it may take some time to get going. I can see it building like this:
1. A few thousand gamers switch to Linux
2. The few games available on Linux sell well to that captive audience
3. A few dozen developers notice the captive audience, and realise that the small effort of making a Linux port will result in enough sales to make it worthwhile.
4. The Linux game catalogue grows, and a few tens of thousands of gamers are motivated to switch
5. Feedback loop continues until almost all developers make a Linux build as a matter of course.
Slashdot Mirror
Robert Broglia's popular series of emulators for Android all support using a Wii controller -- or a Wii Classic Controller -- because they're just Bluetooth devices and the pairing is straightforward.
Yes, I was probably a little bit imprecise. Film and digital sensors give more shades than the human eye can distinguish *within the range available on the display technology*. That is, if zero is between the blackest ink we have, and n is the whitest paper, we can print two different shades between 0 and n which can't be distinguished by a human. But start looking at the darkest darkness, or the brightest light, and sure, neither film nor digital can compete.
But our blackest ink isn't black and our whitest paper isn't white, so we have to do tone-mapping.
Also, although the human eye can handle all these shades, it can't do it without adjusting, and that takes time.
?So what's the point of trying to capture, process, and project brightness values greater than our eyes+brain can process? Was there any point in going past 15 or 16-bit colour?
For the first two, so that we can make artistic decisions in remapping to the smaller range we can project.
I know a little bit about it, and even I'm not going anywhere near it, what is going to change that makes regular Joe give up his known and easily understandable concept of cash for some magic complicated fairy dust that you need a math education to figure out if it's a scam or not?
Just because Regular Joe can't find a use for it, doesn't mean it's of no use to anyone. Already drug dealers and their customers have found it useful. Whether you and I find that morally offensive or not, it's still a practical use. I can well imagine people in third-world countries and oppressive regimes using it to transfer money abroad in circumstances where mainstream methods are too expensive or forbidden by the authorities.
The dynamic range of consumer digital cameras exceeds that of the human eye -- that is an area we see as uniform black, or uniform white, will contain detail we can't see.
The dynamic range of film - especially black & white film - is much wider still. That's why digital still photographers feel the need to achieve "HDR" (high dynamic range) by superimposing multiple shots at different exposures.
But what's the point of capturing a dynamic range that the human eye can't perceive? Well, you can bring it back into the human range in post-processing. The digital HDR folks use algorithmic processing to exaggerate edges, and bring out detail that the eye couldn't otherwise see. In the darkroom, a film photographer can choose which parts of the image to bring out.
Imagine a film negative of a photo taken from the outside of a cave on a sunny day. The dynamic range of negative film is so high that the picture can contain detail of rock shapes in the dark cave, *and* the sunlit vegetation outside. When printing in the darkroom, you can either expose it so that the detail in the dark cave is clear (and the outside is bleached out), or so the detail in the lit outside is clear (and the cave interior is black). Or, being creative, you can cast shadows while exposing the paper, to even things out and get detail in both.
For the final product, modern digital is always fine. CD audio is fine. Blu-Ray is fine. Digital cinema formats are fine. You only want higher dynamic range than that so that you have a bigger capture space to select from. Compare it with resolution. You don't need 15MP captures if you're only going to print 5x4 images -- until you decide you want to crop small parts of the image to print at that size.
The middle class will suffer too. If you currently live in a coastal city, you're going to have to either move (expensive) or fund flood defences (expensive).
OK, to some extent I'm just stating RMS's position, not my own here. I do use non-free software, and I don't sweat too much about it.
However, I do get frustrated when software goes wrong -- or could just benefit from minor new features -- and I can't do anything about it.
I do, actually, expect to be able to repair a toaster. Fortunately most toasters (assuming a simple toaster that's not microprocessor controlled) are simple enough that you don't *need* a circuit diagram -- you can just look at the circuit itself. There is no "compiler" which (as a side effect of its primary function) obfuscates the design. I suppose that's analogous to software written in a non-compiled language.
You might be upset (or maybe you've got used to it!) if a toaster manufacturer went out of their way to make the toaster non-user-serviceable, so you had to go to the manufacturer for repairs, rather than get your own soldering iron out, or going to an independent electrical repair shop. I gather petrol-heads are have been hit by this issue recently -- and have sought legislation to prevent it.
You say RMS prefers free to good. Personally I'll take good over free any day.
I'm not sure whether you're missing the difference between libre and gratis, or whether you just don't value freedom.
Compare what you said with "at least when Mussolini was in charge, the trains ran on time".
a bit of a Palestinian about it.
-1 Flamebait
... and Hans Reiser murdered his wife, but that's quite orthogonal to the quality of his code, and by all accounts ReiserFS is an excellent piece of work.
I too abhor ESR's gun nut, extreme libertarian views. But The Cathedral And The Bazaar was an insightful piece that really did launch a valuable movement. Fetchmail isn't a major achievement, but it's stable and useful, and no doubt a better product for ESR's community-driving than it would have been if he'd coded it all alone.
And don't lump ESR and RMS together - RMS is driven by principle, ESR is driven by pragmatism. RMS believes it's better to use bad software than non-free software. ESR believes open source leads to processes that produce high quality software.
Linus, I think, is on the pragmatic side, and not married to the GPL. I don't think he put a great deal of thought into choosing the license for Linux -- he wanted to share it, he had no intention of it being more than a hobbyist thing, at first. By the time Linux proved to be a potential big deal, there were so many contributors, that getting permission from all of them to alter the license would be all-but-impossible. Note that Linus chose to adopt the proprietary BitKeeper SCM system, before he wrote Git; Git is GPL - so he must be happy with that license for his own work.
Some people can make $2500 worth of sculpture out of $20 worth of clay. That in itself doesn't make the raw materials worth valuable.
I'm pretty sure there was a story somewhere about an "escort agency" accepting bitcoins, and I find it entirely plausible. They're easy to accept. They can be exchanged for "real" currency.
In the demo of Ubuntu for phones, a Samsung S3 is running Android and Ubuntu *at the same time*.
I don't know whether Android is hosting Ubuntu, or Ubuntu is hosting Android, or some third piece of software is hosting both. But the end result is that you plug your phone into an HDMI monitor, operate an Ubuntu desktop on the monitor using a bluetooth keyboard/mouse, and use Android on the handset at the same time. The Ubuntu stuff had hooks into Android so there were desktop apps that interacted with your Android contacts etc.
Fairly neat. I got the impression that it wasn't all as open-source as I'd like it to be -- ain't that the Android way?
Shouldn't jump back in such scenario. Progress bars display percentage of _work_ done, not of time remaining.
It could still go backwards, because you often only have an estimate of work to be done.
To put it in the real world, let's say I'm a menial office worker, and I've been given the task of filing the contents of 10 shoe boxes full of correspondence. I open the first box, it's got about 20 letters in it. After I've filed 10 letters, I tell my boss I'm 5% done - 10 letters out of an estimated 200.
The next 8 boxes also contain 20 letters, on average, so at the end of the 9th box, I tell my boss I'm 90% done.
Then I open the 10th box, and it's got 180 letters in it. So I tell my boss "Yeah, sorry about this, it turns out there were more letters than I thought; actually I'm only 50% done".
Now, in this scenario, if my boss really wanted accurate progress reports, I should have peeked in all the boxes before starting, to make a better estimate of the work to be done. But that's not always possible.
... which is great if it's cold outside and you want to heat your room.
It's not so great if it's warm outside and you'd like your room to be cooler.
I suppose it depends what you mean by "useful distance". I can imagine situations in homes or small offices where line-of-sight over quite short distances would be useful. I've had situations in some of my homes where I wanted something faster than WiFi, cable was messy, trunking/channeling was impractical. What if you could bridge those gaps with a pair of LED trancievers, the sensors focussed on the array of transmitters using a lens?
(a bit like Morse Code from a torch)
Thanks for the clarification, News for Nerds.
Emacs has had a built in web browser for almost as long as there has been a web to browse.
The first web browsers were console mode, including Tim Berners Lee's WorldWideWeb. Lynx was the primary text-mode browser for years, and if the /. webmasters have been behaving themselves, and kept proper fallbacks for non-JS browsers, you should still be able to use it for /. today.
I am not an Emacs user, but I can recite the Emacs user's response to all of this.
Emacs takes a long time to start up - but once it's running, you don't close it for ages.
Emacs *does* embrace the UNIX methodology of running lots of small applications together -- but Emacs is the host for all these small programs. Let Emacs be your shell - and from there spawn all the seds, greps and sorts you want.
(But I use Vim)
Aha, you want terminal war stories.
On my year out from university in the early 90s, I worked for a big IT multinational. We didn't have direct internet access from the office. To reach my university's newsgroups, I had to telnet across the Atlantic to a gateway machine, log into that, then from there telnet back across the Atlantic to a university server, and run the tin newsreader there. There was a minimum lag of a couple of seconds, and every few minutes there would be a lag of 20 seconds or more, during which all my keypresses would buffer up.
That's where I learned vi, probably to a higher standard than I've retained. Under those circumstances vi cursor movement is a real boon. You do not want to hit the arrow button 20 times to move 20 characters. You want to type '20', or '3w' to move 3 words, etc.
On about three occasions I've sat down to do an Emacs tutorial, but it never makes sense. I forget which key is "Meta" and which is "Ctrl"; I forget the long command names; I give up and return to the safety of vi. There's always been `screen` for running multiple shells in a terminal.
I don't tell other people what editor to use. I've just never wrapped my head around Emacs, while Vi made sense pretty much straight away.
Is this serious? Its a fscking editor for gods sake. Is there a "vi community"?
Emacs is an operating system, that just happens that the text editor is its highest profile app. M-x tetris loads another one.
I never grokked Emacs. Perhaps if I'd joined the community?
You want to edit A/V stuff... on a cell phone?
My Samsung S2 (so, last gen) has a video editing app as standard.
It's pretty basic - string together a series of videos or stills from the gallery - stuff you've filmed on your phone, or imported in - add transition effects and a soundtrack - tell it to render then upload it to YouTube. But it works. It's more intuitive than iMovie; it would be fine for the video equivalent of the holiday photo album.
Closed-source abandonware can't be rescued. Sure, you can keep hold of binaries, but it'll never see another bug fix or new feature. It'll never get ported to another OS. If a change to the OS breaks it, it'll stay broken -- short of editing the binary, which is a fairly rare skill.
Open source abandonware can be rescued. If a bug needs fixing, or you want a feature, you can make it happen -- either by hacking at it yourself, or by paying someone else to do it for you.
Yep. We knew Y2K was coming. We tested stuff. We fixed stuff. We got double-time for being on-call instead of partying like it's 1999. And because of all of that, it went smoothly.
The same thing will happen here. All it needs is for management to put people on the tasks.
the BIG PROBLEM which is a good 90%+ of the games are built around DirectX
I find it very hard to believe that any serious developer codes directly to DirectX. Anyone with any kind of foresight has half an eye on portability. If Linux isn't on their radar, PS3 and Wii are, or Android, or Mac, or [insert future platform].
So you put in an indirection layer. Basic software engineering. That's how the big boys release on all the consoles simultaneously. That's how the indie developers have Linux, PC and Mac ports.
A sensibly architected game will be pretty easy to port to Steam for Linux. Even if it's been coded directly for Windows, a developer can make something stable with Winelib and perhaps some code tweaks.
There's a chicken and egg situation, and it may take some time to get going. I can see it building like this:
1. A few thousand gamers switch to Linux
2. The few games available on Linux sell well to that captive audience
3. A few dozen developers notice the captive audience, and realise that the small effort of making a Linux port will result in enough sales to make it worthwhile.
4. The Linux game catalogue grows, and a few tens of thousands of gamers are motivated to switch
5. Feedback loop continues until almost all developers make a Linux build as a matter of course.
Bluetooth keyboard (although Scratch hardly needs any typing)