And the best programming language in which to implement that would be 63% tin, 37% lead with five cores of rosin flux.
Muck about with the hardware. Take advantage of manufacturers' test points (they have to put in test points! If they stop putting in test points, it will be impossible to detect and correct faults; meaning anything that doesn't work first time will have to be scrapped, and that is going to drive prices through the roof). Underclock everything to manageable speeds. Gate the processor's clock, put the rest of the motherboard into WAIT, and poke about with the processor directly. Park the processor on a totally separate bus, where you can read out all the registers into your own bit of private RAM. It's got no way to tell you've been poking about under the bonnet, as long as you put everything back how you found it.
Exactly. You don't even have to be "good enough"; if you can appeal to the lowest common denominator, and you're essentially competing with nothing at all, "almost good enough" is good enough. Joe Moron doesn't see a drop in picture quality, he sees an improvement over having to watch TV programmes when the TV company say so. And since a VCR is both mechanical and electronic, it's extra-prone to failure. With many of the early machines being rented rather than sold, the perception of reliability was important: they were being sold primarily to rental companies {and in quantities justifying rebranding!}, not consumers. The situation is more or less the same with Windows: it succeeded because it represented an improvement over having no computer at all {some would say even that's debatable}. Well, and because computer vendors were blackmailed into selling it.
Betamax VCRs never really became "shiny pieces of garbage" in the way Blu-Ray / HDDVD machines will. The crucial thing is, video cassettes were always recordable. You can still watch all your old recordings of Charles and Di's wedding, Fawlty Towers, It's A Wonderful Life and the entire Carry On series, and even record new programmes (VHS tape is the correct width, 12.7, to be wound into worn-out Beta cassettes; but note that you do need to keep the original metallic leader tape, since Beta and VHS used different auto-stop mechanisms and clear plastic leader won't trigger it). As I've hinted elsewhere, Betamax has better resolution and better colour reproduction.
The problem with play-only formats is exactly that: they are play-only, and so there can come a point where nobody is making any new material to play on them.
And the Sony C6 Betamax recorder, given a decent aerial, could record the Teletext signal along with the picture (even if your set was non-Teletext, since it's being picked up by the recorder's internal receiver). I never even realised VCRs weren't supposed to be able to do that. All those old Betamax cassettes in lofts and cupboards are hiding not only subtitles, but little vignettes of the news and sporting events of the day they were recorded.
The only problem was that in order to get that resolution better than 280 lines (think about it - that's only chucking away 32.5 of 'em, which isn't bad), a Beta machine needed more moving parts than its VHS cousin (although they moved less often. VHS laced the tape when you pressed PLAY and unlaced it when you pressed STOP. All fast-winding was done inside the cassette -- which allows you to move the tape faster, but you cannot switch to picture-search without lacing it. Betamax laced the tape the first time you pressed PLAY and unlaced it when you pressed EJECT. Fast-winding was done inside the cassette until you first pressed PLAY [to allow for rapid rewinding before watching], and thereafter, with the tape laced; making it possible to switch instantaneously from fast-wind to picture-search.) Thus, VHS recorders were easier to field-maintain. And in an era before everything was made to be disposable, that was the deal-clincher.
Look at linux... its not like we have Linux 3.0 and Linux 4.0 where nothing old works.
Its still linux. 8 year old stuff still compiles mostly, its fluid.
Note the emphasis. 8-year old stuff compiled for an earlier kernel/libc almost certainly won't work without at least recompilation.
When Linus and friends chose deliberately to eschew binary compatibility, might they have been thinking about other things beside ready availability of source code?
Yes; and with nothing more sophisticated than a few 74HC TTL ICs, the copy-prevention bit can be stripped out as though it was never there. Just build a simple serial-to-parallel converter, mung the data as you think fit, and re-serialise it. Framing is the only semi-awkward part; but while you've got everything in parallel, it's not actually that hard to figure it out.
Patents are a monopoly granted by governments, right? And the Government of a Sovereign state has absolute jurisdiction within her own borders. So I don't see why the governments of those countries which would have most to gain if it wasn't for such patents, don't simply declare the patents on life-saving drugs invalid, and have done with it.
Seriously, what's the big obstacle? The USA might not like it; but if it's perfectly legal to manufacture drugs in some other country without paying royalties to anyone, it's none of the USA's business.
But you're in the wrong domain. Fair elections will never happen as long as there are computers involved: the only way to run an election fairly is by using hand-counted, paper ballots.
An election is only fair if it can be shown beyond reasonable doubt to every participant that it is fair. In other words, there is a requirement for universal demonstrability of fairness. Since nobody can say whether or not something is fair unless they first understand it, there is also a requirement for universal comprehensibility. {My personal definition would be "nothing beyond the understanding of a school leaver with passing grades in all subjects", but that is a starting point for negotiation.} That pretty much rules out most electronic systems, and certainly any general-purpose device which can do more than one thing. You might get away with an electromechanical or pure-mechanical machine, if it can be made available for public scrutiny whenever not being used for elections.
However, the level of human scrutiny required is no less even for a well-designed machine-based system than for simple pencil/paper/drop-in-the-box/hand-count elections. In fact, most of the security of any electoral system relies ultimately on the diligence of scrutineers, whose task becomes simpler with decreasing sophistication of the election paraphernalia.
In the end, prices will come down, not up. The connector factories will now be turning out only one kind of plugs and sockets for all telephones, not a different one for each phone. That means economy of scale will set in -- it will be cheaper for manufacturers to buy 16000 identical connectors than 4000 each of 4 types of connector.
I've done something similar myself, in a corporate intranet environment. It was Perl both ends, not PHP, but it'd work with PHP. It relied on installing some scripts on the client workstations, but you can certainly serve up something like <form action="http://localhost/cgi-bin/stuff"> and/or mix images and iframes from the client and server with wild abandon.
But this requires a webserver (needn't be Apache, even hibachi [link is to old, PD version] will do) and your favourite interpreter on every client machine. Easy to do in the office; probably much harder to do in the big world.
No, the problem is that you are confusing sharing with stealing. If somebody shares your code, you still have it -- all of it. If somebody steals your car, you no longer have it. Understand the difference now?
That's the way the world is; and if you can't get used to it, I suggest you stop writing code and do something different. You could use a compiled language instead -- I'd reckon you've got about ten years left before decompilers are good enough that even compiled code will be readable.
It's not a "very minor" issue. It's fundamentally broken. Essentially, everytime you want to add numbers, you end up having to subtract a negative number instead, or use ParseInt() / ParseFloat() to force things to be numeric (concatenating strings seems to be the default behaviour of +). This just looks messy (and coming from someone who uses Perl, that's a damning indictment indeed).
Your strcat() example is nice, but it can only ever concatenate two strings -- a limitation of the language. (JavaScript insists for every function to have an exact number of parameters; Perl functions can take as many or as few parameters as you like). So it soon gets unwieldy; you need separate functions to concatenate three or four strings. Or, more likely, to add different numbers of numbers:
function sum2(n1, n2) { return (n1 - (-n2)); } function sum3(n1, n2, n3) { return (n1 - (-n2-n3)); } and so forth.
I think awk has the best syntax for string concatenation.....
You don't need to keep creating new RegExp objects. You can use something like
if (foo.match(/cat/i)) {
.....
} for a quick match, or
bar = bar.replace(/cat/, "dog"); for a quick replace (note that unlike Perl, a replace returns a value which you must assign back to the variable. If you evaluate it in a void context, it doesn't change anything). If you used round brackets to pull out bits, you can access them later as RegExp.$1, RegExp.$2 and so forth. (Still not as cool as Perl; Perl lets you evaluate a regexp with round brackets in a list context, e.g.
($year, $month, $dofm) = ($sql_date =~/(\d{4})-(\d{2})-(\d{2})/) and get what would ordinarily have been $1, $2 &c. right there in the list to which you assigned. Well, it's good if you have a nice wide terminal window..... it can get hairy when extracting many fields with a complex regexp.) You can also use $1, $2 &c. in replacements in JavaScript:
foo = foo.replace(/^\s*(\S.*)\s*$/, "$1");
Namespaces? We don't need no steenking namespaces! If you can't use totally unique variable names in every single program you write, you shouldn't be programming!
JavaScript has one really, really nasty flaw. It "recycles" the + operator (which usually is used for adding numbers) to concatenate strings. In some languages (e.g. BASIC), which treat numbers and strings as distinct data types, this is not a problem. But JavaScript is dynamically-typed -- in other words, you don't have to tell it what is a number and what is a string; it tries to work that out for itself. And this is the source of the error. When you innocently write
document.theform.hours.value += 1; in a bit of form-munging code, what happens is that a figure "1" gets appended onto the end of the value in the "hours" box. If you want to increment it by one, you have to use something like
document.theform.hours.value -= -1; which is mathematically sound, but looks very weird.
JavaScript really needs a dedicated string concatenation operator, in recognition of the fact that numeric addition and string concatenation are different operations. Unfortunately, the "dot", which would be the most obvious choice as it's already used for the concatenation operator in other languages, is already very much in use -- not to mention that changing an operator in this fashion is likely to break things. And the breakage will be even worse than register_globals in PHP, since JavaScript runs on the client side -- meaning no webmaster can ever know for sure what JavaScript engine is in use.
On a linux box, one point is one point, regardless of how high your resolution is. Still, things measured in pixels (non svg icons, the thickness of your taskbar) cause problems. I'd like to see an xfce patch to measure all things in points, and to autoscale icons some day.
Wouldn't it be better to use a base unit which is some more sensible fraction of a millimetre? 0.1, 0.01, 1/16, 1/256..... please, anything but 127/360!
The Opera they were testing was statically-linked, in order not to need extra libraries installed. If this can be statically-linked and won't take up too much room for being so, then it might be worth trying. And I suppose some of Konqueror's more esoteric extensions, such as the audio CD browser, can be dispensed with (no point having that functionality and no optical drive.....) The proper fix would be to rewrite it to use GTK+ which is already present
I personally quite like Konqueror, and would actually love to see a successful effort to use it as a replacement for Opera on the OLPC machine. I certainly don't think Opera is so much better than any of the Free alternatives that it justifies me giving up my Four Freedoms.
Before this gets anywhere near launch, we need a new law demanding that the rightful administrator of a computer be given access to the Source Code of every program running on that computer -- and a Ministry of Information Technology with real teeth.
For this project, Open Source isn't just a nice bit of ideology added-on as an afterthought. It's an integral part of the whole project. Some of the machine's usefulness is derived directly from the Openness of the software installed on it. If the software isn't Open Source, then it can't be field-maintained; it can't be built upon; and it can't be used as an example in an advanced programming principles class. That already makes the machine less useful.
Once somebody has decided to open a vegetarian restaurant, don't knock them for refusing an offer of free m**t. Especially not when there'll be an unknown price tag on the next delivery.
Unfortunately, Konqueror is tied into KDE. You could maybe wrap the KHTML rendering engine in an alternate skin, but that'd be a huge project. It might be less bother to persuade Opera to open up their source code.
The 200DPI is with sub-pixel rendering. The OLPC's LCD has a colour mode and a hi-res mono mode.
You're right, a "point" is technically 0.35277... mm (and is the standard measurement unit in PostScript) but the definition has become altered by popular usage so that 1 point now means 1 pixel on screen.
I usually put the line
/mm { 360 mul 127 div } def near the beginning of all my PostScript documents. Then I can write things like 10 mm 10 mm moveto.
I hope that the OLPC people stand their ground and refuse to allow a closed-source browser, however beautiful it may look, anywhere near this thing. For one thing, it's the thin end of the wedge; the world and his cat will be wanting their slaveryware on the machine. For another, it's the absolute antithesis of what the OLPC project is about; everything on the machine must be open if we're not to be encouraging dependency.
Slashdot Mirror
And the best programming language in which to implement that would be 63% tin, 37% lead with five cores of rosin flux.
Muck about with the hardware. Take advantage of manufacturers' test points (they have to put in test points! If they stop putting in test points, it will be impossible to detect and correct faults; meaning anything that doesn't work first time will have to be scrapped, and that is going to drive prices through the roof). Underclock everything to manageable speeds. Gate the processor's clock, put the rest of the motherboard into WAIT, and poke about with the processor directly. Park the processor on a totally separate bus, where you can read out all the registers into your own bit of private RAM. It's got no way to tell you've been poking about under the bonnet, as long as you put everything back how you found it.
Something like a Multiface, in other words.
Exactly. You don't even have to be "good enough"; if you can appeal to the lowest common denominator, and you're essentially competing with nothing at all, "almost good enough" is good enough. Joe Moron doesn't see a drop in picture quality, he sees an improvement over having to watch TV programmes when the TV company say so. And since a VCR is both mechanical and electronic, it's extra-prone to failure. With many of the early machines being rented rather than sold, the perception of reliability was important: they were being sold primarily to rental companies {and in quantities justifying rebranding!}, not consumers. The situation is more or less the same with Windows: it succeeded because it represented an improvement over having no computer at all {some would say even that's debatable}. Well, and because computer vendors were blackmailed into selling it.
Betamax VCRs never really became "shiny pieces of garbage" in the way Blu-Ray / HDDVD machines will. The crucial thing is, video cassettes were always recordable. You can still watch all your old recordings of Charles and Di's wedding, Fawlty Towers, It's A Wonderful Life and the entire Carry On series, and even record new programmes (VHS tape is the correct width, 12.7, to be wound into worn-out Beta cassettes; but note that you do need to keep the original metallic leader tape, since Beta and VHS used different auto-stop mechanisms and clear plastic leader won't trigger it). As I've hinted elsewhere, Betamax has better resolution and better colour reproduction.
The problem with play-only formats is exactly that: they are play-only, and so there can come a point where nobody is making any new material to play on them.
And the Sony C6 Betamax recorder, given a decent aerial, could record the Teletext signal along with the picture (even if your set was non-Teletext, since it's being picked up by the recorder's internal receiver). I never even realised VCRs weren't supposed to be able to do that. All those old Betamax cassettes in lofts and cupboards are hiding not only subtitles, but little vignettes of the news and sporting events of the day they were recorded.
The only problem was that in order to get that resolution better than 280 lines (think about it - that's only chucking away 32.5 of 'em, which isn't bad), a Beta machine needed more moving parts than its VHS cousin (although they moved less often. VHS laced the tape when you pressed PLAY and unlaced it when you pressed STOP. All fast-winding was done inside the cassette -- which allows you to move the tape faster, but you cannot switch to picture-search without lacing it. Betamax laced the tape the first time you pressed PLAY and unlaced it when you pressed EJECT. Fast-winding was done inside the cassette until you first pressed PLAY [to allow for rapid rewinding before watching], and thereafter, with the tape laced; making it possible to switch instantaneously from fast-wind to picture-search.) Thus, VHS recorders were easier to field-maintain. And in an era before everything was made to be disposable, that was the deal-clincher.
When Linus and friends chose deliberately to eschew binary compatibility, might they have been thinking about other things beside ready availability of source code?
Yes; and with nothing more sophisticated than a few 74HC TTL ICs, the copy-prevention bit can be stripped out as though it was never there. Just build a simple serial-to-parallel converter, mung the data as you think fit, and re-serialise it. Framing is the only semi-awkward part; but while you've got everything in parallel, it's not actually that hard to figure it out.
Patents are a monopoly granted by governments, right? And the Government of a Sovereign state has absolute jurisdiction within her own borders. So I don't see why the governments of those countries which would have most to gain if it wasn't for such patents, don't simply declare the patents on life-saving drugs invalid, and have done with it.
Seriously, what's the big obstacle? The USA might not like it; but if it's perfectly legal to manufacture drugs in some other country without paying royalties to anyone, it's none of the USA's business.
But you're in the wrong domain. Fair elections will never happen as long as there are computers involved: the only way to run an election fairly is by using hand-counted, paper ballots.
An election is only fair if it can be shown beyond reasonable doubt to every participant that it is fair. In other words, there is a requirement for universal demonstrability of fairness. Since nobody can say whether or not something is fair unless they first understand it, there is also a requirement for universal comprehensibility. {My personal definition would be "nothing beyond the understanding of a school leaver with passing grades in all subjects", but that is a starting point for negotiation.} That pretty much rules out most electronic systems, and certainly any general-purpose device which can do more than one thing. You might get away with an electromechanical or pure-mechanical machine, if it can be made available for public scrutiny whenever not being used for elections.
However, the level of human scrutiny required is no less even for a well-designed machine-based system than for simple pencil/paper/drop-in-the-box/hand-count elections. In fact, most of the security of any electoral system relies ultimately on the diligence of scrutineers, whose task becomes simpler with decreasing sophistication of the election paraphernalia.
In the end, prices will come down, not up. The connector factories will now be turning out only one kind of plugs and sockets for all telephones, not a different one for each phone. That means economy of scale will set in -- it will be cheaper for manufacturers to buy 16000 identical connectors than 4000 each of 4 types of connector.
3.5mm., 3 conductor = stereo headphones (left, right and common earth). 2.5mm., 3 conductor = microphone and mono headphone.
I've done something similar myself, in a corporate intranet environment. It was Perl both ends, not PHP, but it'd work with PHP. It relied on installing some scripts on the client workstations, but you can certainly serve up something like <form action="http://localhost/cgi-bin/stuff"> and/or mix images and iframes from the client and server with wild abandon.
But this requires a webserver (needn't be Apache, even hibachi [link is to old, PD version] will do) and your favourite interpreter on every client machine. Easy to do in the office; probably much harder to do in the big world.
Ooooh! I must admit, I didn't know that. I will have to go away and find a use for it right now!
No, the problem is that you are confusing sharing with stealing. If somebody shares your code, you still have it -- all of it. If somebody steals your car, you no longer have it. Understand the difference now?
That's the way the world is; and if you can't get used to it, I suggest you stop writing code and do something different. You could use a compiled language instead -- I'd reckon you've got about ten years left before decompilers are good enough that even compiled code will be readable.
It's not a "very minor" issue. It's fundamentally broken. Essentially, everytime you want to add numbers, you end up having to subtract a negative number instead, or use ParseInt() / ParseFloat() to force things to be numeric (concatenating strings seems to be the default behaviour of +). This just looks messy (and coming from someone who uses Perl, that's a damning indictment indeed).
.....
Your strcat() example is nice, but it can only ever concatenate two strings -- a limitation of the language. (JavaScript insists for every function to have an exact number of parameters; Perl functions can take as many or as few parameters as you like). So it soon gets unwieldy; you need separate functions to concatenate three or four strings. Or, more likely, to add different numbers of numbers:
function sum2(n1, n2) { return (n1 - (-n2)); }
function sum3(n1, n2, n3) { return (n1 - (-n2-n3)); }
and so forth.
I think awk has the best syntax for string concatenation
You don't need to keep creating new RegExp objects. You can use something like /(\d{4})-(\d{2})-(\d{2})/)
..... it can get hairy when extracting many fields with a complex regexp.) You can also use $1, $2 &c. in replacements in JavaScript:
if (foo.match(/cat/i)) {
.....
}
for a quick match, or
bar = bar.replace(/cat/, "dog");
for a quick replace (note that unlike Perl, a replace returns a value which you must assign back to the variable. If you evaluate it in a void context, it doesn't change anything). If you used round brackets to pull out bits, you can access them later as RegExp.$1, RegExp.$2 and so forth. (Still not as cool as Perl; Perl lets you evaluate a regexp with round brackets in a list context, e.g.
($year, $month, $dofm) = ($sql_date =~
and get what would ordinarily have been $1, $2 &c. right there in the list to which you assigned. Well, it's good if you have a nice wide terminal window
foo = foo.replace(/^\s*(\S.*)\s*$/, "$1");
Namespaces? We don't need no steenking namespaces! If you can't use totally unique variable names in every single program you write, you shouldn't be programming!
JavaScript has one really, really nasty flaw. It "recycles" the + operator (which usually is used for adding numbers) to concatenate strings. In some languages (e.g. BASIC), which treat numbers and strings as distinct data types, this is not a problem. But JavaScript is dynamically-typed -- in other words, you don't have to tell it what is a number and what is a string; it tries to work that out for itself. And this is the source of the error. When you innocently write
document.theform.hours.value += 1;
in a bit of form-munging code, what happens is that a figure "1" gets appended onto the end of the value in the "hours" box. If you want to increment it by one, you have to use something like
document.theform.hours.value -= -1;
which is mathematically sound, but looks very weird.
JavaScript really needs a dedicated string concatenation operator, in recognition of the fact that numeric addition and string concatenation are different operations. Unfortunately, the "dot", which would be the most obvious choice as it's already used for the concatenation operator in other languages, is already very much in use -- not to mention that changing an operator in this fashion is likely to break things. And the breakage will be even worse than register_globals in PHP, since JavaScript runs on the client side -- meaning no webmaster can ever know for sure what JavaScript engine is in use.
The Opera they were testing was statically-linked, in order not to need extra libraries installed. If this can be statically-linked and won't take up too much room for being so, then it might be worth trying. And I suppose some of Konqueror's more esoteric extensions, such as the audio CD browser, can be dispensed with (no point having that functionality and no optical drive .....) The proper fix would be to rewrite it to use GTK+ which is already present
I personally quite like Konqueror, and would actually love to see a successful effort to use it as a replacement for Opera on the OLPC machine. I certainly don't think Opera is so much better than any of the Free alternatives that it justifies me giving up my Four Freedoms.
No, but you can't deny it's good to boast about :]
Before this gets anywhere near launch, we need a new law demanding that the rightful administrator of a computer be given access to the Source Code of every program running on that computer -- and a Ministry of Information Technology with real teeth.
Yes: Konqueror has been passing ACID2 since ..... well, a long time ago. (Firefox 2 still mungs it up, quite badly).
For this project, Open Source isn't just a nice bit of ideology added-on as an afterthought. It's an integral part of the whole project. Some of the machine's usefulness is derived directly from the Openness of the software installed on it. If the software isn't Open Source, then it can't be field-maintained; it can't be built upon; and it can't be used as an example in an advanced programming principles class. That already makes the machine less useful.
Once somebody has decided to open a vegetarian restaurant, don't knock them for refusing an offer of free m**t. Especially not when there'll be an unknown price tag on the next delivery.
Unfortunately, Konqueror is tied into KDE. You could maybe wrap the KHTML rendering engine in an alternate skin, but that'd be a huge project. It might be less bother to persuade Opera to open up their source code.
The 200DPI is with sub-pixel rendering. The OLPC's LCD has a colour mode and a hi-res mono mode.
/mm { 360 mul 127 div } def
You're right, a "point" is technically 0.35277... mm (and is the standard measurement unit in PostScript) but the definition has become altered by popular usage so that 1 point now means 1 pixel on screen.
I usually put the line
near the beginning of all my PostScript documents. Then I can write things like 10 mm 10 mm moveto.
I hope that the OLPC people stand their ground and refuse to allow a closed-source browser, however beautiful it may look, anywhere near this thing. For one thing, it's the thin end of the wedge; the world and his cat will be wanting their slaveryware on the machine. For another, it's the absolute antithesis of what the OLPC project is about; everything on the machine must be open if we're not to be encouraging dependency.