The upshot is that I wrote a transcoding filesystem to convert FLAC to AIFF (with art and tags intact) which iTunes understands and will then further transcode to AAC. The filesystem is here: http://www.mcternan.me.uk/aifffffs/
I think they have a point here. For example, the PS3 has a load of services which are in the cloud, such as film rental and downloads as well as game downloads. A HD film or some games seem to be around 7GB to download, but my ISP caps at 20GB per month with £5 for an extra 5GB over that limit (£1 per GB, grrr!!). So basically these PS3 services have to be used with care, otherwise the cost of renting a film is suddenly a lot more than you pay at the Playstation Store.
The really stupid thing is that the ISP doesn't count usage between midnight and 8am, but the PS3 can't be set to schedule downloads in these 'off hours' unless you subscribe to Playstation Plus for an extra £40 a year.
As a result I don't use the Playstation Store for much, and well, haven't used it at all since they lost all the credit card details anyway!
If your extension doesn't work with 3.6, edit your install.rdf file and change the MaxVersion to 3.6 (or wildcard)
Nah. Just install the Add-on Compatibility Reporter plugin and help the beta effort. This add-on lets others run irrespective of the version, but then you can also rate the compatibility of all plugins and indicate if they work or not.
I actually saw one of their demonstrations and it was cool. The pad was just a slightly thick mousepad like device, and you could put multiple phones of different types on it at the same time and at any orientation. They had modified battery modules to contain their own chip which did the inductive pick up and regulation. They said their goal was to get the chip built into devices by default, although unless the chip was very cheap, I suspect this would have been difficult to include in cost sensitive mobile phones and iPods.
The book describes using some large lego wheels to form a drum around which the paper was attached, and how to form a small electro magnet around a bolt through a technic lego plate to pull the pen towards the drum. The pen itself was suspended between two lego axles on a butterfly pin. The whole magnet head assembly could pinion left and right using an improvised lego rotary counter to measure progress with a similar block to rotate the drum.
I had the Sinclair Spectrum version of the book as a child and an IO box of relays. I never made the printer, but made lots of other devices.
smart enough to make these idiot companies with closed-source encryption
It's often overlooked that GSM development started in 1982. At that time computing power was a fraction of what it is now and DSPs, rather than dedicated logic used in today's chipsets, would be used for the first implementations of this new technology. Mobile phones are also very power sensitive devices - battery life is very important.
So given these pressures, some corners had to be cut to make the system workable on the available technology. This lead to the A5 algorithms being both proprietary and somewhat lightweight given the limited computing resources in a mobile phone. Due to the huge success of GSM and the number of handsets out there, it rapidly becomes very difficult to change the standard in such a fundamental manner. 3G is one attempt to upgrade the GSM standards and brings in new ciphers based upon an existing published standard, but even that has taken a long time to get traction and GSM is still very widely available.
So to say these companies are idiots is somewhat ignorant of the historical practicalities required to make GSM a success.
Skipping that number signifies that the planned release has changed form. Avoiding use of that number then neatly avoids confusion about what the new planned releases will contain since Firefox 3.7 already has an attached meaning. It also allows retrospective discussion of what was planned for 3.7; useful if the roadmap is being updated.
If you don't have a published roadmap with promised features, keeping the next release as n + 1 is no problem.
"The power monitor continuously tracks the die temperature. If the temperature reaches the maximum allowed value, a throttle mechanism is initiated. A multi-level tracking algorithm is implemented. Throttling starts with the more efficient dynamic voltage scaling policy and if not sufficient, the power monitor algorithm continues lowering the frequency. If an extreme cooling malfunction occurs, an Out of Spec notification will be initiated, requesting controlled shutdown. Lastly, the CPU can initiate a thermal shutdown and turn off the system."
I'd guess the thermal shutdown cannot be configured by software and would prevent any damage if the other mechanisms were either ineffective or somehow disabled by software.
Making schedulers runtime pluggable would make it really easy to get other people hacking on the Linux scheduler though.
For example, you could lash up a reusable test harness to allow scheduler testing under well defined and repeatable scenarios. This may then allow more direct comparison between schedulers hopefully leading to a best of breed race. Making it runtime un/loadable would also speed up the development cycle for the scheduler much in the same way that loadable modules can often be more rapidly debugged and fixed by not needing a reboot for each change.
You could even go crazy and make a scheduler plug in 'shim' just for the purpose of profiling different implementations under real workloads.
The only thing I would say is that the whole scheduler API should be made in such a way that the scheduler is undeniably covered by the GPL. Binary blob schedulers would be the worst possible outcome and would go against the thought of trying to open up the scheduler as a means of furthering development and healthy competition.
> and of course, having a filesystem and a special MTD driver for > *every single SSD drive manufactured* when they change flash > chips or tweak the controller, could get unwieldy.
Large numbers of flash chips can be supported by the MTD CFI drivers:
Yeah, well Via's driver support for Linux is horrible, while the Intel Atom stuff just works perfectly with Ubuntu out of the box. That may have something to do with why Intel is preferred.
Shame the TCP/IP stack isn't on the microcontroller. Putting uIP on there, or grabbing bits from my stack (http://www.mcternan.co.uk/MAD/) would be awesome.
1) Process-per-tab. It sucks when some JS in some tab gets hung up, bringing everything else in the browser to its knees!
I don't see this as a good thing. Really it's just a workaround for buggy code elsewhere, limiting the scope of damage to a single tab at the expense of using lots more system resources. Instead the JS interpreter or whatever bad behaving code should be fixed so that the browser as a whole is more stable without needing the extra overhead.
The exception to this is of course closed source plugins (Acrobat, I'm looking at you) where the quality if controlled by someone else. These should be in an isolated process and partitioned off as much as possible, killing just the plugin area not the tab if a fault occurs, although that maybe technically difficult to fully achieve without changing the plugin APIs.
I'm not a fan of Microsoft bashing, but it really comes as no surprise that they added this feature to IE8. They don't have a reputation for small and lightweight apps (Vista's much bemoaned bloat being a recent example), and Explorer has had the "launch folder windows in a separate process" option for a long time (which you'll note WinPro recommend enabling for stability, disabling for performance). Given they felt explorer needed this functionality when it's mainly running their own code, I can see how they would think to add it for something taking wild and varied input from the web.
I really hope Mozilla don't feel compelled to add process-per-tab just because some other browsers use this, and if they do add it, that it can be disabled.
I think this now brings the total drivers for the Chrome chipset to 4. There's already:
- Via proprietary binary drivers (support some 3D acceleration and TVout, but only available for specific distro/kernel combinations) - Unichrome drivers (focus on code quality rather than features, so no 3D accel and TVout) - Openchrome drivers (used in most distros, support some of the features, but imperfect and seem not to support Compiz) - The new Via FOSS drivers (2D only at present)
Why couldn't VIA just contribute to one of the existing projects or send them docs and maybe funding? That would have been truely embracing open source.
I'd be interested to know if Via tried to contact any of the uni/openchrome developers.
Yeah - your choice to run old and possibly insecure software, catch some crapware and fill the Interweb with spam and other junk.
While it is your computer, it isn't your Internet. Since Firefox is primarily designed to be connected to the web, it makes sense for Mozilla to promote good behaviour among netizens.
Hmm, you could be right, not sure. I was thinking of 3GPP 21.111, section 9 "Electrical characteristics and transmission protocols":
"Electronic signals and transmission protocols shall be in accordance with the specifications in TS 31.101. The electrical specifications shall at least cover the 1.8V and 3V voltage ranges as specified in GSM 11.12 [9] and GSM 11.18 [10]. Lower voltages may be added in the future. 3G terminals shall not support 5V on the ME-UICC interface."
For GSM R99, 5V is specified, but that is quite old. For 3G, looks like terminals are required not to support 5V SIMs, so I'd expect lower voltage only SIMs to follow suit. I could be completely wrong though!
Mike PS: I was joking about the soldering - if that's really you, thanks for making the video; I liked it.
Well they did brute force the secret key (Ki) from their SIM using the reader they build, but as they said, newer SIMs will detect the high number of requests and self-destruct. Additionally this was a 5V SIM reader, and many modern SIMs are 3V in anycase.
The only thing that worried me in the video was the quality of the soldering!
Slashdot Mirror
Well, it's a compiler extension, but GCC supplies the __cleanup__ attribute which essentially allows arbitrary destructor functions in C.
Mastery of the language is one thing, mastery of the tools another...
These are the lengths I went to to get FLAC onto my iPod: http://www.mcternan.me.uk/cdcollection/
The upshot is that I wrote a transcoding filesystem to convert FLAC to AIFF (with art and tags intact) which iTunes understands and will then further transcode to AAC. The filesystem is here: http://www.mcternan.me.uk/aifffffs/
I think they have a point here. For example, the PS3 has a load of services which are in the cloud, such as film rental and downloads as well as game downloads. A HD film or some games seem to be around 7GB to download, but my ISP caps at 20GB per month with £5 for an extra 5GB over that limit (£1 per GB, grrr!!). So basically these PS3 services have to be used with care, otherwise the cost of renting a film is suddenly a lot more than you pay at the Playstation Store.
The really stupid thing is that the ISP doesn't count usage between midnight and 8am, but the PS3 can't be set to schedule downloads in these 'off hours' unless you subscribe to Playstation Plus for an extra £40 a year.
As a result I don't use the Playstation Store for much, and well, haven't used it at all since they lost all the credit card details anyway!
Nah. Just install the Add-on Compatibility Reporter plugin and help the beta effort. This add-on lets others run irrespective of the version, but then you can also rate the compatibility of all plugins and indicate if they work or not.
Splashpower started in 2001: http://en.wikipedia.org/wiki/Splashpower
I actually saw one of their demonstrations and it was cool. The pad was just a slightly thick mousepad like device, and you could put multiple phones of different types on it at the same time and at any orientation. They had modified battery modules to contain their own chip which did the inductive pick up and regulation. They said their goal was to get the chip built into devices by default, although unless the chip was very cheap, I suspect this would have been difficult to include in cost sensitive mobile phones and iPods.
There's a similar lego plotter in this book: http://www.clarkonline.org/william/mapyor/index.html
The book describes using some large lego wheels to form a drum around which the paper was attached, and how to form a small electro magnet around a bolt through a technic lego plate to pull the pen towards the drum. The pen itself was suspended between two lego axles on a butterfly pin. The whole magnet head assembly could pinion left and right using an improvised lego rotary counter to measure progress with a similar block to rotate the drum.
I had the Sinclair Spectrum version of the book as a child and an IO box of relays. I never made the printer, but made lots of other devices.
There's some inside pictures of the book here: http://www.hexapodrobot.com/forum/viewtopic.php?f=35&t=318
A PDF of the book is here: http://www.worldofspectrum.org/infoseekid.cgi?id=2000479
It's often overlooked that GSM development started in 1982. At that time computing power was a fraction of what it is now and DSPs, rather than dedicated logic used in today's chipsets, would be used for the first implementations of this new technology. Mobile phones are also very power sensitive devices - battery life is very important.
So given these pressures, some corners had to be cut to make the system workable on the available technology. This lead to the A5 algorithms being both proprietary and somewhat lightweight given the limited computing resources in a mobile phone. Due to the huge success of GSM and the number of handsets out there, it rapidly becomes very difficult to change the standard in such a fundamental manner. 3G is one attempt to upgrade the GSM standards and brings in new ciphers based upon an existing published standard, but even that has taken a long time to get traction and GSM is still very widely available.
So to say these companies are idiots is somewhat ignorant of the historical practicalities required to make GSM a success.
Doesn't Chromium use GTK?
3.7 stands for a feature set on the Firefox roadmap.
Skipping that number signifies that the planned release has changed form. Avoiding use of that number then neatly avoids confusion about what the new planned releases will contain since Firefox 3.7 already has an attached meaning. It also allows retrospective discussion of what was planned for 3.7; useful if the roadmap is being updated.
If you don't have a published roadmap with promised features, keeping the next release as n + 1 is no problem.
Yeah - I'd be surprise if you could damage the CPU in the way described in the original post.
There's a bunch about thermal monitoring and control from Intel here:
http://www.intel.com/technology/itj/2006/volume10issue02/art01_intro_to_core_duo/p06_thermal_design_point.htm
The relevant bit is:
"The power monitor continuously tracks the die temperature. If the temperature reaches the maximum allowed value, a throttle mechanism is initiated. A multi-level tracking algorithm is implemented. Throttling starts with the more efficient dynamic voltage scaling policy and if not sufficient, the power monitor algorithm continues lowering the frequency. If an extreme cooling malfunction occurs, an Out of Spec notification will be initiated, requesting controlled shutdown. Lastly, the CPU can initiate a thermal shutdown and turn off the system."
I'd guess the thermal shutdown cannot be configured by software and would prevent any damage if the other mechanisms were either ineffective or somehow disabled by software.
Making schedulers runtime pluggable would make it really easy to get other people hacking on the Linux scheduler though.
For example, you could lash up a reusable test harness to allow scheduler testing under well defined and repeatable scenarios. This may then allow more direct comparison between schedulers hopefully leading to a best of breed race. Making it runtime un/loadable would also speed up the development cycle for the scheduler much in the same way that loadable modules can often be more rapidly debugged and fixed by not needing a reboot for each change.
You could even go crazy and make a scheduler plug in 'shim' just for the purpose of profiling different implementations under real workloads.
The only thing I would say is that the whole scheduler API should be made in such a way that the scheduler is undeniably covered by the GPL. Binary blob schedulers would be the worst possible outcome and would go against the thought of trying to open up the scheduler as a means of furthering development and healthy competition.
Lots and lots.
I find Java a lot of fun.
Mozy is good - it's offsite backup with nice shell integration. Sadly it's Windows only though :(
They probably worked out the costs if they sold >1M. They sold 100k, so never reached those economies of scale.
That's a shame, but at least they were thinking big. If they started out planning to sell 100k, they wouldn't have bothered.
I wish them luck in what they do next. Pleo is still unique.
> and of course, having a filesystem and a special MTD driver for
> *every single SSD drive manufactured* when they change flash
> chips or tweak the controller, could get unwieldy.
Large numbers of flash chips can be supported by the MTD CFI drivers:
http://en.wikipedia.org/wiki/Common_Flash_Memory_Interface
Something similar could be done for SSDs too, except they've chosen HDD standards as they are a better fit.
Mike
Yeah, well Via's driver support for Linux is horrible, while the Intel Atom stuff just works perfectly with Ubuntu out of the box. That may have something to do with why Intel is preferred.
Shame the TCP/IP stack isn't on the microcontroller. Putting uIP on there, or grabbing bits from my stack (http://www.mcternan.co.uk/MAD/) would be awesome.
> Chrome seemed to take a second to open just one tab, let alone 15.
I think some of that maybe the price you pay for process-per-tab.
Here's a link to my lightbulb on the internet: http://mcternan.co.uk/MAD/
It's an ambient device, and while only IPv4, but it does run on a lovely ATmega168 and support DHCP, AutoIP, NMNS and has a HTTP tiny client.
I don't see this as a good thing. Really it's just a workaround for buggy code elsewhere, limiting the scope of damage to a single tab at the expense of using lots more system resources. Instead the JS interpreter or whatever bad behaving code should be fixed so that the browser as a whole is more stable without needing the extra overhead.
The exception to this is of course closed source plugins (Acrobat, I'm looking at you) where the quality if controlled by someone else. These should be in an isolated process and partitioned off as much as possible, killing just the plugin area not the tab if a fault occurs, although that maybe technically difficult to fully achieve without changing the plugin APIs.
I'm not a fan of Microsoft bashing, but it really comes as no surprise that they added this feature to IE8. They don't have a reputation for small and lightweight apps (Vista's much bemoaned bloat being a recent example), and Explorer has had the "launch folder windows in a separate process" option for a long time (which you'll note WinPro recommend enabling for stability, disabling for performance). Given they felt explorer needed this functionality when it's mainly running their own code, I can see how they would think to add it for something taking wild and varied input from the web.
I really hope Mozilla don't feel compelled to add process-per-tab just because some other browsers use this, and if they do add it, that it can be disabled.
I think this now brings the total drivers for the Chrome chipset to 4. There's already:
- Via proprietary binary drivers (support some 3D acceleration and TVout, but only available for specific distro/kernel combinations)
- Unichrome drivers (focus on code quality rather than features, so no 3D accel and TVout)
- Openchrome drivers (used in most distros, support some of the features, but imperfect and seem not to support Compiz)
- The new Via FOSS drivers (2D only at present)
Why couldn't VIA just contribute to one of the existing projects or send them docs and maybe funding? That would have been truely embracing open source.
I'd be interested to know if Via tried to contact any of the uni/openchrome developers.
Yeah - your choice to run old and possibly insecure software, catch some crapware and fill the Interweb with spam and other junk.
While it is your computer, it isn't your Internet. Since Firefox is primarily designed to be connected to the web, it makes sense for Mozilla to promote good behaviour among netizens.
You should upgrade or unplug.
Hmm, you could be right, not sure. I was thinking of 3GPP 21.111, section 9 "Electrical characteristics and transmission protocols":
"Electronic signals and transmission protocols shall be in accordance with the specifications in TS 31.101.
The electrical specifications shall at least cover the 1.8V and 3V voltage ranges as specified in GSM 11.12 [9] and GSM 11.18 [10]. Lower voltages may be added in the future. 3G terminals shall not support 5V on the ME-UICC interface."
Linky: http://www.3gpp.org/ftp/Specs/latest/Rel-6/21_series/21111-630.zip
For GSM R99, 5V is specified, but that is quite old. For 3G, looks like terminals are required not to support 5V SIMs, so I'd expect lower voltage only SIMs to follow suit. I could be completely wrong though!
Mike
PS: I was joking about the soldering - if that's really you, thanks for making the video; I liked it.
Well they did brute force the secret key (Ki) from their SIM using the reader they build, but as they said, newer SIMs will detect the high number of requests and self-destruct. Additionally this was a 5V SIM reader, and many modern SIMs are 3V in anycase.
The only thing that worried me in the video was the quality of the soldering!
Mike