I can't see this working very well, somehow. Not if it works anything like an ordinary building lift..... For one thing, how far down will the lift shaft have to go? And won't a metal box on the end of a hydraulic piston be a bit wobbly without some sort of superstructure around it? I wouldn't want to be anywhere near the pump if those hoses burst, either.....
"Extended warranties" are just a cheap form of insurance policy, with a one-payment premium, no surrender value and {probably} a claims procedure designed to discourage claims. Great for the insurance company, but to get the best value out of it as a customer, you really need your own paper recycling facility. Yet, incredibly, people are stupid enough to pay for them. This suggests to me that they don't know how something works, whether that's the insurance or the electronics. But then again, there's a fine tradition of getting fat off other people's ignorance.....
Having worked in the electronics industry, I know about the bathtub curve (the probability of failure plotted against time resembles a side view of a bathtub..... drops sharply over the first few months, stays constant, begins rising again after a fixed time). In fact, we used to deliberately pre-stress many of the units we made, by running them for a few hours at high ambient temperature and then rapidly cooling them, before giving them a final test. Better an important component fails in our test chamber than on the customer's premises..... especially if the thing is strapped to the engine of a muddy tractor..... And for the failure rates we experienced and the cost of corrective action {most of the failures were repairable..... unless they went on fire..... it was always fun when that happened} this testing was still cheaper, and less work, than honouring a warranty.
The point is, if just about anything electronic doesn't break within the first year -- where it's covered by law -- then it'll probably last ten years or more. {Of course you have to allow for the Six B's (batteries, bulbs, brushes, belts, bearings, blades); but since these are usually designed to be field-replaceable, they fall outside the scope of any warranty.} Extended warranties are almost never worthwhile -- if you ever have to claim on it, a new appliance even better than the one you bought probably will not cost you much more than the extended warranty plan.
First, get Joe Six pack, who can install a copy of Office now, do the same for a copy he has to compile.
I think you're assuming compilation would be a more or less interactive process; I'm assuming it would be completely non-interactive. After all, properly-managed packages search for and download any missing essentials, so they can just compile without you having to do anything. A less kind person than myself would say forget your bad experience with RPM and try something like FreeBSD Ports.
Oh, that's right, Windows doesn't come with a compiler. Well, add in the cost of a compiler to the OS. In fact, intergate it.
Just like every unix-ish system then..... seriously, a compiler already has been written, so it isn't going to cost anything; and its source code is widely available, so it is to some extent trustworthy (if it's compiled by trustworthy methods).
Next, since a machine can't boot source code, somewhere you're going to need a kernel to boot. Next, you have to authinticate against something somewhere that the code you think you are booting is actually the code you are booting....
This is indeed the sticking point. My proposed solution is a hardware switch that would allow running of arbitrary, unsigned code -- sort of a "dangerous mode" if you will -- while it was active, and for the user to compile their initial bootstrap loader and kernel after booting from a read-only disc in dangerous mode.
What you describe is a trusted computing base. See "Trusting trust" for more insight.
But unlike Microsoft's plan, I'm proposing that the owner of the machine should have the ability to control the keys. You are right, though, that you can only trust everything as far back as the last thing that happened in "dangerous mode" (whether or not "dangerous mode" was selected with your blessing -- hence a hardware switch). The real point is that you can't trust anything you didn't build yourself. For that matter, could someone have nobbled you -- by drugs, hypnosis or whatever -- into building in certain "special" features you didn't really want? After all, anything is possible in tinfoil territory. Perhaps I should move into a shack in the woods with no electricity, and grow my own food..... but maybe that's just what they want me to do.....
Adding complexity of the nature you propose does noting to protect against idiot users.
Adding complexity has one effect, in that it forces people to think just that little bit harder about what they are doing. Of course, if users actually had a clue then none of it would be necessary.
In fact, that just gave me a blinding flash of inspiration. The real question we should be asking is, who gets fat off keeping users clueless?
You, as the owner of the box, would obviously get to create the public and private keys required to run software on it. The source code would not be encrypted; it would be in the clear. It would be the compiled code that would be encrypted. Ordinarily you would do the encryption during compilation, because you would be the one in the best position to compile all the software your box ran. Otherwise you would have either to send your public key to Microsoft for them to encrypt against, or change your private key to one supplied by Microsoft.
If you run a 30,000 node network, how do you manage all 30,000 unique copies of the OS, productivity, and all the batch files used to mange all 30,000 systems?
You manage 30 000 copies of an OS by making sure they are all encrypted to the same key. Or 1000 copies each encrypyed to one of 30 keys, or something like that..... at least any infection can be contained.
And what would keep mal-ware writers from inserting their malware at the comple-the-source stage for each and every processor?
While it's possible to distribute malware in source form, it would be unfeasible. Bear in mind that "good guys" outnumber "bad guys", and it would soon be found out. Imagine a breakfast cereal that listed "Amanita phalloides" in its ingredients..... as soon as anybody with any savvy sees what's in it, the company have effectively sold the last box. Of course, they probably wouldn't want to do that if they didn't have to, but think of a regime that made it next to impossible not to declare your ingredients..... or where everyone has a pocket-sized mass spectrometer..... in fact, I wouldn't be surprised if the Japs start building them into phones sometime soon.
The "installation requires a conscious act" feature means that you have to know about any software you install. Of course it's possible that this could be bypassed (a piece of software that was allowed to run could act as a crude emulator, doing things depending on the contents of disk/memory locations where normally non-executable data would reside) but still there would be some kind of audit trail.
Like spam, viruses are not a technical problem. It's a human problem.
IMHO, the greater part of the problem is that people are too willing to run software on their machine that was compiled by someone else and never checked.
I see the real long term solution to the problem of unwanted software execution being a form of public-key cryptography at the hardware level -- effectively, for every processor to have its own unique instruction set, so that only code compiled for that particular processor can be run on it. (Maybe there would need to be a compatibility-mode switch, to install a kernel and a compiler just to get you going; but please let it be something like a jumper on the motherboard which you have to put on -- certainly there should be no way that software could subvert this security feature.) Also, the installation of new software should require a conscious action on the part of the user, and involve a hardware operation -- such as operating a normally-concealed switch. If you bought a new computer, you would have to recompile all your software from source, but that's a small price to pay. Alternatively, you could allow the user to flash the thing with a new key pair; so you could just give your new computer the same instruction set as the old one. Or a corporation with many desktops to administer need only give all their machines the same keys, and then compile application software once to run on any of them.
The average user won't really notice much. They will simply see an extra step taking place after downloading and before installing, as an automatic configure and make are performed. And they will have to validate the install, but I can't see how anybody would think that unusual: if it can affect the way your computer works, you damn well should have to tell it you're sure you want to go ahead.
Since every piece of downloaded software would have to include the source code, it would be much simpler to chase up infections if they occurred. And if every software installation required users to validate it, drive-by downloads -- arguably a form of virus infection -- would become a thing of the past.
It would still be possible to sell closed-source software; but you would either have to insist that users programmed their machine to a key pair you specified {which is great for locking out your competitors, but rather defeats the entire point of personalised instruction sets} or supply you with the public key of their machine so you can compile software for it {a little more secure for the user, but very expensive to implement}.
BTW, why is anti-virus software closed-source? What don't the likes of Symantec want us to know?
Schneier's Law states: "Anyone can come up with a security system so clever that he
can't see its flaws."
Even although the discs may be individually locked to a particular player, this will
not prevent copying and sharing. The fact is that somebody can get access
to an unencrypted signal, and it only takes one person to do it before the
whole effort is wasted.
Any watermarking they are talking about can be defeated. In fact, it's
likely that the recording technique will do this anyway if it lacks the bandwidth to
resolve the watermarking signal. Of course, if the watermarking is out-of-band (and
injected at the last stage) then this process can be subverted.
And if you can't hack machines, try hacking people -- have you met my alter ego? If
so, you told me something useful, so thank you! What's to stop the manufacturers of
those 6000 machines making a few extra, "special" ones that will play any disc meant
for any of the "real" ones? What's to stop the manufacturers of those special DVDs
from making a few extra, "special" ones that will play on any player?
In theory, you can use almost any pair of wires to carry a broadband signal. That's because in theory, any pair of wires are perfectly conductive. Also, as soon as an extra electron tries to enter one end, another one drops out the other end, instantaneously, and if you try to pull an electron out of one end, another will be sucked in at the other end, equally instantaneously.
It ain't like that in practice.
Imagine a drainpipe stuffed with tennis balls. When you try to push in an extra tennis ball, what happens is that all the other tennis balls give a little, and for one fleeting instant there really is an extra ball in the pipe. Then the balls expand back to normal size and one is shoved out the far end.
Now, any pair of wires will have a capacitance (since they are conductors separated by an insulator), an inductance (since they are wires; at low frequencies you need a full-on coil to get any effect, but at high frequencies any slight bend will do the job) and a resistance (since they aren't perfect conductors). It's what electrical engineers call a composite impedance, and what everybody else calls..... well, they don't have a word for it, they call an engineer to fix it. But what you need to remember is that the potential difference (voltage) across a capacitor can only change gradually, never suddenly; and the current through an inductor also can only change gradually, never suddenly.
For any given transmission line, if you stick a battery across the terminals at one end and a resistor across the terminals at the other end, look at each end with an oscilloscope and have some magical way of lining up the time axes, you won't see just a simple step change of voltage. When you apply the battery to the T.L., it looks like some composite impedance (which it is) and likely draws more current than the resistive load at the far end wants, since it's charging up the capacitance of the line -- or less than that, since it's charging through an inductance. One or the other phenomenon will win out every time.
Once the capacitance of the line has charged -- via the inductance and resistance of the line -- it then begins discharging into the resistor on the far end. Actually, it doesn't wait at all, but starts discharging as soon as it has begun charging. And what you may even see, is a pulse of current reflected back towards the battery, if too much current went in at first compared to what the resistor was expecting. You can even get multiple reflections if the first one isn't exactly right. What you essentially see on the scope traces is a damped sine wave at the frequency at which the resistance and capacitance of the line resonate -- and a delay between applying power from the source and seeing it at the load.
That's what you get with DC. With AC, the capacitance and inductance tend to distort the shape of the waveform, but not change the frequency -- though it's very likely that other frequencies will be added in. Also, anything under a few hundred kHz behaves mostly like DC -- albeit more-or-less-slowly-changing DC -- but broadband networks need carrier frequencies measured in MHz, and by the timed you get to that sort of frequency, the AC phenomena are well established.
Now if all you are concerned about is getting the maximum energy throughput, as are the electricity board for example, then you want to minimise resistance (which turns energy into heat -- capacitance and inductance just store it in electric and magnetic fields, respectively, then give it up again) even if that makes the line highly capacitive or inductive. All that will happen is that you'll get a huge reflection the first time you connect up, then a series of ever-decreasing ones, but most of the power from your source ends up in the load even if it takes awhile to make it down the line, and even if the shape of the waveform is significantly altered.
The ability to allow popups on specific sites is good. I wrote our in-house telesales software to use pop-up windows for Good {eliminating screen clutter, avoiding excessive HTTP POST requests}, rather than for Evil {displaying advertisements which cause users to avoid the products advertised}.
Er...the Earth isn't exactly using them. To imply that the use of petroleum products is somehow 'stealing' from the Earth is silly.
The Earth is using them: they are keeping carbon out of circulation. Burning fossil fuels adds CO2 to the atmosphere. Growing plants remove CO2 from the atmosphere; if the plant is later burned, then the same amount of CO2 is returned to the atmosphere. There is no net loss or gain. That is a good reason to stop extracting fossil fuels.
Continuing to use the present supply of fossil fuels will increase CO2 levels, and the only way to reduce them is to wait as long as it takes for more fossil fuels to form.
I am advocating a nationalised approach because I don't trust corporations. Somebody out there would want to find a way of holding the population at large to ransom -- effectively, to be the Microsoft of the energy industry. That must never be allowed to happen. There must be no question that the techniques involved in manufacturing "artificial oil" are the rightful property of the public, and not some corporation. Sometimes, you can make sure that something will get done by making certain that if it isn't done, somebody somewhere won't get a meal on their table. Other times, that simply won't work -- the lawyers will have a field day with all the IP litigation that, in the end, won't do anybody any good except lawyers. Everybody else will suffer as a result of patents blocking the best ways leading to second-rate solutions. That puts food on the lawyers' dinner tables.
Wouldn't it be better to ensure that this scenario can't happen, by using public money to start the process, and only allowing private companies to compete with the nationalised one once it is properly established?
At least have the courtesy to indicate which bits you disagree with. Assuming, of course, and contrary to what you have indicated by posting anonymously, you aren't just being a mindless troll. Otherwise you stand a good chance of being ignored.
You don't accomplish things by telling people they are wrong.
Being a numerical majority -- or even labouring under the impression that you are one -- does not make you right. When almost everyone believed the Sun revolved around the Earth, did it? The indisputable fact is that one day there will be no more oil left in the ground. Do you dispute that something needs to be done about that?
Why must we deplete more of the Earth's precious resources like this? Look, we know we're going to run out of oil sooner or later. That's a certainty. Why don't we just accept that now and get working on the alternatives, so we're actually ready for the day when the oil does run out?
The first phase should be to develop a "drop-in" replacement for petroleum fuels, manufactured from plants and waste products, and usable in existing engines with little to no alteration. The priority would be for public transport and emergency vehicles first, then private delivery vehicles, then private cars. Once such fuels are produced in sufficient quantities, petroleum exploration can be discontinued altogether, and we can add a statement to our foreign policy that we will not lend our support to any attempt on the part of a petroleum-consuming nation to wage war, if it is believed that the primary object of that war is to secure further supplies of petroleum.
The next phase will be to develop, in synergy, a range of fuels and engines which sacrifice backward-compatibility for greater efficiency. We then stop making the petroleum-compatible engines, and just produce enough "old skool" fuels to run all remaining petroleum-compatible engines into the ground.
All this can best be done under the framework of a nationalised industry (therefore no petty bickering, IP disputes, anti-competitive practices &c. as are so common in the private sector. All publicly-funded research would be licenced on a non-discriminatory basis so that private companies could enter a competitive market when the technology became established). We should pay for the replacement of petroleum by means of a tax on the use of petroleum -- and non-fossil fuels must be conspicuously exempt from such tax.
1. Install apache server.
2. Add the following line to httpd.conf:
AddType application/x-httpd-php.asp.aspx
3. Rewrite all their crappy ASP scripts in PHP.
4. ???
5. Profit!
To get this past management, you need to use some euphemisms as follows: Step 1 is "ordering a new little server for testing", and once it's in then you can re-install the real one.
Step 3 can be referred to as "auditing the code for security before system-wide deployment". As long as enough People Who Do The Real Work (tm) are in on it, nobody else need ever know. Actually, once you've been running on a proper industrial strength web server for a goodly while, you could switch them back to IIS/ASP just for shits and giggles -- see how long before someone complains!
The "== is asking, = is telling" trap seemed to fly over a lot of heads (all C programmers: I dare you to look me squarely in the eyes and tell me you have never done it yourself). It could have been spotted by a human, was my point.
The Thompson problem is "trivially" solved by coding your own C compiler from scratch in assembly language. If you have written it well, then you can be sure that any programme compiled using your homebrew compiler does exactly what the source code says it does.
By reading the source code to Thompson's compiler -- let's call it "ktcc.c" -- you can discern that if it were compiled cleanly {i.e. not using a compiler which silently modified the code en passant} it would be free of backdoors. The problem is that you cannot be certain that any compiler not written by you doesn't modify the code it compiles.
Writing a C compiler is hard work, however (hence my "speech marks" above), so we shall concentrate on a slightly simpler task: code a partial C interpreter which is aware of just enough of the language to enable it to run the compiler interpretatively. Let's call it 'ci'. Use your homebrew interpreter -- which you trust implicitly -- to run the "clean" compiler code. Now you can be sure that 'ktcc.c' under 'ci' (in other words, the clean compiler which is being interpreted by your interpreter) does exactly what it says -- which is to compile C code into its exactly equivalent assembly language representation.
Now you run "ktcc.c" through ("ktcc.c" under "ci") and you have a machine code programme which you can be sure does whatever "ktcc" ostensibly does.
You can only ever be sure that the object code does what the source code looks as though it should do, but that's surer than not knowing anything. I agree with you that "whether or not what the source code is saying is the same as your original specification" is a whole 'nother question, and have no suggestions as to how to proceed.
If that is not exactly what you wanted to do, then the bug is right there. If that is what you wanted to do, then there is no bug in this fragment. The information you have given is insufficient to determine anything more.
I basically wrote my company's software procurement policy and it goes something like this in order of priority:
Open source software implementing open standards
Software developed in-house
Closed source software implementing open standards
Non-computerised methods
Any software implementing closed standards
Of course there is some redundancy, because open source software can only ever implement open standards; but the priority is given to us knowing how our data is represented in case we ever need to access it ourselves. In practice, (4) and (5) seem consistently to be reversed -- but both are gradually being replaced by (2) anyway. If your company isn't run by hackers, then you might want to omit the even numbers when suggesting it to your own managers / directors.
Opera is closed source. For all you know it could be infested with just as many nasties as IE. I mean, it probably isn't; but you just don't know, do you?
Here is my postulate: The only way you can trust any software is through independent audit of the source code.
Whether that's you yourself, or somebody to whom you have paid a sum of money. Relying on what the software supplier -- or their hired goons -- have said, is asking for trouble. Somewhere in between the two extremes, lies a third option: just let enough ordinary people, independent of yourself and the author, look at the source code -- and cling with all your might to the assumption that if anybody spots something nasty, then they will speak out, just because they have no good reason not to.
If anyone knows another way that software can be made trustworthy, beside independent source audit, please feel free to enlighten me. Until such a time, I stand by my assertion that open source software is more likely to be trustworthy than closed source, varying with the validity of the aformentioned Great Assumption.
Don't feel sorry for them. They tried to make a closed-source product, and they got exactly what they deserved.
No person is an island. All the fruits of all human endeavour belong to all of humankind. If you try to deny me what rightfully belongs to me, rest assured that I will take it anyway: and though I will use as little force as possible, have no doubt that I will use as much as necessary.
Well, I'm rather assuming that most people are like me and will ignore advertisements anyway -- or even go so far as actively to avoid products where advertisements are being shoved down their throats. When you put it the way you do, it does make me wonder why they bother; but perhaps there really is a minority who take notice of adverts, and they're to blame for the crap with which the rest of us get bombarded.
When I want to buy something expensive, I'll generally search for impartial information before parting with my hard-earned, whether that be in magazines, on the Internet or by asking people; every manufacturer is going to say their $THING is the best there is anyway. On the other hand, if it's something cheap, I'll just get the nearest one. Advertising really isn't a factor in my decision-making processes (unless a company has really pissed me off with a particularly nasty advert -- then they can forget about me).
Excuse me being thick here, but how does anyone lose money -- or even make less money -- just because someone is not looking at adverts? What difference does it make whether people see the adverts and do not buy the products, or do not see the adverts?
So Google and others want to offer a 1GB e-mail service with indexing and searchability. Well, that's fine and dandy as far as ideas go, but you have to remember that this means your mail being stored on someone else's server; possibly for longer than you wanted -- and no way of being sure it's been deleted when you no longer want it.
I'm thinking about rolling my own searchable e-mail archive. And it won't be limited to one poxy gigabyte, either! I could register a domain and point the MX to my TV cable broadband connection, but the IP address is not guaranteed truly static, so there's a possibility that mail could get lost or even wind up on someone else's box -- so I'll trust my existing PO3 connection for now, counting it as another reason to add to my list in favour of a "proper" (read: business class) broadband connection. Next I'll hack Spamassassin to bits: when I'm done, it will store the header info and spamminess test results in a MySQL database, and the body in a text file. While I'm at it, I'll index the attachments in terms of mime type and encoding into another database. Finally, I'll set up some scripts to manage searching according to my databases and body contents.
Eventually -- which is to say, once I can go a month without resorting to phpMyAdmin or grep -- I'll release it; probably under a BSD-like licence, but with this extra little clause: "Any redistribution of the software or derived work in binary form must be accompanied by an offer of the source code, to be valid until the lapse of copyright on the work in question".
Consider the problem of fitting an ashtray to a motorcycle. It may not seem directly relevant, but bear with me..... it'll all make sense later.
The first, and most obvious problem is, how are you going to prevent the ash and nub-ends from blowing out all over the place? But even if you can sort that one out, then you have other problems to solve. Assuming you can make quite certain that bits of burning tobacco are going to stay well away from any inflammable fuel, then how do you put a cigarette between your lips while wearing a crash helmet -- never mind the non-trivial question of how to establish a burn and keep it alight in the equivalent of a 100km/h headwind. Assuming that you can manage workable solutions to those three problems, you still have yet another one: how are you supposed to wrap a Rizla paper around some tobacco, lick it and stick it, without taking your hands off the handlebars or your eyes off the road?
So, those motorcyclists who insist to smoke tend to stop and dismount; roll a cigarette, smoke it at a leisurely pace, perhaps engaging in polite conversation if they have been riding with a partner; trample the butt into the floor, and maybe take a leak before roaring off again. And that is why motorbikes don't have ashtrays.
Now, building a robot lawnmower is similar to fitting an ashtray on a motorcycle -- it sounds like a great idea at first, but there are just too many reasons, belonging to different domains, why it won't work. And the longer you think about it, the stupider the idea begins to look. For chuff's sake, if you really can't be bothered to cut your lawn, just pave over it! Or if you really must be high-tech about it, try and genetically engineer a slow-growing strain of grass that only needs cutting once or twice a year.
Do you seriously think that somebody looks at every single line of code in every OSS package? The high profile projects have eyes on them, it's true, but the average project is never analyzed except by other developers
Yes, some people do look intimately at OSS packages. And it only takes for one person to spot something bad. Plus, everything that ever happens in Userland potentially can be logged without the say-so of the process being logged.
You say "only developers" look at things closely, but there are a lot of small-time developers in the Open Source community. To characterise us all as freeloaders expecting something for nothing is no better than to characterise all Windows users as malware-writing script kiddies.
Slashdot Mirror
I can't see this working very well, somehow. Not if it works anything like an ordinary building lift ..... For one thing, how far down will the lift shaft have to go? And won't a metal box on the end of a hydraulic piston be a bit wobbly without some sort of superstructure around it? I wouldn't want to be anywhere near the pump if those hoses burst, either .....
It's the law! Try somewhere like the Office of Fair Trading .....
"Extended warranties" are just a cheap form of insurance policy, with a one-payment premium, no surrender value and {probably} a claims procedure designed to discourage claims. Great for the insurance company, but to get the best value out of it as a customer, you really need your own paper recycling facility. Yet, incredibly, people are stupid enough to pay for them. This suggests to me that they don't know how something works, whether that's the insurance or the electronics. But then again, there's a fine tradition of getting fat off other people's ignorance .....
..... drops sharply over the first few months, stays constant, begins rising again after a fixed time). In fact, we used to deliberately pre-stress many of the units we made, by running them for a few hours at high ambient temperature and then rapidly cooling them, before giving them a final test. Better an important component fails in our test chamber than on the customer's premises ..... especially if the thing is strapped to the engine of a muddy tractor ..... And for the failure rates we experienced and the cost of corrective action {most of the failures were repairable ..... unless they went on fire ..... it was always fun when that happened} this testing was still cheaper, and less work, than honouring a warranty.
Having worked in the electronics industry, I know about the bathtub curve (the probability of failure plotted against time resembles a side view of a bathtub
The point is, if just about anything electronic doesn't break within the first year -- where it's covered by law -- then it'll probably last ten years or more. {Of course you have to allow for the Six B's (batteries, bulbs, brushes, belts, bearings, blades); but since these are usually designed to be field-replaceable, they fall outside the scope of any warranty.} Extended warranties are almost never worthwhile -- if you ever have to claim on it, a new appliance even better than the one you bought probably will not cost you much more than the extended warranty plan.
In fact, that just gave me a blinding flash of inspiration. The real question we should be asking is, who gets fat off keeping users clueless?
The "installation requires a conscious act" feature means that you have to know about any software you install. Of course it's possible that this could be bypassed (a piece of software that was allowed to run could act as a crude emulator, doing things depending on the contents of disk/memory locations where normally non-executable data would reside) but still there would be some kind of audit trail. IMHO, the greater part of the problem is that people are too willing to run software on their machine that was compiled by someone else and never checked.
I see the real long term solution to the problem of unwanted software execution being a form of public-key cryptography at the hardware level -- effectively, for every processor to have its own unique instruction set, so that only code compiled for that particular processor can be run on it. (Maybe there would need to be a compatibility-mode switch, to install a kernel and a compiler just to get you going; but please let it be something like a jumper on the motherboard which you have to put on -- certainly there should be no way that software could subvert this security feature.) Also, the installation of new software should require a conscious action on the part of the user, and involve a hardware operation -- such as operating a normally-concealed switch. If you bought a new computer, you would have to recompile all your software from source, but that's a small price to pay. Alternatively, you could allow the user to flash the thing with a new key pair; so you could just give your new computer the same instruction set as the old one. Or a corporation with many desktops to administer need only give all their machines the same keys, and then compile application software once to run on any of them.
The average user won't really notice much. They will simply see an extra step taking place after downloading and before installing, as an automatic configure and make are performed. And they will have to validate the install, but I can't see how anybody would think that unusual: if it can affect the way your computer works, you damn well should have to tell it you're sure you want to go ahead.
Since every piece of downloaded software would have to include the source code, it would be much simpler to chase up infections if they occurred. And if every software installation required users to validate it, drive-by downloads -- arguably a form of virus infection -- would become a thing of the past.
It would still be possible to sell closed-source software; but you would either have to insist that users programmed their machine to a key pair you specified {which is great for locking out your competitors, but rather defeats the entire point of personalised instruction sets} or supply you with the public key of their machine so you can compile software for it {a little more secure for the user, but very expensive to implement}.
BTW, why is anti-virus software closed-source? What don't the likes of Symantec want us to know?
I'm asexual, you insensitive clod!
"You'll find gun nuts along with total lefties," Linus Torvalds, the creator of Linux, said in an e-mail message.
;-)
Any prizes for guessing who he was referring to?
Schneier's Law states: "Anyone can come up with a security system so clever that he can't see its flaws."
Even although the discs may be individually locked to a particular player, this will not prevent copying and sharing. The fact is that somebody can get access to an unencrypted signal, and it only takes one person to do it before the whole effort is wasted.
Any watermarking they are talking about can be defeated. In fact, it's likely that the recording technique will do this anyway if it lacks the bandwidth to resolve the watermarking signal. Of course, if the watermarking is out-of-band (and injected at the last stage) then this process can be subverted.
And if you can't hack machines, try hacking people -- have you met my alter ego? If so, you told me something useful, so thank you! What's to stop the manufacturers of those 6000 machines making a few extra, "special" ones that will play any disc meant for any of the "real" ones? What's to stop the manufacturers of those special DVDs from making a few extra, "special" ones that will play on any player?
In theory, you can use almost any pair of wires to carry a broadband signal. That's because in theory, any pair of wires are perfectly conductive. Also, as soon as an extra electron tries to enter one end, another one drops out the other end, instantaneously, and if you try to pull an electron out of one end, another will be sucked in at the other end, equally instantaneously.
..... well, they don't have a word for it, they call an engineer to fix it. But what you need to remember is that the potential difference (voltage) across a capacitor can only change gradually, never suddenly; and the current through an inductor also can only change gradually, never suddenly.
It ain't like that in practice.
Imagine a drainpipe stuffed with tennis balls. When you try to push in an extra tennis ball, what happens is that all the other tennis balls give a little, and for one fleeting instant there really is an extra ball in the pipe. Then the balls expand back to normal size and one is shoved out the far end.
Now, any pair of wires will have a capacitance (since they are conductors separated by an insulator), an inductance (since they are wires; at low frequencies you need a full-on coil to get any effect, but at high frequencies any slight bend will do the job) and a resistance (since they aren't perfect conductors). It's what electrical engineers call a composite impedance, and what everybody else calls
For any given transmission line, if you stick a battery across the terminals at one end and a resistor across the terminals at the other end, look at each end with an oscilloscope and have some magical way of lining up the time axes, you won't see just a simple step change of voltage. When you apply the battery to the T.L., it looks like some composite impedance (which it is) and likely draws more current than the resistive load at the far end wants, since it's charging up the capacitance of the line -- or less than that, since it's charging through an inductance. One or the other phenomenon will win out every time.
Once the capacitance of the line has charged -- via the inductance and resistance of the line -- it then begins discharging into the resistor on the far end. Actually, it doesn't wait at all, but starts discharging as soon as it has begun charging. And what you may even see, is a pulse of current reflected back towards the battery, if too much current went in at first compared to what the resistor was expecting. You can even get multiple reflections if the first one isn't exactly right. What you essentially see on the scope traces is a damped sine wave at the frequency at which the resistance and capacitance of the line resonate -- and a delay between applying power from the source and seeing it at the load.
That's what you get with DC. With AC, the capacitance and inductance tend to distort the shape of the waveform, but not change the frequency -- though it's very likely that other frequencies will be added in. Also, anything under a few hundred kHz behaves mostly like DC -- albeit more-or-less-slowly-changing DC -- but broadband networks need carrier frequencies measured in MHz, and by the timed you get to that sort of frequency, the AC phenomena are well established.
Now if all you are concerned about is getting the maximum energy throughput, as are the electricity board for example, then you want to minimise resistance (which turns energy into heat -- capacitance and inductance just store it in electric and magnetic fields, respectively, then give it up again) even if that makes the line highly capacitive or inductive. All that will happen is that you'll get a huge reflection the first time you connect up, then a series of ever-decreasing ones, but most of the power from your source ends up in the load even if it takes awhile to make it down the line, and even if the shape of the waveform is significantly altered.
If you want a transmission line that does not
The ability to allow popups on specific sites is good. I wrote our in-house telesales software to use pop-up windows for Good {eliminating screen clutter, avoiding excessive HTTP POST requests}, rather than for Evil {displaying advertisements which cause users to avoid the products advertised}.
Continuing to use the present supply of fossil fuels will increase CO2 levels, and the only way to reduce them is to wait as long as it takes for more fossil fuels to form.
I am advocating a nationalised approach because I don't trust corporations. Somebody out there would want to find a way of holding the population at large to ransom -- effectively, to be the Microsoft of the energy industry. That must never be allowed to happen. There must be no question that the techniques involved in manufacturing "artificial oil" are the rightful property of the public, and not some corporation. Sometimes, you can make sure that something will get done by making certain that if it isn't done, somebody somewhere won't get a meal on their table. Other times, that simply won't work -- the lawyers will have a field day with all the IP litigation that, in the end, won't do anybody any good except lawyers. Everybody else will suffer as a result of patents blocking the best ways leading to second-rate solutions. That puts food on the lawyers' dinner tables.
Wouldn't it be better to ensure that this scenario can't happen, by using public money to start the process, and only allowing private companies to compete with the nationalised one once it is properly established?
Why?! Why?! Why?!
Why must we deplete more of the Earth's precious resources like this? Look, we know we're going to run out of oil sooner or later. That's a certainty. Why don't we just accept that now and get working on the alternatives, so we're actually ready for the day when the oil does run out?
The first phase should be to develop a "drop-in" replacement for petroleum fuels, manufactured from plants and waste products, and usable in existing engines with little to no alteration. The priority would be for public transport and emergency vehicles first, then private delivery vehicles, then private cars. Once such fuels are produced in sufficient quantities, petroleum exploration can be discontinued altogether, and we can add a statement to our foreign policy that we will not lend our support to any attempt on the part of a petroleum-consuming nation to wage war, if it is believed that the primary object of that war is to secure further supplies of petroleum.
The next phase will be to develop, in synergy, a range of fuels and engines which sacrifice backward-compatibility for greater efficiency. We then stop making the petroleum-compatible engines, and just produce enough "old skool" fuels to run all remaining petroleum-compatible engines into the ground.
All this can best be done under the framework of a nationalised industry (therefore no petty bickering, IP disputes, anti-competitive practices &c. as are so common in the private sector. All publicly-funded research would be licenced on a non-discriminatory basis so that private companies could enter a competitive market when the technology became established). We should pay for the replacement of petroleum by means of a tax on the use of petroleum -- and non-fossil fuels must be conspicuously exempt from such tax.
2. Add the following line to httpd.conf: 3. Rewrite all their crappy ASP scripts in PHP.
4. ???
5. Profit!
To get this past management, you need to use some euphemisms as follows: Step 1 is "ordering a new little server for testing", and once it's in then you can re-install the real one. Step 3 can be referred to as "auditing the code for security before system-wide deployment". As long as enough People Who Do The Real Work (tm) are in on it, nobody else need ever know. Actually, once you've been running on a proper industrial strength web server for a goodly while, you could switch them back to IIS/ASP just for shits and giggles -- see how long before someone complains!
The "== is asking, = is telling" trap seemed to fly over a lot of heads (all C programmers: I dare you to look me squarely in the eyes and tell me you have never done it yourself). It could have been spotted by a human, was my point.
The Thompson problem is "trivially" solved by coding your own C compiler from scratch in assembly language. If you have written it well, then you can be sure that any programme compiled using your homebrew compiler does exactly what the source code says it does.
By reading the source code to Thompson's compiler -- let's call it "ktcc.c" -- you can discern that if it were compiled cleanly {i.e. not using a compiler which silently modified the code en passant} it would be free of backdoors. The problem is that you cannot be certain that any compiler not written by you doesn't modify the code it compiles.
Writing a C compiler is hard work, however (hence my "speech marks" above), so we shall concentrate on a slightly simpler task: code a partial C interpreter which is aware of just enough of the language to enable it to run the compiler interpretatively. Let's call it 'ci'. Use your homebrew interpreter -- which you trust implicitly -- to run the "clean" compiler code. Now you can be sure that 'ktcc.c' under 'ci' (in other words, the clean compiler which is being interpreted by your interpreter) does exactly what it says -- which is to compile C code into its exactly equivalent assembly language representation.
Now you run "ktcc.c" through ("ktcc.c" under "ci") and you have a machine code programme which you can be sure does whatever "ktcc" ostensibly does.
You can only ever be sure that the object code does what the source code looks as though it should do, but that's surer than not knowing anything. I agree with you that "whether or not what the source code is saying is the same as your original specification" is a whole 'nother question, and have no suggestions as to how to proceed.
- Open source software implementing open standards
- Software developed in-house
- Closed source software implementing open standards
- Non-computerised methods
- Any software implementing closed standards
Of course there is some redundancy, because open source software can only ever implement open standards; but the priority is given to us knowing how our data is represented in case we ever need to access it ourselves. In practice, (4) and (5) seem consistently to be reversed -- but both are gradually being replaced by (2) anyway. If your company isn't run by hackers, then you might want to omit the even numbers when suggesting it to your own managers / directors.Opera is closed source. For all you know it could be infested with just as many nasties as IE. I mean, it probably isn't; but you just don't know, do you?
Here is my postulate: The only way you can trust any software is through independent audit of the source code.
Whether that's you yourself, or somebody to whom you have paid a sum of money. Relying on what the software supplier -- or their hired goons -- have said, is asking for trouble. Somewhere in between the two extremes, lies a third option: just let enough ordinary people, independent of yourself and the author, look at the source code -- and cling with all your might to the assumption that if anybody spots something nasty, then they will speak out, just because they have no good reason not to.
If anyone knows another way that software can be made trustworthy, beside independent source audit, please feel free to enlighten me. Until such a time, I stand by my assertion that open source software is more likely to be trustworthy than closed source, varying with the validity of the aformentioned Great Assumption.
Don't feel sorry for them. They tried to make a closed-source product, and they got exactly what they deserved.
No person is an island. All the fruits of all human endeavour belong to all of humankind. If you try to deny me what rightfully belongs to me, rest assured that I will take it anyway: and though I will use as little force as possible, have no doubt that I will use as much as necessary.
Well, I'm rather assuming that most people are like me and will ignore advertisements anyway -- or even go so far as actively to avoid products where advertisements are being shoved down their throats. When you put it the way you do, it does make me wonder why they bother; but perhaps there really is a minority who take notice of adverts, and they're to blame for the crap with which the rest of us get bombarded.
When I want to buy something expensive, I'll generally search for impartial information before parting with my hard-earned, whether that be in magazines, on the Internet or by asking people; every manufacturer is going to say their $THING is the best there is anyway. On the other hand, if it's something cheap, I'll just get the nearest one. Advertising really isn't a factor in my decision-making processes (unless a company has really pissed me off with a particularly nasty advert -- then they can forget about me).
Excuse me being thick here, but how does anyone lose money -- or even make less money -- just because someone is not looking at adverts? What difference does it make whether people see the adverts and do not buy the products, or do not see the adverts?
So Google and others want to offer a 1GB e-mail service with indexing and searchability. Well, that's fine and dandy as far as ideas go, but you have to remember that this means your mail being stored on someone else's server; possibly for longer than you wanted -- and no way of being sure it's been deleted when you no longer want it.
I'm thinking about rolling my own searchable e-mail archive. And it won't be limited to one poxy gigabyte, either! I could register a domain and point the MX to my TV cable broadband connection, but the IP address is not guaranteed truly static, so there's a possibility that mail could get lost or even wind up on someone else's box -- so I'll trust my existing PO3 connection for now, counting it as another reason to add to my list in favour of a "proper" (read: business class) broadband connection. Next I'll hack Spamassassin to bits: when I'm done, it will store the header info and spamminess test results in a MySQL database, and the body in a text file. While I'm at it, I'll index the attachments in terms of mime type and encoding into another database. Finally, I'll set up some scripts to manage searching according to my databases and body contents.
Eventually -- which is to say, once I can go a month without resorting to phpMyAdmin or grep -- I'll release it; probably under a BSD-like licence, but with this extra little clause: "Any redistribution of the software or derived work in binary form must be accompanied by an offer of the source code, to be valid until the lapse of copyright on the work in question".
Consider the problem of fitting an ashtray to a motorcycle. It may not seem directly relevant, but bear with me ..... it'll all make sense later.
The first, and most obvious problem is, how are you going to prevent the ash and nub-ends from blowing out all over the place? But even if you can sort that one out, then you have other problems to solve. Assuming you can make quite certain that bits of burning tobacco are going to stay well away from any inflammable fuel, then how do you put a cigarette between your lips while wearing a crash helmet -- never mind the non-trivial question of how to establish a burn and keep it alight in the equivalent of a 100km/h headwind. Assuming that you can manage workable solutions to those three problems, you still have yet another one: how are you supposed to wrap a Rizla paper around some tobacco, lick it and stick it, without taking your hands off the handlebars or your eyes off the road?
So, those motorcyclists who insist to smoke tend to stop and dismount; roll a cigarette, smoke it at a leisurely pace, perhaps engaging in polite conversation if they have been riding with a partner; trample the butt into the floor, and maybe take a leak before roaring off again. And that is why motorbikes don't have ashtrays.
Now, building a robot lawnmower is similar to fitting an ashtray on a motorcycle -- it sounds like a great idea at first, but there are just too many reasons, belonging to different domains, why it won't work. And the longer you think about it, the stupider the idea begins to look. For chuff's sake, if you really can't be bothered to cut your lawn, just pave over it! Or if you really must be high-tech about it, try and genetically engineer a slow-growing strain of grass that only needs cutting once or twice a year.
You say "only developers" look at things closely, but there are a lot of small-time developers in the Open Source community. To characterise us all as freeloaders expecting something for nothing is no better than to characterise all Windows users as malware-writing script kiddies.