Eiffel? No, they wanted something that would actually run.
That's why people still use languages like C. It's quick to get a program together, even if it doesn't do exactly what you wanted first time. You fix the mistakes and try again. Each time you go around the loop, there should be fewer bugs (but Sod's Law says that each one will take longer to find). After just a few generations, you end up with a mostly-usable program.
With all these fancy-arsed "designed so mistakes are impossible" languages, you can spend longer trying to write a "demonstrably-correct-first-time" program than you would chasing down bugs in a nearly-right one. Or at least, that's what it feels like.
Actually, the first time this happened was in the UK.
Way back in 1992 or 1993 or thereabouts (sometime between Tracey Langton going upstairs to get a book and coming back down following an apparent head transplant), there was a fictitious supermarket called "Bettabuy" in Coronation Street, managed by Reg Holdsworth. The scenes were filmed on location in a branch of Morrisons. Morrisons launched a range of "economy" products (you know; the ones that are packaged to look like UN disaster relief, in the hope that you'll find a few extra pennies to rub together and buy something that doesn't mark you out to the checkout operator and all the other customers in the store as either a miser or a pov) under the name "Bettabuy" in honour of this.
It somehow managed to slip under the radar (product placement is illegal on British telly, even on the stations which accept advertisements; quiz shows are not allowed to announce the names of the sponsors of their prizes, and even mentioning specific brand names is frowned upon) probably because the product being advertised was one that people would actively avoid if given the choice.
The security of Public Key Encryption depends on you not being able to determine, by inspection alone, how to invert the encryption function. What works so well in current systems is that modulo arithmetic is used -- basically, you have a numbering system that "wraps around" at some point and goes back to zero (like the old Atari 2600 games which only counted scores up to 9999). The encryption function is
Y = (x ** a) % c
implying that the public key tells you a and c; the decryption function is
Y = (x ** b) % c
and the private key tells you b and c; and a, b and c are chosen at the time of key generation such that
(((x ** a) % c) ** b) % c == (((x ** b) % c) ** a) % c == x
Now, when you actually transmit the message, you throw away some important information: you leave out how many times the counter wrapped around. All you have is Y, where
Y = x ** a - d * c
You know a and c, but you don't know d. If you have the proper decryption function, you don't need d. But with only the encryption function available, you end up with fewer equations than variables.
If the checking is being done remotely, then your computer must be sending properly-formed packets down the network -- because properly-formed packets are the only thing you can send over the network. That kind of nullifies the address-knocking scheme (it doesn't matter what language the Natives speak amongst themselves, if it has to be translated into English before the messenger can deliver it to their Chief far away). There's still a chink in the armour.
TPM is beatable. I'd even go so far as to say "trivially", as long as you understand that I mean that in the strict mathematical sense. Hell, even my own Trusted Computing idea -- which would be where every single CPU had a different instruction set and addressing schema, and could only run code compiled for it, thus precluding distribution of software in binary form; unlike Microsoft's idea, this one is strictly about you, the owner of the computer having absolute control of whatever runs on it -- is beatable, if users are careless enough.
Whatever happens, the software is looking for a particular response from the TPM chip -- even if it asserts the "challenge" indirectly by address-knocking or something. You can determine from the software what it's looking for, and feed it the right things.
To all intents and purposes, TPM is just a password embedded into the motherboard. All you have to do is examine the hash function and the expected value, and then you can create something that hashes to the same thing. The hash function probably won't be very big in terms of code size. Because it absolutely has to be "live" while the check is being done, it can't be held encrypted, at least not during that phase. It may well be re-scrambled as soon as it finishes.
But maybe you don't even have to brute-force the password..... because a successful comparison will set a status flag somewhere. Every so often, that flag gets checked and if it is not set, the processor chucks an exception. By the very definition of what virtualisation is, you can make changes deep within the virtualised processor from outside the virtual environment -- that is to say, you can alter status bits, register contents, even the IP; anything really, without so much as missing a clock cycle within the virtual processor.
Except that there is no way for software to determine whether or not it is running in a virtualised environment. (If there was, that would indicate your virtualisation is not being done right.) Your virtual environment just has to listen for the challenges and send the correct responses. And you can know, by examining the software which is running within the virtualised environment, exactly what response it is expecting.
The point is that with something like public-key encryption using an Open Source algorithm, the only thing that has to be kept secret, and does not even have to be shared with the other party, is the decryption key. And you can prove that (if you've studied enough maths). You are in total charge of the only thing that needs to be kept secret for your communications to be secure.
Whereas, with something like Skype -- which uses a closed-source implementation of christ-knows-what algorithm and handles its own key generation -- there's no way to be sure exactly what needs to be kept secret, or even who else knows it (without reading and understanding the Source Code, you can't be sure that the decryption key is not being made available to anyone else). That's "security by obscurity": someone other than you is in charge of the secrets.
See, that's the beginning and end of the problem: the closedness of Windows. If when you bought a Windows licence you got the Source Code (but weren't allowed to pass on copies to anyone else; not giving out the Source Code works really well to prevent that, doesn't it?) then at least everyone could choose what architecture they were going to run it on. Microsoft's obstinacy with the Source Code crippled Alpha. Anyone who designs a new, 80x86-incompatible processor architecture finds themself in approximately the same situation as a high-rise flat resident who wins a canoe in a radio phone-in competition.
Yes, I'm from the UK (as my e-mail address suggests).
At the moment, we have a confusing situation of being halfway between two systems; it seems to be that the units are selected for the purpose of keeping the numbers within a certain range. Children's clothes sizes are given in centimetres, but adults' clothes sizes are given in inches. The doctor will weigh you in kilos, measure you in centimetres, then convert it to stones and feet for you. Temperatures are given in Fahrenheit if it's a hot day ("ninety in the shade") but in Celsius if it's a cold day ("it's minus five out"). Small amounts of drugs are sold in grammes (except hashish which seems always to be sold in multiples of "1/8 ounce", though nearer in practice to 3g. than 3.5g.), larger amounts in ounces (though again not always a "proper" 28.35 gramme ounce), and still larger amounts in kilos -- never pounds. Milk is delivered by the milkman in pint bottles (though they are labelled as "568ml"; newer ones have dropped the word "pint" altogether) but bought from a supermarket in cartons of one or two litres. Building materials come in quasi-imperial metric sizes (multiples of 300mm). Copper pipes are sized in millimetres OD; but sometimes in older buildings you will find older ones which were sized in inches ID and while 15mm. OD is dimensionally compatible with 0.5in ID, 22mm. ID is slightly larger than 0.75in ID -- just enough that 22mm. won't fit into a 0.75in. joint at all, while 0.75in. will fit into a 22mm. joint but the solder won't draw properly and will eventually leak. (And there is a fair bit of 0.75in / 22mm. plumbing around, as it used to be compulsory to supply a water heater at low pressure from a cistern -- never directly from the main -- and you can't get the flow rate through the thinner pipe.) Electric heaters are rated in kilowatts, and electricity is sold by the kilowatt-hour, but gas heaters are rated in BTU/h. Gas is sold by the kWh, but the meter measures cubic feet or cubic metres (depending on its age) and the conversion is shown on your bill. Petrol is sold by the litre (and bought by the poundsworth -- drivers invariably put £20.01 in their car, the extra penny being clocked up by the pump as the nozzle is replaced), but fuel economy is measured in miles per gallon. Road signs are in miles, but running races -- even those taking places on roads -- are in kilometres. Clearance signs on bridges &c. usually are given in both feet and metres (except really old ones in rural areas where there have been no accidents and hence the sign has stayed), but sometimes the conversion is inaccurate by a few centimetres (enough to get you stuck if you were relying on the larger of the two being correct).
All things considered, you might as well just point and say "about so big", or "As much as I can buy for a fiver".
Yes, but Ubuntu installs both 32- and 64-bit libraries. It pretends the 32-bit libraries for a 64-bit system are a 64-bit package, and that 32-bit closed source apps (as packaged for Ubuntu) are 64-bit packages which depend on the package containing the 32-bit libraries.
The problem is that you can't say for definite what the intrinsic value of a precious metal is; or that a mole of gold is and always will be worth the same amount as x moles of silver (and if you did, you could bet some smarmy bastard would try to redefine Avogadro's constant in his own favour). But you can say for definite exactly what a kilowatt-hour is.
Modern "80x86" processors actually have a RISC core emulating 80x86 CISC instructions. That can't possibly be efficient: there are some occasions when you don't need every bit of an 80x86 instruction to happen (for instance, ADC sets the carry flag, but the next instruction may not care about the state of the carry flag). Although the "interpreter" -- because that's what it really is -- might well be able to optimise out some microinstructions on-the-fly, it almost certainly isn't looking far enough ahead to be certain about that.
Native code running directly on the underlying RISC core, if there was a way to do it, ought to be faster than emulated 80x86 code. A lot faster, if the compiler is good.
Really, the only reason 80x86 (which really is a truly horrible design, mostly cruft and bodges upon bodges) is still popular at all, is to allow Microsoft to keep the Source Code of Windows secret. The BSDs and Linux don't have any such requirement -- the Source Code is readily available, and they can and do run on almost any processor architecture. AMD's 64-bit architecture is a little cleaner but still held back by the need to implement 32-bit instructions.
Think what we could do with something like ARM, but built in straight 64-bit (i.e. ditch byte addressing and deal strictly in 64-bit words) and going back to Furber and Wilson's original concepts which eschewed complications such as hardware multiply and divide precisely because software implementations can be quicker for shorter word lengths (multiplying two 8-bit values requires only 8 additions, but a 64-bit hardware multiplier will always do 64 anyway). If 64 bits really is too much for one instruction, then maybe squeeze in two 32-bit instructions that then (attempt to) execute in parallel (so must be writing into different registers, unless the condition fields -- with ARM, every instruction is conditional, though there are "AL" and "NV" conditions that execute always and never respectively -- are such that both won't be satisfied together). This would need two logic matrices, but they could share a common register file.
If you don't mind the idea of a chip which lies about its own capabilities, go ahead and buy a VIA CPU. They detect as 80686, but in fact only implement a partial subset of 80686 instructions. This got me when I tried to build Asterisk to run on a little mini-thing I had lying around.
It was easy enough to fix with a configure option, and there was stuff about it on the Wiki when I looked, but still. Back in the days when most cars only had four gears and a five-speed transmission was an extra, at least the four-speed variants didn't have the non-existent "5" position marked on the knob (which could have caused a nasty accident had someone attempted to engage 5th gear on a motorway or something).
That's because OpenSUSE isn't a true 64-bit Operating System. It has a 64-bit kernel, but both 32- and 64-bit libraries and can run 32- or 64- bit code (except for a handful of closed-source 32-bit programs that use one or more of the instructions that are not available when the processor is running in 64-bit mode). In fact, most "64-bit" GNU/Linux OSes (except Debian) are hybrid 32/64-bit.
64-bit Debian is a 64-bit Operating System in the way that a Continental tape measure is metric. That is, it has a 64-bit kernel and 64-bit libraries, and only 64-bit libraries (/lib64 exists but is just a symlink to/lib). The idea is that you can make "32-bit software" run on it simply by recompiling. Hence, no need for two versions of the same library and problems if they get out-of-sync. The recommended (or, at any rate, least-proscribed; Debian are known for their puritanical stance on non-Free software) method for running closed-source 32-bit applications on 64-bit Debian is to set up a chroot environment with its own 32-bit libraries.
64-bit Ubuntu does it the SUSE way rather than the Debian way.
In that case, don't touch it with a barge pole. Anything that searches inside files and for which you haven't seen the Source Code is a massive security risk.
I checked that script, but it still requires a package manager; it only works with apt, yum, yast, urpmi or rpm. Also, it wants root privileges.
But don't worry! You can install.deb packages on Slackware with minimal effort. They are actually "ar" archives that you can open with ar -x foo.deb. Then you will see files called "debian-binary" (just a format specifier, which you may safely ignore), "control.tar.gz" (which you can leave alone for now) and "data.tar.gz". The last is the interesting one; and in fact, being a gzipped tarball which needs to be unpacked into the root directory, is embarrassingly similar to a Slackware package. Just tar xvzf data.tar.gz -C/ to unpack it. With any luck, your file layout will resemble what Debian were expecting closely enough for it to work. The "control.tar.gz" archive contains Debian metadata, MD5 checksums and essential scripts which are run when installing / removing.
The Linux version might compile fine on Solaris; or at any rate, the necessary tweak may be a trivial one (usually some d.h. hard-codes a constant in somewhere instead of getting it from the header files). Linux and Solaris aren't too different, esp. if you have the GNU toolchain installed. Give it a try.
Er, they have already. Plants have been doing it for years!
Actually they turn CO2 and H2O into carbohydrates and oxygen, but you can turn carbohydrates into hydrocarbons, and eventually pure carbon, by burying them deep underground for millions of years and waiting for heat and pressure to do their stuff. First you get natural gas; keep going a bit longer and you get oil; and if you go on long enough, and you really pile on the pressure, you can get coal or even diamonds.
Um, 4.54 litres is one gallon, not 1.2 gallons. A pint of water weighs a pound and a quarter (which, I suppose, is why the twentieth part of a pint is called a fluid ounce: and indeed, twenty ounces are a pound and a quarter [or a pound and two thirds if you were using troy weights, where there are only twelve ounces to the pound and a pound troy is only 373g. as opposed to 454g. for an ordinary pound]). So eight pints (= 1 gallon) of water weigh ten pounds.
Now, when you had money in pounds, shillings and pence (where £1 = 20/- and 1/- = 12d) and mass in pounds and ounces, it made it really easy for shopkeepers to rip you off: you have to convert ounces to fractions of pounds and pounds, shillings and pence per pound to pence per pound, then convert pence back to pounds, shillings and pence. You could possibly have taken an autistic kid shopping with you, but autism did not exist in those days (it seems to have been invented around the same time that schools stopped using the Cane). Now it's all £p (where £1 = 100p) and kg, you can at least check the maths directly using a cheap pocket calculator.
And yet people still have the gall to say the metric system is complicated! Personally I think we should ban them from using electrical units such as the volt, ampere and watt, which belong officially to SI, and make them measure potential differences in Daniells, current in ounces of electrons per second and power in BTU per hour.
Slashdot Mirror
Eiffel? No, they wanted something that would actually run.
That's why people still use languages like C. It's quick to get a program together, even if it doesn't do exactly what you wanted first time. You fix the mistakes and try again. Each time you go around the loop, there should be fewer bugs (but Sod's Law says that each one will take longer to find). After just a few generations, you end up with a mostly-usable program.
With all these fancy-arsed "designed so mistakes are impossible" languages, you can spend longer trying to write a "demonstrably-correct-first-time" program than you would chasing down bugs in a nearly-right one. Or at least, that's what it feels like.
Actually, the first time this happened was in the UK.
Way back in 1992 or 1993 or thereabouts (sometime between Tracey Langton going upstairs to get a book and coming back down following an apparent head transplant), there was a fictitious supermarket called "Bettabuy" in Coronation Street, managed by Reg Holdsworth. The scenes were filmed on location in a branch of Morrisons. Morrisons launched a range of "economy" products (you know; the ones that are packaged to look like UN disaster relief, in the hope that you'll find a few extra pennies to rub together and buy something that doesn't mark you out to the checkout operator and all the other customers in the store as either a miser or a pov) under the name "Bettabuy" in honour of this.
It somehow managed to slip under the radar (product placement is illegal on British telly, even on the stations which accept advertisements; quiz shows are not allowed to announce the names of the sponsors of their prizes, and even mentioning specific brand names is frowned upon) probably because the product being advertised was one that people would actively avoid if given the choice.
Not in the UK or Europe, no. It runs afoul of consumer protection and environmental legislation.
If the checking is being done remotely, then your computer must be sending properly-formed packets down the network -- because properly-formed packets are the only thing you can send over the network. That kind of nullifies the address-knocking scheme (it doesn't matter what language the Natives speak amongst themselves, if it has to be translated into English before the messenger can deliver it to their Chief far away). There's still a chink in the armour.
TPM is beatable. I'd even go so far as to say "trivially", as long as you understand that I mean that in the strict mathematical sense. Hell, even my own Trusted Computing idea -- which would be where every single CPU had a different instruction set and addressing schema, and could only run code compiled for it, thus precluding distribution of software in binary form; unlike Microsoft's idea, this one is strictly about you, the owner of the computer having absolute control of whatever runs on it -- is beatable, if users are careless enough.
Whatever happens, the software is looking for a particular response from the TPM chip -- even if it asserts the "challenge" indirectly by address-knocking or something. You can determine from the software what it's looking for, and feed it the right things.
..... because a successful comparison will set a status flag somewhere. Every so often, that flag gets checked and if it is not set, the processor chucks an exception. By the very definition of what virtualisation is, you can make changes deep within the virtualised processor from outside the virtual environment -- that is to say, you can alter status bits, register contents, even the IP; anything really, without so much as missing a clock cycle within the virtual processor.
To all intents and purposes, TPM is just a password embedded into the motherboard. All you have to do is examine the hash function and the expected value, and then you can create something that hashes to the same thing. The hash function probably won't be very big in terms of code size. Because it absolutely has to be "live" while the check is being done, it can't be held encrypted, at least not during that phase. It may well be re-scrambled as soon as it finishes.
But maybe you don't even have to brute-force the password
Except that there is no way for software to determine whether or not it is running in a virtualised environment. (If there was, that would indicate your virtualisation is not being done right.) Your virtual environment just has to listen for the challenges and send the correct responses. And you can know, by examining the software which is running within the virtualised environment, exactly what response it is expecting.
Would that be one of those ATM machines where you type in your PIN number, then?
I seem to recall that they have their electronics on a single PCB board.
That'd be Hanlon's Razor -- "Never ascribe to malice that which can adequately be explained by incompetence".
The point is that with something like public-key encryption using an Open Source algorithm, the only thing that has to be kept secret, and does not even have to be shared with the other party, is the decryption key. And you can prove that (if you've studied enough maths). You are in total charge of the only thing that needs to be kept secret for your communications to be secure.
Whereas, with something like Skype -- which uses a closed-source implementation of christ-knows-what algorithm and handles its own key generation -- there's no way to be sure exactly what needs to be kept secret, or even who else knows it (without reading and understanding the Source Code, you can't be sure that the decryption key is not being made available to anyone else). That's "security by obscurity": someone other than you is in charge of the secrets.
See, that's the beginning and end of the problem: the closedness of Windows. If when you bought a Windows licence you got the Source Code (but weren't allowed to pass on copies to anyone else; not giving out the Source Code works really well to prevent that, doesn't it?) then at least everyone could choose what architecture they were going to run it on. Microsoft's obstinacy with the Source Code crippled Alpha. Anyone who designs a new, 80x86-incompatible processor architecture finds themself in approximately the same situation as a high-rise flat resident who wins a canoe in a radio phone-in competition.
Yes, I'm from the UK (as my e-mail address suggests).
At the moment, we have a confusing situation of being halfway between two systems; it seems to be that the units are selected for the purpose of keeping the numbers within a certain range. Children's clothes sizes are given in centimetres, but adults' clothes sizes are given in inches. The doctor will weigh you in kilos, measure you in centimetres, then convert it to stones and feet for you. Temperatures are given in Fahrenheit if it's a hot day ("ninety in the shade") but in Celsius if it's a cold day ("it's minus five out"). Small amounts of drugs are sold in grammes (except hashish which seems always to be sold in multiples of "1/8 ounce", though nearer in practice to 3g. than 3.5g.), larger amounts in ounces (though again not always a "proper" 28.35 gramme ounce), and still larger amounts in kilos -- never pounds. Milk is delivered by the milkman in pint bottles (though they are labelled as "568ml"; newer ones have dropped the word "pint" altogether) but bought from a supermarket in cartons of one or two litres. Building materials come in quasi-imperial metric sizes (multiples of 300mm). Copper pipes are sized in millimetres OD; but sometimes in older buildings you will find older ones which were sized in inches ID and while 15mm. OD is dimensionally compatible with 0.5in ID, 22mm. ID is slightly larger than 0.75in ID -- just enough that 22mm. won't fit into a 0.75in. joint at all, while 0.75in. will fit into a 22mm. joint but the solder won't draw properly and will eventually leak. (And there is a fair bit of 0.75in / 22mm. plumbing around, as it used to be compulsory to supply a water heater at low pressure from a cistern -- never directly from the main -- and you can't get the flow rate through the thinner pipe.) Electric heaters are rated in kilowatts, and electricity is sold by the kilowatt-hour, but gas heaters are rated in BTU/h. Gas is sold by the kWh, but the meter measures cubic feet or cubic metres (depending on its age) and the conversion is shown on your bill. Petrol is sold by the litre (and bought by the poundsworth -- drivers invariably put £20.01 in their car, the extra penny being clocked up by the pump as the nozzle is replaced), but fuel economy is measured in miles per gallon. Road signs are in miles, but running races -- even those taking places on roads -- are in kilometres. Clearance signs on bridges &c. usually are given in both feet and metres (except really old ones in rural areas where there have been no accidents and hence the sign has stayed), but sometimes the conversion is inaccurate by a few centimetres (enough to get you stuck if you were relying on the larger of the two being correct).
All things considered, you might as well just point and say "about so big", or "As much as I can buy for a fiver".
Yes, but Ubuntu installs both 32- and 64-bit libraries. It pretends the 32-bit libraries for a 64-bit system are a 64-bit package, and that 32-bit closed source apps (as packaged for Ubuntu) are 64-bit packages which depend on the package containing the 32-bit libraries.
The problem is that you can't say for definite what the intrinsic value of a precious metal is; or that a mole of gold is and always will be worth the same amount as x moles of silver (and if you did, you could bet some smarmy bastard would try to redefine Avogadro's constant in his own favour). But you can say for definite exactly what a kilowatt-hour is.
Modern "80x86" processors actually have a RISC core emulating 80x86 CISC instructions. That can't possibly be efficient: there are some occasions when you don't need every bit of an 80x86 instruction to happen (for instance, ADC sets the carry flag, but the next instruction may not care about the state of the carry flag). Although the "interpreter" -- because that's what it really is -- might well be able to optimise out some microinstructions on-the-fly, it almost certainly isn't looking far enough ahead to be certain about that.
Native code running directly on the underlying RISC core, if there was a way to do it, ought to be faster than emulated 80x86 code. A lot faster, if the compiler is good.
Really, the only reason 80x86 (which really is a truly horrible design, mostly cruft and bodges upon bodges) is still popular at all, is to allow Microsoft to keep the Source Code of Windows secret. The BSDs and Linux don't have any such requirement -- the Source Code is readily available, and they can and do run on almost any processor architecture. AMD's 64-bit architecture is a little cleaner but still held back by the need to implement 32-bit instructions.
Think what we could do with something like ARM, but built in straight 64-bit (i.e. ditch byte addressing and deal strictly in 64-bit words) and going back to Furber and Wilson's original concepts which eschewed complications such as hardware multiply and divide precisely because software implementations can be quicker for shorter word lengths (multiplying two 8-bit values requires only 8 additions, but a 64-bit hardware multiplier will always do 64 anyway). If 64 bits really is too much for one instruction, then maybe squeeze in two 32-bit instructions that then (attempt to) execute in parallel (so must be writing into different registers, unless the condition fields -- with ARM, every instruction is conditional, though there are "AL" and "NV" conditions that execute always and never respectively -- are such that both won't be satisfied together). This would need two logic matrices, but they could share a common register file.
If you don't mind the idea of a chip which lies about its own capabilities, go ahead and buy a VIA CPU. They detect as 80686, but in fact only implement a partial subset of 80686 instructions. This got me when I tried to build Asterisk to run on a little mini-thing I had lying around.
It was easy enough to fix with a configure option, and there was stuff about it on the Wiki when I looked, but still. Back in the days when most cars only had four gears and a five-speed transmission was an extra, at least the four-speed variants didn't have the non-existent "5" position marked on the knob (which could have caused a nasty accident had someone attempted to engage 5th gear on a motorway or something).
That's because OpenSUSE isn't a true 64-bit Operating System. It has a 64-bit kernel, but both 32- and 64-bit libraries and can run 32- or 64- bit code (except for a handful of closed-source 32-bit programs that use one or more of the instructions that are not available when the processor is running in 64-bit mode). In fact, most "64-bit" GNU/Linux OSes (except Debian) are hybrid 32/64-bit.
/lib). The idea is that you can make "32-bit software" run on it simply by recompiling. Hence, no need for two versions of the same library and problems if they get out-of-sync. The recommended (or, at any rate, least-proscribed; Debian are known for their puritanical stance on non-Free software) method for running closed-source 32-bit applications on 64-bit Debian is to set up a chroot environment with its own 32-bit libraries.
64-bit Debian is a 64-bit Operating System in the way that a Continental tape measure is metric. That is, it has a 64-bit kernel and 64-bit libraries, and only 64-bit libraries (/lib64 exists but is just a symlink to
64-bit Ubuntu does it the SUSE way rather than the Debian way.
In that case, don't touch it with a barge pole. Anything that searches inside files and for which you haven't seen the Source Code is a massive security risk.
Oh, come on. If you're a Slackware user, you're unlikely to have any problem with that.
I checked that script, but it still requires a package manager; it only works with apt, yum, yast, urpmi or rpm. Also, it wants root privileges.
.deb packages on Slackware with minimal effort. They are actually "ar" archives that you can open with ar -x foo.deb. Then you will see files called "debian-binary" (just a format specifier, which you may safely ignore), "control.tar.gz" (which you can leave alone for now) and "data.tar.gz". The last is the interesting one; and in fact, being a gzipped tarball which needs to be unpacked into the root directory, is embarrassingly similar to a Slackware package. Just tar xvzf data.tar.gz -C/ to unpack it. With any luck, your file layout will resemble what Debian were expecting closely enough for it to work. The "control.tar.gz" archive contains Debian metadata, MD5 checksums and essential scripts which are run when installing / removing.
But don't worry! You can install
The Linux version might compile fine on Solaris; or at any rate, the necessary tweak may be a trivial one (usually some d.h. hard-codes a constant in somewhere instead of getting it from the header files). Linux and Solaris aren't too different, esp. if you have the GNU toolchain installed. Give it a try.
Er, they have already. Plants have been doing it for years!
Actually they turn CO2 and H2O into carbohydrates and oxygen, but you can turn carbohydrates into hydrocarbons, and eventually pure carbon, by burying them deep underground for millions of years and waiting for heat and pressure to do their stuff. First you get natural gas; keep going a bit longer and you get oil; and if you go on long enough, and you really pile on the pressure, you can get coal or even diamonds.
Um, 4.54 litres is one gallon, not 1.2 gallons. A pint of water weighs a pound and a quarter (which, I suppose, is why the twentieth part of a pint is called a fluid ounce: and indeed, twenty ounces are a pound and a quarter [or a pound and two thirds if you were using troy weights, where there are only twelve ounces to the pound and a pound troy is only 373g. as opposed to 454g. for an ordinary pound]). So eight pints (= 1 gallon) of water weigh ten pounds.
Now, when you had money in pounds, shillings and pence (where £1 = 20/- and 1/- = 12d) and mass in pounds and ounces, it made it really easy for shopkeepers to rip you off: you have to convert ounces to fractions of pounds and pounds, shillings and pence per pound to pence per pound, then convert pence back to pounds, shillings and pence. You could possibly have taken an autistic kid shopping with you, but autism did not exist in those days (it seems to have been invented around the same time that schools stopped using the Cane). Now it's all £p (where £1 = 100p) and kg, you can at least check the maths directly using a cheap pocket calculator.
And yet people still have the gall to say the metric system is complicated! Personally I think we should ban them from using electrical units such as the volt, ampere and watt, which belong officially to SI, and make them measure potential differences in Daniells, current in ounces of electrons per second and power in BTU per hour.
You're thinking mega-microwave. Which, of course, would just be a wave.
The real miracle would be to turn Strongbow into Dry Blackthorn.
(I can already do the reverse.)