Watch out there. Have you not heard the news? SCO just discovered that they own The Simpsons. They have already changed their name to SKO and are demanding a $200 payment for every "Komedy K".
I was thinking 2004 would be the year I go for my driving test. Now I know for certain what kind of vehicle I want to get myself when I do! It will have a Diesel engine with a mechanical fuel pump. Not only will it run fine on cookig oil, it will be immune to any attempt to jam it electronically. Since I'll be running it on non-fossil fuels, I'm not too worried about the extra CO2 emissions -- it's just was already there before the sunflowers were grown, after all.
Anyone know if you can get a Diesel engine onto a series I/II Landie? Or were they all petrol?
Yeah, but you can easily change a number plate. Especially if you can find a similar car -- perhaps belonging to a person you know for sure won't have an alibi -- and replicate its number plates. There are regulations to prevent unauthorised manufacture of number plates; these, however, are about as effective as a chocolate fireguard, only somewhat less edible.
What happens is that when criminals are put in prison, they talk about their various crimes and discuss ways they could have been improved. Put a forger and a smuggler in the same cell, and false paperwork will turn up in the conversation sooner or later. Back on the outside, ideas will find their way into practice. So if a carjacker and a cracker get together, then that may well end up happening.
I've often wondered why they put criminals convicted of different crimes in the same prison, rather than away from people convicted of other crimes, precisely to avoid this sort of thing. And for that matter, why do they allow prisoners to smoke? Surely a non-smoking axe murderer is a better citizen than a smoking axe murderer?
Depends if or not you filled the tyres with expanding polyurethane foam {sold -- in a can with a tyre valve connector -- at motor accessory stores, for repairing punctures} before you started. I'm sure there must already be some sort of "honeycomb" tyre already available for extreme situations where you might get a puncture but still need to be able to run for several kilometres.
I thought the idea was to release a film on, say, the eighth of April in the USA and the fourth of August the same year in the rest of the world. Then they could write the release date in figures on the posters, and use just one print run for the whole world.
For broadcasting and storage, I would agree with you -- you can get away with less bandwidth on the colour signals than the picture signal because the human eye has fewer colour sensors than brightness sensors, and the Y component is suitable for feeding direct into a mono CRT. But for digital applications, I would have thought it better to do the YUV-RGB transform entirely in the digital domain {it's just a straightforward matrix multiplication after all}, and output the red, green and blue signals straight from the DAC to the set.
As I pointed out, this is already done in Europe - the SCART connector carries RGB and a separate timing signal which just happens to include picture and colour information.
It isn't that hard to remove the Macrovision. You're right, it adds out-of-range pulses during the "invisible" parts of the picture signal which throw off the VCR's automatic gain control circuitry {a TV receiver can get away with a much longer time constant on its AGC as there is no need to avoid overloading a tape head}.
A conventional lowpass filter will not work because it will attenuate the high frequencies in the picture, ruining sharp edges. Unless, as the parent points out, the sync signal has only timing information on it..... or at least only the timing matters and there is no AGC.....
Now, assuming that the VCR's motor has a nice heavy flywheel and the tape speed is thus good and constant, you can work out where the sync pulses should go and substitute a nice, clean, locally-generated version of whatever the sync pulse should have looked like. Early attempts to do this in the analogue domain seem to have been supplanted by microcontrolled circuits, now PICs have broken the 10MHz barrier.
But the whole idea that the movie industry could insist that TV manufacturers use a connection system which is technically inferior to the best merely in order to allow for an easily-defeated copy prevention scheme acknowledged to do more harm than good, frankly beggars belief.
MySQL. Store tasks in a database - make use of datetime and text field types. Perl. Use/etc/passwd for managing the user accounts.
Use a web-based interface with JavaScript and Java applets on the client end and avoid the need for RPC altogether. Any CGI script can generate a bit of JavaScript to bring up a page automatically on a timeout. A quick and dirty bodge would be to popup a window and make it self-minimise; said window runs a bit of a CGI script which responds to trigger events {watches a directory for files changing, for example}, and refreshes itself at intervals so it keeps on checking. When the appropriate event occurs, the window restores itself, displays the appropriate content and comes to the front.
It doesn't really have to be Exchange. All means to the same end are equally valid.
Don't Evolution, Kmail and Konqueror {or Mozilla Firebird and Thunderbird} on the desktop, and Sendmail, Procmail, Qpopper, Apache, MySQL and P(HP|erl|ython) on the server, constitute an effective Exchange/Outlook replacement? The admin side of the job is easy too; once you know exactly what packages are needed on the desktop, you put them on your own local package repository {whoops, better add ProFTPD to the server wish list}. Now compile a package of your own with no files {go on then, maybe some ready-made *rc files}, just dependencies on those packages; then just try to install your metapackage on those machines and let the automatic dependency resolution do the hard work {I'm assuming.deb here, but I'm sure.rpm probably isn't much different if you set it up properly}.
Sure, it sounds like hard work setting it all up, but think about this. Windows clients typically need something doing to them at least once a day, and the time it takes to do that for every machine you have to see to mounts up. Now if you spend a whole day writing a programme to do in five minutes something you could have done by hand in an hour, that sounds like an extravagance - nearly seven hours wasted. But the eighth time you run that programme, it's begun to break even. I'm not suggesting you can write an entire application suite in just one day, but if you're in charge of Windows machines just try adding up your time spent fart-arsing around resetting boxes and so forth.....
And if I really wanted to dangle the bait, I would say anyone who thinks KDE and Gnome ripped off ideas from Microsoft should remember who ripped those ideas off from Apple.
First cousin = someone who shares one grandparent with you. A parent's sibling's child.
Second cousin = someone who shares one great-grandparent with you. A parent's cousin's child.
Cousins n times removed - your cousin's children are your cousins once removed, their grandchildren are your cousins twice removed, and so on. Or your parent's {intentional singular - ajs} cousins would also be your cousins once removed. {Your cousin's parents aren't your cousins once removed, of course; they're your auntie and uncle.} Firstness and secondness start to get a bit blurred with removals. There are, in theory, such relations as third, fourth and even higher generation cousins; however, it's only now that people are living longer and having children sooner that anybody is likely to have any real-life examples.
If you think that's confusing, think how much uglier it gets when you factor in people who become a member of your family by getting married to someone who is already a member of your family. In some jurisdictions there probably could exist a kind of race condition where one marriage might render another marriage unlawful, depending on the order in which they took place!
So why don't we send a staffed mission to Mars? Something with a human being on board might stand a fighting chance of actually getting there -- if some unusual situation is encountered, it can be dealt with right there and then. It's not as though human beings are in short supply or require any special tools to manufacture. Even if the trip is strictly one-way, it wouldn't be the first time anyone didn't make it home {how many casualties in Iraq?} Beside which, the honour of "first Earthling buried on Mars" would be a great one, even despite its inherent posthumousness.
I say, get thinking the unthinkable. Stop the cowardice and send a staffed mission now. A few human lives would be a small price to pay for the dividend it would bring.
I thought U and V were just other names for the colour-difference components R-Y and B-Y, but I couldn't remember which was red and which was blue, so I cheated and failed to mention it. Like pronouncing "Samhain" as "'kel-tik nyoo 'yee-ah". Anyway, according to my understanding, Y = 0.3 * R + 0.6 * G + 0.1 * B, and the red and blue differences are R-Y and B-Y. So you can easily recreate R and B with two op-amps, R = (R-Y) + Y and B = (B-Y) + Y, but to get G you have to fartarse around..... G = (Y - 0.3 * R - 0.1 * B) * 1.667. The nasty multiplying factors are to compensate for the human eye's response, which makes green light appear brighter than red and blue light appear dimmer than red for the same actual amount of energy. Using Y = 0.3 * R + 0.6 * G + 0.1 * B means you can feed a mono CRT from just Y and get a sane-looking picture..... so the fancy circuitry to regenerate the red, green and blue grid drives for a colour CRT goes only into colour sets {remember, colour TV predates the integrated circuit so when I say "an op-amp" remember that must be built up using at least 3 triodes or transistors} and colour signals degrade gracefully on mono sets.
As for the thing about Macrovision.......... shit! You've got to be kidding, right?
For one thing, it's so easily defeated as not to be a serious threat to anything {it makes it slightly awkward to copy from VHS to VHS, because you need a sync regenerator; they are legally available because some older composite monitors are allergic to Macrovision, and before sync regenerators could be banned, the movie studios would have to pay to replace everyone's incompatible equipment and arrange for it to be recycled in an environmentally-friendly manner. It's cheaper just to let people have Macrovision strippers^W^Wsync regenerators.}
As for connectors, does US kit not have SCART sockets, or is the wiring of a US SCART socket different from a European one? If not SCART, what does your all-in-one connector look like?
Here in Europe {where PAL reigns supreme}, Y/Pr/Pb aka YUV component video is rarely used. Most European TV sets have at least one SCART socket. SCART is a 21-pin connector which can carry RGB or composite video and audio, logic-level switching signals and enough returns to shield everything. Most TVs have the first SCART socket {AV1} fully wired, and the second {AV2} wired for composite only {VCRs don't do RGB}. The neat part is that in RGB mode, the pin that would normally be used for the composite picture signal is used for the timing signal, but of course the timing information is all in the negative-going portions. So an appliance such as a Playstation or DVD player will put out a full composite video signal on the "timing" output and RGB on the main RGB outputs. Remember I said the SCART connector has switching pins; pin 8 selects from the internal off-air receiver or from the SCART socket, and pin 16 selects composite or RGB. If the TV input supports RGB, then it will respond to the logic 1 on pin 16 and use the RGB signal, taking the timing from the composite signal. If the input is composite-only, then it will totally ignore pin 16 and display the composite picture signal, which will be the same albeit a little fuzzier. Of course on a small screen of say 35cm., the composite fuzz will be less noticeable anyway.
I don't know why anyone would prefer YUV over RGB, as the latter is more like what the CRT expects. It's easy enough to change between the two, assuming you have ideal op-amps:-) I guess it must just be an NTSC vs PAL thing.
A train uses a diesel engine to directly energize the traction motors, meaning that when you want more power to the wheels, you have to open up the throttle on the diesel.
Maybe in America, but in Britain and other parts of Europe where the railways are not fully electrified, the diesel engine runs at a constant RPM and powers an AC generator. The output from this is rectified using a bridge of very big diodes; no battery bank is used; so, although the current is flowing in the same direction all the time, it still pulses on and off as the magnets approach and retreat from the coils. This property is crucial. There is a device called an SCR - Silicon Controlled Rectifier, which is a kind of electronic switching device that starts as an open circuit, but when triggered by a pulse on one terminal, starts conducting and stays so until the current is interrupted by some other means. This last reason is why the current must be pulsed. The control circuit works by providing an adjustable delay between the start of the power pulse from the generator and the pulse to the SCR to connect the motor: the shorter the delay, the more power ends up in the motor. All the while the engine is turning at the same speed {well, it tries to slow down every time the SCRs switch on, but the flywheel and governor prevent this}.
The SCR is used instead of a transistor because it changes state quickly from very high resistance {almost no current, so very low power dissipation} to very low resistance {almost no potential difference, so very low power dissipation} -- either way the power dissipation is minimised. Contrast this with a variable resistance controller {as used on sewing machines, for example} where the series resistance is always dissipating power. A transistor voltage regulator is just a fancy kind of variable series resistance, of course.
The reason trains require the electric stage is because there's no way to make a clutch that will start a 10,000 ton train at the bottom of a hill.
Except a hydraulic one..... It works like this. On the spindle of the engine is a centrifugal pump, which pumps hydraulic fluid through a three way valve {similar to the one used in a central heating system}, which can send the fluid one of two ways: through a turbine which drives the wheels and back to the pump, or just straight back to the pump. The valve can be adjusted to any position between the two extremes, so as to transmit more or less power from the pump to the turbine.
The fan on your processor is a spindleless, inside-out electric motor: the stator, with an electromagnet coil, is in the middle and the armature, with ceramic magnets, is on the outside. There is no commutator: the reversal of the current in the stator coil is done by means of a bridge of four transistors, and timed by one of the magnetic poles passing a sensor. So there is nothing particularly new in putting the armature on the outside of the stator.
Nor is there anything new in the way the control system would work. In Europe, most washing machines are front-loaders. The drum has to be able to revolve at a low speed in both directions for washing, and at a high speed for spin drying. Instead of using a gearbox, the motor's windings are split so they can be connected in various series and parallel combinations. Electronically there is no difference {a motor doing 300 watts of work is using 300 watts of electricity and just looks like a resistance dissipating 300 watts of heat} -- mechanically there may be an improvement {the speed-changer need only be a set of relay contacts, not a solenoid-operated or electro-hydraulic gearbox}.
Many trains in Britain {where not all railways are electrified} use a Diesel engine to spin a generator at constant RPM {everyone knows this is the most efficiengt way to run any sort of engine}, which then drives several small electric motors via an electronic control system which actually depends on the waveform of freshly-generated, as opposed to stored, electricity. I think this was invented by our baguette-munching neighbours at the SNCF {Societe/ Nationale de Cattle Freight by my own experience} but not sure so don't quote me on that.
So, all in all it's not much new. But hey, it's an interesting application anyway..... and being a Diesel engine, it'll run quite happily on cooking fat, so the Dutch won't have to go to war with anybody when the oil wells run dry!
It depends on the escrow contract. Think of a company which would normally use only Open Source software, but tempted to choose a closed source solution subject to an escrow agreement. That company almost certainly would insist on certain terms for release from escrow {quite likely for dispute resolution purposes as well as in event of supplier's inability to fulfil obligation, and possibly in any case after a fixed period of time} and would do well to insist that the binary they receive should be identical to the compilation product of the escrowed source code. One way to be certain would be for the escrow agency to perform the compilation themselves and finally deliver the binary to the customer.
Or, how about this: representatives from the escrow agency and the customer meet with the supplier. The supplier initiates the compilation of the source code, and the binary form is transferred to a read-only medium. The computer used for compilation is shutdown cleanly and the hard disk drive removed. This is placed under lock and key; both supplier and customer receive receipts for it. It is thus known to contain the source code and -- assuming some Bash-like history system -- a record of the commands used to compile it.
Badly-implemented Source Code Escrow, being worse than useless, would actually make a good argument in favour of Open Source -- it would provide all the maximum theoretical protection of source escrow, but no scary potential for failure.
Re:A better way to avoid this problem
on
Source Code Escrow
·
· Score: 1
I agree with you about how Open Source should be law in the end. In the meantime, however, source code escrow is a good half-measure, and provides customers with a modicum of protection against suppliers going bust -- which is itself a serious argument against closed source software {if both the software and the supplier go T.U. then so are you, and it's technically illegal for anybody to sort it out. I think this has happened on at least one occasion before, with customers left high and dry}.
I also think that there should be a requirement that source code in escrow should be allowed to be opened in case of a dispute where, say, the customer suspects a bug in the software and the vendor insists otherwise. The source could be examined by an independent panel of experts to determine the existence or not of a fault.
If Source Code Escrow became standard practice, or if it was demonstrated in real life that the system worked {either through a company being saved from disaster through the use of Source Code Escrow, or a spectacular failure that would have been prevented by Source Code Escrow} then it would be worthwhile petitioning for it to become law. Open Source would be safe either way, of course; if the law said the source code had to be to be accessible in an emergency, Open Source would automatically satisfy this requirement because it would be accessible even outside an emergency.
Of course, all these services would be a great way for third parties to make money - escrow agencies, programming experts and teams of lawyers would all be demanding payment. Some people might find it more cost-effective simply to release their software Open Source in the first place.
Any employee of a Linux-using company is likely to be much better gruntled that a similar employee of an otherwise similar but Windows-using company. After all, if a boss is open-minded and generally non-anal-retentive enough to use Linux, then they probably are more likely to be nice to their staff.
Reat the flaming article, dude. He gave her a PC with Linux -- pre-installed and configured by him -- on it. It worked. Other people gave other people PCs with Windows on them. They didn't work. Windows is not reliable, Linux is. Unless there is a specific piece of software you want to use that only exists for Windows, and you really really can't do without it, there is no excuse to use that sorry excuse for an OS.
The worst part with Linux is still the installation {though Mandrake is probably the easiest for a n00b}, and installing Windows on a new PC is no fun either {it always seems to want the Windows CD and the mobo CD at the same time}. If someone else has already done that, then it's not an issue.
And the fact that Windows is unreliable actually suits Microsoft et al. They get paid for fixing problems. If one day they managed to write the perfect operating system, making the computer electronically incapable of crashing and absolutely immune to unsolicited outside interference, they would be out of a job. Whereas, nobody gets fat on Linux bugs. If you write a piece of free software, you still have to support it -- unless it's already perfect and therefore needs no technical support. Not being paid to fix it in the first place kind of removes the disincentive against fixing it.
You probably think you are "cool" because you rip off copies of software with a street value of hundreds or thousands of pounds. You probably think you're sticking it to the Man. But what you're really doing is no different than those people who do the exact opposite of whatever is fashionable {thereby being influenced by fashion} so they can claim they aren't influenced by fashion and therefore "cooler" than everyone else. But while you're ripping off expensive proprietary software, other people have taken the trouble to write software that does more or less the same things, and give it away for nothing. Just check out what Slackware {to pick a distro at random} gives you on one CD, and see what it would cost you to put together a proprietary equivalent. You may feel big and clever because you've installed thousands of pounds of software and not paid a single penny, but at the end of the day your computer doesn't do anything positive that mine doesn't do, and I still haven't spent any more than you. You haven't stuck anything to the Man. If you pay for proprietary software, the Man's been sticking it to you. Pirating it is just a nil-nil draw.
Had a minor teething problem with their Linux service. The MIME type thing is straightforward enough if you know what a MIME type is. In Konqueror, you also need to enable "run in terminal" to get the download manager to display. I didn't have a working NSCD on my laptop. However, I do have BIND on my firewall box which pulgs into the broadband cable.
Problem I noticed so far: the supplied installer wants to put files in/usr, as opposed to/usr/local. If you're running Slackware, LFS or Gentoo that's not likely to be a problem, but I can see problems creeping in on systems with a militant package management system.
Also, I can't seem to apt-get the missing NSCD package. This may be totally unrelated to the eMusic installation, of course.
Still, it's nice to see someone making a brave effort to support Linux; their hearts are in the right place, and I'll be giving them plenty of feedback. Anyone know if you can get barred for editing cookies;-)
Is it possible that two people working independently of one another could write what amounted to the same header file?
Let's examine what is in a header file. It is a list of the names of the variables, constants and functions used in the main programme source code. The names of these entities are chosen at the whim of the programmer, but good practice teaches that names should be short and meaningful; this is done for the benefit of future developers. Two programmers who learned from similar texts might develop a particular style. Of course, some names might be influenced by specific extant personality traits. If psychometric testing of the two programmers revealed significant differences that might influence choice of variable names, then we might be surer that the two sets of header files are derived from a common ancestor.
Then there is the question of ordering. Convention dictates that the declarations be split into groups by type, and ordered either alphabetically or as they appear in the programme proper. If both programmers have used alphabetical ordering then this is not an issue, but given some automatic latitude by virtue of mathematical equivalency in the order of statements, it would be a greater coincidence for two programmers to code their functions, make use of constants and initialise their variables in the same order.
Of course, if the code in question is trivial, the circumstances are such that names are effectively prescribed {for instance, "port_addr" might well be a popular choice for a variable specifying a port address; and "init_printer()" is a logical choice of a name for a function to initialise a printer}, and/or it acts in certain very specific ways that depend on an exact sequence of instructions {thereby negating the "automatic latitude" proposed above} then there is more likelihood that two programmers would produce identical code when working independently to perform the same function.
The greatest degree of freedom comes in the addition of comments to code. An individual will inevitably develop a particular style in writing comments. Even this might be influenced by mood. Anything beyond the mere explanatory {for instance, "Jeff was here 9T6!"} is as individual as a fingerprint. However, coding convention in certain environments {a corporation keen to project a "professional" image, for instance; or a fluid international collaborative effort} might demand that comments are confined to the minimum necessary to explain the functionality of the code, with correspondingly less scope for personal expression.
In the light of the fact that we are talking about short programmes to accomplish specific simple tasks, in an environment which necessarily minimises an individual's latitude to leave a personal stamp on their code, it becomes more likely that two independent developers could indeed produce identical code. Alternatively, the existence of ancestral code on which Linux could legally have been based would cast reasonable doubt on SCO's assertions that portions of Linux were copied from SCO Unix.
Slashdot Mirror
Watch out there. Have you not heard the news? SCO just discovered that they own The Simpsons. They have already changed their name to SKO and are demanding a $200 payment for every "Komedy K".
I was thinking 2004 would be the year I go for my driving test. Now I know for certain what kind of vehicle I want to get myself when I do! It will have a Diesel engine with a mechanical fuel pump. Not only will it run fine on cookig oil, it will be immune to any attempt to jam it electronically. Since I'll be running it on non-fossil fuels, I'm not too worried about the extra CO2 emissions -- it's just was already there before the sunflowers were grown, after all.
Anyone know if you can get a Diesel engine onto a series I/II Landie? Or were they all petrol?
Yeah, but you can easily change a number plate. Especially if you can find a similar car -- perhaps belonging to a person you know for sure won't have an alibi -- and replicate its number plates. There are regulations to prevent unauthorised manufacture of number plates; these, however, are about as effective as a chocolate fireguard, only somewhat less edible.
What happens is that when criminals are put in prison, they talk about their various crimes and discuss ways they could have been improved. Put a forger and a smuggler in the same cell, and false paperwork will turn up in the conversation sooner or later. Back on the outside, ideas will find their way into practice. So if a carjacker and a cracker get together, then that may well end up happening.
I've often wondered why they put criminals convicted of different crimes in the same prison, rather than away from people convicted of other crimes, precisely to avoid this sort of thing. And for that matter, why do they allow prisoners to smoke? Surely a non-smoking axe murderer is a better citizen than a smoking axe murderer?
Depends if or not you filled the tyres with expanding polyurethane foam {sold -- in a can with a tyre valve connector -- at motor accessory stores, for repairing punctures} before you started. I'm sure there must already be some sort of "honeycomb" tyre already available for extreme situations where you might get a puncture but still need to be able to run for several kilometres.
That is a joke, isn't it?
I thought the idea was to release a film on, say, the eighth of April in the USA and the fourth of August the same year in the rest of the world. Then they could write the release date in figures on the posters, and use just one print run for the whole world.
For broadcasting and storage, I would agree with you -- you can get away with less bandwidth on the colour signals than the picture signal because the human eye has fewer colour sensors than brightness sensors, and the Y component is suitable for feeding direct into a mono CRT. But for digital applications, I would have thought it better to do the YUV-RGB transform entirely in the digital domain {it's just a straightforward matrix multiplication after all}, and output the red, green and blue signals straight from the DAC to the set.
As I pointed out, this is already done in Europe - the SCART connector carries RGB and a separate timing signal which just happens to include picture and colour information.
You can make a man forget all kinds of stuff by showing him a woman in the right state!
It isn't that hard to remove the Macrovision. You're right, it adds out-of-range pulses during the "invisible" parts of the picture signal which throw off the VCR's automatic gain control circuitry {a TV receiver can get away with a much longer time constant on its AGC as there is no need to avoid overloading a tape head}.
..... or at least only the timing matters and there is no AGC .....
A conventional lowpass filter will not work because it will attenuate the high frequencies in the picture, ruining sharp edges. Unless, as the parent points out, the sync signal has only timing information on it
Now, assuming that the VCR's motor has a nice heavy flywheel and the tape speed is thus good and constant, you can work out where the sync pulses should go and substitute a nice, clean, locally-generated version of whatever the sync pulse should have looked like. Early attempts to do this in the analogue domain seem to have been supplanted by microcontrolled circuits, now PICs have broken the 10MHz barrier.
But the whole idea that the movie industry could insist that TV manufacturers use a connection system which is technically inferior to the best merely in order to allow for an easily-defeated copy prevention scheme acknowledged to do more harm than good, frankly beggars belief.
MySQL. Store tasks in a database - make use of datetime and text field types. Perl. Use /etc/passwd for managing the user accounts.
Use a web-based interface with JavaScript and Java applets on the client end and avoid the need for RPC altogether. Any CGI script can generate a bit of JavaScript to bring up a page automatically on a timeout. A quick and dirty bodge would be to popup a window and make it self-minimise; said window runs a bit of a CGI script which responds to trigger events {watches a directory for files changing, for example}, and refreshes itself at intervals so it keeps on checking. When the appropriate event occurs, the window restores itself, displays the appropriate content and comes to the front.
It doesn't really have to be Exchange. All means to the same end are equally valid.
Don't Evolution, Kmail and Konqueror {or Mozilla Firebird and Thunderbird} on the desktop, and Sendmail, Procmail, Qpopper, Apache, MySQL and P(HP|erl|ython) on the server, constitute an effective Exchange/Outlook replacement? The admin side of the job is easy too; once you know exactly what packages are needed on the desktop, you put them on your own local package repository {whoops, better add ProFTPD to the server wish list}. Now compile a package of your own with no files {go on then, maybe some ready-made *rc files}, just dependencies on those packages; then just try to install your metapackage on those machines and let the automatic dependency resolution do the hard work {I'm assuming .deb here, but I'm sure .rpm probably isn't much different if you set it up properly}.
.....
Sure, it sounds like hard work setting it all up, but think about this. Windows clients typically need something doing to them at least once a day, and the time it takes to do that for every machine you have to see to mounts up. Now if you spend a whole day writing a programme to do in five minutes something you could have done by hand in an hour, that sounds like an extravagance - nearly seven hours wasted. But the eighth time you run that programme, it's begun to break even. I'm not suggesting you can write an entire application suite in just one day, but if you're in charge of Windows machines just try adding up your time spent fart-arsing around resetting boxes and so forth
And if I really wanted to dangle the bait, I would say anyone who thinks KDE and Gnome ripped off ideas from Microsoft should remember who ripped those ideas off from Apple.
First cousin = someone who shares one grandparent with you. A parent's sibling's child.
Second cousin = someone who shares one great-grandparent with you. A parent's cousin's child.
Cousins n times removed - your cousin's children are your cousins once removed, their grandchildren are your cousins twice removed, and so on. Or your parent's {intentional singular - ajs} cousins would also be your cousins once removed. {Your cousin's parents aren't your cousins once removed, of course; they're your auntie and uncle.} Firstness and secondness start to get a bit blurred with removals. There are, in theory, such relations as third, fourth and even higher generation cousins; however, it's only now that people are living longer and having children sooner that anybody is likely to have any real-life examples.
If you think that's confusing, think how much uglier it gets when you factor in people who become a member of your family by getting married to someone who is already a member of your family. In some jurisdictions there probably could exist a kind of race condition where one marriage might render another marriage unlawful, depending on the order in which they took place!
So why don't we send a staffed mission to Mars? Something with a human being on board might stand a fighting chance of actually getting there -- if some unusual situation is encountered, it can be dealt with right there and then. It's not as though human beings are in short supply or require any special tools to manufacture. Even if the trip is strictly one-way, it wouldn't be the first time anyone didn't make it home {how many casualties in Iraq?} Beside which, the honour of "first Earthling buried on Mars" would be a great one, even despite its inherent posthumousness.
I say, get thinking the unthinkable. Stop the cowardice and send a staffed mission now. A few human lives would be a small price to pay for the dividend it would bring.
I thought U and V were just other names for the colour-difference components R-Y and B-Y, but I couldn't remember which was red and which was blue, so I cheated and failed to mention it. Like pronouncing "Samhain" as "'kel-tik nyoo 'yee-ah". Anyway, according to my understanding, Y = 0.3 * R + 0.6 * G + 0.1 * B, and the red and blue differences are R-Y and B-Y. So you can easily recreate R and B with two op-amps, R = (R-Y) + Y and B = (B-Y) + Y, but to get G you have to fartarse around ..... G = (Y - 0.3 * R - 0.1 * B) * 1.667. The nasty multiplying factors are to compensate for the human eye's response, which makes green light appear brighter than red and blue light appear dimmer than red for the same actual amount of energy. Using Y = 0.3 * R + 0.6 * G + 0.1 * B means you can feed a mono CRT from just Y and get a sane-looking picture ..... so the fancy circuitry to regenerate the red, green and blue grid drives for a colour CRT goes only into colour sets {remember, colour TV predates the integrated circuit so when I say "an op-amp" remember that must be built up using at least 3 triodes or transistors} and colour signals degrade gracefully on mono sets.
.......... shit! You've got to be kidding, right?
As for the thing about Macrovision
For one thing, it's so easily defeated as not to be a serious threat to anything {it makes it slightly awkward to copy from VHS to VHS, because you need a sync regenerator; they are legally available because some older composite monitors are allergic to Macrovision, and before sync regenerators could be banned, the movie studios would have to pay to replace everyone's incompatible equipment and arrange for it to be recycled in an environmentally-friendly manner. It's cheaper just to let people have Macrovision strippers^W^Wsync regenerators.}
As for connectors, does US kit not have SCART sockets, or is the wiring of a US SCART socket different from a European one? If not SCART, what does your all-in-one connector look like?
Here in Europe {where PAL reigns supreme}, Y/Pr/Pb aka YUV component video is rarely used. Most European TV sets have at least one SCART socket. SCART is a 21-pin connector which can carry RGB or composite video and audio, logic-level switching signals and enough returns to shield everything. Most TVs have the first SCART socket {AV1} fully wired, and the second {AV2} wired for composite only {VCRs don't do RGB}. The neat part is that in RGB mode, the pin that would normally be used for the composite picture signal is used for the timing signal, but of course the timing information is all in the negative-going portions. So an appliance such as a Playstation or DVD player will put out a full composite video signal on the "timing" output and RGB on the main RGB outputs. Remember I said the SCART connector has switching pins; pin 8 selects from the internal off-air receiver or from the SCART socket, and pin 16 selects composite or RGB. If the TV input supports RGB, then it will respond to the logic 1 on pin 16 and use the RGB signal, taking the timing from the composite signal. If the input is composite-only, then it will totally ignore pin 16 and display the composite picture signal, which will be the same albeit a little fuzzier. Of course on a small screen of say 35cm., the composite fuzz will be less noticeable anyway.
:-) I guess it must just be an NTSC vs PAL thing.
I don't know why anyone would prefer YUV over RGB, as the latter is more like what the CRT expects. It's easy enough to change between the two, assuming you have ideal op-amps
The SCR is used instead of a transistor because it changes state quickly from very high resistance {almost no current, so very low power dissipation} to very low resistance {almost no potential difference, so very low power dissipation} -- either way the power dissipation is minimised. Contrast this with a variable resistance controller {as used on sewing machines, for example} where the series resistance is always dissipating power. A transistor voltage regulator is just a fancy kind of variable series resistance, of course. Except a hydraulic one
The fan on your processor is a spindleless, inside-out electric motor: the stator, with an electromagnet coil, is in the middle and the armature, with ceramic magnets, is on the outside. There is no commutator: the reversal of the current in the stator coil is done by means of a bridge of four transistors, and timed by one of the magnetic poles passing a sensor. So there is nothing particularly new in putting the armature on the outside of the stator.
..... and being a Diesel engine, it'll run quite happily on cooking fat, so the Dutch won't have to go to war with anybody when the oil wells run dry!
Nor is there anything new in the way the control system would work. In Europe, most washing machines are front-loaders. The drum has to be able to revolve at a low speed in both directions for washing, and at a high speed for spin drying. Instead of using a gearbox, the motor's windings are split so they can be connected in various series and parallel combinations. Electronically there is no difference {a motor doing 300 watts of work is using 300 watts of electricity and just looks like a resistance dissipating 300 watts of heat} -- mechanically there may be an improvement {the speed-changer need only be a set of relay contacts, not a solenoid-operated or electro-hydraulic gearbox}.
Many trains in Britain {where not all railways are electrified} use a Diesel engine to spin a generator at constant RPM {everyone knows this is the most efficiengt way to run any sort of engine}, which then drives several small electric motors via an electronic control system which actually depends on the waveform of freshly-generated, as opposed to stored, electricity. I think this was invented by our baguette-munching neighbours at the SNCF {Societe/ Nationale de Cattle Freight by my own experience} but not sure so don't quote me on that.
So, all in all it's not much new. But hey, it's an interesting application anyway
It depends on the escrow contract. Think of a company which would normally use only Open Source software, but tempted to choose a closed source solution subject to an escrow agreement. That company almost certainly would insist on certain terms for release from escrow {quite likely for dispute resolution purposes as well as in event of supplier's inability to fulfil obligation, and possibly in any case after a fixed period of time} and would do well to insist that the binary they receive should be identical to the compilation product of the escrowed source code. One way to be certain would be for the escrow agency to perform the compilation themselves and finally deliver the binary to the customer.
Or, how about this: representatives from the escrow agency and the customer meet with the supplier. The supplier initiates the compilation of the source code, and the binary form is transferred to a read-only medium. The computer used for compilation is shutdown cleanly and the hard disk drive removed. This is placed under lock and key; both supplier and customer receive receipts for it. It is thus known to contain the source code and -- assuming some Bash-like history system -- a record of the commands used to compile it.
Badly-implemented Source Code Escrow, being worse than useless, would actually make a good argument in favour of Open Source -- it would provide all the maximum theoretical protection of source escrow, but no scary potential for failure.
I agree with you about how Open Source should be law in the end. In the meantime, however, source code escrow is a good half-measure, and provides customers with a modicum of protection against suppliers going bust -- which is itself a serious argument against closed source software {if both the software and the supplier go T.U. then so are you, and it's technically illegal for anybody to sort it out. I think this has happened on at least one occasion before, with customers left high and dry}.
I also think that there should be a requirement that source code in escrow should be allowed to be opened in case of a dispute where, say, the customer suspects a bug in the software and the vendor insists otherwise. The source could be examined by an independent panel of experts to determine the existence or not of a fault.
If Source Code Escrow became standard practice, or if it was demonstrated in real life that the system worked {either through a company being saved from disaster through the use of Source Code Escrow, or a spectacular failure that would have been prevented by Source Code Escrow} then it would be worthwhile petitioning for it to become law. Open Source would be safe either way, of course; if the law said the source code had to be to be accessible in an emergency, Open Source would automatically satisfy this requirement because it would be accessible even outside an emergency.
Of course, all these services would be a great way for third parties to make money - escrow agencies, programming experts and teams of lawyers would all be demanding payment. Some people might find it more cost-effective simply to release their software Open Source in the first place.
Any employee of a Linux-using company is likely to be much better gruntled that a similar employee of an otherwise similar but Windows-using company. After all, if a boss is open-minded and generally non-anal-retentive enough to use Linux, then they probably are more likely to be nice to their staff.
Reat the flaming article, dude. He gave her a PC with Linux -- pre-installed and configured by him -- on it. It worked. Other people gave other people PCs with Windows on them. They didn't work. Windows is not reliable, Linux is. Unless there is a specific piece of software you want to use that only exists for Windows, and you really really can't do without it, there is no excuse to use that sorry excuse for an OS.
The worst part with Linux is still the installation {though Mandrake is probably the easiest for a n00b}, and installing Windows on a new PC is no fun either {it always seems to want the Windows CD and the mobo CD at the same time}. If someone else has already done that, then it's not an issue.
And the fact that Windows is unreliable actually suits Microsoft et al. They get paid for fixing problems. If one day they managed to write the perfect operating system, making the computer electronically incapable of crashing and absolutely immune to unsolicited outside interference, they would be out of a job. Whereas, nobody gets fat on Linux bugs. If you write a piece of free software, you still have to support it -- unless it's already perfect and therefore needs no technical support. Not being paid to fix it in the first place kind of removes the disincentive against fixing it.
You probably think you are "cool" because you rip off copies of software with a street value of hundreds or thousands of pounds. You probably think you're sticking it to the Man. But what you're really doing is no different than those people who do the exact opposite of whatever is fashionable {thereby being influenced by fashion} so they can claim they aren't influenced by fashion and therefore "cooler" than everyone else. But while you're ripping off expensive proprietary software, other people have taken the trouble to write software that does more or less the same things, and give it away for nothing. Just check out what Slackware {to pick a distro at random} gives you on one CD, and see what it would cost you to put together a proprietary equivalent. You may feel big and clever because you've installed thousands of pounds of software and not paid a single penny, but at the end of the day your computer doesn't do anything positive that mine doesn't do, and I still haven't spent any more than you. You haven't stuck anything to the Man. If you pay for proprietary software, the Man's been sticking it to you. Pirating it is just a nil-nil draw.
Had a minor teething problem with their Linux service. The MIME type thing is straightforward enough if you know what a MIME type is. In Konqueror, you also need to enable "run in terminal" to get the download manager to display. I didn't have a working NSCD on my laptop. However, I do have BIND on my firewall box which pulgs into the broadband cable.
/usr, as opposed to /usr/local. If you're running Slackware, LFS or Gentoo that's not likely to be a problem, but I can see problems creeping in on systems with a militant package management system.
;-)
Problem I noticed so far: the supplied installer wants to put files in
Also, I can't seem to apt-get the missing NSCD package. This may be totally unrelated to the eMusic installation, of course.
Still, it's nice to see someone making a brave effort to support Linux; their hearts are in the right place, and I'll be giving them plenty of feedback. Anyone know if you can get barred for editing cookies
Is it possible that two people working independently of one another could write what amounted to the same header file?
Let's examine what is in a header file. It is a list of the names of the variables, constants and functions used in the main programme source code. The names of these entities are chosen at the whim of the programmer, but good practice teaches that names should be short and meaningful; this is done for the benefit of future developers. Two programmers who learned from similar texts might develop a particular style. Of course, some names might be influenced by specific extant personality traits. If psychometric testing of the two programmers revealed significant differences that might influence choice of variable names, then we might be surer that the two sets of header files are derived from a common ancestor.
Then there is the question of ordering. Convention dictates that the declarations be split into groups by type, and ordered either alphabetically or as they appear in the programme proper. If both programmers have used alphabetical ordering then this is not an issue, but given some automatic latitude by virtue of mathematical equivalency in the order of statements, it would be a greater coincidence for two programmers to code their functions, make use of constants and initialise their variables in the same order.
Of course, if the code in question is trivial, the circumstances are such that names are effectively prescribed {for instance, "port_addr" might well be a popular choice for a variable specifying a port address; and "init_printer()" is a logical choice of a name for a function to initialise a printer}, and/or it acts in certain very specific ways that depend on an exact sequence of instructions {thereby negating the "automatic latitude" proposed above} then there is more likelihood that two programmers would produce identical code when working independently to perform the same function.
The greatest degree of freedom comes in the addition of comments to code. An individual will inevitably develop a particular style in writing comments. Even this might be influenced by mood. Anything beyond the mere explanatory {for instance, "Jeff was here 9T6!"} is as individual as a fingerprint. However, coding convention in certain environments {a corporation keen to project a "professional" image, for instance; or a fluid international collaborative effort} might demand that comments are confined to the minimum necessary to explain the functionality of the code, with correspondingly less scope for personal expression.
In the light of the fact that we are talking about short programmes to accomplish specific simple tasks, in an environment which necessarily minimises an individual's latitude to leave a personal stamp on their code, it becomes more likely that two independent developers could indeed produce identical code. Alternatively, the existence of ancestral code on which Linux could legally have been based would cast reasonable doubt on SCO's assertions that portions of Linux were copied from SCO Unix.
tnx