I read Stallman's essays when I was younger {he's written a few more since then} and thought This is great, but it doesn't go far enough. We need to take by force what is rightfully ours. So I went about my way, exercising Freedoms 0 and 2 with or without anybody's -- but, it has to be said, towards the end, mostly Microsoft's -- sayso.
However, as I grew up I also realised the importance of Freedoms 1 and 3. In the 8-bit days I had dabbled with BASIC and machine code. The 16-bit years seemed somehow as though something was missing. I had this wonderful spanky new machine and yet I couldn't make it do exactly what I wanted it to do! I was all ready to pull out my old BBC model B from the loft, when it hit me. I wasn't hurting the software industry one iota by illegally copying their products -- I was just as dependent upon them as any paying customer. I needed Freedoms 1 and 3, and that meant I needed the source code. In the Beeb days, it was enough to disassemble a machine code game to make silly changes, like changing the keys or adding extra lives or disabling collision detection {with 32K of ram, and a framebuffer eating 20K of that and the OS eating another K or so for itself, the game was very hackable}. Or, of course, there would be listings printed in magazines, to be typed in over the course of several days; and these often could be improved upon. I realised I was missing Freedom 1 in a big way.
I had used VAX/VMS and UNIX at university, some years before. Though I actually preferred the former, because it used words instead of symbols, the latter was the direction in which all things were going {and VMS even had a "unix emulator" -- append/CLI=SHELL to your username when logging in}. I had even tried Linux -- with plenty of help from someone else. It must have been about 1992 or 1993. He booted a floppy in a PC in a lab, and it came up with a Unix login prompt. You could telnet to it {it was safe to send a plaintext password in those days} from anywhere in the world. And run vi on it. Vi was not as nice to use as EVE -- but you could run vi with just about any terminal that supported even rudimentary cursor positioning.
When a friend of mine gave Linux a serious try, I decided that it must be worth a go. In the end I set up an old machine running Linux -- Debian slink; or it might have been potato, I think -- as a "modem sharer" so that my Windows 95 box and any machine I borrowed could both use my single, 56K dial-up line. When my ISP of the day introduced individual cgi-bin directories, I set up apache and perl on my "modem sharer" so it could be used as a testing environment for my scripts.
And when I bought an Athlon XP 2000+, I knew I had to make a serious decision. Would I dual-boot Linux and Windows, or single-boot Linux? The Windows 98 SE installer disc answered that for me. It didn't believe there was such a thing as a whole gigabyte of memory on one motherboard, and barfed. I ended up installing Mandrake 8.2, got for me by a broadband-enabled "warez n pr0n d00d".
And I never looked back. One day I picked up my e-mail using kMail. There was a message from my erstwhile ISP asking if I knew anybody who wanted a job doing a bit of programming and system maintenance. I said "yes, me!", and got the job.
As I remember, push-to-talk was how early two-way radios worked. The same circuit would act as a receiver or -- at the push of a button -- a transmitter. The same frequency was used for speech in both directions. The advent of cheap transistors with a few MHz of bandwidth led to cheap two-way radios being marketed as kids' toys. They were probably illegal as hell; but then, the batteries would barely last long enough for The Authorities to find anyone using them.
The very early VHF mobile phones {where you actually had to dial a different STD code, depending on the approximate location of the called party} were half-duplex, using a push-to-talk button embedded in a normal telephone handset {so more like a squeeze-to-talk}. Later VHF mobiles were still half-duplex, but used to autodetect a signal in the mic.
We have had full-duplex mobile voice calling for ages, so this seems like a backward step to me. Almost nobody uses a mobile phone for voice anyway in the UK, because it canes your credit.
Seriously, just buy a DVD+RW recorder {Argos have them for £79.99}. Connect it to your VCR with a SCART to SCART cable. Make sure to plug the TV aerial into the VCR so a picture will come out of it at first -- this will fool the copy protection circuit in the DVD+RW recorder into thinking the picture is "clean", it only checks for Macrovision when you first press RECORD {hey, the guys in Philips' labs -- all these machines use Philips chipsets -- have massive collections of Macrovision-encumbered VHS cassettes themselves, you know.....} Start the DVD recording, then play the VHS. Manually insert a chapter marker at the beginning of the movie and skip the crap next time you watch it, or mark the chapter 'hidden' if you can find the menu option to do so.
You could use your computer as a DVD recorder..... and you could use the saw blade on a Swiss Army knife for cutting down trees. But something that was designed for cutting down trees and only cutting down trees, will invariably do a better job of cutting down trees than something that was designed to be used for many different jobs. On the other hand, you won't have much joy getting a stone out of a horse's hoof with a chainsaw.....
On most cars, first is left and away from you, second left and towards you, third is in the middle and away, fourth in the middle and towards, fifth is right and away from you, and Neutral is in the middle where it moves freely left and right. The difference is in where they put Reverse.
You are attempting to apply Windows concepts to Linux, which is why you are going to be disappointed. Linux is not Windows.
I'm sick of car analogies, so I'll try a dog analogy. When you are training a dog, you can't apply two-legged concepts to it. The dog won't get them and you will end up pissing yourself off. You have to think in terms a dog will understand. A dog doesn't get the concept of punishment except right after the event {in which case it is just another case of cause and effect, this time an undesirable effect of a cause which it will endeavour not to repeat}. A dog doesn't see you getting a tin of dog food out of the cupboard and opening it; it sees you catching something and skinning it. A dog doesn't think it's a person: it thinks it's a wolf and you {despite the leg count} are the alpha wolf in its pack. {If you give it the wrong signals, it thinks it's in charge. And it probably won't know what to do, living in a two-legged environment, so it will mess up really badly.} And so on.
Every Linux distro has its own preferred method of installing packages. With Debian and Ubuntu, it's apt-get; with Gentoo, it's emerge; with Mandriva, it's configure my computer->install software; with SUSE, it's YAST. You didn't state what distribution you were using. If you were using GNOME, I'd guess probably Fedora or Ubuntu. But that's by the by. Your distribution has its own preferred way of installing software. {There are many ways to accomplish this task. The people who set up your distro picked a way they liked, and expect everyone else to do it that way. They were there first and they had to make some rules for the sake of their own sanity.}
With Windows the standard method of installing software is to download a self-extracting executable archive, which contains pre-compiled binaries and automatically installs them somewhere. This is possible because (1) Windows only runs on Pentium / Athlon-type processors, (2) every Windows installation has the same kernel call points, and (3) Windows is actually a little more flexible than Linux with respect to the locations of libraries -- by default, it will first look for a library in the same directory as the program that asked for it. On the downside, (2) means that the Windows XP kernel is cluttered up with remnants from Windows 2000, Me, NT, 98, 95 and 3.11; and (3) means that the hard drives of Windows machines are cluttered up with copies of the same libraries, installed in different locations by different programs.
With Linux, things are a lot more flexible in general -- in fact, Linux is known to run on at least a dozen incompatible architectures. So the canonical method of installing software is to download an archive which contains source code -- which will compile for whatever processor is in the target system, extract it, compile the source, linking it against the installed kernel and libraries, and install the freshly-created binaries. Usually a script is included which will check that the build environment is complete, to avoid disappointment: if you know how to interpret the error messages you get from an abortive attempt at compilation, then you can fix things and it will work next time you try.
However, if you can make certain assumptions about the target system, you can actually install pre-compiled binaries on a Linux system. If you are a distro maintainer, you have pretty much stipulated what versions of libraries and other important base tier software are going to be installed. You can compile binaries against this setup and they will install and run correctly on another machine with the same setup. Slackware.tgz packages contain just the files which need to be installed: if the file is unpacked in the root directory, then everything will be deposited in the right place. Debian's.deb files, and others'.rpm files, go a step better by incorporating some metadata wh
But a GM car is harder to drive than a Ford car! I'll prove it. Reverse on a Vauxhall or a Daewoo is left and away from you. Reverse on a Ford is right and towards you, opposite fifth, which is obviously the proper place where Reverse gear belongs. GM's way of doing it means four away and two towards, which is just horribly unbalanced!
You think that's bad? I visited an electronics superstore to return a faulty DVD+RW recorder. They were using a mainframe system for stock management -- with Windows PCs running a payware ANSI [VT320-class] terminal emulator.
{For the uninitiated,the Linux console natively supports ANSI escape sequences; and there exist more Open Source terminal emulators, ANSI and otherwise, than you can shake an actual real VT100 keyboard at.}
Unfortunately, science is not cool anymore. It's a victim of its own success; things which obey rules never really attract attention. If light suddenly decided not to travel in straight lines, or objects suddenly ceased to attract one another in proportion to the ratio of the product of their masses to the distance between them, that would get noticed. If you want to get into the papers for drawing a triangle, all you have to do is make sure that its angles add up to something other than 180 degrees. If the pressure in a fluid were to act more strongly in one direction than another, or a homogeneous filament suspended by its ends formed some other curve than y = k * (e ** x + e ** -x), no doubt somebody would be screaming for Something To Be Done. {Except they would not, because we'd all be dead}.
It probably doesn't help either that there is a public perception that scientists create things like nuclear weapons, genetically modified foods, climate change &c. and haven't yet given us the flying cars and wristwatch TV sets they promised us.
Pseudo-science, on the other hand, is cool. It attracts the kind of sad-acts who, no longer content with merely refusing to eat the same kinds of food as the rest of us or call their kids the same kinds of names as the rest of us, now apparently resent the concept of being bound by the same fundamental laws as the rest of us.
is really no more secure than having register_globals turned on in the first place. The real insecurity came from the order in which the variable sources were processed; by default a query string in a GET request would clobber a session variable. Doing GET first, then POST, then cookies and finally sessions fixes it {although you can't do some nifty tricks which are useful for testing}. So my preference is
variables_order = "EGPCS" register_globals = On
which gives me the best of both worlds; I'm not cluttering up my code reading form variables out of globals, but neither is it possible to override session variables with a query string.
Beside which, there is nothing quite so insecure as the fact that any PHP script running on the same server can fopen() any file in any other user's webspace -- and some cheap hosting companies really are stupid enough to use the same login and password for Linux login and MySQL database. And on Mandrake {not that anyone uses that in a serious hosting environment}, it was the default for any user to be able to use `poweroff` at the command line. I wonder if that included, or still includes, the Apache daemon's user?:)
People who fear non-GPL open source licenses fail to realize this; the fact that Apache hasn't been displaced by a closed-source fork should be proof enough that open source can work even when the license doesn't force people to keep the source open.
The Apache project, and the various BSD projects, work their collective bollocks off to make sure that if anyone tries to create a closed-source fork, they will have a superior open-source alternative.
As much as I admire all that hard work, I simply don't feel confident that I personally could go to such extreme lengths just to prevent code that I wrote for the benefit of all humanity from being locked up. Other people get to exercise their rights because I live up to the obligations incumbent upon me.
All closed-source software by definition abridges two of the Four Freedoms; and many EULAs would seek to abridge one or both of the other two if only they were legally enforceable. I would much prefer to see the Four Freedoms protected by the Law of the Land.
There are two tasks I do all the time with my digital photos: thumbnail creation and rotation. Both of these are done very easily with ImageMagick, which is probably on your installation CDs if not installed already.
To create a thumbnail of dimensions 160 by 120:
$ convert -resize 160x120 foo.jpg foo_tiny.jpg
To rotate a picture 90 degrees anti-clockwise:
$ mogrify -rotate -90 foo.jpg
These alone should be enough for most people and will save hours of fart-arsing around dragging and clicking. But if you happen to want to pull out a 200x100 pixel segment from (55, 668):
$ convert -crop 200x100+55+668 foo.jpg bar.jpg
If you like charcoal drawings, ytr this {change the 2 for different thickneses of charcoal stick}:
$ convert -charcoal 2 foo.jpg foo_charcoal.jpg
Of course there are more options you can use. If you have a GUI running, try:
$ display foo.jpg
Middle-click to magnify and get co-ordinates. Left-click for a menu. Everything you see in the menus can be done from the command line. The basic commands are mogrify {which takes one filename and overwrites the old file with the new}, convert {which takes two filenames, the first is the existing file and the second is the new filename to be created} and display {which takes as many filenames as you like and displays them one after another, press space to select}. They all take the same options; see manpage for details. Note that the arguments to convert need not be the same filetype; the input filetype is determined automagically and the output filetype is set according to the extension. This means you can do something like
Well, the thrill is in the hunt, not the kill. If you solve the problem, then you can't go looking for solutions anymore.
If the movie studios held private exhibitions just for critics {the way they usedta hafta do before VCRs and DVD players existed.....} then there would be no way that these "screeners" could leak out. But there would be a definite financial cost {in transport and accommodation expenses -- I'm presupposing the use of existing cinemas, owned by a subsidiary company of the studios, in the morning when they would normally be closed}, which would be greater than the immediate cost of shipping out recordings to the reviewers' homes. So the movie studios' shareholders would see real money going to waste. At least when they send out individual DVDs which get copied, it's only pretend money being lost through "piracy". And because it's pretend money, they can pretend it's as much or as little as they like.
But there's another reason not to clamp down on it altogether. The movie studios will never admit it, but "piracy" - up to a point - actually does them more good than it does harm. If somebody sees a "pirate" copy of a film with a certain actor | actress | director | tea boy, they may remember the name next time the same name comes around in another film; and this time around, they may be inclined to pay for it. Or they might tell their friends, who have so much hassle involved to get a "pirate" copy that they give up and pay for it. If the film comes around again in the cinemas, some people will go and pay just to watch it on a big screen. Still, and this point needs to be stressed, the vast majority of the people who watch "pirate" copies of films would simply have chosen to do without altogether if there were no "pirate" copies available. So not every "pirate" copy represents a lost sale. And some "pirate" copies actually represent successful free advertisements.
Yes, exactly so! I am proposing to recover a picture signal from the CRT drive signals {which must be "in the clear" *}. The scan coils {which move the electron beam side-to-side and up-and-down} carry the timing information. Note that in the CRT scan coils, we have a voltage which starts low, slowly but linearly rises and then falls suddenly; much faster in the H-coil {once for each line of picture} than the V-coil {once for each complete picture}. A real TV timing signal is just a pulse indicating the start of a line and a long pulse or burst of pulses indicating the start of a picture. The grid drive signals {which alter the strength of the red, green and blue electron beams} carry the RGB signals; but note that you need a higher voltage for dim and a lower voltage for bright. A real TV signal has 0V for off, going up to 5V for maximum brightness, on each of the red, green and blue pins; with a series impedance of 470 ohms {so giving 0.7V into 75 ohms}. So you need some simple signal conditioning, but it's nothing that cannot be done using a few inexpensive op-amps, resistors and capacitors. And then you have an RGB signal suitable for feeding into any fully-wired SCART socket.
* Barring the introduction of a protection method whereby the picture is displayed in scrambled form, and decoded in the brain of the viewer using a mild hallucinogenic drug and neuro-linguistic programming techniques. The drug could even be mixed with another drug, designed to react with growth hormone, to provide age restriction {a twelve-year-old has more growth hormone than a fifteen-year-old, who in turn has more than an eighteen-year-old} by inducing debilitating effects in a person too young to watch a 12 / 15 / 18 rated film. This would guarantee a further revenue source in sales of the viewing drug, as one viewing of the film requires one pill per person. The NLP would be performed from a chapter at the beginning of the disc {there are tremendous opportunities here for high-price, captive-audience advertising since it would be impossible to see the movie without undergoing the NLP}, and would wear off with the drug.
So, I bought into the legend. Well, I stand corrected now. It does sort of make me wonder what they will say about Linus when he is dead, though.....
[Tanenbaum's] claim was (and is) that microkernels were better, not that they were faster.
A faster kernel will nearly always be better in Real World applications, where speed is as make-or-break important as stability. But I can't argue that for learning about how things work a more modular approach - where you can just ignore whole chunks in the name of simplification - is a good thing.
And the success of Linux really doesn't address the fundamental design and architetural differences between micro and macrokernels at all.
Maybe not. For a truly valid experiment {as opposed to just observing that the most successful OSes generally tend to have monolithic kernels and making an inference from that}, you would have to simultaneously release two OSes -- one with a microkernel, one with a macrokernel, but otherwise identical -- and see which one took off.
Yes. There is a "plain text" version available on the scan coils {from which you can recover the H- and V- timing information -- in fact, the exact position of the electron beam at any instant} and the red, green and blue grid drives {from which you can recover the RGB video signals}.
A simple proof-of-concept device would consist of a sawn-off CRT neck, a piece of breadboard with mostly passives and a few op-amps, and a cable with an ordinary SCART plug on the end. Plug the fake CRT end into a TV set in place of the real CRT. Plug the SCART end into another, unmodified TV set.
The first TV set doesn't know that it is driving a fake picture tube. The second TV set only knows that it's getting an RGB signal.
NB. Most VCRs have only "partially wired" SCARTs which do not accept RGB input signals, but most DVD recorders have "fully wired" SCARTs: an RGB output for the TV set and an RGB input for a satellite decoder.
This does not surprise me. In my city there were plans for a power plant which would use household waste as a fuel. First there would be a multi-stage segregation process to divert glass, metal and some plastics for melting down; secondly a gasification stage converting organic matter to methane, and finally a turbo-charged, intercooled, internal combustion engine spinning an alternator at constant RPM.
The local Friends of the Earth miscategorised this as an incinerator, claiming that it would produce dioxins {about as much in one full year of running as 5 November} and CO2 {instead of an equal amount of CO2 which would no longer be produced from other power plants and some of which would be from non-fossil fuel sources due to the presence of plant and animal matter in the process feedstock}. When these arguments were shot down, they still claimed that the plant was a bad idea as by improving recycling rates it would encourage people to throw stuff away! In the end, the plant did not get built and people are still being poisoned both nearby {by leachate from landfill sites, which produce methane -- one molecule of CH4 is equivalent to 21 molecules of CO2 in terms of heat-trapping power} and far away {by mining metal ores to replace the recyclable metal being buried in landfill}. All to avoid a negligible effect on air quality in an area where the majority of the population smokes fags anyway.
There's no point even trying to reason with Greens, because they fundamentally don't get science.
No. You would be switching the kernel from Linux to Minix {or The Hurd}, whilst retaining a GNU userland. So you would be switching over to GNU/Minix, or GNU/Hurd.
There are two parts to an operating system; the kernel {which provides a very low level interface to the computer's hardware} and the userland {which provides an interface to people}. The GNU project has created a viable userland, but is still having difficulty producing a kernel. Linus Torvalds -- then a student of Tanenbaum -- created Linux, originally a simple kernel which has now grown into something much bigger.
When you type "ls" {which is a userland command} into the shell {another userland process, which accepts commands from users [by means of a call to the kernel], passes them to the process sheduler [another userland process..... often having PID=1 and capable to bring down a system if inelegantly terminated] and sends back the output generated from the command}, the "ls" command is invoked. The kernel checks to see if there is an undamaged copy of "ls" in memory already, and if not loads one. The "ls" command passes a call to the kernel to read the directory listing from the disk, then generates some human-readable output from this data. The shell calls the kernel to write this information to the screen.
It was when hackers wrapped a GNU userland around the Linux kernel that the magic really began to happen. Of course, you could just as easily wrap a GNU userland around the FreeBSD kernel, or a BSD userland around Linux, but GNU and Linux just hit it off the best.
The delicious irony of all this is that Linux really was first created just to prove a point: that a monolithic kernel could sometimes outperform a microkernel {which Tanenbaum disputed}. Though apparently counter-intuitive, this is not really all that surprising when you think about it a little harder: certain Typical Real Life Operations are predictable enough to optimise very hard, and a monolithic kernel naturally supports harder optimisation than a microkernel at the expense of some flexibility. If the operations you optimise hardest happen commonly enough, then the performance gain can be significant. {Cf. if you live in an area with plenty of sunshine, waste disposal by landfill, and your water heater runs on almost any fuel besides electricity, then terry nappies will definitely be greener; whereas if your household waste is burned in a reasonably modern power plant, your water heater is electric and prevailing weather conditions are such that you need to use a tumble drier for the majority of your washing loads, disposables might work out better.}
If you don't like the licence, don't use the software -- and tell the vendors what you think about it. Bitch about the terms by all means, but at least make sure someone is listening who can do something about them.
I made the decision awhile ago to use only software that guarantees me my Four Freedoms. The chances are that such software will come under either the GPL or a BSD-like licence. Both these licences are easy to understand and do not seek to abridge your statutory rights.
The only way EULA madness will be brought to an end, is when people stop accepting it. Otherwise it's going to come to something like this:
You do not own the SOFTWARE. You have purchased a temporary, limited licence to use the SOFTWARE contingent upon your meeting certain conditions set by the LICENSOR. The LICENSOR may revoke this licence at any time.
You may install the SOFTWARE on one (1) computer, which shall become the property of the LICENSOR. You may not make or attempt to make any backup or archival copies. You may use the software only for the purposes approved by the LICENSOR and described in the accompanying documentation.
The SOFTWARE contains the proprietary secrets of the LICENSOR. You may not reverse-engineer, disassemble, decompile, de-obfuscate or otherwise attempt to understand the SOFTWARE, nor by any means attempt to make the SOFTWARE comprehensible to a human being or any other living organism.
You are not permitted to develop software which competes directly or indirectly with the SOFTWARE nor any other product supplied by the LICENSOR. Direct competition includes without limitation any software which attempts to perform one or more functions which could be performed using the SOFTWARE or any other product supplied by the LICENSOR. Indirect competition includes without limitation any software which attempts to use any key combination, mouse movement or other technique identical or similar to a technique found within the SOFTWARE or any other product supplied by the LICENSOR to perform a similar or different function.
The instructions and techniques for using the SOFTWARE are the proprietary secrets of the LICENSOR. You are privy to such knowledge only as long as you remain bound by this licence agreement and only to the extent that you may use the SOFTWARE in a manner approved by the LICENSOR. You may not communicate to any third party any details concerning the operation or use of SOFTWARE irrespective of whether or not such party may be independently licenced to use the SOFTWARE.
The operational details of the SOFTWARE are the proprietary secrets of the LICENSOR. You are not permitted to use any technique to attempt to discover any fact connected with the operation of the SOFTWARE. Examples of prohibited acts include:
Reading the directory listing from the media upon which the SOFTWARE is delivered.
Quantitatively or qualitatively examining data travelling into or out of the computer upon which the SOFTWARE is running.
Attempting to measure the speed of the computer upon which the SOFTWARE is running.
Measuring the temperature of any electronic component in the computer while the SOFTWARE is running.
Everything you create with the aid of the SOFTWARE shall be the property of the LICENSOR. All Intellectual Property rights embodied in anything you create with the aid SOFTWARE shall be deemed to belong to the LICENSOR but may at the LICENSOR's sole discretion be licenced back to you so long as your licence to use the SOFTWARE remains in force.
This licence may be terminated at any time by the LICENSOR, for any reason and without prior notice. Upon termination of the licence, you must immediately:
Cease using the SOFTWARE and destroy all copies, including the documentation, together with the computer upon which the SOFTWARE has been installed, to the satisfaction of the LICENSOR.
I wrote some mail-munging code to add a disclaimer to outgoing e-mails for an exim-based mail server project once. It looked for a MIME boundary and if there was one, inserted an extra attachment of type text/plain; otherwise it just appended its stuff onto the end of the message. It's probably very illegal in many jurisdictions -- pending a clarification over whether or not e-mail is subject to the same laws as snail mail. In Britain, an undelivered letter is Crown property, and tampering with it is considered treason -- one of the few crimes still punishable by death. I believe that in Germany and the Netherlands there is a specific offence relating to altering e-mails in transit.
The default disclaimer text actually stated that the message had been modified in transit without the permission of the sender and to call the police if you believed that such a practice was illegal.
And yes, all this quite rightly broke PGP signatures {unless each attachment was PGPed in its own right}.
I'm talking about each and every processor having a different instruction set. There would be two modes, selectable in hardware by shorting a pin to ground or not. In "Compatibility Mode" -- aka "Dangerous Mode" -- the instruction set would be known and standardised; thus allowing you to use a standardised toolchain to compile some bootstrap code {a kernel and a minimal userland} for running in Safe Mode. In "Safe Mode", the processor would use its own "personalised" instruction set, which you would necessarily have the ability to change. It must not be possible to determine, by cross-referencing "Safe Mode" compiled code with its corresponding source code, the full personalisation schema of the target processor. Any sources you compiled in Safe Mode would only run on that processor {or an identically-personalised one}.
In a corporate environment, you might conceivably have all the machines in a department personalised the same way; so you would only have to compile your applications once per department. Any malware that gets on the loose there would be contained.
Some variant of public key encryption / digital signature would be a nice way of doing this; but I fear that once PK-on-a-chip is a reality, The Bad Guys would find a way to use it against us. The serious weak spot in this scheme derives from the need to show your personalisation details to the compiler running in Dangerous Mode -- I don't see how you can be sure that there is no way for an "evil compiler" to send a copy of your schema to some malware author. And as has already been hinted elsewhere, an "evil compiler" is frighteningly possible {the only known antidote being a simple interpreter [just complete enough to interpretatively run the compilation of the compiler source code] written in assembler by someone you trust}.
And this is why I like the idea of binaries being tied hard to the exact processor for which they were compiled, rather than every processor having the same instruction set. It makes it a stackload harder to do stuff like that, when actually enabling the build environment requires physical access to the machine. As long as there exists binary compatibility between your systen and Some Unknown Bad Guy's system, there will be rootkits.
Now that we have seen proof of checksum collisions, I do not doubt that the next big thing in malware circles will be to create modified binaries whose checksums are the same as the originals..... if they haven't already..... of course, using checksums is actually a pretty christian way of checking for intrusions, because you don't really know for sure that the checksum creator itself hasn't been interfered with.
The whole point of telephony is interconnectivity, which Skype is going dead against with its closed protocol. {I'm using a hardware SIP phone [the only way to do it IMHO] and my own copy of Asterisk to connect through an ISDN line at work..... with my boss's blessing}. Now that's compatible with every "proper" SIP phone and, thanks to the gateway, with every ordinary telephone whether mobile or tethered. I can even introduce encryption at the IAX layer {present assumption: any machine on my LAN is trustworthy; if/when Wireless is introduced, it will be encrypted and tightly firewalled}.
Unless Skype is opened -- willingly or by force {are you out there, DVD Jon?} -- it will not succeed in the long term. Its short-term success is due to early adopters; not all of whom will stay loyal, particularly once the insurmountable-by-design disadvantages begin to become apparent. How many electric companies do you know that sell 72V, 20Hz out of weird sockets with two half-moon and one flat pin and are still in business?
Slashdot Mirror
I read Stallman's essays when I was younger {he's written a few more since then} and thought This is great, but it doesn't go far enough. We need to take by force what is rightfully ours. So I went about my way, exercising Freedoms 0 and 2 with or without anybody's -- but, it has to be said, towards the end, mostly Microsoft's -- sayso.
/CLI=SHELL to your username when logging in}. I had even tried Linux -- with plenty of help from someone else. It must have been about 1992 or 1993. He booted a floppy in a PC in a lab, and it came up with a Unix login prompt. You could telnet to it {it was safe to send a plaintext password in those days} from anywhere in the world. And run vi on it. Vi was not as nice to use as EVE -- but you could run vi with just about any terminal that supported even rudimentary cursor positioning.
However, as I grew up I also realised the importance of Freedoms 1 and 3. In the 8-bit days I had dabbled with BASIC and machine code. The 16-bit years seemed somehow as though something was missing. I had this wonderful spanky new machine and yet I couldn't make it do exactly what I wanted it to do! I was all ready to pull out my old BBC model B from the loft, when it hit me. I wasn't hurting the software industry one iota by illegally copying their products -- I was just as dependent upon them as any paying customer. I needed Freedoms 1 and 3, and that meant I needed the source code. In the Beeb days, it was enough to disassemble a machine code game to make silly changes, like changing the keys or adding extra lives or disabling collision detection {with 32K of ram, and a framebuffer eating 20K of that and the OS eating another K or so for itself, the game was very hackable}. Or, of course, there would be listings printed in magazines, to be typed in over the course of several days; and these often could be improved upon. I realised I was missing Freedom 1 in a big way.
I had used VAX/VMS and UNIX at university, some years before. Though I actually preferred the former, because it used words instead of symbols, the latter was the direction in which all things were going {and VMS even had a "unix emulator" -- append
When a friend of mine gave Linux a serious try, I decided that it must be worth a go. In the end I set up an old machine running Linux -- Debian slink; or it might have been potato, I think -- as a "modem sharer" so that my Windows 95 box and any machine I borrowed could both use my single, 56K dial-up line. When my ISP of the day introduced individual cgi-bin directories, I set up apache and perl on my "modem sharer" so it could be used as a testing environment for my scripts.
And when I bought an Athlon XP 2000+, I knew I had to make a serious decision. Would I dual-boot Linux and Windows, or single-boot Linux? The Windows 98 SE installer disc answered that for me. It didn't believe there was such a thing as a whole gigabyte of memory on one motherboard, and barfed. I ended up installing Mandrake 8.2, got for me by a broadband-enabled "warez n pr0n d00d".
And I never looked back. One day I picked up my e-mail using kMail. There was a message from my erstwhile ISP asking if I knew anybody who wanted a job doing a bit of programming and system maintenance. I said "yes, me!", and got the job.
As I remember, push-to-talk was how early two-way radios worked. The same circuit would act as a receiver or -- at the push of a button -- a transmitter. The same frequency was used for speech in both directions. The advent of cheap transistors with a few MHz of bandwidth led to cheap two-way radios being marketed as kids' toys. They were probably illegal as hell; but then, the batteries would barely last long enough for The Authorities to find anyone using them.
The very early VHF mobile phones {where you actually had to dial a different STD code, depending on the approximate location of the called party} were half-duplex, using a push-to-talk button embedded in a normal telephone handset {so more like a squeeze-to-talk}. Later VHF mobiles were still half-duplex, but used to autodetect a signal in the mic.
We have had full-duplex mobile voice calling for ages, so this seems like a backward step to me. Almost nobody uses a mobile phone for voice anyway in the UK, because it canes your credit.
Seriously, just buy a DVD+RW recorder {Argos have them for £79.99}. Connect it to your VCR with a SCART to SCART cable. Make sure to plug the TV aerial into the VCR so a picture will come out of it at first -- this will fool the copy protection circuit in the DVD+RW recorder into thinking the picture is "clean", it only checks for Macrovision when you first press RECORD {hey, the guys in Philips' labs -- all these machines use Philips chipsets -- have massive collections of Macrovision-encumbered VHS cassettes themselves, you know .....} Start the DVD recording, then play the VHS. Manually insert a chapter marker at the beginning of the movie and skip the crap next time you watch it, or mark the chapter 'hidden' if you can find the menu option to do so.
..... and you could use the saw blade on a Swiss Army knife for cutting down trees. But something that was designed for cutting down trees and only cutting down trees, will invariably do a better job of cutting down trees than something that was designed to be used for many different jobs. On the other hand, you won't have much joy getting a stone out of a horse's hoof with a chainsaw .....
You could use your computer as a DVD recorder
On most cars, first is left and away from you, second left and towards you, third is in the middle and away, fourth in the middle and towards, fifth is right and away from you, and Neutral is in the middle where it moves freely left and right. The difference is in where they put Reverse.
Ford:
1 3 5
|-|-|
2 4 R
Vauxhall:
1 3 5 R
`-|-|-'
2 4
You are attempting to apply Windows concepts to Linux, which is why you are going to be disappointed. Linux is not Windows.
.tgz packages contain just the files which need to be installed: if the file is unpacked in the root directory, then everything will be deposited in the right place. Debian's .deb files, and others' .rpm files, go a step better by incorporating some metadata wh
I'm sick of car analogies, so I'll try a dog analogy. When you are training a dog, you can't apply two-legged concepts to it. The dog won't get them and you will end up pissing yourself off. You have to think in terms a dog will understand. A dog doesn't get the concept of punishment except right after the event {in which case it is just another case of cause and effect, this time an undesirable effect of a cause which it will endeavour not to repeat}. A dog doesn't see you getting a tin of dog food out of the cupboard and opening it; it sees you catching something and skinning it. A dog doesn't think it's a person: it thinks it's a wolf and you {despite the leg count} are the alpha wolf in its pack. {If you give it the wrong signals, it thinks it's in charge. And it probably won't know what to do, living in a two-legged environment, so it will mess up really badly.} And so on.
Every Linux distro has its own preferred method of installing packages. With Debian and Ubuntu, it's apt-get; with Gentoo, it's emerge; with Mandriva, it's configure my computer->install software; with SUSE, it's YAST. You didn't state what distribution you were using. If you were using GNOME, I'd guess probably Fedora or Ubuntu. But that's by the by. Your distribution has its own preferred way of installing software. {There are many ways to accomplish this task. The people who set up your distro picked a way they liked, and expect everyone else to do it that way. They were there first and they had to make some rules for the sake of their own sanity.}
With Windows the standard method of installing software is to download a self-extracting executable archive, which contains pre-compiled binaries and automatically installs them somewhere. This is possible because (1) Windows only runs on Pentium / Athlon-type processors, (2) every Windows installation has the same kernel call points, and (3) Windows is actually a little more flexible than Linux with respect to the locations of libraries -- by default, it will first look for a library in the same directory as the program that asked for it. On the downside, (2) means that the Windows XP kernel is cluttered up with remnants from Windows 2000, Me, NT, 98, 95 and 3.11; and (3) means that the hard drives of Windows machines are cluttered up with copies of the same libraries, installed in different locations by different programs.
With Linux, things are a lot more flexible in general -- in fact, Linux is known to run on at least a dozen incompatible architectures. So the canonical method of installing software is to download an archive which contains source code -- which will compile for whatever processor is in the target system, extract it, compile the source, linking it against the installed kernel and libraries, and install the freshly-created binaries. Usually a script is included which will check that the build environment is complete, to avoid disappointment: if you know how to interpret the error messages you get from an abortive attempt at compilation, then you can fix things and it will work next time you try.
However, if you can make certain assumptions about the target system, you can actually install pre-compiled binaries on a Linux system. If you are a distro maintainer, you have pretty much stipulated what versions of libraries and other important base tier software are going to be installed. You can compile binaries against this setup and they will install and run correctly on another machine with the same setup. Slackware
But a GM car is harder to drive than a Ford car! I'll prove it. Reverse on a Vauxhall or a Daewoo is left and away from you. Reverse on a Ford is right and towards you, opposite fifth, which is obviously the proper place where Reverse gear belongs. GM's way of doing it means four away and two towards, which is just horribly unbalanced!
You think that's bad? I visited an electronics superstore to return a faulty DVD+RW recorder. They were using a mainframe system for stock management -- with Windows PCs running a payware ANSI [VT320-class] terminal emulator.
{For the uninitiated,the Linux console natively supports ANSI escape sequences; and there exist more Open Source terminal emulators, ANSI and otherwise, than you can shake an actual real VT100 keyboard at.}
This guy is talking bollocks.
Unfortunately, science is not cool anymore. It's a victim of its own success; things which obey rules never really attract attention. If light suddenly decided not to travel in straight lines, or objects suddenly ceased to attract one another in proportion to the ratio of the product of their masses to the distance between them, that would get noticed. If you want to get into the papers for drawing a triangle, all you have to do is make sure that its angles add up to something other than 180 degrees. If the pressure in a fluid were to act more strongly in one direction than another, or a homogeneous filament suspended by its ends formed some other curve than y = k * (e ** x + e ** -x), no doubt somebody would be screaming for Something To Be Done. {Except they would not, because we'd all be dead}.
It probably doesn't help either that there is a public perception that scientists create things like nuclear weapons, genetically modified foods, climate change &c. and haven't yet given us the flying cars and wristwatch TV sets they promised us.
Pseudo-science, on the other hand, is cool. It attracts the kind of sad-acts who, no longer content with merely refusing to eat the same kinds of food as the rest of us or call their kids the same kinds of names as the rest of us, now apparently resent the concept of being bound by the same fundamental laws as the rest of us.
I have found a company apparently doing exactly this: Initial CityLink.
c el.asp, the server wants to set a cookie. The name of the cookie is PHPSESSID.
When you visit the link http://www.city-link.co.uk/track_parcel/track_par
PHP requires just as little effort if you turn register_globals back on.
It's only insecure if you let it be insecure. Blindly doing an iteration such as is really no more secure than having register_globals turned on in the first place. The real insecurity came from the order in which the variable sources were processed; by default a query string in a GET request would clobber a session variable. Doing GET first, then POST, then cookies and finally sessions fixes it {although you can't do some nifty tricks which are useful for testing}. So my preference is which gives me the best of both worlds; I'm not cluttering up my code reading form variables out of globals, but neither is it possible to override session variables with a query string.
Beside which, there is nothing quite so insecure as the fact that any PHP script running on the same server can fopen() any file in any other user's webspace -- and some cheap hosting companies really are stupid enough to use the same login and password for Linux login and MySQL database. And on Mandrake {not that anyone uses that in a serious hosting environment}, it was the default for any user to be able to use `poweroff` at the command line. I wonder if that included, or still includes, the Apache daemon's user?
As much as I admire all that hard work, I simply don't feel confident that I personally could go to such extreme lengths just to prevent code that I wrote for the benefit of all humanity from being locked up. Other people get to exercise their rights because I live up to the obligations incumbent upon me.
All closed-source software by definition abridges two of the Four Freedoms; and many EULAs would seek to abridge one or both of the other two if only they were legally enforceable. I would much prefer to see the Four Freedoms protected by the Law of the Land.
To create a thumbnail of dimensions 160 by 120: To rotate a picture 90 degrees anti-clockwise: These alone should be enough for most people and will save hours of fart-arsing around dragging and clicking. But if you happen to want to pull out a 200x100 pixel segment from (55, 668): If you like charcoal drawings, ytr this {change the 2 for different thickneses of charcoal stick}: Of course there are more options you can use. If you have a GUI running, try: Middle-click to magnify and get co-ordinates. Left-click for a menu. Everything you see in the menus can be done from the command line. The basic commands are mogrify {which takes one filename and overwrites the old file with the new}, convert {which takes two filenames, the first is the existing file and the second is the new filename to be created} and display {which takes as many filenames as you like and displays them one after another, press space to select}. They all take the same options; see manpage for details. Note that the arguments to convert need not be the same filetype; the input filetype is determined automagically and the output filetype is set according to the extension. This means you can do something like and it will Just Work.
Well, the thrill is in the hunt, not the kill. If you solve the problem, then you can't go looking for solutions anymore.
If the movie studios held private exhibitions just for critics {the way they usedta hafta do before VCRs and DVD players existed.....} then there would be no way that these "screeners" could leak out. But there would be a definite financial cost {in transport and accommodation expenses -- I'm presupposing the use of existing cinemas, owned by a subsidiary company of the studios, in the morning when they would normally be closed}, which would be greater than the immediate cost of shipping out recordings to the reviewers' homes. So the movie studios' shareholders would see real money going to waste. At least when they send out individual DVDs which get copied, it's only pretend money being lost through "piracy". And because it's pretend money, they can pretend it's as much or as little as they like.
But there's another reason not to clamp down on it altogether. The movie studios will never admit it, but "piracy" - up to a point - actually does them more good than it does harm. If somebody sees a "pirate" copy of a film with a certain actor | actress | director | tea boy, they may remember the name next time the same name comes around in another film; and this time around, they may be inclined to pay for it. Or they might tell their friends, who have so much hassle involved to get a "pirate" copy that they give up and pay for it. If the film comes around again in the cinemas, some people will go and pay just to watch it on a big screen. Still, and this point needs to be stressed, the vast majority of the people who watch "pirate" copies of films would simply have chosen to do without altogether if there were no "pirate" copies available. So not every "pirate" copy represents a lost sale. And some "pirate" copies actually represent successful free advertisements.
Yes, exactly so! I am proposing to recover a picture signal from the CRT drive signals {which must be "in the clear" *}. The scan coils {which move the electron beam side-to-side and up-and-down} carry the timing information. Note that in the CRT scan coils, we have a voltage which starts low, slowly but linearly rises and then falls suddenly; much faster in the H-coil {once for each line of picture} than the V-coil {once for each complete picture}. A real TV timing signal is just a pulse indicating the start of a line and a long pulse or burst of pulses indicating the start of a picture. The grid drive signals {which alter the strength of the red, green and blue electron beams} carry the RGB signals; but note that you need a higher voltage for dim and a lower voltage for bright. A real TV signal has 0V for off, going up to 5V for maximum brightness, on each of the red, green and blue pins; with a series impedance of 470 ohms {so giving 0.7V into 75 ohms}. So you need some simple signal conditioning, but it's nothing that cannot be done using a few inexpensive op-amps, resistors and capacitors. And then you have an RGB signal suitable for feeding into any fully-wired SCART socket.
* Barring the introduction of a protection method whereby the picture is displayed in scrambled form, and decoded in the brain of the viewer using a mild hallucinogenic drug and neuro-linguistic programming techniques. The drug could even be mixed with another drug, designed to react with growth hormone, to provide age restriction {a twelve-year-old has more growth hormone than a fifteen-year-old, who in turn has more than an eighteen-year-old} by inducing debilitating effects in a person too young to watch a 12 / 15 / 18 rated film. This would guarantee a further revenue source in sales of the viewing drug, as one viewing of the film requires one pill per person. The NLP would be performed from a chapter at the beginning of the disc {there are tremendous opportunities here for high-price, captive-audience advertising since it would be impossible to see the movie without undergoing the NLP}, and would wear off with the drug.
It's two thousand and freaking five, for crying out loud.
Can't we at least say 500mm Laptop ?
There is a very weak link in the chain: see here.
One day, I'm going to get my shit together to actually make one of those babies.
Yes. There is a "plain text" version available on the scan coils {from which you can recover the H- and V- timing information -- in fact, the exact position of the electron beam at any instant} and the red, green and blue grid drives {from which you can recover the RGB video signals}.
A simple proof-of-concept device would consist of a sawn-off CRT neck, a piece of breadboard with mostly passives and a few op-amps, and a cable with an ordinary SCART plug on the end. Plug the fake CRT end into a TV set in place of the real CRT. Plug the SCART end into another, unmodified TV set.
The first TV set doesn't know that it is driving a fake picture tube. The second TV set only knows that it's getting an RGB signal.
NB. Most VCRs have only "partially wired" SCARTs which do not accept RGB input signals, but most DVD recorders have "fully wired" SCARTs: an RGB output for the TV set and an RGB input for a satellite decoder.
This does not surprise me. In my city there were plans for a power plant which would use household waste as a fuel. First there would be a multi-stage segregation process to divert glass, metal and some plastics for melting down; secondly a gasification stage converting organic matter to methane, and finally a turbo-charged, intercooled, internal combustion engine spinning an alternator at constant RPM.
The local Friends of the Earth miscategorised this as an incinerator, claiming that it would produce dioxins {about as much in one full year of running as 5 November} and CO2 {instead of an equal amount of CO2 which would no longer be produced from other power plants and some of which would be from non-fossil fuel sources due to the presence of plant and animal matter in the process feedstock}. When these arguments were shot down, they still claimed that the plant was a bad idea as by improving recycling rates it would encourage people to throw stuff away! In the end, the plant did not get built and people are still being poisoned both nearby {by leachate from landfill sites, which produce methane -- one molecule of CH4 is equivalent to 21 molecules of CO2 in terms of heat-trapping power} and far away {by mining metal ores to replace the recyclable metal being buried in landfill}. All to avoid a negligible effect on air quality in an area where the majority of the population smokes fags anyway.
There's no point even trying to reason with Greens, because they fundamentally don't get science.
No. You would be switching the kernel from Linux to Minix {or The Hurd}, whilst retaining a GNU userland. So you would be switching over to GNU/Minix, or GNU/Hurd.
..... often having PID=1 and capable to bring down a system if inelegantly terminated] and sends back the output generated from the command}, the "ls" command is invoked. The kernel checks to see if there is an undamaged copy of "ls" in memory already, and if not loads one. The "ls" command passes a call to the kernel to read the directory listing from the disk, then generates some human-readable output from this data. The shell calls the kernel to write this information to the screen.
There are two parts to an operating system; the kernel {which provides a very low level interface to the computer's hardware} and the userland {which provides an interface to people}. The GNU project has created a viable userland, but is still having difficulty producing a kernel. Linus Torvalds -- then a student of Tanenbaum -- created Linux, originally a simple kernel which has now grown into something much bigger.
When you type "ls" {which is a userland command} into the shell {another userland process, which accepts commands from users [by means of a call to the kernel], passes them to the process sheduler [another userland process
It was when hackers wrapped a GNU userland around the Linux kernel that the magic really began to happen. Of course, you could just as easily wrap a GNU userland around the FreeBSD kernel, or a BSD userland around Linux, but GNU and Linux just hit it off the best.
The delicious irony of all this is that Linux really was first created just to prove a point: that a monolithic kernel could sometimes outperform a microkernel {which Tanenbaum disputed}. Though apparently counter-intuitive, this is not really all that surprising when you think about it a little harder: certain Typical Real Life Operations are predictable enough to optimise very hard, and a monolithic kernel naturally supports harder optimisation than a microkernel at the expense of some flexibility. If the operations you optimise hardest happen commonly enough, then the performance gain can be significant. {Cf. if you live in an area with plenty of sunshine, waste disposal by landfill, and your water heater runs on almost any fuel besides electricity, then terry nappies will definitely be greener; whereas if your household waste is burned in a reasonably modern power plant, your water heater is electric and prevailing weather conditions are such that you need to use a tumble drier for the majority of your washing loads, disposables might work out better.}
I made the decision awhile ago to use only software that guarantees me my Four Freedoms. The chances are that such software will come under either the GPL or a BSD-like licence. Both these licences are easy to understand and do not seek to abridge your statutory rights.
The only way EULA madness will be brought to an end, is when people stop accepting it. Otherwise it's going to come to something like this:
I wrote some mail-munging code to add a disclaimer to outgoing e-mails for an exim-based mail server project once. It looked for a MIME boundary and if there was one, inserted an extra attachment of type text/plain; otherwise it just appended its stuff onto the end of the message. It's probably very illegal in many jurisdictions -- pending a clarification over whether or not e-mail is subject to the same laws as snail mail. In Britain, an undelivered letter is Crown property, and tampering with it is considered treason -- one of the few crimes still punishable by death. I believe that in Germany and the Netherlands there is a specific offence relating to altering e-mails in transit.
The default disclaimer text actually stated that the message had been modified in transit without the permission of the sender and to call the police if you believed that such a practice was illegal.
And yes, all this quite rightly broke PGP signatures {unless each attachment was PGPed in its own right}.
I'm talking about each and every processor having a different instruction set. There would be two modes, selectable in hardware by shorting a pin to ground or not. In "Compatibility Mode" -- aka "Dangerous Mode" -- the instruction set would be known and standardised; thus allowing you to use a standardised toolchain to compile some bootstrap code {a kernel and a minimal userland} for running in Safe Mode. In "Safe Mode", the processor would use its own "personalised" instruction set, which you would necessarily have the ability to change. It must not be possible to determine, by cross-referencing "Safe Mode" compiled code with its corresponding source code, the full personalisation schema of the target processor. Any sources you compiled in Safe Mode would only run on that processor {or an identically-personalised one}.
In a corporate environment, you might conceivably have all the machines in a department personalised the same way; so you would only have to compile your applications once per department. Any malware that gets on the loose there would be contained.
Some variant of public key encryption / digital signature would be a nice way of doing this; but I fear that once PK-on-a-chip is a reality, The Bad Guys would find a way to use it against us. The serious weak spot in this scheme derives from the need to show your personalisation details to the compiler running in Dangerous Mode -- I don't see how you can be sure that there is no way for an "evil compiler" to send a copy of your schema to some malware author. And as has already been hinted elsewhere, an "evil compiler" is frighteningly possible {the only known antidote being a simple interpreter [just complete enough to interpretatively run the compilation of the compiler source code] written in assembler by someone you trust}.
And this is why I like the idea of binaries being tied hard to the exact processor for which they were compiled, rather than every processor having the same instruction set. It makes it a stackload harder to do stuff like that, when actually enabling the build environment requires physical access to the machine. As long as there exists binary compatibility between your systen and Some Unknown Bad Guy's system, there will be rootkits.
..... if they haven't already ..... of course, using checksums is actually a pretty christian way of checking for intrusions, because you don't really know for sure that the checksum creator itself hasn't been interfered with.
Now that we have seen proof of checksum collisions, I do not doubt that the next big thing in malware circles will be to create modified binaries whose checksums are the same as the originals
..... but Skype isn't.
..... with my boss's blessing}. Now that's compatible with every "proper" SIP phone and, thanks to the gateway, with every ordinary telephone whether mobile or tethered. I can even introduce encryption at the IAX layer {present assumption: any machine on my LAN is trustworthy; if/when Wireless is introduced, it will be encrypted and tightly firewalled}.
The whole point of telephony is interconnectivity, which Skype is going dead against with its closed protocol. {I'm using a hardware SIP phone [the only way to do it IMHO] and my own copy of Asterisk to connect through an ISDN line at work
Unless Skype is opened -- willingly or by force {are you out there, DVD Jon?} -- it will not succeed in the long term. Its short-term success is due to early adopters; not all of whom will stay loyal, particularly once the insurmountable-by-design disadvantages begin to become apparent. How many electric companies do you know that sell 72V, 20Hz out of weird sockets with two half-moon and one flat pin and are still in business?