Sun could use a variant of the PINE licence. Insist that only unmodified, Sun-sanctioned binaries be distributed; but allow distribution of modified source code as long as (1) the eventual user is made aware that the source code is not the original, "official" Java implementation by Sun Microsystems and (2) the distribution of modified sources is not further restricted.
This won't affect Linux and the BSDs much: every GNU/Linux and BSD installation includes GCC, so distro-specific patches will be made at source level and the Java interpreter will be compiled locally. And Microsoft won't be able to "embrace, extend and extinguish" Java unless they start bundling a C compiler with Windows {and even then, Sun will still be able to take back the Microsoft extensions -- Microsoft can't stop anyone else from distributing source code modified by Microsoft}. The likes of SuSE and Red Hat might well purchase special licences allowing them to distribute slightly-customised binary versions of Java under terms that Sun are happy with.
Of course, Debian aren't even happy about the Pine licence {enforced distribution of source code isn't good enough for them, it seems -- but surely you can't get more Open Source than that?}; you have to get the Pine sources out of non-free. So some things won't change:)
My first computer was a ZX81. 3.5MHz Z80A, 1KB of RAM {soon expanded to 16KB}, 32*22 text or 64*44 graphics, upper case only, mono, unreliable cassette interface, slow. Got as far as I could manage in BASIC, couldn't get anywhere in machine code. Graduated to a BBC model B, 2MHz 6502, 32KB of RAM {of which up to 20KB required for framebuffer}, various colour and mono text and graphics modes, blindingly fast by standards of ZX81. More sophisticated BASIC allowed for some stunning graphics programs {you could write a program to draw an animated scene -- the beeb could draw filled triangles, and palette switching was a doddle} and integral assembler meant I was doing 6502 machine code before I knew it. Was also building stuff to plug into the expansion ports, like a device with relays for controlling Lego motors. Now more comfortable with the basic concepts of machine code, having learned to program an easy one, I returned to study Z80 machine code, this time on a Spectrum 48KB -- everyone knows the specs of that machine. And to plug some homebrew goodies into it. BTW, it's a bad idea to short A8 and A9 together; your program will crash and stay so even after you remove the short, requiring a power cycle.
Then came my first 16-bit machine, the Commodore Amiga 500. 7MHz 68000, 512KB RAM, graphics to blow you away. And though it came with a version of BASIC, of sorts, it seemed very limited. The Beeb allowed you to do anything in BASIC that you could do in machine code. Anything that the computer was physically capable of. Even the Spectrum gave you access to the I/O with IN and OUT statements. The Amiga..... well, if you knew the right addresses, you probably could write a program full of POKE statements that would do something stunning. But those addresses just weren't in the manual. Also, we were told that we could program it in C; but it didn't actually come with a C compiler. At least PC operating systems do come with a C compiler nowadays!
That, I think, is when the rot really set in: when computers and peripherals were no longer supplied with all the boring technical manuals {I even learned some PostScript reading a laser printer manual}.
All that being said, most of the people who had 8-bit computers in the 1980s were using them just for games; not very many people mastered BASIC, still fewer machine code. If they did any "programming" at all, it was usually typing in listings from magazines..... anyone remember that? Probably some people experimented with modifying things {let's see what happens if we change line 210 to read LIVES%=255.....} At least we do have the internet nowadays..... or what's left of it, anyway..... so there's an opportunity for beginning programmers to share the knowledge they acquire.
There is only one way to be sure whether or not a piece of software is likely to contain spyware: READ THE SOURCE CODE.
As a second best method, only ever download software which has been vetted by someone you trust who is independent of the original author.
Insist on source code even if you end up downloading a pre-compiled binary. If they don't want to let you look at the source code, then they are obviously trying to hide something! That probably means the software contains malware. It really is as simple as that.
Another way of syncing two cards, if they are the same make and model: Find the crystal, which will be either a two- or three-leaded metal can {on an expensive card} or a three-leaded ceramic blob {on a cheap and nasty one}. Probe each pin of the crystal with a 10:1 scope probe; you will see that one will have a "squarer" waveform than the other. Note which one {this is the oscillator output}. Unsolder the crystal from the slave card. Get a 74HC04 and a small piece of breadboard {or use a 74LX1GU04, single gate, if you can get it; even just a simple NOT gate consisting of a MOSFET and two resistors should do}. Plumb this in to any convenient positive supply and 0V. Ground all save one of the 74HC04 inputs. Wire the oscillator output {pin with the squarer waveform} on the master sound card to the remaining input of the 04, and take the output to the opposite hole on the slave card {crystal input}. This should work for multiple slaves: one NOT gate will easily feed more inputs than most motherboards have expansion slots.
How it works: a crystal behaves like a precision delay line. If it's connected between the output and input of a NOT gate, then the "output" of the crystal will change states half a period after its "input" changes state, so forcing the output of the NOT gate to change state; this will cause the "output" of the crystal to change state another half period later. As long as the period of the crystal is longer than the propagation delay of the NOT gate and the capacitances on the two pins of the crystal are unequal {and in any real circuit, they will be different enough} this will start and continue to oscillate. What we just did was to feed the oscillator input of the slave card from the oscillator output of the master card. A crystal has too high an internal resistance to supply more than one gate, and the crystal output must be the opposite of its input; so we have to use a proper NOT gate so the signals at the two oscillator inputs will be in phase with each other.
Hey, what self-respecting BOFH lets users choose their own passwords?;> Depending on your usermod(8) implementation, it might or might not work for users anyway.
As for the lower entropy due to more rigidly defined patterns..... I know, but it's a compromise. A weak password that isn't written down on a yellow sticky note attached to the side of the PC is still more secure than a strong one that is written down. A brute force attempt will generate log file entries that can be spotted before the l337 5cript kiddies get far enough to do any damage.
No; there were noise pulses in the vertical retrace of store-bought cassettes which were extending beyond the normal range of the video signal, and so affecting the video AGC circuit in the ex-studio monitor; the picture would go dim for several frames at a time. My initial assumption was that these pulses -- absent from home recordings -- were an artefact introduced somehow by the mass-production process and the video company were just being cheap. {Most TV sets have a much shorter video AGC time constant than a studio monitor or most VCRs and so won't be affected.} Upon further investigation I discovered them to be a deliberate addition, a supposed anti-copying measure requiring any would-be video pirate to interpose a timebase corrector between the playback and recording decks {and, incidentally, lowering the recording quality; if the VCR is electrically capable of outputting a signal which goes all the way up to 3 volts, but can't do it all the time because it has to keep it down to about 1V most of the time and only peak occasionally at 3V for the sole purpose of preventing the people who pay their wages from doing something that they do not even know for sure we do not have permission to do, then that's a criminal waste of dynamic range IMHO}. When I lent my TBC out, I chose to shorten the time constant in the monitor rather than build or buy another.
Opera is not Free. It may not cost you money, but it costs you some of your liberty. Until Opera comes with the source code, I'm sticking with Konqueror.
Handwritten signatures were used until quite recently to authorise transactions. This prompted me to make the following:
PATENT APPLICATION: Method for handing over personal property to another person. What is claimed is:
A method by which a person, hereinafter referred to as victim, and equipped with a payment {credit or debit} card issued by a bank or similar institution and a mobile telephone, substantially enriches two other parties, hereinafter referred to as villain and accomplice, one of whom is already equipped with a mobile telephone.
The villain and accomplice being known to one another but the victim not necessarily knowing either.
The handing over by the victim, at the {somewhat less than polite} request of the villain, of a payment card and mobile telephone belonging to the victim, and the announcement in a trembly voice of the PIN associated with the card for the purpose of withdrawing cash from a hole-in-the-wall machine or making payment at a store checkout.
The victim remaining in the firm grasp of the accomplice whilst the villain enters a nearby store with the payment card and the victim's telephone; the accomplice also retains a telephone.
If applicable, the announcement by the victim, in an even shakier voice, of the correct PIN associated with the card, upon a simple request {initiated using the victim's own mobile telephone} from the villain to the accomplice.
The suffering of financial loss by the victim, as a result of all the above actions.
Anything else not mentioned above but which the victim may reasonably be expected to do under the circumstances described above.
Note that I have phrased this patent application from the point of view that it would be violated by the victim of "PINpoint robbery", rather than the perpetrator. For one thing, it's not usually illegal to be robbed, which makes getting a patent just a little easier. For another, claiming a royalty payment requires actually getting hold of the person who owes the money; the perpetrator is likely to be long gone, but the victim is right there.
You mean like my naïve assumption that the noise burst in the vertical retrace interval of store-bought video cassettes {which played havoc with an otherwise gorgeous PAL monitor of mine, necessitating de-soldering one lead of a capacitor in order to shorten the video AGC time constant} and absent from home-recorded cassettes {which played fine through said monitor} was just some artefact left over from the mass-production process?
That's what's so great about having all your important stuff on in-house written and customised web applications, rather than some closed-source crap that makes you work the way they want you to work. As well as requiring passwords, you can lock things to an IP address. Users can't change their IP address without the root password for their workstation -- which, of course, they don't have. Users' application passwords can be the same as their workstation login passwords {just paste the first part of a line from/etc/shadow into/var/www/html/*/htpasswd} or different. The IT department never need to know a user's password, despite the show we always make of looking away as they enter it:)
Thanks to a complicated mess..... er..... a cunning arrangement of NFS mounts and symlinks {which ensures there's always a root user and a dummy user called 'user', even if the remote mounts don't come up because some D.H. has been messing with cables}, it's possible to enter something like
It's the same with my PIN-codes. I just remember a figure and how to draw it in a certain order.
Um.
One of the disadvantages {or advantages, if you're dishonest} of those point-of-sale payment machines is that the keypad layout is static. Yes, there's a plastic screen around the keys; but a person watching from above and behind can see everything if they know what they're looking for. Those tendons..... they're an Achilles' heel {irony fully intended}.
I had the idea that it might be more secure to use full-travel keyswitches with built-in OLED or LCD display elements {rather than a touchscreen, which creates errors through the absence of negative feedback} and scramble the key layout for each user {possibly even for each digit, though this might be too confusing}. This way, although you know what keys the person in the next checkout lane was pressing, you don't know what number they were entering.
But that doesn't fit the paradigm, if people memorise the pattern formed on a "standard" keyboard by their PIN rather than the digits themselves. And it could actually end up making things easier for fraudsters. It really would be better to use something more secure than a four-digit PIN to authorise a payment..... how about a handwritten signature {which cannot be disclosed under duress} instead?
Unix is a bit more "self assembly" than VMS. Try this. It's a little Perl script I wrote to generate passwords. The standard form is CCVCDCVC which is fairly "pronounceable", obviously you can customise it. To get around issues with letters looking like numbers and vive versa, it will never use a capital letter O nor a small letter L in a password. Save it in/usr/local/bin/pwgen and chmod it 755.
Usage:
pwgen [username]
If a username is not specified, generates a "pronounceable" password of the form consonant, consonant, vowel, consonant, digit, consonant, vowel, consonant and displays it on STDOUT; along with its scrambled form suitable for usermod(8) or direct editing of the password file.
If a username is specified, and that user actually exists, then pwgen sets the new password using usermod(8).
NB. My careful indenting was spoiled by Slashdot. Feel free to un-spoil it. Good job it's written in Perl and not That Other Language!
#!/usr/bin/perl -w # this is/usr/local/bin/pwgen
my ($password, $salt, $scram, $user, @stuff);
$user = shift || "";
sub vowel { $_ = substr "aeiou", int rand 5, 1; tr/aeiu/AEIU/ if rand >.75; return $_; }; sub consonant { $_ = substr "bcdfghjkLmnpqrstvwxyz", int rand 21, 1; tr/a-z/A-Z/ if rand >.75; return $_; }; sub digit { $_ = int rand 10; }; sub saltchar { $_ = substr "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLM NOPQRSTUVWXYZ./", int rand 64, 1; };
print "\nAJS's password generator - now with no Os or ls!\n"; print "-" x 48 . "\n\n"; print "Password is $password.\n"; print "Scrambled form is '$scram'.\n";
if ($user) { if (@stuff = getpwnam $user) { system "usermod -p'$scram' $user"; print "Set password for '$user' to '$password'.\n"; } else { print "There is no such user as '$user'.\n"; }; };
print "\n";
exit;
Copyright 2005-2006 AJS.
Distribution of this program in Source Code form is allowed, with or without modification, provided that this licence accompanies every copy of the program. Distribution in binary executable form, where applicable, is permitted only in conjunction with complete corresponding Source Code and build instructions.
Statement of Warranty: the copyright holders warrant that this program, when run on a properly-functioning computer, will perform substantially as indicated by the source code. No other warranty is made in respect of the program. If you are in doubt as to what this program does, you should consult a competent programmer.
This licence is in addition to, and is not to be construed as prejudicing, any statutory rights granted to you under the Law of the Land.
That all depends on your implementation of crypt()..... some systems truncate passwords to 8 characters. Yours is not one of these, if the stored passwords start with $1$.
2. If not, is it possible promote the Progress of Science and useful Arts without securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries?
That's because digital music files do not get worn out with repeated playings {like vinyl records or walkman cassettes}, nor degrade with age even if left unplayed {like CDs}, and do not require specialist equipment to manufacture in the first place. Digital media conforms much better to the new Economics of Plenty {i.e. goods can be replicated indefinitely at essentially zero cost and recycled perfectly at end-of-life} than the old Economics of Scarcity which unfortunately are still being taught despite their diminishing relevance.
Have the mailserver check that the OpenPGP signature on every message corresponds properly to the sender and is not on a blocked list. Otherwise, or if the message is not signed, it goes in/dev/null.
There's little point doing this on the outgoing SMTP server because most spam is sent from hastily-bodged-up SMTP servers running on compromised Windows boxes. It really should be done on the POP3 server {which, of course, receives mail by SMTP but then drops it in/var/mail/$LOGNAME and users pick it up by POP3}.
Insisting on signatures would also mean that all users would have access to decent strength encryption {since it's the same key pair..... the public and secret keys are inverse functions of each other, so if you encrypt a known plaintext with the secret key, anyone with the public key can decrypt it..... but only the person who knew the secret key could have encrypted it in the first place}. I don't think that can be a bad thing at all.
Well, it wouldn't surprise me if there is at least one band out there who has done exactly that.
My suggestion for a new recording industry: Artists borrow money using the rights to their work as collateral {this step requires musically-savvy bankers, perh. wannabe pundits} and use this to finance CD recording. Bank, having lien over work, may dictate initial terms of distribution {within reason, laws required to protect artists}. Sales of CDs recoup initial loan; when paid off in full, rights revert to artist. From this point onward, licencing must be on a non-discriminatory basis {i.e. if you allow one person to do X with your work, you must allow anyone else to do X with your work on the same terms}. Additional CDs may be ordered from different suppliers, artist is no longer tied to a label. Possibility exists for "full package deal" recording companies with studio facilities and pressing plant; production-only studios with only mastering facilities, no pressing; also for studio-less labels {perh. supermarkets or specialist "budget" distributors} which only press CDs from masters. {Albums which have recouped must be good sellers.}
The current system is what is called "free market capitalism". Live performance tickets are a scarce resource {unlike recorded albums; which, to all intents and purposes, are an infinite resource and therefore not susceptible to the capitalist economic model; see elsewhere}. The value of tickets increases substantially after the last one is sold.
Anyone with sufficient capital may purchase a ticket whilst they are on general sale, then re-sell the ticket for more than they paid for it. The difference is profit.
One with sufficient capital to invest may even create useful work by employing people to purchase tickets on their behalf, for a mutually acceptable wage. Although the profit per ticket will be smaller, there is a possibility of acquiring {and so reselling} more tickets this way and so realising a larger total profit.
Diminishing returns will set in after a point, but by this time a good capitalist should have diversified into another field.
Note that it may or may not be economically viable to employ a ticket-purchaser directly, on a casual basis, to purchase just one ticket for your own use.
No no no no no! Artists do not make, and never have made, money from CD sales. Artists make money the same way as they always made money before the gramophone was invented: from gigs. I've heard of bands actually losing money on CD sales, but am not sure how true this is.
The most money is to be made from gigs in the kind of intimate venues in towns with an active local music scene, that are attended religiously by a hard core of loyal fans -- i.o.w., shitholes that people like Madonna think they are above playing. The least money is to be made from gigs in stadia and other large venues.
A few months after Philips are manufacturing these things, you know that Daewoo will start buying the same chipset. One quick firmware hack later, you will have a telly that automatically changes channels for you when the adverts come on. Or a DVD+RW recorder that automatically puts chapter marks fore and aft of every piss-break.
I mean, seriously..... come on. If there is ever a reliable way to distinguish advertising from editorial content {such a thing actually was nearly mandated in the UK once but was rejected}, then it will end up being used in ways that benefit the consumer more than the advertiser.
Also, I don't see what there is to grant a patent against. Either there's already a spec for an "advertisement" flag, in which case making use of it to enforce viewing of advertisements should be obvious; or there isn't a spec for an "advertisement" flag, in which case introducing such a flag would be obvious. Patent application is invalid on grounds of obviety either way. Ting! Next, please.
Google's adverts are very easy to ignore; it's as though the TV adverts only appeared in one small corner of the screen. As for Yahoo, MSN and MySpace, well..... the people who use these sites only put up with the adverts because they aren't savvy enough to know there is an advert-free alternative.
Adverts hosted on a "pay per click" basis are ripe for abuse. Something like
running on several computers {possibly without the knowledge or consent of their administrators}, so as to fetch the advert and the page just as though someone loaded up the banner and clicked on it, can generate many bogus clicks on Baseball Bat Finance's homepage {which BBF have to pay for, even although nobody is going to take any action based on such a page hit}. It'd need a real-looking HTTP-user-agent header to make it look more plausible, but you get the general idea. Just set up a business persuading web site owners to carry pay-per-click adverts which you are selling; stick in a quick drive-by download to catch IE users unawares {or maybe a bit of fancy DHTML / JavaScript involving iFrames, cookies and self-redirection now that Firefox is becoming so popular}; the people buying your adverts receive click after click after click {precious little business, mind, but hey -- that's the nature of the advertising game}, and you're coining it in.
{Of course, other loan firms may also wish to set up bogus clicks against Baseball Bat Finance, just to cost their competitors money. And why not? There's nothing quite like stirring up a fight, then selling ammo to both sides and tickets to non-combatants. I swear I had an ancestor who made his living re-fletching used Danish arrows to fire out of a Saxon bow. But I'm digressing a little.}
Let's look at the players again. Baseball Bat Finance are a company with a product or service to sell and plenty of money with which to promote it. They buy advertisements from ScumPeddlers -- a scruple-free online advertisement broker who claim that they can show your advertisement to 120 million people every day, all of whom will be desperate to buy whatever you're selling, several times over and maybe get a few spares for their mates. Fluffy Kitten Stroking Club of the Outer Hebrides is one of many web sites to which ScumPeddlers pay a mere pittance for carrying advertisements. And there's Punters like me and thee who go looking for web sites about kittens and end up getting bombarded with advertisements for products and services which we neither want nor need.
It's unsustainable because eventually, the people who pay for the advertisements {Baseball Bat Finance} are bound to realise that they are not working, and then they will just stop buying them. Up to now, the people who push the adverts onto the punters {ScumPeddlers} have simply resorted to more and more "in-yer-face" techniques, but there's almost no further along that path to go. In addition, the owners of the web sites who are being paid to host these adverts {FKSCotOH} probably are not terribly happy because their visitors {us!} keep asking when they will do anything to get rid of the horrid flashing banners. They might well decide to stop taking the adverts and swallow the costs of running the site, rather than continue alienating their visitors.
As far as I can see, Quantum Encryption is still vulnerable to a man-in-the-middle attack, as long as the malicious interloper can also intercept the "secondary channel" over which Alice and Bob compare their notes and the insecure channel over which the final data will be sent. What QKE really relies on is that Alice doesn't know for certain whether Bob will receive any given one of her bits transmitted over the quantum channel as a "zero" or a "one", and so they have to compare notes over a secondary communications channel before anything can be exchanged using the key. What's said over this channel is not the key itself, but the key EORed with random zeros and ones {which can be inferred by Alice or Bob, but nobody else who did not see the bits sent or received}, and so is ordinarily meaningless to anyone trying to eavesdrop. But if Mallory has a suitable receiver like Bob's and transmitter like Alice's, and records whatever he receives from Alice exactly the way Bob is doing, then it should be possible to reconstruct the keys for both legs of the transmission {Alice to Mallory and Mallory to Bob} from what is already known.
There are a lot of reasons why this would be hard to do, but it's not strictly impossible. And it's exactly the sort of system that's likely to be used where the stakes are high.
Slashdot Mirror
Sun could use a variant of the PINE licence. Insist that only unmodified, Sun-sanctioned binaries be distributed; but allow distribution of modified source code as long as (1) the eventual user is made aware that the source code is not the original, "official" Java implementation by Sun Microsystems and (2) the distribution of modified sources is not further restricted.
:)
This won't affect Linux and the BSDs much: every GNU/Linux and BSD installation includes GCC, so distro-specific patches will be made at source level and the Java interpreter will be compiled locally. And Microsoft won't be able to "embrace, extend and extinguish" Java unless they start bundling a C compiler with Windows {and even then, Sun will still be able to take back the Microsoft extensions -- Microsoft can't stop anyone else from distributing source code modified by Microsoft}. The likes of SuSE and Red Hat might well purchase special licences allowing them to distribute slightly-customised binary versions of Java under terms that Sun are happy with.
Of course, Debian aren't even happy about the Pine licence {enforced distribution of source code isn't good enough for them, it seems -- but surely you can't get more Open Source than that?}; you have to get the Pine sources out of non-free. So some things won't change
That's a bit of a problem, though, when your processor is not binary-compatible with the architecture for which the binary was compiled.
..... oh, bollocks.
Unless you wrote the Java interpreter in a truly cross-platform language like Ja
My first computer was a ZX81. 3.5MHz Z80A, 1KB of RAM {soon expanded to 16KB}, 32*22 text or 64*44 graphics, upper case only, mono, unreliable cassette interface, slow. Got as far as I could manage in BASIC, couldn't get anywhere in machine code. Graduated to a BBC model B, 2MHz 6502, 32KB of RAM {of which up to 20KB required for framebuffer}, various colour and mono text and graphics modes, blindingly fast by standards of ZX81. More sophisticated BASIC allowed for some stunning graphics programs {you could write a program to draw an animated scene -- the beeb could draw filled triangles, and palette switching was a doddle} and integral assembler meant I was doing 6502 machine code before I knew it. Was also building stuff to plug into the expansion ports, like a device with relays for controlling Lego motors. Now more comfortable with the basic concepts of machine code, having learned to program an easy one, I returned to study Z80 machine code, this time on a Spectrum 48KB -- everyone knows the specs of that machine. And to plug some homebrew goodies into it. BTW, it's a bad idea to short A8 and A9 together; your program will crash and stay so even after you remove the short, requiring a power cycle.
..... well, if you knew the right addresses, you probably could write a program full of POKE statements that would do something stunning. But those addresses just weren't in the manual. Also, we were told that we could program it in C; but it didn't actually come with a C compiler. At least PC operating systems do come with a C compiler nowadays!
..... anyone remember that? Probably some people experimented with modifying things {let's see what happens if we change line 210 to read LIVES%=255 .....} At least we do have the internet nowadays ..... or what's left of it, anyway ..... so there's an opportunity for beginning programmers to share the knowledge they acquire.
Then came my first 16-bit machine, the Commodore Amiga 500. 7MHz 68000, 512KB RAM, graphics to blow you away. And though it came with a version of BASIC, of sorts, it seemed very limited. The Beeb allowed you to do anything in BASIC that you could do in machine code. Anything that the computer was physically capable of. Even the Spectrum gave you access to the I/O with IN and OUT statements. The Amiga
That, I think, is when the rot really set in: when computers and peripherals were no longer supplied with all the boring technical manuals {I even learned some PostScript reading a laser printer manual}.
All that being said, most of the people who had 8-bit computers in the 1980s were using them just for games; not very many people mastered BASIC, still fewer machine code. If they did any "programming" at all, it was usually typing in listings from magazines
There is only one way to be sure whether or not a piece of software is likely to contain spyware: READ THE SOURCE CODE.
As a second best method, only ever download software which has been vetted by someone you trust who is independent of the original author.
Insist on source code even if you end up downloading a pre-compiled binary. If they don't want to let you look at the source code, then they are obviously trying to hide something! That probably means the software contains malware. It really is as simple as that.
Another way of syncing two cards, if they are the same make and model: Find the crystal, which will be either a two- or three-leaded metal can {on an expensive card} or a three-leaded ceramic blob {on a cheap and nasty one}. Probe each pin of the crystal with a 10:1 scope probe; you will see that one will have a "squarer" waveform than the other. Note which one {this is the oscillator output}. Unsolder the crystal from the slave card. Get a 74HC04 and a small piece of breadboard {or use a 74LX1GU04, single gate, if you can get it; even just a simple NOT gate consisting of a MOSFET and two resistors should do}. Plumb this in to any convenient positive supply and 0V. Ground all save one of the 74HC04 inputs. Wire the oscillator output {pin with the squarer waveform} on the master sound card to the remaining input of the 04, and take the output to the opposite hole on the slave card {crystal input}. This should work for multiple slaves: one NOT gate will easily feed more inputs than most motherboards have expansion slots.
How it works: a crystal behaves like a precision delay line. If it's connected between the output and input of a NOT gate, then the "output" of the crystal will change states half a period after its "input" changes state, so forcing the output of the NOT gate to change state; this will cause the "output" of the crystal to change state another half period later. As long as the period of the crystal is longer than the propagation delay of the NOT gate and the capacitances on the two pins of the crystal are unequal {and in any real circuit, they will be different enough} this will start and continue to oscillate. What we just did was to feed the oscillator input of the slave card from the oscillator output of the master card. A crystal has too high an internal resistance to supply more than one gate, and the crystal output must be the opposite of its input; so we have to use a proper NOT gate so the signals at the two oscillator inputs will be in phase with each other.
Hey, what self-respecting BOFH lets users choose their own passwords? ;> Depending on your usermod(8) implementation, it might or might not work for users anyway.
..... I know, but it's a compromise. A weak password that isn't written down on a yellow sticky note attached to the side of the PC is still more secure than a strong one that is written down. A brute force attempt will generate log file entries that can be spotted before the l337 5cript kiddies get far enough to do any damage.
As for the lower entropy due to more rigidly defined patterns
No; there were noise pulses in the vertical retrace of store-bought cassettes which were extending beyond the normal range of the video signal, and so affecting the video AGC circuit in the ex-studio monitor; the picture would go dim for several frames at a time. My initial assumption was that these pulses -- absent from home recordings -- were an artefact introduced somehow by the mass-production process and the video company were just being cheap. {Most TV sets have a much shorter video AGC time constant than a studio monitor or most VCRs and so won't be affected.} Upon further investigation I discovered them to be a deliberate addition, a supposed anti-copying measure requiring any would-be video pirate to interpose a timebase corrector between the playback and recording decks {and, incidentally, lowering the recording quality; if the VCR is electrically capable of outputting a signal which goes all the way up to 3 volts, but can't do it all the time because it has to keep it down to about 1V most of the time and only peak occasionally at 3V for the sole purpose of preventing the people who pay their wages from doing something that they do not even know for sure we do not have permission to do, then that's a criminal waste of dynamic range IMHO}. When I lent my TBC out, I chose to shorten the time constant in the monitor rather than build or buy another.
Opera is not Free. It may not cost you money, but it costs you some of your liberty. Until Opera comes with the source code, I'm sticking with Konqueror.
PATENT APPLICATION: Method for handing over personal property to another person.
What is claimed is:
Note that I have phrased this patent application from the point of view that it would be violated by the victim of "PINpoint robbery", rather than the perpetrator. For one thing, it's not usually illegal to be robbed, which makes getting a patent just a little easier. For another, claiming a royalty payment requires actually getting hold of the person who owes the money; the perpetrator is likely to be long gone, but the victim is right there.
You mean like my naïve assumption that the noise burst in the vertical retrace interval of store-bought video cassettes {which played havoc with an otherwise gorgeous PAL monitor of mine, necessitating de-soldering one lead of a capacitor in order to shorten the video AGC time constant} and absent from home-recorded cassettes {which played fine through said monitor} was just some artefact left over from the mass-production process?
Thanks to a complicated mess
One of the disadvantages {or advantages, if you're dishonest} of those point-of-sale payment machines is that the keypad layout is static. Yes, there's a plastic screen around the keys; but a person watching from above and behind can see everything if they know what they're looking for. Those tendons
I had the idea that it might be more secure to use full-travel keyswitches with built-in OLED or LCD display elements {rather than a touchscreen, which creates errors through the absence of negative feedback} and scramble the key layout for each user {possibly even for each digit, though this might be too confusing}. This way, although you know what keys the person in the next checkout lane was pressing, you don't know what number they were entering.
But that doesn't fit the paradigm, if people memorise the pattern formed on a "standard" keyboard by their PIN rather than the digits themselves. And it could actually end up making things easier for fraudsters. It really would be better to use something more secure than a four-digit PIN to authorise a payment
Distribution of this program in Source Code form is allowed, with or without modification, provided that this licence accompanies every copy of the program. Distribution in binary executable form, where applicable, is permitted only in conjunction with complete corresponding Source Code and build instructions.
Statement of Warranty: the copyright holders warrant that this program, when run on a properly-functioning computer, will perform substantially as indicated by the source code. No other warranty is made in respect of the program. If you are in doubt as to what this program does, you should consult a competent programmer.
This licence is in addition to, and is not to be construed as prejudicing, any statutory rights granted to you under the Law of the Land.
That all depends on your implementation of crypt() ..... some systems truncate passwords to 8 characters. Yours is not one of these, if the stored passwords start with $1$.
1. Does the system of copyright as it exists today still serve the purpose for which it was initiated -- that is, To promote the Progress of Science and useful Arts?
2. If not, is it possible promote the Progress of Science and useful Arts without securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries?
That's because digital music files do not get worn out with repeated playings {like vinyl records or walkman cassettes}, nor degrade with age even if left unplayed {like CDs}, and do not require specialist equipment to manufacture in the first place. Digital media conforms much better to the new Economics of Plenty {i.e. goods can be replicated indefinitely at essentially zero cost and recycled perfectly at end-of-life} than the old Economics of Scarcity which unfortunately are still being taught despite their diminishing relevance.
My idea for a completely "spam-proof" system:
/dev/null.
/var/mail/$LOGNAME and users pick it up by POP3}.
..... the public and secret keys are inverse functions of each other, so if you encrypt a known plaintext with the secret key, anyone with the public key can decrypt it ..... but only the person who knew the secret key could have encrypted it in the first place}. I don't think that can be a bad thing at all.
Have the mailserver check that the OpenPGP signature on every message corresponds properly to the sender and is not on a blocked list. Otherwise, or if the message is not signed, it goes in
There's little point doing this on the outgoing SMTP server because most spam is sent from hastily-bodged-up SMTP servers running on compromised Windows boxes. It really should be done on the POP3 server {which, of course, receives mail by SMTP but then drops it in
Insisting on signatures would also mean that all users would have access to decent strength encryption {since it's the same key pair
Well, it wouldn't surprise me if there is at least one band out there who has done exactly that.
My suggestion for a new recording industry: Artists borrow money using the rights to their work as collateral {this step requires musically-savvy bankers, perh. wannabe pundits} and use this to finance CD recording. Bank, having lien over work, may dictate initial terms of distribution {within reason, laws required to protect artists}. Sales of CDs recoup initial loan; when paid off in full, rights revert to artist. From this point onward, licencing must be on a non-discriminatory basis {i.e. if you allow one person to do X with your work, you must allow anyone else to do X with your work on the same terms}. Additional CDs may be ordered from different suppliers, artist is no longer tied to a label. Possibility exists for "full package deal" recording companies with studio facilities and pressing plant; production-only studios with only mastering facilities, no pressing; also for studio-less labels {perh. supermarkets or specialist "budget" distributors} which only press CDs from masters. {Albums which have recouped must be good sellers.}
The current system is what is called "free market capitalism". Live performance tickets are a scarce resource {unlike recorded albums; which, to all intents and purposes, are an infinite resource and therefore not susceptible to the capitalist economic model; see elsewhere}. The value of tickets increases substantially after the last one is sold.
Anyone with sufficient capital may purchase a ticket whilst they are on general sale, then re-sell the ticket for more than they paid for it. The difference is profit.
One with sufficient capital to invest may even create useful work by employing people to purchase tickets on their behalf, for a mutually acceptable wage. Although the profit per ticket will be smaller, there is a possibility of acquiring {and so reselling} more tickets this way and so realising a larger total profit.
Diminishing returns will set in after a point, but by this time a good capitalist should have diversified into another field.
Note that it may or may not be economically viable to employ a ticket-purchaser directly, on a casual basis, to purchase just one ticket for your own use.
SEAT?! Get real. For £250, I would expect a standing ticket.
No no no no no! Artists do not make, and never have made, money from CD sales. Artists make money the same way as they always made money before the gramophone was invented: from gigs. I've heard of bands actually losing money on CD sales, but am not sure how true this is.
The most money is to be made from gigs in the kind of intimate venues in towns with an active local music scene, that are attended religiously by a hard core of loyal fans -- i.o.w., shitholes that people like Madonna think they are above playing. The least money is to be made from gigs in stadia and other large venues.
A few months after Philips are manufacturing these things, you know that Daewoo will start buying the same chipset. One quick firmware hack later, you will have a telly that automatically changes channels for you when the adverts come on. Or a DVD+RW recorder that automatically puts chapter marks fore and aft of every piss-break.
..... come on. If there is ever a reliable way to distinguish advertising from editorial content {such a thing actually was nearly mandated in the UK once but was rejected}, then it will end up being used in ways that benefit the consumer more than the advertiser.
I mean, seriously
Also, I don't see what there is to grant a patent against. Either there's already a spec for an "advertisement" flag, in which case making use of it to enforce viewing of advertisements should be obvious; or there isn't a spec for an "advertisement" flag, in which case introducing such a flag would be obvious. Patent application is invalid on grounds of obviety either way. Ting! Next, please.
Adverts hosted on a "pay per click" basis are ripe for abuse. Something like running on several computers {possibly without the knowledge or consent of their administrators}, so as to fetch the advert and the page just as though someone loaded up the banner and clicked on it, can generate many bogus clicks on Baseball Bat Finance's homepage {which BBF have to pay for, even although nobody is going to take any action based on such a page hit}. It'd need a real-looking HTTP-user-agent header to make it look more plausible, but you get the general idea. Just set up a business persuading web site owners to carry pay-per-click adverts which you are selling; stick in a quick drive-by download to catch IE users unawares {or maybe a bit of fancy DHTML / JavaScript involving iFrames, cookies and self-redirection now that Firefox is becoming so popular}; the people buying your adverts receive click after click after click {precious little business, mind, but hey -- that's the nature of the advertising game}, and you're coining it in.
{Of course, other loan firms may also wish to set up bogus clicks against Baseball Bat Finance, just to cost their competitors money. And why not? There's nothing quite like stirring up a fight, then selling ammo to both sides and tickets to non-combatants. I swear I had an ancestor who made his living re-fletching used Danish arrows to fire out of a Saxon bow. But I'm digressing a little.}
Let's look at the players again. Baseball Bat Finance are a company with a product or service to sell and plenty of money with which to promote it. They buy advertisements from ScumPeddlers -- a scruple-free online advertisement broker who claim that they can show your advertisement to 120 million people every day, all of whom will be desperate to buy whatever you're selling, several times over and maybe get a few spares for their mates. Fluffy Kitten Stroking Club of the Outer Hebrides is one of many web sites to which ScumPeddlers pay a mere pittance for carrying advertisements. And there's Punters like me and thee who go looking for web sites about kittens and end up getting bombarded with advertisements for products and services which we neither want nor need.
It's unsustainable because eventually, the people who pay for the advertisements {Baseball Bat Finance} are bound to realise that they are not working, and then they will just stop buying them. Up to now, the people who push the adverts onto the punters {ScumPeddlers} have simply resorted to more and more "in-yer-face" techniques, but there's almost no further along that path to go. In addition, the owners of the web sites who are being paid to host these adverts {FKSCotOH} probably are not terribly happy because their visitors {us!} keep asking when they will do anything to get rid of the horrid flashing banners. They might well decide to stop taking the adverts and swallow the costs of running the site, rather than continue alienating their visitors.
As far as I can see, Quantum Encryption is still vulnerable to a man-in-the-middle attack, as long as the malicious interloper can also intercept the "secondary channel" over which Alice and Bob compare their notes and the insecure channel over which the final data will be sent. What QKE really relies on is that Alice doesn't know for certain whether Bob will receive any given one of her bits transmitted over the quantum channel as a "zero" or a "one", and so they have to compare notes over a secondary communications channel before anything can be exchanged using the key. What's said over this channel is not the key itself, but the key EORed with random zeros and ones {which can be inferred by Alice or Bob, but nobody else who did not see the bits sent or received}, and so is ordinarily meaningless to anyone trying to eavesdrop. But if Mallory has a suitable receiver like Bob's and transmitter like Alice's, and records whatever he receives from Alice exactly the way Bob is doing, then it should be possible to reconstruct the keys for both legs of the transmission {Alice to Mallory and Mallory to Bob} from what is already known.
There are a lot of reasons why this would be hard to do, but it's not strictly impossible. And it's exactly the sort of system that's likely to be used where the stakes are high.
What about "Give a man a fish, and he gets a fish. Teach a man to fish, and you get to sell him bait for the rest of his life" ?