You're confused, CRT based television is by definition electronic. Mechanical scanning referred to the use of a large spinning disk instead of a CRT.
The electron beam in the CRT in 1930s era televisions was bent (or more correctly deflected) so that it scanned the screen building up a picture, in one of two ways. Electrostatic deflection or Electromagnetic deflection.
Electromagnetic deflection uses an electro-magnet built around the outside of the electron gun. Passing a varying current through the electro-magnet varies the magnetic field produced which bends the electronic beam.
Electrostatic deflection used X-Y plates within the electron gun, a varying voltage (not current) applied to the plates attracts or deflects the electron beam.
Initially electrostatic deflection was used (in first gen TVs of 1936), these CRTs had small deflection angles meaning the tubes had to be very long (and thus mounted vertically and watched in a mirror - giving the name mirror lid televisions).
Efforts to increase the deflection angle of CRTs (and thus make shorter tubes) led to the switch to electro-magnetic deflection by 1938.
Again a completely Ameri-centric viewpoint. High definition television in Great Britain (as opposed to Baird's mechanical system) was developed by EMI in the early 30s, in parallel and independently of Farnsworth or RCA (i.e. Zworykin). The EMI developed Emitron camera (patented 1932) and 405 line-system was used to start the worlds first high definition television service by the BBC in November 1936 (to the London area).
The incandescent light bulb was developed in parallel and independently on both sides of the Atlantic. Edison in the US and Joseph Swan in the UK, with Swan patenting in the UK first.
> The only thing I'm not sure how well unsquashfs handles the extraction of sparse files.
If the file is stored as a sparse file in the Squashfs filesystem (normally the case), then Unsquashfs will create it as a sparse file when extracting it. It doesn't need any more filesystem space than the filled parts of the file when doing so.
Try Squashfs which creates deduplicated and compressed filesystem archives (http://www.linux-mag.com/id/7357/ for a good journal article).
If you're using Ubuntu, Debian, Fedora Squashfs will be already built into your distro kernel, and the squashfs-tools will also already be available in your distro repository.
Oh wow, a little Englander on slashdot, I thought you'd all be at the Tory conference in Manchester.
I describe myself first as British, secondly as a (proud) European, and lastly and hardly ever as English, for all the negative connotations people like you have given it.
Britain is a European country, it has a proud history of involvement (for the better too) with the other countries in Europe, and it is a European culture.
Complete twaddle. Do you really think that these jobs are going to the hundreds of thousands of Indians surviving on less than a dollar a day? They'll be going to the rich English speaking Indian middle class who could afford to go to university. You never know, but, some of those American workers may have pulled themselves out of (American levels of) poverty by getting their IT qualifications and career. It's too easy to say America rich, India poor and therefore this always justifies outsourcing American jobs.
Mark Shuttleworth is effectively the user every free software developer wants, because he puts his money where his mouth is. Vision is one thing, being prepared to pay for it is better.
Besides someone's needless continuity breakage/stability disruption is often another's necessary innovation. Often I've been begged by some users to implement something which they badly need, but then got criticised by others for yet another incompatible version. You can't please everyone all of the time.
Innovation doesn't need to be the evil twin of stability, it unfortunately often feels that way in free software IMO due to lack of resources. I, for example, as a free software developer only have the time to support the latest (and 'greatest') version, and so all users are forced to use it whether or not they want the latest features. If I made enough money from the software to pay developers, I could support the last couple of versions or when adding features I could implement a backwards compatibility option. However, I can't do this.
Free software is still driven by developers working on what interests or concerns them.
If it is being developed in the developer's free time then this should be expected, The software is effectively a hobby which the developer enjoys and users benefit from. Innovation is enjoyable, maintenance isn't, and users if they aren't paying should expect this. If they want reliable long term maintenance (or any other "boring" issues) they should consider playing for support, like in any normal business relationship,
If I (as a spare-time software developer) gets asked to do something I'm not interested in, I may not refuse, but it gets placed at the end of a priority sorted list, and it can stay there for a long time. However, If I can see that it is of use to a large amount of users I will usually do it, but it is as a favour and it shouldn't be expected (I get annoyed when I feel this is the case).
Why should a developer be expected to do something users want, if the developer has no interest in it, and the users aren't willing to pay or at least make a donation? It's not expected in other aspects of life, and so I don't understand why it is increasingly being expected in free software.
Use a compressed read-only filesystem like Squashfs. For genuinely read-only directories (like/usr) these can be used directly, for directories that need to be writable, the read-only Squashfs can be used with aufs/unionfs to make it writeable. A number of people have mentioned systems like Puppy, and that is exactly what these systems do.
Using a compressed read-only filesystem not only solves the wear-levelling problem, but it makes accesses faster because less data has to be read. It also means more data can be fitted into the flash.
Search for Squashfs, aufs/unions and flash, you'll find lots of pages explaining what to do.
> I have been trying to think of famous British open source people/projects. Here is what I have come up with so far:
I wouldn't say famous, but four more British open source projects/people are:
JamVM - a free open source Java Virtual Machine, written and maintained by Robert Lougher
Squashfs - a compressed filesystem for Linux. This is the most widely used filesystem for LiveCDs, used by most major Linux distributions. It is also extensively used in embedded systems (i.e. most Linux based wireless routers). Written and maintained by Phillip Lougher (myself).
JFFS2 - a compressed filesytem for NAND flash. Originated and maintained by David Woodhouse.
Ext3 - written and maintained by Stephen Tweedie (and others).
Try to think less like a programmer and more like a business person.
Now that's below the belt... I didn't flame you...:-)
I don't know what's more offensive: being called a mere programmer or the suggestion that a business person is somehow better placed to make value judgements.
Speaking from experience (and I do have a lot of experience in this), places work better when everyone is respected for what they do. Each to their own and everyone doing what they do best etc. Companies, in my experience, tend to fail when one group starts to make all the decisions based on an acquired sense of inate superiority.
Getting back to the question at hand, I dispute your figures, and I can't help feeling you have an axe to grind against JVM developers. Speaking from a business point of view, JVM companies tended to use JVM performance/technology as _the_ differentiator. Everyone used the Sun class libraries, but offered their own or vastly improved JVM. From a purely business point of view that makes the JVM the most important piece of technology because it is what pursuaded a customer to buy their solution.
You may think of the class libraries as the easy grunt work, but that's the difference between a useful system and a technically insteresting but perfectly useless system
Actually putting all your efforts into Classpath and nothing into the JVM would result in a free-Java system that is so rediculously slow in comparison to the commercial JVMs that no one will use it. Free Java needs both a complete class library and a fast JVM to be useful.
You seem to be forgetting that the class libraries may give the required compatibility, but it is largely the JVM which provides the necessary speed.
I'm sure all five people who give a sh*t about this are just outraged.
Moderators should mod the parent up because in an ironic way it is unintentionally quite funny.
It's funny because the post illustrates a fact that becomes obvious to anyone reguarly reading the 'technical' reviews devoted to liveCDs. The reviews never mention anything about the underlying techniques that the liveCD uses, as if such things were totally unimportant, and yet go into excruciating detail about every little package and widget on the Gnome/KDE desktop as if that was really important.
The fact is the speed of application launching and general 'user experience' of using the liveCD is very much determined by the filesystem used, the file placing strategy (if any), and other general lowlevel things which never get a mention. Try it sometime by reading a LiveCD review, they may tell you what packages are on the CDROM but they never ever tell you how the liveCD was built and what it was built out of!
Cloop is a *read/write* FS, SquashFS is read only.
Err, sorry, but Cloop is read-only. Even if it was read/write (which is isn't) being stored on a CDROM would make it read-only:-)
All liveCDs irrespective of the underlying read-only fs (cloop/squashfs), need to make some part of the root filesystem writable in someway. There are many techniques to do that - symbolic links which point into tmpfs ramdisks, tmpfs ramdisks which are the root with symbolic links that point back into the read-only filesystem, or more recently through the use of unionfs or mini-fo. These techniques apply equally well to cloop or squashfs.
The point I was making is Squashfs is a faster filesystem which compresses better than Cloop. This makes the Linux system run faster. Google for performance results comparing Squashfs against Cloop, they're publically available...
Incidently the wiki page which you refer to is the wiki page I mentioned. Knowing a fair bit about liveCD design I can't see anything terribly novel or 'much more rocking' about the Ubuntu liveCD.
According to the Ubuntu liveCD wiki the liveCD still uses the cloop (compressed loopback) system to compress the filesystem on the CDROM. This is a pity because most new liveCDs are now using SquashFS which is faster and compresses better.
This is disapointing for me because I both use Ubuntu and I'm the author of Squashfs:-)
Anyone remember the old Timex-Sinclair 2000 with embedded basic and the unstable 16k extension pack?
Yes, though in the UK/Europe it was known as the Sinclair ZX81. It was a UK computer and was renamed for the US (never really knew why).
The Sinclair range of computers (ZX80, ZX81, Spectrum, QL), is probably responsible (blame?) for the generation of programmers in Europe in the 80s/90s. Even Linus Torvalds started out on a QL!
The argument was who invented the first light bulb, not the first commercially practical light bulb/electrical distribution system. I hardly think Edison's first bulb was immediately commercially viable either:-)
Seriously if a programmer can't even put forth the effort to make autoconf work on more than one platform
A very unwarranted attack... Many OSS programmers do not have access to more than one platform. They may want their stuff to work on more than one platform and try hard to do so, but without actual farms of differing platforms a lot of this is simply guess work.
Anyway there's a big difference between being committed to producing quality code and being committed to quality standards (whatever they are). I'm committed to producing quality code, but I'd be the first to admit I hate any kind of paperwork associated with standards/auditing of all kinds.
Slashdot Mirror
You're confused, CRT based television is by definition electronic. Mechanical scanning referred to the use of a large spinning disk instead of a CRT.
The electron beam in the CRT in 1930s era televisions was bent (or more correctly deflected) so that it scanned the screen building up a picture, in one of two ways. Electrostatic deflection or Electromagnetic deflection.
Electromagnetic deflection uses an electro-magnet built around the outside of the electron gun. Passing a varying current through the electro-magnet varies the magnetic field produced which bends the electronic beam.
Electrostatic deflection used X-Y plates within the electron gun, a varying voltage (not current) applied to the plates attracts or deflects the electron beam.
Initially electrostatic deflection was used (in first gen TVs of 1936), these CRTs had small deflection angles meaning the tubes had to be very long (and thus mounted vertically and watched in a mirror - giving the name mirror lid televisions).
Efforts to increase the deflection angle of CRTs (and thus make shorter tubes) led to the switch to electro-magnetic deflection by 1938.
Again a completely Ameri-centric viewpoint. High definition television in Great Britain (as opposed to Baird's mechanical system) was developed by EMI in the early 30s, in parallel and independently of Farnsworth or RCA (i.e. Zworykin). The EMI developed Emitron camera (patented 1932) and 405 line-system was used to start the worlds first high definition television service by the BBC in November 1936 (to the London area).
The incandescent light bulb was developed in parallel and independently on both sides of the Atlantic. Edison in the US and Joseph Swan in the UK, with Swan patenting in the UK first.
> The only thing I'm not sure how well unsquashfs handles the extraction of sparse files.
If the file is stored as a sparse file in the Squashfs filesystem (normally the case), then Unsquashfs will create it as a sparse file when extracting it. It doesn't need any more filesystem space than the filled parts of the file when doing so.
I wrote the code and so I should know :-)
Do you know anything about hard-links? Hint, you have multiple directory entries pointing to the same file (inode).
hiring that really bright coder 12 timezones away with good English skills ... and grabbing that talent before it fleas to a country
Unlike you then, it's flees not fleas.
Why fancy doing some research do you?
Ddywedwch means "say" not douche!
"yr hyn a ddywedwch" -> What you say
"yn debygol iawn" -> very probably
"wir" -> true
Try Squashfs which creates deduplicated and compressed filesystem archives (http://www.linux-mag.com/id/7357/ for a good journal article).
If you're using Ubuntu, Debian, Fedora Squashfs will be already built into your distro kernel, and the squashfs-tools will also already be available in your distro repository.
Oh wow, a little Englander on slashdot, I thought you'd all be at the Tory conference in Manchester.
I describe myself first as British, secondly as a (proud) European, and lastly and hardly ever as English, for all the negative connotations people like you have given it.
Britain is a European country, it has a proud history of involvement (for the better too) with the other countries in Europe, and it is a European culture.
Complete twaddle. Do you really think that these jobs are going to the hundreds of thousands of Indians surviving on less than a dollar a day? They'll be going to the rich English speaking Indian middle class who could afford to go to university. You never know, but, some of those American workers may have pulled themselves out of (American levels of) poverty by getting their IT qualifications and career. It's too easy to say America rich, India poor and therefore this always justifies outsourcing American jobs.
No, I'm not American.
Mark Shuttleworth is effectively the user every free software developer wants, because he puts his money where his mouth is. Vision is one thing, being prepared to pay for it is better.
Besides someone's needless continuity breakage/stability disruption is often another's necessary innovation. Often I've been begged by some users to implement something which they badly need, but then got criticised by others for yet another incompatible version. You can't please everyone all of the time.
Innovation doesn't need to be the evil twin of stability, it unfortunately often feels that way in free software IMO due to lack of resources. I, for example, as a free software developer only have the time to support the latest (and 'greatest') version, and so all users are forced to use it whether or not they want the latest features. If I made enough money from the software to pay developers, I could support the last couple of versions or when adding features I could implement a backwards compatibility option. However, I can't do this.
Free software is still driven by developers working on what interests or concerns them.
If it is being developed in the developer's free time then this should be expected, The software is effectively a hobby which the developer enjoys and users benefit from. Innovation is enjoyable, maintenance isn't, and users if they aren't paying should expect this. If they want reliable long term maintenance (or any other "boring" issues) they should consider playing for support, like in any normal business relationship,
If I (as a spare-time software developer) gets asked to do something I'm not interested in, I may not refuse, but it gets placed at the end of a priority sorted list, and it can stay there for a long time. However, If I can see that it is of use to a large amount of users I will usually do it, but it is as a favour and it shouldn't be expected (I get annoyed when I feel this is the case).
Why should a developer be expected to do something users want, if the developer has no interest in it, and the users aren't willing to pay or at least make a donation? It's not expected in other aspects of life, and so I don't understand why it is increasingly being expected in free software.
Use a compressed read-only filesystem like Squashfs. For genuinely read-only directories (like /usr) these can be used directly, for directories that need to be writable, the read-only Squashfs can be used with aufs/unionfs to make it writeable. A number of people have mentioned systems like Puppy, and that is exactly what these systems do.
Using a compressed read-only filesystem not only solves the wear-levelling problem, but it makes accesses faster because less data has to be read. It also means more data can be fitted into the flash.
Search for Squashfs, aufs/unions and flash, you'll find lots of pages explaining what to do.
> I have been trying to think of famous British open source people/projects. Here is what I have come up with so far:
I wouldn't say famous, but four more British open source projects/people are:
JamVM - a free open source Java Virtual Machine, written and maintained by Robert Lougher
Squashfs - a compressed filesystem for Linux. This is the most widely used filesystem for LiveCDs, used by most major Linux distributions. It is also extensively used in embedded systems (i.e. most Linux based wireless routers). Written and maintained by Phillip Lougher (myself).
JFFS2 - a compressed filesytem for NAND flash. Originated and maintained by David Woodhouse.
Ext3 - written and maintained by Stephen Tweedie (and others).
Now that's below the belt... I didn't flame you... :-)
I don't know what's more offensive: being called a mere programmer or the suggestion that a business person is somehow better placed to make value judgements.
Speaking from experience (and I do have a lot of experience in this), places work better when everyone is respected for what they do. Each to their own and everyone doing what they do best etc. Companies, in my experience, tend to fail when one group starts to make all the decisions based on an acquired sense of inate superiority.
Getting back to the question at hand, I dispute your figures, and I can't help feeling you have an axe to grind against JVM developers. Speaking from a business point of view, JVM companies tended to use JVM performance/technology as _the_ differentiator. Everyone used the Sun class libraries, but offered their own or vastly improved JVM. From a purely business point of view that makes the JVM the most important piece of technology because it is what pursuaded a customer to buy their solution.
Actually putting all your efforts into Classpath and nothing into the JVM would result in a free-Java system that is so rediculously slow in comparison to the commercial JVMs that no one will use it. Free Java needs both a complete class library and a fast JVM to be useful.
You seem to be forgetting that the class libraries may give the required compatibility, but it is largely the JVM which provides the necessary speed.
Moderators should mod the parent up because in an ironic way it is unintentionally quite funny.
It's funny because the post illustrates a fact that becomes obvious to anyone reguarly reading the 'technical' reviews devoted to liveCDs. The reviews never mention anything about the underlying techniques that the liveCD uses, as if such things were totally unimportant, and yet go into excruciating detail about every little package and widget on the Gnome/KDE desktop as if that was really important.
The fact is the speed of application launching and general 'user experience' of using the liveCD is very much determined by the filesystem used, the file placing strategy (if any), and other general lowlevel things which never get a mention. Try it sometime by reading a LiveCD review, they may tell you what packages are on the CDROM but they never ever tell you how the liveCD was built and what it was built out of!
Err, sorry, but Cloop is read-only. Even if it was read/write (which is isn't) being stored on a CDROM would make it read-only :-)
All liveCDs irrespective of the underlying read-only fs (cloop/squashfs), need to make some part of the root filesystem writable in someway. There are many techniques to do that - symbolic links which point into tmpfs ramdisks, tmpfs ramdisks which are the root with symbolic links that point back into the read-only filesystem, or more recently through the use of unionfs or mini-fo. These techniques apply equally well to cloop or squashfs.
The point I was making is Squashfs is a faster filesystem which compresses better than Cloop. This makes the Linux system run faster. Google for performance results comparing Squashfs against Cloop, they're publically available...
Incidently the wiki page which you refer to is the wiki page I mentioned. Knowing a fair bit about liveCD design I can't see anything terribly novel or 'much more rocking' about the Ubuntu liveCD.
According to the Ubuntu liveCD wiki the liveCD still uses the cloop (compressed loopback) system to compress the filesystem on the CDROM. This is a pity because most new liveCDs are now using SquashFS which is faster and compresses better.
:-)
This is disapointing for me because I both use Ubuntu and I'm the author of Squashfs
It was actually a Z80A clocked at 3.5 MhZ. It had a 8K BASIC ROM.
Yes, though in the UK/Europe it was known as the Sinclair ZX81. It was a UK computer and was renamed for the US (never really knew why).
The Sinclair range of computers (ZX80, ZX81, Spectrum, QL), is probably responsible (blame?) for the generation of programmers in Europe in the 80s/90s. Even Linus Torvalds started out on a QL!
The argument was who invented the first light bulb, not the first commercially practical light bulb/electrical distribution system. I hardly think Edison's first bulb was immediately commercially viable either :-)
Even on that definition Edison didn't invent the light bulb. Joseph Swan did.
So now we finally have a light bulb. Invented by Edison. In the US.
Nope. So we finally have a light bulb. Invented by Swan. In Britain.
Seriously if a programmer can't even put forth the effort to make autoconf work on more than one platform
A very unwarranted attack... Many OSS programmers do not have access to more than one platform. They may want their stuff to work on more than one platform and try hard to do so, but without actual farms of differing platforms a lot of this is simply guess work.
Anyway there's a big difference between being committed to producing quality code and being committed to quality standards (whatever they are). I'm committed to producing quality code, but I'd be the first to admit I hate any kind of paperwork associated with standards/auditing of all kinds.