Well, Vegemite is just a rip off of the Brit original... Marmite. And if any of you know any Brits, you'll know Marmite is a national institution. Although even the company that makes it admits it's a love it of hate it thing with Marmite, not one is ever indifferent to it!
I visited a Brazilian friend a few years ago, and she had heard of it and asked me to bring a pot of 'this very British thing'. The first thing she said to me was 'You really eat this stuff?!'. She was almost ill:)
Someone mentioned in the thread that that reason OLED/LEP tech uses less juice than LCD is because only the pixels that need to be lit are lit, instead of lighting them all and then limiting the escape of that light.
And the problems with colour OLED/LEP that has taken time to overcome have been the lifespan of the blue pixels. Monochrome OLED screens have been around for ages, and are probably ready for production now.
So... How about a hybrid? Use a normal LCD layer with it's chromic filters, and a pixel array made of 3:1 rectangular pixels in RGB groups just like any other LED display. Then replace the backlight with the monochrome OLED, which has pixels that are square, 3 times the size of the pixels in the LCD layer and 'fit' behind a whole RGB group on the LCD layer.
Then the incoming video signal is split into a 'chroma' and 'luma' signal. The 'luma' signal is derived per pixel from MAX (R,G,B), and is sent to the OLED layer. The chroma signal is processed so that the intensity values are scaled per pixel, so that the largest value in the RGB group is 100%, and this is then sent to the LCD layer. The LCD is now only setting the relative intensity of the 3 colours, not the absolute intensity, and black pixels (for instance) are not lit at all.
You then get some of the power saving of OLED, without the display slowly going more and more yellow in tint (think what happens if the blue output falls off faster than the red and green....). Plus, if you configure the LCD layer to pass light when it's not charged, if you get a pixel going 'dead', it just becomes monochrome.
Sony and TiVo have entered into a deal that will allow Sony to integrate (and even modify) TiVo's software and services into their entertainment products.
Anyone thought the work to port Linux onto US and European region PS2s could be in preparation to run Tivo Software on your PS2? Supposedly, FireWire is emerging as the defacto standard for sending digital video signals from digital tuners (terrestrial, cable or satelite) to other h/w (Your new TV set, or D-VHS, or in future DVD-RAM). PS2 is ready to take an MPEG feed, and the Hard Disk is on the way....
If anyone would like to see what Musgrave and Mandelbrot were up to in the late 70's/early 80's with all this stuff (and yes, that makes Musgrave the 'daddy' of fractal landscapes! Loren Carpenter, eat ya heart out:^), you should check out the book they contributed to:
The Science of Fractal Images, edited by Heinz Otto Peitgen.
This book can be considered 'Fractals 101', and when I was doing a fractal related final year university project about 8 years ago, it came it VERY handy:)
However, the images on Musgrave's website don't look much better than the colour plates in that book, so other peoples comments, like 'Big Deal' etc, do hold. I was expecting him to have at least produced better looking images than my team at Uni did:^)
But whatever, the guy still gets major respect from me, he is a true computing pioneer.
Many people have already mentioned NeXT/Open/GnuStep, and OpenDoc as fine examples of 'the right way' to do things, and Open Source developers are in a unique position that they are not (usually) hamstrung from shareholders demanding profits, marketoids or backwards compatability that tends to stop 'the right way' from being developed elsewhere.
But one comment struck me, because I have had thoughts on this point for a while:
> There's no GUI equivalent to the command-line pipe/redirect paradigm
To me, this is one of the most elegant things about how Unix works for the user, even if the command line switches make things very cryptic for 'Joe Schmoe'.
The reason it all hangs together it that all the CLI tools use PLAIN TEXT for input and output, and these text streams are not contaminated by error reporting. Plain text is a very simple data format, and therefore the tools are small and simple. The GoodEasy environment detailed on Wired and mentioned on/. a few days ago runs with this idea in a GUI setting.
But the way it does this is to throw away WYSIWYG, on the assumption that 'what you get' only refers to 'when you hit the print button', and in an increasingly paperless world, there's no need for 'rich media'.
But I like rich media, and I bet a lot of you do too. I think HTML email allows for far more expressive messages, and therefore better communication.
So how do we get this 'plug in' idea of tools to work? Well, my thought is a kind of 'live import/export filter'. If you think of possibly the most complex doc type there is, DTP, it has many layers of structure. Chapters, pages, layout boxes, graphics, columns, paragraphs, fonts and formating, right down to the 'plain text'. What if you could 'live export' just the plain text? All a spellchecker needs is plain text, so the spellcheck component would hook into a 'live filter' component, that exposed just the plain text on the spellcheck side, but was exposed to the full DTP dataset on the other. The spellchecker replaces text in what it thinks is just plain text, and the filter passes the changes to the plain text components in the DTP data. Another filter could expose just the layout components of the DTP data to a drawing tool, and so on.
The base document type could change to be a spreadsheet, and a different 'live filter' would again export the plain text components to the very same spellchecker, and so you get code reuse, and consistancy of interface for the user.
Effectively, these filters give our complex rich media formats multiple personalities, they pretend to be a file format that they are not, so that common tools can be used to edit them.
Add this to the component document ideas started with OpenDoc and its 'part handlers', and continuing with Bonobo, and we could have a true 'Unix way' WYSIWYG productivity system.
Slashdot Mirror
Oneishy needs a headset? Sony Ericsson HBH-35 or HBH-60 (The first has better battery life and audio pickup, the second is smaller)
:)
Bluetooth Flip phone? Moto V600, Panasonic X70 or Sony Ericsson Z600 (that's assuming Verizon are using GSM, I wouldn't know, I'm a Brit).
Out of those 3, the Moto is the daddy
Andy
Well, Vegemite is just a rip off of the Brit original... Marmite. And if any of you know any Brits, you'll know Marmite is a national institution. Although even the company that makes it admits it's a love it of hate it thing with Marmite, not one is ever indifferent to it!
I visited a Brazilian friend a few years ago, and she had heard of it and asked me to bring a pot of 'this very British thing'. The first thing she said to me was 'You really eat this stuff?!'. She was almost ill :)
Someone mentioned in the thread that that reason OLED/LEP tech uses less juice than LCD is because only the pixels that need to be lit are lit, instead of lighting them all and then limiting the escape of that light.
And the problems with colour OLED/LEP that has taken time to overcome have been the lifespan of the blue pixels. Monochrome OLED screens have been around for ages, and are probably ready for production now.
So... How about a hybrid? Use a normal LCD layer with it's chromic filters, and a pixel array made of 3:1 rectangular pixels in RGB groups just like any other LED display. Then replace the backlight with the monochrome OLED, which has pixels that are square, 3 times the size of the pixels in the LCD layer and 'fit' behind a whole RGB group on the LCD layer.
Then the incoming video signal is split into a 'chroma' and 'luma' signal. The 'luma' signal is derived per pixel from MAX (R,G,B), and is sent to the OLED layer.
The chroma signal is processed so that the intensity values are scaled per pixel, so that the largest value in the RGB group is 100%, and this is then sent to the LCD layer. The LCD is now only setting the relative intensity of the 3 colours, not the absolute intensity, and black pixels (for instance) are not lit at all.
You then get some of the power saving of OLED, without the display slowly going more and more yellow in tint (think what happens if the blue output falls off faster than the red and green....). Plus, if you configure the LCD layer to pass light when it's not charged, if you get a pixel going 'dead', it just becomes monochrome.
Sony and TiVo have entered into a deal that will allow Sony to integrate (and even modify) TiVo's software and services into their entertainment products.
Anyone thought the work to port Linux onto US and European region PS2s could be in preparation to run Tivo Software on your PS2? Supposedly, FireWire is emerging as the defacto standard for sending digital video signals from digital tuners (terrestrial, cable or satelite) to other h/w (Your new TV set, or D-VHS, or in future DVD-RAM). PS2 is ready to take an MPEG feed, and the Hard Disk is on the way....
Any Thoughts? Andy.
If anyone would like to see what Musgrave and Mandelbrot were up to in the late 70's/early 80's with all this stuff (and yes, that makes Musgrave the 'daddy' of fractal landscapes! Loren Carpenter, eat ya heart out :^), you should check out the book they contributed to:
:)
:^)
The Science of Fractal Images, edited by Heinz Otto Peitgen.
This book can be considered 'Fractals 101', and when I was doing a fractal related final year university project about 8 years ago, it came it VERY handy
However, the images on Musgrave's website don't look much better than the colour plates in that book, so other peoples comments, like 'Big Deal' etc, do hold. I was expecting him to have at least produced better looking images than my team at Uni did
But whatever, the guy still gets major respect from me, he is a true computing pioneer.
Andy
Many people have already mentioned NeXT/Open/GnuStep, and OpenDoc as fine examples of 'the right way' to do things, and Open Source developers are in a unique position that they are not (usually) hamstrung from shareholders demanding profits, marketoids or backwards compatability that tends to stop 'the right way' from being developed elsewhere.
/. a few days ago runs with this idea in a GUI setting.
But one comment struck me, because I have had thoughts on this point for a while:
> There's no GUI equivalent to the command-line pipe/redirect paradigm
To me, this is one of the most elegant things about how Unix works for the user, even if the command line switches make things very cryptic for 'Joe Schmoe'.
The reason it all hangs together it that all the CLI tools use PLAIN TEXT for input and output, and these text streams are not contaminated by error reporting. Plain text is a very simple data format, and therefore the tools are small and simple. The GoodEasy environment detailed on Wired and mentioned on
But the way it does this is to throw away WYSIWYG, on the assumption that 'what you get' only refers to 'when you hit the print button', and in an increasingly paperless world, there's no need for 'rich media'.
But I like rich media, and I bet a lot of you do too. I think HTML email allows for far more expressive messages, and therefore better communication.
So how do we get this 'plug in' idea of tools to work? Well, my thought is a kind of 'live import/export filter'. If you think of possibly the most complex doc type there is, DTP, it has many layers of structure. Chapters, pages, layout boxes, graphics, columns, paragraphs, fonts and formating, right down to the 'plain text'. What if you could 'live export' just the plain text? All a spellchecker needs is plain text, so the spellcheck component would hook into a 'live filter' component, that exposed just the plain text on the spellcheck side, but was exposed to the full DTP dataset on the other. The spellchecker replaces text in what it thinks is just plain text, and the filter passes the changes to the plain text components in the DTP data. Another filter could expose just the layout components of the DTP data to a drawing tool, and so on.
The base document type could change to be a spreadsheet, and a different 'live filter' would again export the plain text components to the very same spellchecker, and so you get code reuse, and consistancy of interface for the user.
Effectively, these filters give our complex rich media formats multiple personalities, they pretend to be a file format that they are not, so that common tools can be used to edit them.
Add this to the component document ideas started with OpenDoc and its 'part handlers', and continuing with Bonobo, and we could have a true 'Unix way' WYSIWYG productivity system.
-- Andy the Webbunny