"When sound waves impinge upon a diaphragm, such as the skin of a tambourine, they cause it to vibrate. If one could somehow cause such a diaphragm to re-execute the same sequence of vibrations, one must suppose that the effect would be a faithful reproduction of the original sound."
This led, pretty much directly, to the invention of the phonograph.....
Fast-forward to nowadays, and a few realities. The data being transmitted to the sound card are passed as electrical impulses over a bus, and are subject to interception. The format of the data being transmitted to the sound card must be known by anyone who writes software which talks directly to the sound card. {In the case of older cards, such as the venerable SB16, this information is widely known; but there may well be newer cards out there where the drivers are closed-source and proprietary to the manufacturers. At least until the Linux brigade get to work on them}. Most software does not talk directly to the sound card, but rather via a driver. The driver converts the data from some "standard" format {which is specified, if not by the operating system, then at least at some higher level than the hardware; and must be known by anyone who writes software which talks to the driver} to the format used by a particular card. The means by which data are fed to the driver must also be known to anyone who writes software which talks to the driver.
The upshot of all which is, it's trivially easy to capture data meant for the sound card; and there is no place for any kind of security through obscurity, because everyone needs to know at some level how to send data to a sound card. Even if the format of data being sent to the card were kept secret, the format somewhere upstream must be known in order for anyone to be able to get a sound out of the card {and in any case, the format could be discovered anyway, given patience and time}.
If anyone genuinely believes that it is, or ever will be, at all possible to prevent music files from being copied, they are an idiot. Copy protection is mathematically impossible to achieve, and it's about time the music industry got round to dealing with this.
Surely somebody, somewhere will read the source code for these malicious extensions, point out that they are no good, and maybe eventually they or someone else will release a "safe" version?
After all, that's the whole argument for why Open Source is reckoned to be proof against Spyware.
Re:Not just developing countries
on
The Sub-$100 Laptop?
·
· Score: 2, Insightful
Remember the Baygen Freeplay clockwork radio? That was meant for use in developing countries, but ended up becoming popular in Europe and the USA as a sort of fashion statement.
Selling some units in the West would be a good way to recoup some of the initial investment {tooling costs &c.}; though it would not be at all wise to rely on this as a permanent subsidy, because (1) the novelty value will wear off eventually, and (2) the ultimate aim must surely be for the third world not to have to rely on handouts.
Ideally the machines should be made using local labour as far as possible. Anything that creates jobs has to be good for the economy. One way would be to set up several production facilities in different countries, perhaps using money generated from first-world sales to offset initial building and equipment costs. By the time that particular source of revenue dries up, if the factories are managed properly they should already have begun making other products. Eventually, these developing countries might even become developed countries!
You can indeed download the software under the GPL. As long as you accept that you did not write that library yourself, and respect the hours of Other People's Hard Work that went into it by adhering to the terms of the licence, you may use it. Copyright law recognises your creation as a derivative work based on the QT library, and forbids you to distribute it without permission from TrollTech.
The GPL grants you the necessary permission to distribute the combination of your hard work and Other people's hard work provided that distribution is made under the terms of the GPL. As ye have reaped, so shall ye sow.
What you cannot do is download the GPL version of the library, and then use it to write a closed-source application. That would make you a big cowardy-custard {Linus, RMS, ESR et al are not afraid to show off their source code!} and a rotten cheapskate to boot {you tried to profit from their hard work but don't seem to want to let others profit from yours}.
Interestingly, there was never anything stopping anybody from porting a GPL version of QT to Windows. It would run counter to the letter and the spirit of the GPL to restrict a piece of software to a particular platform. Also, if you really, really want to write a closed-source application based on QT, all you need do is insist that the user download a GPL version of QT, and omit all GPL code from your downloadable package. The user would be allowed by the GPL to distribute the GPL code and to use the combined code, but forbidden by copyright law to distribute the combined code. However, you may well be found guilty of aiding and abetting or conspiracy if any copyright offence is committed by the eventual user with respect to the GPL code.
RISC OS was loosely based on some stuff that was written on the eight-bit beeb, back in the days when if someone used your idea you just thought "Wow, they had the same idea I did! How cool is that?" There may indeed be prior art. The AMX Mouse for the BBC microcomputer came out in about 1984 or 85.
Here in the UK, real-life stores are moving to a payment system called Chip and PIN. The idea is that instead of signing the receipt when you pay for your goods, you will enter your PIN {the same one as used for hole-in-the-wall machines} using a small, hand-held keypad. Your bank card will include a "smart card" chip, which is supposed to make it more difficult to forge than the old-fashioned magnetic stripe {at least, until more people become aware of smart card development kits..... after all, if the banks can make smart cards, so can the fraudsters}.
The problem is that this system, while it might have a temporary impact on the use of forged cards, is not at all secure against physical theft of the real card. At least with the signature system, you have a grace period as long it takes for someone to learn to forge your signature convincingly before anyone can get at your account. If you notice your card is missing, you can hopefully report it before anyone has learned your signature {about an hour or two in my experience}. With Chip and PIN, anybody can steal your card and use it to pay for goods. It isn't hard to spot someone's PIN being typed {people who aren't used to the system have even been observed to say it out loud to the cashier}, nor does it take long to persuade a person to reveal a PIN if you hold a blade to their throat.
The traditional problem with this kind of intimidation-based robbery has been that H-I-T-W users are photographed; and if some account holder appears to have had a head transplant, someone somewhere will want to know why. Shops and filling stations probably have their own CCTV systems -- nobody is ever out of sight of a camera in the UK, except maybe in their own home and even then only with the curtains drawn -- but their arrangements are almost certain to be less formal than the banks' ones, and getting access to a third party's CCTV footage means more bureaucracy.
The real benefit is that human beings -- specifically the cashiers, who previously had the responsibility to decide if a signature was valid -- are taken out of the loop, so there is one less person to blame if {when} a fraudulent transaction does go through. This of course mainly benefits the banks. Someone will end up paying for all these false transactions, and in all likelihood it will be the cardholder {who has no way to prove the transaction was not legitimate} and the store {who won't be paid by the bank because they can't prove the transaction was legitimate}. This is the short-term future of card crime in the UK: many independent small-time operators. Get a card, purchase a few high-value-density items {cigarettes, cosmetics, designer clothes}, ditch the card, rinse and repeat. Of course, once somebody works out how to forge smart cards, the paradigm will shift again, back in favour of crime bosses.
Anyway, it's back to cheques for me. At least there is a reasonable audit trail backed up by a signature.
No..... the ultimate rights-management solution is PharmaGard (TM). Unlike conventional scrambling and encryption technologies, which work by unscrambling the picture and taking a leap of faith that nothing can intercept it on its way to the screen, with PharmaGard (TM) there is never a recoverable, unencrypted signal: the final decryption takes place in the viewer's brain.
The secret of PharmaGard (TM) is a special pill, containing a phenylethylamine-type {= ecstasy-like} drug that you have to take before you watch the film. The first few minutes of the film are neurolinguistic programming -- basically, reprogramming your mind so that, under the perception-distorting influence of the drug, it unscrambles the picture -- embedded into an advertisement sequence. There is no possible way for the viewer not to see this sequence if they are going to see the film, so this advertising space would be worth a fortune. As long as the drug's effect lasts, the film appears unscrambled through your altered perception. When it wears off, your eyes go back to normal.
Anyone can copy a film protected with PharmaGard (TM). But only people who have taken the special drug can watch it. If viewers invite friends to watch with them, their friends will have to take some too. A stash of pills are provided with the movie; if you want to watch it again, you have to buy more of them from your local retailer.
PharmaGard (TM) also provides built-in age-restriction. The pills for different-certificate movies are formulated slightly differently. The pills provided with an "18" film will contain an additional substance which reacts with Human Growth Hormone at the levels found in under-18-year-olds to induce undesirable side-effects e.g. nausea, breathing difficulty, loss of balance &c. There will be less of this substance in a "15" film pill to account for the fact that a 15-year old's body will contain a higher level of growth hormone; but the "15" pill will not be a powerful enough psychedelic to allow the consumer's brain to unscramble an "18" film.
Hah. In Europe, every TV bigger than 35cm. since 1981 has had to have a SCART socket. This is a 21 pin connector which gives you at least analogue audio and composite video inputs, and also has a logic-level switching input to select the signal from the TV receiver or the input. On most sets, the SCART connector also provides for RGB. RGB over SCART uses the c-video signal line for the timing signal, and a second logic-level switching signal to indicate RGB mode as opposed to composite; so you can actually put out a full picture signal on the video/timing pin, and RGB on their own individual pins, and that will give you an RGB picture on a "fully-wired set" and a composite video picture on a "partially-wired" set. Many modern sets actually have one fully-wired input {for a DVD player or recorder} and one or more partially-wired inputs {for VCRs, game consoles &c.}. Plus a row of audio sockets around the front for a camcorder.
S-VHS came after SCART, and there is no official way to provide for S-VHS over SCART {though there is an unofficial standard, which uses the "red" signal line for the colour and the "picture" line for the picture; and there is no way to signal electronically that a signal is S-VHS, so it has to be selected manually}. But RGB is technically superior to S-VHS anyway -- it goes pretty much straight to the electron gun control grids in the tube, there is no need for a decoding matrix. {It also is totally independent of PAL, SECAM or NTSC. As long as the horizontal sync is in range that the line output transformer can handle without fear of failure, a set built for any TV standard should be able to resolve a picture from RGB.}
..... Which would be fine, except that microkernels don't work in practice. The theory is fine on a chalkboard. It just breaks down because most of the time, in real life, people aren't using their computers in anything like the way the theoreticians modelled. The hardware you use all the time -- keyboard, display, disc controller -- might just as well have their drivers right there in kernel space, than eating a process in user space. And if the necessary checks and balances are implemented in the kernel space driver -- rather than in a user space driver which then passes its own pre-sanitised data to a kernel space "microdriver" which just chucks it straight at the port -- then they can never be bypassed by any malicious code in user space.
Occasionally hardware can fail in ways the driver was not expecting, but that just says "badly written driver!" The temporary workaround is to compile the driver as a module; then, if the batteries run down on your digital camera in the middle of transferring a load of snapshots, you can always rmmod usb-storage && modprobe usb-storage to reload the driver {after plugging in the mains adapter, of course.....}.
By exactly the same token, the Fire Brigade could save a fortune if people had to book in advance when their houses were going to burn down, and the National Health Service could save a fortune if people had to book in advance when they were going to be ill.
That sort of thing is totally unacceptable, and I cannot think of a punishment -- eighth amendment notwithstanding -- that would not seem overly lenient.
The reason why it would not be necessary to place open source code in escrow, is this. Code Escrow would be there to ensure that anyone who might need access to the source code, can get it -- in a rather limited fashion, but enough to resolve a dispute. Example: user says "This feature doesn't work", vendor says "This user is simply not using it properly", courts say "OK, then -- we'll get a panel of experts to look at the source code", experts say who was right, whoever was wrong gets the bill. In the case of Open Source code, the user already has a copy of the exact same source code from which the software was compiled -- because they compiled it themself on their own computer. All the requirements which would have been satisfied by placing the code in escrow would be equally satisfied by releasing the source code to the Community. And since all means to the same end are equally valid, then there is obviously no requirement to place a copy in escrow. The user has the chance to get the code looked at by an expert before they compile it, so such a dispute should never arise in the first place.
Closed-source vendors should suffer a penalty because they are doing something wrong -- trying to hide their source code and restrict others from improving and sharing it. All the fruits of all human endeavour rightfully belong to all of humankind, and it is wrong for anyone to prevent anyone else from taking their share.
But why should you have a say in my choice?
I'm sorry, but that just sounds too much like "It's my knife, I'll stick it where I like; and if your guts get in the way, tough luck."
I think the Parable of the Tiger is relevant here:
Two men were walking in the forest. Suddenly they spied a tiger. One of them immediately began donning his expensive new Nike trainers.
"Do you really think you can outrun a tiger?," asked his companion.
The first responded, "I don't have to outrun the tiger -- I just have to outrun you."
Distribution package maintainers have to carry out a certain amount of auditing on stuff they add to their distribution. They generally are trustworthy, as they are (1) independent of the author, (2) not doing it for the money and (3) they would lose all their credibility if they fouled up. Then there are the security labs, and all the bored hackers who just like looking at code. If there are flaws, somebody out there will spot them. Remember, there are by definition more good guys than there are bad guys. The "white hats", if they find a vulnerability, will make it public if not fix it outright there and then. It's only the "black hats" who will keep it to themselves until they find a way to use it to your disadvantage.
So any individual user needn't "outrun a tiger" {conduct a full source audit}, because there is a "slower travelling companion" {upstream package maintainer} who will "keep the tiger occupied for awhile". I do audit some code myself, and would not hesitate to inform The Community At Large if I found anything alarming. So far, I haven't.
{To counter your assertion re. the compiler, all you need do is hard-code a subset of a C interpreter in assembler -- it need only know enough C to run the compiler interpretatively. There is then no dirty compiler to mung the clean compiler source. Then you have to worry, does the CCA instruction really only clear the carry flag and do an addition..... ? So you have to build your own processor out of TTL logic gate ICs [yes, it would work, but only up to a few megahertz]..... but then you have to wonder, does that NAND gate really only ever put out a 'one' when either or both inputs are 'zero'?}
I still won't run closed-source software, just on general principle. If the author is not prepared to show me what is inside, then I do not want it in case of what might be inside.
An error occurred while attempting to run a script on this page.
http://www.msn.com/ line 149:
TypeError: Attempt at calkling a function that expects a HTMLDocument on a Window.
But people don't want to compile software - they just want to install it in a form that runs right away.
If you don't compile the software on your own machine, then how do you know it does what it's supposed to do? We should be trumpeting the advantages of local compilation, not trying to pretend it's OK to download packages compiled by someone else. The only objection is that it takes a small but finite amount of time to do. But once done, it's done forever.
As an experienced user, I really don't see what's wrong with the command line. I actually think the command line is another strength we should be trumpeting -- it's often just the quickest way of getting instructions into the computer. I'd much rather open up an Xterm and type
than fart-arse around with loading a graphics editor, loading up the picture through a file requester, navigating through another complex requester to resize it and then back to the file requester to save it. Back in my Windows days, I often used to have to do a lot of just that kind of fart-arsing around, just to create thumbnails of photos for my web site. Even doing one picture at a time on the command line was quicker, but since I learned a bit of Bash and Perl there's been no stopping me.
Maybe we need a generic package installer with a GUI front end, that also shows you how you could have achieved the same operation at the command line. Take the CD-burning package K3B, for instance -- it is really just a pretty frontend to cdrecord, cdrdao and growisofs, and it actually shows you in its output what commands it was running. {It also has some smarts, and will try to figure out how your system is already set up rather than insist to have you configure your system the way it expects.} How hard can it be to have a pretty frontend for gunzip, tar, less, configure and make?
If they want me to believe their product contains no malware, spyware or adware, there is exactly one way they can convince me. And that's the same way that RMS, Linus and ESR convinced me that their software is clean.
If you have nothing to hide, you have nothing to fear.
You are confusing freedom with power. It's an easy mistake to make, though, particularly when you grow up in a power-obsessed society {such as the USA is and the UK is becoming}.
If you were allowed to own slaves, your "freedom index" would be higher. But those slaves would by definition have zero freedom index, and so the mean "freedom index" across the whole of society would be lower.
Imposing ownership on software makes users less free. And to say that proprietary, closed-source software, file formats and protocols somehow impinge on human rights less than slavery is grossly to underestimate the importance of computers in the Western world in the 21st century. As long as your data is saved in a Microsoft Word document or Excel spreadsheet, you do not own it: it is subject to the whims and caprices of Microsoft. If Microsoft decide to bring out a new version of Office that will not open the manuscripts of your magnum opus, your life's work is wasted. This will, of course, be sold as a benefit to you.
I don't think software should be banned for having "overly vague comments", but I think that deliberately making it difficult to understand how a programme works should ultimately be an offence. My "roadmap" {I hate that buzz-word but can't think of a better one} for the end to closed-source software would be: Mandate open data formats. At first, simply guarantee everyone the right to examine data formats and protocols and publish their discoveries; eventually, make it binding on software vendors to publish data format documentation. Since the best documentation for developers is the source code, Open Source suppliers probably would be automatically compliant unless they were using deliberate obfuscation. Require guarantees of performance. It isn't enough to say "if this programme does not do what you thought it would, it's your fault". Other products offered for sale have to be guaranteed. Software should be no different. For this purpose, software supplied as source code should be considered analogous to a kit of parts. The purchaser has the opportunity to subject the source code to independent analysis to determine its suitability for a particular application, and is free to make such modifications as are deemed necessary. Source code escrow is the best way I can see to protect guarantees: a software vendor would be obliged to place a copy of the source code to their product in escrow, and it would be un-sealed by order of the Courts anytime a dispute arose which could only be settled by examining the source code. Of course, Open Source code need never be placed in escrow as the recipient already has a copy of the code. There might never be a need for an actual prohibition on secrecy of source code, as long as it remains more economical to distribute Open Source and thus be automatically compliant with the provisions.
Windows is hopelessly broken. The fact that a binary compiled against Windows 3.1 will work on Windows XP just goes to show that XP is laden down with unnecessary legacy support. It is not any kind of benefit. It is a bad thing, because those dregs of Windows 3.1 that persist into Windows XP are exactly why we have the malware problems we have. In the DOS days, programmers could afford to use techniques that relied on some heavy assumptions since falsified: that a machine would not be connected to a network, and that there were some operations that no user would ever have a legitimate need to perform. {Unix always was network-aware, and always gave its system admins more than enough rope to hang themselves and trip up anybody who came looking for bodies.} DOS, and Windows afterward, ended up being more tolerant of shoddy programming than proper "industrial" operating systems. In some cases, bad programming was actually encouraged by DOS/Windows design blunders. As desktop PC power overtook the first Unix mainframes, and Internet connectivity became the norm, the vectors were lining up for disaster.
You do not need for systems to be backward compatible with ancient binaries. As long as you have the source code, you can simply re-compile it against your latest kernel and libraries, and it will Just Work. If something really has changed so much that it won't compile without editing, then it was already broken in the first place.
Stable closed-source drivers running in or with a closed-source kernel will never exist. Perfection can only be achieved when the driver developer and the kernel developer each have access to the other's code. Anything less than the full, annotated source code is just incomplete documentation.
Closed source is destroying computing. If everything is closed source, then it makes sense to build machines with the kind of processor and the I/O ports in the same addresses. Otherwise you need to supply different versions of essentially the same software just to work with different manufacturers' computers. {Think back to the cassette-based software on the 8-bit computers of the 1980s, and the racks in W.H.Smith full of similar games in versions for the Oric, the Spectrum, the Commodore 64, the BBC model B and the Amstrad CPC464. Come to think of it, why didn't they just record all the different versions on the same cassette one after another, for crying out loud?} All machines built the same way is one way to do it. It is not the only way. You can eliminate architecture-dependence by distributing the source code. Then, any architecture for which a suitable compiler exists can potentially run it.
If there were more machine architectures -- by which I mean physically different instruction sets and/or port addressing schemas -- out there, then we would instantly reduce the susceptibility of the worldwide user base to viruses, worms and trojans. Call it electronic biodiversity. In an environment like that, software would pretty much have to be open source to survive; it would hardly be economically viable for a vendor to release many versions of the same software. You would obtain a package in source form, audit it if desired, compile it, then have to perform some deliberate hardware action {like pressing a small, recessed button; or moving a jumper on the motherboard} to allow it to be installed.
Microsoft will get their comeuppance, though. Sooner or later they will have to launch a new version of Windows that will totally break compatibility with legacy software. Buyers will now have the choice: spend a lot of money buying the latest Windows system, not be able to use any of your old Windows software, have most of your old documents rendered totally unreadable and worry about the next time Microsoft pulls this kind of stunt; or spend not mu
Sorry, I forgot that. Yes, I agree absolutely: all protocols should be open. Maybe I'm just so used to files and block/char devices being accessed alike, that I forgot there even was a distinction: a file is really just a build-up of information, and a protocol is really just a file format for files that move.
It's clear that too many important people have had their heads up their arses for too long.
We need to have it made law that file formats are not secrets and not patentable, but form as much a part of the specification for interacting with the software as, say, the key bindings. {I personally would like to see it become law that software vendors must supply full annotated source code with their products, but let's take it one step at a time..... Mandate open data formats first, then guarantees of performance, then source code escrow to back up the performance guarantees and protect against vendor , then slowly tighten the screws on the escrow agencies and software companies till it's no longer economically viable to sell closed-source software.}
It wouldn't surprise me if some software vendor had tried at some stage seriously to claim in an EULA that all the rights in any document created with their software belonged to them. I know that it used to be a breach of EULA to use a certain software company's programming languages to develop applications that competed directly with that company's offerings.
The good news is that EULAs aren't legally enforceable in any sane jurisdiction anyway, so you can go ahead and exercise your inalienable statutory right to reverse-engineer documents -- for the purposes of study, creation of interoperable software or just morbid curiosity -- to your heart's content. In fact, you can even refuse to accept the EULA at all. You can still quite legally use the software under your inalienable statutory right of Fair Dealing -- you just don't get any benefits that were only promised to you in the EULA.
I know this is at best very tenuously connected to the topic under discussion, but:
Is there some way to use lynx {or some other, similar text-only browser -- I'm not fussy} to render a HTML document as plain text? {And not just sed -e's///' either. I'm not that big a n00b.}
People who refuse to donate their organs are not killing anyone.
I think failing to act in a way that would save someone's life comes a very close second to actually killing them. So do a great many people who have survived accidents that claimed their companions; search for "guilt of survivor" sometime.
Everybody has a right to life, but nobody has the right to take somebody's organs against their wishes.
True, but only living people have wishes. Dead people are a waste product, and waste products should be recycled where possible.
You are not in a position to dictate to others what is and is not worthy of worship. To do so would be to admit that you place no value in the concept of free religious practice.
Some practices are just plain wrong, religious or otherwise. The events of 11/9/2001, and of 21/11/1974, were carried out in the name of religion, by people who genuinely believed they were doing somebody a favour.
You want to do away with the separation of church and state.
Last time I checked, Church and State were one. Same woman in charge of both of them, anyway. Kind of ironic that a Church founded on the principle of easy divorce hasn't gone the whole way and divorced itself but there you go.
Only religions which fit certain criteria are allowed.
So are you saying it's OK to sacrifice virgins at midnight on Full Moon, provided it's done in the name of religion? Are you saying it's OK to bleed a fully conscious animal to death, provided it's done in the name of religion? And if not, why is it somehow OK to deny someone else the gift of life in the name of religion?
Yes, you can; but that won't make any difference. Apache runs as its own non-privileged user {often "nobody", sometimes "www-data" or "apache"} and has a group to itself. Any processes it spawns {to execute scripts, for instance} also run as the Apache user {not the owner of the script} -- unless SUID is in operation, and that's a huge security risk. You don't know who the hell is connecting to your box via HTTP -- anyone potentially could set a script running with root privileges {therefore able to tamper with any logfiles}, without entering any kind of username or password.
On most Unixes, only root can chown files. You ought to be able to chown your own files, but it's strictly a one-way ticket. {Why?} And let's not forget the opportunity to frame a colleague {chown unluckyeddy:itdept 10yr_old_amy.jpg win_xp_src.tar.gz star_wars_episode_3.dvd.iso && shred -n1 ~/.bash_history}. Best not to let every Caz, Shaz and Daz use it.
So even if only the Apache user was allowed to read your scripts, you would be no more secure than if they were world-readable. Password-hunting scripts would still be running in the name of Apache, therefore allowed to access others' passwords.
Try it if you don't believe me; but if you do it on a real ISP's server, watch you don't get caught, because it is almost certain to be a breach of AUP. Open a sacrificial hosting account and consider it money spent in the name of research.
Linux passwords are scrambled, but the root user can read the scrambled password file. The first part of the scrambled password ($1$, eight letters/digits, $) is the "salt". The same plaintext password and the same salt will always produce the same scrambled password. The password scrambling algorithm is a standard C library function, so almost every programme uses it, not just the login validator.
Upshot: if you copy a scrambled password from one user to another, or out of/etc/shadow into a.htpasswd {apache password file; used to password-protect directories} or something similar, it'll Just Work.
MySQL actually uses a different password hashing algorithm, unless you tweaked the source, but I think the parent is talking about PHPMyAdmin. This creates a standard.htpasswd file when it is installed, and it uses root's UNIX password. Note you still have to supply PHPMyAdmin with a MySQL username and password. By default, MySQL has a user called "root" with no password who is only allowed to login locally. This is considered secure enough for most applications.
NB: it's generally a very bad idea to use the same password for login and database. One dodgy web hosting company I have experienced actually did this. The MySQL username and password have to be in your user directory somewhere, in plaintext, and they have to be world-readable so the Apache daemon can see them. Upshot: any user can see any other user's database username and password. {This is why the root/no password combination isn't so insecure as it looks.} Ordinarily, the PHP {or Perl or Python} interpreter gets them first, and the user only ever sees the output from the interpreter; but you can pay for an account with the same company, determine the directory structure reasonably easily, and use a simple PHP, Perl, Python or Bash script to traverse other users' directories looking for passwords. If the database username and password is the same as the UNIX password then you can have much fun, since these passwords are also good for FTP, POP3 and SSH.
Slashdot Mirror
From a 19th century notebook: This led, pretty much directly, to the invention of the phonograph
Fast-forward to nowadays, and a few realities. The data being transmitted to the sound card are passed as electrical impulses over a bus, and are subject to interception. The format of the data being transmitted to the sound card must be known by anyone who writes software which talks directly to the sound card. {In the case of older cards, such as the venerable SB16, this information is widely known; but there may well be newer cards out there where the drivers are closed-source and proprietary to the manufacturers. At least until the Linux brigade get to work on them}. Most software does not talk directly to the sound card, but rather via a driver. The driver converts the data from some "standard" format {which is specified, if not by the operating system, then at least at some higher level than the hardware; and must be known by anyone who writes software which talks to the driver} to the format used by a particular card. The means by which data are fed to the driver must also be known to anyone who writes software which talks to the driver.
The upshot of all which is, it's trivially easy to capture data meant for the sound card; and there is no place for any kind of security through obscurity, because everyone needs to know at some level how to send data to a sound card. Even if the format of data being sent to the card were kept secret, the format somewhere upstream must be known in order for anyone to be able to get a sound out of the card {and in any case, the format could be discovered anyway, given patience and time}.
If anyone genuinely believes that it is, or ever will be, at all possible to prevent music files from being copied, they are an idiot. Copy protection is mathematically impossible to achieve, and it's about time the music industry got round to dealing with this.
Surely somebody, somewhere will read the source code for these malicious extensions, point out that they are no good, and maybe eventually they or someone else will release a "safe" version?
After all, that's the whole argument for why Open Source is reckoned to be proof against Spyware.
Remember the Baygen Freeplay clockwork radio? That was meant for use in developing countries, but ended up becoming popular in Europe and the USA as a sort of fashion statement.
Selling some units in the West would be a good way to recoup some of the initial investment {tooling costs &c.}; though it would not be at all wise to rely on this as a permanent subsidy, because (1) the novelty value will wear off eventually, and (2) the ultimate aim must surely be for the third world not to have to rely on handouts.
Ideally the machines should be made using local labour as far as possible. Anything that creates jobs has to be good for the economy. One way would be to set up several production facilities in different countries, perhaps using money generated from first-world sales to offset initial building and equipment costs. By the time that particular source of revenue dries up, if the factories are managed properly they should already have begun making other products. Eventually, these developing countries might even become developed countries!
You can indeed download the software under the GPL. As long as you accept that you did not write that library yourself, and respect the hours of Other People's Hard Work that went into it by adhering to the terms of the licence, you may use it. Copyright law recognises your creation as a derivative work based on the QT library, and forbids you to distribute it without permission from TrollTech.
The GPL grants you the necessary permission to distribute the combination of your hard work and Other people's hard work provided that distribution is made under the terms of the GPL. As ye have reaped, so shall ye sow.
What you cannot do is download the GPL version of the library, and then use it to write a closed-source application. That would make you a big cowardy-custard {Linus, RMS, ESR et al are not afraid to show off their source code!} and a rotten cheapskate to boot {you tried to profit from their hard work but don't seem to want to let others profit from yours}.
Interestingly, there was never anything stopping anybody from porting a GPL version of QT to Windows. It would run counter to the letter and the spirit of the GPL to restrict a piece of software to a particular platform. Also, if you really, really want to write a closed-source application based on QT, all you need do is insist that the user download a GPL version of QT, and omit all GPL code from your downloadable package. The user would be allowed by the GPL to distribute the GPL code and to use the combined code, but forbidden by copyright law to distribute the combined code. However, you may well be found guilty of aiding and abetting or conspiracy if any copyright offence is committed by the eventual user with respect to the GPL code.
RISC OS was loosely based on some stuff that was written on the eight-bit beeb, back in the days when if someone used your idea you just thought "Wow, they had the same idea I did! How cool is that?" There may indeed be prior art. The AMX Mouse for the BBC microcomputer came out in about 1984 or 85.
You think that's bad?
..... after all, if the banks can make smart cards, so can the fraudsters}.
Here in the UK, real-life stores are moving to a payment system called Chip and PIN. The idea is that instead of signing the receipt when you pay for your goods, you will enter your PIN {the same one as used for hole-in-the-wall machines} using a small, hand-held keypad. Your bank card will include a "smart card" chip, which is supposed to make it more difficult to forge than the old-fashioned magnetic stripe {at least, until more people become aware of smart card development kits
The problem is that this system, while it might have a temporary impact on the use of forged cards, is not at all secure against physical theft of the real card. At least with the signature system, you have a grace period as long it takes for someone to learn to forge your signature convincingly before anyone can get at your account. If you notice your card is missing, you can hopefully report it before anyone has learned your signature {about an hour or two in my experience}. With Chip and PIN, anybody can steal your card and use it to pay for goods. It isn't hard to spot someone's PIN being typed {people who aren't used to the system have even been observed to say it out loud to the cashier}, nor does it take long to persuade a person to reveal a PIN if you hold a blade to their throat.
The traditional problem with this kind of intimidation-based robbery has been that H-I-T-W users are photographed; and if some account holder appears to have had a head transplant, someone somewhere will want to know why. Shops and filling stations probably have their own CCTV systems -- nobody is ever out of sight of a camera in the UK, except maybe in their own home and even then only with the curtains drawn -- but their arrangements are almost certain to be less formal than the banks' ones, and getting access to a third party's CCTV footage means more bureaucracy.
The real benefit is that human beings -- specifically the cashiers, who previously had the responsibility to decide if a signature was valid -- are taken out of the loop, so there is one less person to blame if {when} a fraudulent transaction does go through. This of course mainly benefits the banks. Someone will end up paying for all these false transactions, and in all likelihood it will be the cardholder {who has no way to prove the transaction was not legitimate} and the store {who won't be paid by the bank because they can't prove the transaction was legitimate}. This is the short-term future of card crime in the UK: many independent small-time operators. Get a card, purchase a few high-value-density items {cigarettes, cosmetics, designer clothes}, ditch the card, rinse and repeat. Of course, once somebody works out how to forge smart cards, the paradigm will shift again, back in favour of crime bosses.
Anyway, it's back to cheques for me. At least there is a reasonable audit trail backed up by a signature.
No ..... the ultimate rights-management solution is PharmaGard (TM). Unlike conventional scrambling and encryption technologies, which work by unscrambling the picture and taking a leap of faith that nothing can intercept it on its way to the screen, with PharmaGard (TM) there is never a recoverable, unencrypted signal: the final decryption takes place in the viewer's brain.
The secret of PharmaGard (TM) is a special pill, containing a phenylethylamine-type {= ecstasy-like} drug that you have to take before you watch the film. The first few minutes of the film are neurolinguistic programming -- basically, reprogramming your mind so that, under the perception-distorting influence of the drug, it unscrambles the picture -- embedded into an advertisement sequence. There is no possible way for the viewer not to see this sequence if they are going to see the film, so this advertising space would be worth a fortune. As long as the drug's effect lasts, the film appears unscrambled through your altered perception. When it wears off, your eyes go back to normal.
Anyone can copy a film protected with PharmaGard (TM). But only people who have taken the special drug can watch it. If viewers invite friends to watch with them, their friends will have to take some too. A stash of pills are provided with the movie; if you want to watch it again, you have to buy more of them from your local retailer.
PharmaGard (TM) also provides built-in age-restriction. The pills for different-certificate movies are formulated slightly differently. The pills provided with an "18" film will contain an additional substance which reacts with Human Growth Hormone at the levels found in under-18-year-olds to induce undesirable side-effects e.g. nausea, breathing difficulty, loss of balance &c. There will be less of this substance in a "15" film pill to account for the fact that a 15-year old's body will contain a higher level of growth hormone; but the "15" pill will not be a powerful enough psychedelic to allow the consumer's brain to unscramble an "18" film.
Hah. In Europe, every TV bigger than 35cm. since 1981 has had to have a SCART socket. This is a 21 pin connector which gives you at least analogue audio and composite video inputs, and also has a logic-level switching input to select the signal from the TV receiver or the input. On most sets, the SCART connector also provides for RGB. RGB over SCART uses the c-video signal line for the timing signal, and a second logic-level switching signal to indicate RGB mode as opposed to composite; so you can actually put out a full picture signal on the video/timing pin, and RGB on their own individual pins, and that will give you an RGB picture on a "fully-wired set" and a composite video picture on a "partially-wired" set. Many modern sets actually have one fully-wired input {for a DVD player or recorder} and one or more partially-wired inputs {for VCRs, game consoles &c.}. Plus a row of audio sockets around the front for a camcorder.
S-VHS came after SCART, and there is no official way to provide for S-VHS over SCART {though there is an unofficial standard, which uses the "red" signal line for the colour and the "picture" line for the picture; and there is no way to signal electronically that a signal is S-VHS, so it has to be selected manually}. But RGB is technically superior to S-VHS anyway -- it goes pretty much straight to the electron gun control grids in the tube, there is no need for a decoding matrix. {It also is totally independent of PAL, SECAM or NTSC. As long as the horizontal sync is in range that the line output transformer can handle without fear of failure, a set built for any TV standard should be able to resolve a picture from RGB.}
..... Which would be fine, except that microkernels don't work in practice. The theory is fine on a chalkboard. It just breaks down because most of the time, in real life, people aren't using their computers in anything like the way the theoreticians modelled. The hardware you use all the time -- keyboard, display, disc controller -- might just as well have their drivers right there in kernel space, than eating a process in user space. And if the necessary checks and balances are implemented in the kernel space driver -- rather than in a user space driver which then passes its own pre-sanitised data to a kernel space "microdriver" which just chucks it straight at the port -- then they can never be bypassed by any malicious code in user space.
.....}.
Occasionally hardware can fail in ways the driver was not expecting, but that just says "badly written driver!" The temporary workaround is to compile the driver as a module; then, if the batteries run down on your digital camera in the middle of transferring a load of snapshots, you can always rmmod usb-storage && modprobe usb-storage to reload the driver {after plugging in the mains adapter, of course
By exactly the same token, the Fire Brigade could save a fortune if people had to book in advance when their houses were going to burn down, and the National Health Service could save a fortune if people had to book in advance when they were going to be ill.
That sort of thing is totally unacceptable, and I cannot think of a punishment -- eighth amendment notwithstanding -- that would not seem overly lenient.
Closed-source vendors should suffer a penalty because they are doing something wrong -- trying to hide their source code and restrict others from improving and sharing it. All the fruits of all human endeavour rightfully belong to all of humankind, and it is wrong for anyone to prevent anyone else from taking their share. I'm sorry, but that just sounds too much like "It's my knife, I'll stick it where I like; and if your guts get in the way, tough luck."
I think the Parable of the Tiger is relevant here:
..... ? So you have to build your own processor out of TTL logic gate ICs [yes, it would work, but only up to a few megahertz] ..... but then you have to wonder, does that NAND gate really only ever put out a 'one' when either or both inputs are 'zero'?}
Two men were walking in the forest. Suddenly they spied a tiger. One of them immediately began donning his expensive new Nike trainers.
"Do you really think you can outrun a tiger?," asked his companion.
The first responded, "I don't have to outrun the tiger -- I just have to outrun you."
Distribution package maintainers have to carry out a certain amount of auditing on stuff they add to their distribution. They generally are trustworthy, as they are (1) independent of the author, (2) not doing it for the money and (3) they would lose all their credibility if they fouled up. Then there are the security labs, and all the bored hackers who just like looking at code. If there are flaws, somebody out there will spot them. Remember, there are by definition more good guys than there are bad guys. The "white hats", if they find a vulnerability, will make it public if not fix it outright there and then. It's only the "black hats" who will keep it to themselves until they find a way to use it to your disadvantage.
So any individual user needn't "outrun a tiger" {conduct a full source audit}, because there is a "slower travelling companion" {upstream package maintainer} who will "keep the tiger occupied for awhile". I do audit some code myself, and would not hesitate to inform The Community At Large if I found anything alarming. So far, I haven't.
{To counter your assertion re. the compiler, all you need do is hard-code a subset of a C interpreter in assembler -- it need only know enough C to run the compiler interpretatively. There is then no dirty compiler to mung the clean compiler source. Then you have to worry, does the CCA instruction really only clear the carry flag and do an addition
I still won't run closed-source software, just on general principle. If the author is not prepared to show me what is inside, then I do not want it in case of what might be inside.
An error occurred while attempting to run a script on this page.
http://www.msn.com/ line 149:
TypeError: Attempt at calkling a function that expects a HTMLDocument on a Window.
As an experienced user, I really don't see what's wrong with the command line. I actually think the command line is another strength we should be trumpeting -- it's often just the quickest way of getting instructions into the computer. I'd much rather open up an Xterm and type than fart-arse around with loading a graphics editor, loading up the picture through a file requester, navigating through another complex requester to resize it and then back to the file requester to save it. Back in my Windows days, I often used to have to do a lot of just that kind of fart-arsing around, just to create thumbnails of photos for my web site. Even doing one picture at a time on the command line was quicker, but since I learned a bit of Bash and Perl there's been no stopping me.
Maybe we need a generic package installer with a GUI front end, that also shows you how you could have achieved the same operation at the command line. Take the CD-burning package K3B, for instance -- it is really just a pretty frontend to cdrecord, cdrdao and growisofs, and it actually shows you in its output what commands it was running. {It also has some smarts, and will try to figure out how your system is already set up rather than insist to have you configure your system the way it expects.} How hard can it be to have a pretty frontend for gunzip, tar, less, configure and make?
You don't buy a pair of shoes unless you've tried them on. Why should I buy software without having a dekko at the source code first?
If they want me to believe their product contains no malware, spyware or adware, there is exactly one way they can convince me. And that's the same way that RMS, Linus and ESR convinced me that their software is clean.
If you have nothing to hide, you have nothing to fear.
You are confusing freedom with power. It's an easy mistake to make, though, particularly when you grow up in a power-obsessed society {such as the USA is and the UK is becoming}.
If you were allowed to own slaves, your "freedom index" would be higher. But those slaves would by definition have zero freedom index, and so the mean "freedom index" across the whole of society would be lower.
Imposing ownership on software makes users less free. And to say that proprietary, closed-source software, file formats and protocols somehow impinge on human rights less than slavery is grossly to underestimate the importance of computers in the Western world in the 21st century. As long as your data is saved in a Microsoft Word document or Excel spreadsheet, you do not own it: it is subject to the whims and caprices of Microsoft. If Microsoft decide to bring out a new version of Office that will not open the manuscripts of your magnum opus, your life's work is wasted. This will, of course, be sold as a benefit to you.
I don't think software should be banned for having "overly vague comments", but I think that deliberately making it difficult to understand how a programme works should ultimately be an offence. My "roadmap" {I hate that buzz-word but can't think of a better one} for the end to closed-source software would be: Mandate open data formats. At first, simply guarantee everyone the right to examine data formats and protocols and publish their discoveries; eventually, make it binding on software vendors to publish data format documentation. Since the best documentation for developers is the source code, Open Source suppliers probably would be automatically compliant unless they were using deliberate obfuscation. Require guarantees of performance. It isn't enough to say "if this programme does not do what you thought it would, it's your fault". Other products offered for sale have to be guaranteed. Software should be no different. For this purpose, software supplied as source code should be considered analogous to a kit of parts. The purchaser has the opportunity to subject the source code to independent analysis to determine its suitability for a particular application, and is free to make such modifications as are deemed necessary. Source code escrow is the best way I can see to protect guarantees: a software vendor would be obliged to place a copy of the source code to their product in escrow, and it would be un-sealed by order of the Courts anytime a dispute arose which could only be settled by examining the source code. Of course, Open Source code need never be placed in escrow as the recipient already has a copy of the code. There might never be a need for an actual prohibition on secrecy of source code, as long as it remains more economical to distribute Open Source and thus be automatically compliant with the provisions.
Windows is hopelessly broken. The fact that a binary compiled against Windows 3.1 will work on Windows XP just goes to show that XP is laden down with unnecessary legacy support. It is not any kind of benefit. It is a bad thing, because those dregs of Windows 3.1 that persist into Windows XP are exactly why we have the malware problems we have. In the DOS days, programmers could afford to use techniques that relied on some heavy assumptions since falsified: that a machine would not be connected to a network, and that there were some operations that no user would ever have a legitimate need to perform. {Unix always was network-aware, and always gave its system admins more than enough rope to hang themselves and trip up anybody who came looking for bodies.} DOS, and Windows afterward, ended up being more tolerant of shoddy programming than proper "industrial" operating systems. In some cases, bad programming was actually encouraged by DOS/Windows design blunders. As desktop PC power overtook the first Unix mainframes, and Internet connectivity became the norm, the vectors were lining up for disaster.
You do not need for systems to be backward compatible with ancient binaries. As long as you have the source code, you can simply re-compile it against your latest kernel and libraries, and it will Just Work. If something really has changed so much that it won't compile without editing, then it was already broken in the first place.
Stable closed-source drivers running in or with a closed-source kernel will never exist. Perfection can only be achieved when the driver developer and the kernel developer each have access to the other's code. Anything less than the full, annotated source code is just incomplete documentation.
Closed source is destroying computing. If everything is closed source, then it makes sense to build machines with the kind of processor and the I/O ports in the same addresses. Otherwise you need to supply different versions of essentially the same software just to work with different manufacturers' computers. {Think back to the cassette-based software on the 8-bit computers of the 1980s, and the racks in W.H.Smith full of similar games in versions for the Oric, the Spectrum, the Commodore 64, the BBC model B and the Amstrad CPC464. Come to think of it, why didn't they just record all the different versions on the same cassette one after another, for crying out loud?} All machines built the same way is one way to do it. It is not the only way. You can eliminate architecture-dependence by distributing the source code. Then, any architecture for which a suitable compiler exists can potentially run it.
If there were more machine architectures -- by which I mean physically different instruction sets and/or port addressing schemas -- out there, then we would instantly reduce the susceptibility of the worldwide user base to viruses, worms and trojans. Call it electronic biodiversity. In an environment like that, software would pretty much have to be open source to survive; it would hardly be economically viable for a vendor to release many versions of the same software. You would obtain a package in source form, audit it if desired, compile it, then have to perform some deliberate hardware action {like pressing a small, recessed button; or moving a jumper on the motherboard} to allow it to be installed.
Microsoft will get their comeuppance, though. Sooner or later they will have to launch a new version of Windows that will totally break compatibility with legacy software. Buyers will now have the choice: spend a lot of money buying the latest Windows system, not be able to use any of your old Windows software, have most of your old documents rendered totally unreadable and worry about the next time Microsoft pulls this kind of stunt; or spend not mu
Sorry, I forgot that. Yes, I agree absolutely: all protocols should be open. Maybe I'm just so used to files and block/char devices being accessed alike, that I forgot there even was a distinction: a file is really just a build-up of information, and a protocol is really just a file format for files that move.
It's clear that too many important people have had their heads up their arses for too long.
..... Mandate open data formats first, then guarantees of performance, then source code escrow to back up the performance guarantees and protect against vendor , then slowly tighten the screws on the escrow agencies and software companies till it's no longer economically viable to sell closed-source software.}
We need to have it made law that file formats are not secrets and not patentable, but form as much a part of the specification for interacting with the software as, say, the key bindings. {I personally would like to see it become law that software vendors must supply full annotated source code with their products, but let's take it one step at a time
It wouldn't surprise me if some software vendor had tried at some stage seriously to claim in an EULA that all the rights in any document created with their software belonged to them. I know that it used to be a breach of EULA to use a certain software company's programming languages to develop applications that competed directly with that company's offerings.
The good news is that EULAs aren't legally enforceable in any sane jurisdiction anyway, so you can go ahead and exercise your inalienable statutory right to reverse-engineer documents -- for the purposes of study, creation of interoperable software or just morbid curiosity -- to your heart's content. In fact, you can even refuse to accept the EULA at all. You can still quite legally use the software under your inalienable statutory right of Fair Dealing -- you just don't get any benefits that were only promised to you in the EULA.
That's it ..... I knew there was a way. You have earned yourself a blue dot by my nickname.
I know this is at best very tenuously connected to the topic under discussion, but:
Is there some way to use lynx {or some other, similar text-only browser -- I'm not fussy} to render a HTML document as plain text? {And not just sed -e's///' either. I'm not that big a n00b.}
Yes, you can; but that won't make any difference. Apache runs as its own non-privileged user {often "nobody", sometimes "www-data" or "apache"} and has a group to itself. Any processes it spawns {to execute scripts, for instance} also run as the Apache user {not the owner of the script} -- unless SUID is in operation, and that's a huge security risk. You don't know who the hell is connecting to your box via HTTP -- anyone potentially could set a script running with root privileges {therefore able to tamper with any logfiles}, without entering any kind of username or password.
On most Unixes, only root can chown files. You ought to be able to chown your own files, but it's strictly a one-way ticket. {Why?} And let's not forget the opportunity to frame a colleague {chown unluckyeddy:itdept 10yr_old_amy.jpg win_xp_src.tar.gz star_wars_episode_3.dvd.iso && shred -n1 ~/.bash_history}. Best not to let every Caz, Shaz and Daz use it.
So even if only the Apache user was allowed to read your scripts, you would be no more secure than if they were world-readable. Password-hunting scripts would still be running in the name of Apache, therefore allowed to access others' passwords.
Try it if you don't believe me; but if you do it on a real ISP's server, watch you don't get caught, because it is almost certain to be a breach of AUP. Open a sacrificial hosting account and consider it money spent in the name of research.
Linux passwords are scrambled, but the root user can read the scrambled password file. The first part of the scrambled password ($1$, eight letters/digits, $) is the "salt". The same plaintext password and the same salt will always produce the same scrambled password. The password scrambling algorithm is a standard C library function, so almost every programme uses it, not just the login validator.
/etc/shadow into a .htpasswd {apache password file; used to password-protect directories} or something similar, it'll Just Work.
.htpasswd file when it is installed, and it uses root's UNIX password. Note you still have to supply PHPMyAdmin with a MySQL username and password. By default, MySQL has a user called "root" with no password who is only allowed to login locally. This is considered secure enough for most applications.
Upshot: if you copy a scrambled password from one user to another, or out of
MySQL actually uses a different password hashing algorithm, unless you tweaked the source, but I think the parent is talking about PHPMyAdmin. This creates a standard
NB: it's generally a very bad idea to use the same password for login and database. One dodgy web hosting company I have experienced actually did this. The MySQL username and password have to be in your user directory somewhere, in plaintext, and they have to be world-readable so the Apache daemon can see them. Upshot: any user can see any other user's database username and password. {This is why the root/no password combination isn't so insecure as it looks.} Ordinarily, the PHP {or Perl or Python} interpreter gets them first, and the user only ever sees the output from the interpreter; but you can pay for an account with the same company, determine the directory structure reasonably easily, and use a simple PHP, Perl, Python or Bash script to traverse other users' directories looking for passwords. If the database username and password is the same as the UNIX password then you can have much fun, since these passwords are also good for FTP, POP3 and SSH.