It comes from two sources. Firstly, standard practice in the console biz is to start selling the thing at a loss, with the expectation that you can optimise the production pipeline, so that you can make a profit on the boxes sold later. That's actually quite a specific price bracket, and is chosen to reduce the cost of entry, maximising profit from the system in totality (including game royalties). In effect, the hardware is being subsdised from the game royalties. Note that Sony started like that for both the PS1 and PS2, and now makes a small profit (I think it's around £20 a box) on the PS2.
Second piece: The original market price of the Xbox, claims that they were not going to drop the price, and then the round of price cuts. That's circumstansial, but if they were not selling the boxes at a loss [0] after those steep cuts, I'll be very surprised.
Interesting economics point: How many games does the average console owner have, per console? I'll take a stab at 4. Therefore, the correct thing to look at, from a business point of view, is not the profit per console - but the profit from console + 5 games. Me, I'd price the box so that the initial loss on the hardware is around the profit on 4 games [1]. Keep the initial cost's low, more adoption, and leach the money out of the customer base over time.
Now, that's all well and good, but none of that says how much profit is made on each box right now , only what they would have done at launch (loss), and near the end of the xbox lifetime (profit).
I'm going to accept that after the price dropped to 200, they were making a loss per box. They seemed quite forced into it, mainly by Sony, who had probably already improved the manufacture of PS2's, so they were not worried by the price cut.
Do they make a loss now?
Let me evade that for a moment, and discuss the development costs of the console. Aught they to be included in the 'cost' per unit sold? From a strictly business point of view - yes. You need to make back that money, before any profit is generated. From the 'does the manufacturer lose money on this sale' point of view - no. You can make the dev costs back from other sales. This complicates the whole question.
Note that this is based on economic arguemnts, and this sort of anaylsis will applie to any sales model that has a buy in cost that is greater than the per unit cost (printers, razor blades etc).
Let me link to a few facts: BBC: Microst loose $177 million. Note that that's from September last year, and is for 3 months preceding, off revenue of $1.28 billion
Q4 2002 (CNET) made a $348 million loss for the division.
And it's too early for Q2 2003 data (rember that we need by divisional break downs, not overall profits for this).
So, they're definitly making a loss somewhere in their buisness, within the division that handles the Xbox. Is that on the xbox itself, or something else? [2]
No one can answear that. Apparently Mircosoft have confirmend that they make a loss on the hardware.
I'll take a different take to the linked article. The initial launch price was $300. Assume microsoft get $7 per game (average of the 5-10 range), and that would put the manufacturing costs at $330, or so; consistant with the analysts estimates in the above link.
They were forced to drop the price to $200 before they wanted to - I think that's clear. So suddently they were makeing over $100 loss per system. How much had they managed to reduce costs by? The above link trys to assert that they drop in lines with Moores law - that's crap [3]. My guess is that the cost is sliding down into the $220 to 250 range, based off the fact the M
cdrecord supports two different methods of working with ATAPI burners. dev=ATAPI uses a packet writing interface in the cdrom suport (in 2.4.X). However, the program actually uses the sg device (SCSI generic), so yes, it's still thinking it's talking to a SCSI device at some level. However, this is prety damn efficent - there's no full blown SCSI layer in the way. Given that ATAPI is basically SCSI over IDE (hence all the SCSI crap in the first place), this is more or less fine, with one exception.
If you're using the 2.5 new interface, then maybe (don't really know, not played around with it). However, it does support DMA, which is rather tricky to get working over the other methods (too many layers in the way, or solething like that).
Um, rip open your favourite cd burning package. Poke around it till you find the ASPI dll's. Nero includes it's own ASPI managers - others might use Windows own ones, so you might have to break a debugger or similar (hurtin' for ldd there) over them to spot it.
ASPI is a SCSI interface standard. It stands for SCSI Programing Interface - it's designed so that ASPI complient hardware can all use a single driver, for a specific type of device. If it's using the ASPI code, then it's working a SCSI device - at least in emulation.
A couple of links, to back up that cd burners use ASPI in windows: http://aspi.radified.com/ http://www.nc f.carleton.ca/~aa571/aspi.htm
There is only really module-init-tools, rather than modutils.
The main reason for this change is that there is now a kernel level module loader. This is for various changes, so that drivers will be handled in exactly the same manner whether they are loaded as a module, or included in the main kernel image. This makes a number of problems in driver writing, and a bunch of idiosyncrities just go away. For example, you should be able to load multiple copies of a driver, compiled into the main kernel. Previously, you had to use them as modules to work that trick. This is important in situations like three identical soundcards.
I believe that is the only required (significant and normally needed) chage to userland tools. Other tools will benefit from updating, to support new features, but that's always the case, and not required. Note that the kernel aught to boot without it - just be less useful if you use modules.
It's worth noting that the sound infrasturcture changed from OSS, to primerly ALSA. OSS is still in, but marked DEPRECATED, so at some point over 2.6, you aught to expect to shift to ALSA sound. It aught to be painless - ALSA supports OSS emulation, so you can phase apps through that. I can't think of any other userland level changes for 2.5 (at least, that impact on your average commodity PC desktop / server - If your're using LVM / md stuff, I think that there might be a shift in there).
One fun change is that you shouldn't need to use ide-scsi emulation to drive CD burners anymore (though that'll require updating userland tools). That's a really useful one, particulary for newcomers [0].
[0] Windows actually also does the 'pretend it's a SCSI device' trick too - but hides it a lot better.
Well, that's already covered by the current policies.
As it stands, (and this is pre attack on two towers) the door is ment to be locked. If anyone is held hostage, they are expendable until, and unless, the plane is safely landed.
That stands.
However, note that the pilots are in communication with air traffic control. The ability to communicate is powerful, but it also works to help the pilots. Put them on to an anti-terrorist specialist (as is, and has been, in the procedure for several years), and book an appointment with a counseller for the pilots.
The point of the 'no door' is to refuse the pilots options that will cause more harm. It's harsh, but you're dealing with people who are prepared to kill.
That's covered. It's a 'soft' wall - as you get ner to the wall, it generates a small opposition to the pilots actions, and that opposition increases as they get closer.
So, with a mid air collision scenario, unless both planes are right on the limit of the wall, then the pilots can steer fine. One direction will be slightly less preffered by the autopilot, but that should not be significant, at the outside of the area.
Note also: That aircraft should not be near the wall off area's anyway, so the situation aught not to arise. It's totally software controlled, so interfacing with teh current mid air collision systems [0] and breaking the wall in that case would be perfeclty feasable.
I think that's one of the lesser problems with the idea.
Personally, I'm with the 'bulkhead without a door school of thought (The pilots have a seperate external door. That makes it impossible to physically coerce pilots, because you can't get to them. Problem solved.
[0] As it stands, the computers in two aircraft nearing collision have a chat, and decide on the two optimal vectors, and then move the planes along those vectors automatically, after ensureing that they will not collide.
It will only adversly affect vision when consumed. Getting methanol on your hands has an unpleasent smell and leaves the skin feeling really yucky [0]. If you leave it there for prolonged times, then it can cross the skin, but I'm not convinced that's a significant danger in a consumer product (given that people will tend to go an wash it off should it get spilt).
Methanol/Ethanol solutions are available from my high street - it's not that dangerous.
In fact, I'd rate it about as dangrous as boiling water, or there abouts. Even if consumed, there is an appreciable quantity before the effects kick in [1]. So, yes, drinking the contents of a methanol cartidge will be really unpleasnt, and probably have perment nasty effects. Just like drinking the contents of your typical battery, in fact. [2]
[0] I was a lab chemist, that's from experience.
[1] The real problem is vodka that's contaniated with methanol. It's cheap, and the sort of people who tend to buy that drink enough to get retinal damage. It's not skin contact.
[2] Ok, yes, it would be easier to crack open a methanol cartridge and drink that. It's all about levels of risk.
The point with this is that currently you cannot buy one. This is (one of?) the first methanol fuel cells laptops. Give it a year (frankly, year an a half given typical engineering development time estimates), then, and only then, will you have a choice.
Now, all that aside, I'd rather have the fuel cell system. Let's assume that they weigh the same, and run for a similar time on one charge, like you suggest. With a methanol fuel cell, a replacement charge will weight, what, 100g, cost around a dollar or two, and be field recharageable. This means that I can carry enough fuel to last a day of use without falling over. To do that same trick with batteries, you'd have to carry 5 spare batteries, each costing, what, 50-75 dollars [0], and weigh the thick end of a kilogram each. Not only that, but spare batteries have an interenal discharge rate, meaning that they cannot be stored indefinitly (It's about a month for NiCd, less for NiMh, dunno about Li technologies).
Granted, if you break a methanol cartridge, then it's not pleasant stuff. Mind you, nethers the contents of your typical battery.
The trade off is then you can carry much more fuel, but you'll need to find a specialist to get more, vs the limited fuel and easy refilling for battery technologies.
Once the runtime of a single cartridge of methanol gets up, to me that's a no brainer. YMMV
[0] Off top of head, no actual idea how accurate that is - it's based of raw cells.
Sorry, I'm afraid that there is no exception clause. The lameness filter doesn't like in the diff output, so I've removed it. Each line of the diff output started with
NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the heading of "derived work".
Also note that the GPL below is copyrighted by the Free Software
Foundation, but the instance of code that it refers to (the Linux
kernel) is copyrighted by me and others who actually wrote it.
Also note that the only valid version of the GPL as far as the kernel
is concerned is _this_ particular version of the license (ie v2, not
v2.2 or v3.x or whatever), unless explicitly otherwise stated.
Linus Torvalds
[Line of hypthens the lameness filter doesn't like]
[End diff output]
The only difference between the liscence on Linux and the GPL is noted there, and it does not mention binary drivers.
So, either it's a breach of the Linux lisence to use them (because there is no exception clause), or no clause is required to use them legally.
Also, note that these actions by SCO do not involve distribution. They claim that they found some of thier IP [0] was illegally placed in Linux. They have then seperatly given a group of people a non-transferrable liscence to use that IP. I cannot see how that caused GPL to apply.
As I mentioned above, the fact that they distributed Linux puts them in a sticky situation. Note that it doesn't mean that they accepted the GPL - it means either they accepted the GPL, or were in breach of a software liscence.
From the header: If they approve the use of 'their' IP in Linux in a single kernel, then the GPL holds that IP SCO allows to be used by a select few must be freely released to any and all. It appears that all Linux users everywhere were just given a license to continued use of Linux even if SCO would win their suit with IBM.
No, emphatically not.
GPL applies to copyright'ed materials only. If SCO have other form of IP protection (such as patent, or, as they in fact claim, trade secret) the the GPL does not even interact with it. And see below.
Further, it is possible for SCO to liscence their copyrighted code such that all thier customers may use it. That does not make it GPL'd.
The GPL only applies upon redistribution - it is quite valid for me to link in code written under any sort of liscence to the Linux kernel. However, I may not freely redistribute it unless I can meet all the restrictions on it. From the GPl, section 7:
If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all.
Granted, it is talking principly in terms of patent liscencing, but that's inconsequential.
As a case in point, conside the NVIDIA binary drivers. If you have an NVIDIA card, you have a liscence to use that copyrighted code. You do not have a liscence to re-distribute NVIDIA's code. Yet you may link the two systems together, just fine, provided you don't try to redistribute the combined work.
Now, SCO redistributing binaries from their ftp site, _after_ they make claims about thier code being in Linux is a whole different kettle of fish. That's a different issue however.
This patent has moved from the period where it was a novel, and powerful innovation, into textbook area. Part of the problem with software patents is that this take a year or so, compared with the 18 years patent life.
With chemistry, your looking at 15-20 years. That's one of the reasons why there is so much chemistry research - the patent lifespan is just right in that field.
The delaying of the patent for so long has crippled the use of this technique. This was not by bad buerocracy, but by deliberate intent. It is this deliberate intent to delay the onset of the patent that I object to - as this technique, novel and non-obvious in the 1960's, is commonplace now. The patent would have been, on balance, a good one in its time.
The loophole was plugged - to prevent more of this in the furture. The detritus from it's existance needs to be delt with.
Oh, and the patent does not apply to laser printers. It's quite specific about collimated beams of energy, and streams of matter to undergo chemical raction. Laser printers do not have a stream of matter, as defined in the patent. There is a reaction, which might be defined as chemical, on the photosensitive drum. However, I'm quite sure [0] the the motion of the drum will not qualify as a stream of matter.
[0] I'm not a patent lawyer. This is not legal advise. For legal advise, consult a professional liscened in your juristriction.
Ok, firstly, please read the patent. It is not as trivial as it may appear from the few lines description.
It doesn't strike me as earth shatteringly novel, but then, most patents never have. It's written in usual obfuscated patent speak, which doesn't help.
The workaround: It is quite specific about collimated beams of radiation. So stick a lens in the way, de-collimate your beam, and the patent no longer applies.
If you are putting the laser through a window, then a couple of lenses, to de-focus the beam, and then focus it in the reaction zone will do the trick.
I'm not sure how this related to chip fabriacation, but I'm going to hazard a guess that it's in a CVD style deposition stage. The only time that precise focus would be needed is if your etching by laser onto a surface. In which case, you don't have a flow of matter.
This will not work if you are reflecting a collimated beam around so that it crosses the reaction zone multiple times.
Any fabiration engineers want to elucidate on where this patent might apply? Specifically, would a lens (I'm thinking of a power of around -1 uD) stop the system from working?
However, working around the patent may be considered a tacit admission of it's validity, and thus is a tatic in opposition to the legal challenge.
Unfortunatly, the H-bomb is not a chemical reaction, but rather a nuclear reaction. Thus, the patent does not apply.
Secondly, if your looking for prior art, best start by reading the patent. It's quite specific about streams of matter, and intersecting those streams with radient energy. Thus, the H-bomb, even were it chemical, would be well off.
You need to find stream of matter, and energy, inside a reaction vessel.
I agree that some songs on the album are better than others [0]. However, I was replying to wether theme albums still exist, not wether every track on them was great. Even with my least favourite tracks, there presence on the album carries meaning, and I do not resent even it's inclusion (unlike tracks of a similar interest to me, on a non-themed album)
I would agree it's all about a negotiated contract. If the artist doesn't want to sell each track individually, that's fine by me. Like you said, if they don't sell, that's thier problem, not mine.
I would argue, however, that it would be rather rich to release a single, but not to allow that track to be sold separatly online.
[0] Was worth the cost for 'Travelin' solider' and 'Long time gone' alone though.
Software patents are bad. See RTLinux for an example.
Copyright is good. Note that we are dying to find out what code SCO claims was missaproriated, so that it can be removed, ending an unintentional copyright violation.
IP is not a homogeneus entity. To consider it as such is to miss a very important point.
Patents say that because I thought of it before you, you cannot use the idea without paying me.
Copyright says that if you want to use this idea, either pay me for the right, or go away and do it yourself.
The latter encourages competition. The former anhiliates it.
Try a different player. That will identify and eliminate that aspect of the problem.
I'd reccomend Ogle - it's just a DVD player, and thus has the advantage of specialisation on it's side. Other than that, the other two media players are mplayer and xine. Xine is in debian, so that's probably the best bet. Mplayer is available from an alternate source (deb http://marillat.free.fr/ stable main), but I've had difficulty with audio decoding. Still, it'll help with problem identification.
Are you sure that it actually crashed the kernel? Or was it just X windows and input? I've had a couple of times that the only way I can unfreeze the system is to ssh in from another box, and do some kill -9 ing. Might be worht trying, if you can.
See if you can get a DVD-ROM from somewhere. Various magazines occasionally carry a DVD with programs on the front cover, so see if you can read one of those. Note that you may need UDF filesystem in the kernel (it's a loadable module if your using stock debian kernels).
Try instructing your player not to process the audio, and not to process the video. You may find that the problem is in the audio libraries, rather than video.
Quick aside: A bloated kernel will not slow the system down to any significant degree. The only reason to compile your own with a distro is to reduce the memory requirements, or for a different version of the kernel (new drivers, or experimetal / alternate patches). There is a slight slowdown at startup, but the fast path is not corrupted by additional options (Usually. There's a couple of minor exceptions, but they barely have any effect).
Beyond all that, I can't really help. But do try to narrow the problem down. You might also look from newer drive firmware - it sounds to me like the CSS firmware in the drive got a bit mangled, so a firmware update (even to the same version as it currently has) may help. May not, however - leave that as a last resort.
Every song on the album revolves around the themes of friendship, belong and community, in some fashion. Granted, some are tied more strongly than others, and there's probably room for debate, but that's my opinion.
Surprised me too, but there you are.
Youy really want to talk about new albums by the way, rather than recently listened to ones, otherwise I can my Frank Sinatra and Alic Cooper collection's into the ring, along with a few others. I'll exclude all the opera cd's too.
Radiohead do tend to make albums that have a theme, so I'm not to concered by they talking like that. I'll leave noticable abscences there.
Lets separate what real nanotech offers from what nanotech does in SF stories.
Firstly, look at some of the stories set now, written 50 years ago. How many of them have an even part way accurate description of, well, anything?
So, when your talking about nanotech, what are you actually thinking of?
What I'm thinking of is something that will be a bit like a cross between mechanical engineering and chemistry - make the various mechanical parts small so that they tend to operate in a chemicaly relevent length scale. That's the sort of thing that these micro-engines are.
Think about biology for a moment, and about the sorts of biochemical reactions that go on in a living being. Those are the sort of things that nanotach can do. I do not believe that we will see a "Universal constructor" type device for many centuries, if ever.
Note that the two examples that you give have been solved without the use of nano tech. Superconducting powerlines are in use in europe. They are unfortunatly only cost effective for short range (around 100 miles or so) high power transfers - but that's improving. The problem with fusion is not materials. You cannot get a material that will contain a fusion reaction - instead they use magnetic containment. And the problem is keeping the thing stable. I cannot see how nanotech devices would assist in this.
So, in sumary, you are thinking of the effects of something, but I've no idea what.
It's just very carefully selected semantical dodges.
It is talking about how much energy is contained inside these systems. (I'm assuming there's talking either per unit volume, or per unit mass. Other wise, well, it's totally meaningless).
That's a different number from how much energy you cet get out of the systems. In fact, my gut instinct is that they are comparing the energy you can get out of a battery to the total energy available from the fuel with the micro-engine. That's a false comparison either way, as the micro engine will not be 100 % efficent.
(Been over this kind of linguistic dodge many time with battery vs fuel cell arguments. It's very similar)
Ok, don't use it myself (OSx doesn't run on any of my boxen). But I've never had a problem with Mplayer. Ocassional teething problems in compilation, but if your on Mac hardware, those nice people behind Fink have taken care of all that.
If there's something you don't like about mplayer, you could look at xine. Might be more to your tastes.
It is an MPEG codec. DivX is an implementation of MPEG-4. If you want source code for a decoder see the ffmpeg (as libavcodec) or xvid codecs. Between then, I've not see an OS with a POSIX layer that's not been able to compile a decoder engine. Granted, there are large bunches of optional parts that the various decoders don't all cover, but I've not yet see any problems with ffmpeg decoder.
If by MPEGS you mean MPEG-1, then yes - that is slightly more portable than MPEG-4 codecs, but not noticably (better support on embeded systems). They do however, have poorer picture quality, and larger bitrates. So, it's not really a good choice for internet distribution. MPEG-2 would also be better than MPEG-1, but it's also not quite as good as MPEG-4, interms of low bitrate quality. And for a web demo, the lower the bitrate, the better.
If you've got a particular platform in mind, then drop a line, and I'll see if I can find a pre-compiled setup for it.
SCO has legitimate reasons for keeping the alleged infringed code under wraps until a court of law can determine whether or not infringement actually occured.
Can you enumerate them, because I can't see any.
(Aside: Award of damages depends on the claiment taking action to minisime harm (for example, a cease and desist notice). SCO have refused to allow the accused the opertunity to minimuse the harm.
Discliamer: I'm not liscenced to practice law in your juristriction. This is not legal advice. For legal advice, see a lawyer in your juristriction.)
Slashdot Mirror
It comes from two sources. Firstly, standard practice in the console biz is to start selling the thing at a loss, with the expectation that you can optimise the production pipeline, so that you can make a profit on the boxes sold later. That's actually quite a specific price bracket, and is chosen to reduce the cost of entry, maximising profit from the system in totality (including game royalties). In effect, the hardware is being subsdised from the game royalties. Note that Sony started like that for both the PS1 and PS2, and now makes a small profit (I think it's around £20 a box) on the PS2.
Second piece: The original market price of the Xbox, claims that they were not going to drop the price, and then the round of price cuts. That's circumstansial, but if they were not selling the boxes at a loss [0] after those steep cuts, I'll be very surprised.
Interesting economics point: How many games does the average console owner have, per console? I'll take a stab at 4. Therefore, the correct thing to look at, from a business point of view, is not the profit per console - but the profit from console + 5 games. Me, I'd price the box so that the initial loss on the hardware is around the profit on 4 games [1]. Keep the initial cost's low, more adoption, and leach the money out of the customer base over time.
Now, that's all well and good, but none of that says how much profit is made on each box right now , only what they would have done at launch (loss), and near the end of the xbox lifetime (profit).
I'm going to accept that after the price dropped to 200, they were making a loss per box. They seemed quite forced into it, mainly by Sony, who had probably already improved the manufacture of PS2's, so they were not worried by the price cut.
Do they make a loss now?
Let me evade that for a moment, and discuss the development costs of the console. Aught they to be included in the 'cost' per unit sold? From a strictly business point of view - yes. You need to make back that money, before any profit is generated. From the 'does the manufacturer lose money on this sale' point of view - no. You can make the dev costs back from other sales. This complicates the whole question.
Note that this is based on economic arguemnts, and this sort of anaylsis will applie to any sales model that has a buy in cost that is greater than the per unit cost (printers, razor blades etc).
Let me link to a few facts: BBC: Microst loose $177 million. Note that that's from September last year, and is for 3 months preceding, off revenue of $1.28 billion
Q4 2002 (CNET) made a $348 million loss for the division.
Next quarter (Q1 2003) at CNET, and it's $190 million loss.
And it's too early for Q2 2003 data (rember that we need by divisional break downs, not overall profits for this).
So, they're definitly making a loss somewhere in their buisness, within the division that handles the Xbox. Is that on the xbox itself, or something else? [2]
No one can answear that. Apparently Mircosoft have confirmend that they make a loss on the hardware.
I'll take a different take to the linked article. The initial launch price was $300. Assume microsoft get $7 per game (average of the 5-10 range), and that would put the manufacturing costs at $330, or so; consistant with the analysts estimates in the above link.
They were forced to drop the price to $200 before they wanted to - I think that's clear. So suddently they were makeing over $100 loss per system. How much had they managed to reduce costs by? The above link trys to assert that they drop in lines with Moores law - that's crap [3]. My guess is that the cost is sliding down into the $220 to 250 range, based off the fact the M
Um, sorta maybe.
cdrecord supports two different methods of working with ATAPI burners. dev=ATAPI uses a packet writing interface in the cdrom suport (in 2.4.X). However, the program actually uses the sg device (SCSI generic), so yes, it's still thinking it's talking to a SCSI device at some level. However, this is prety damn efficent - there's no full blown SCSI layer in the way. Given that ATAPI is basically SCSI over IDE (hence all the SCSI crap in the first place), this is more or less fine, with one exception.
If you're using the 2.5 new interface, then maybe (don't really know, not played around with it). However, it does support DMA, which is rather tricky to get working over the other methods (too many layers in the way, or solething like that).
Um, rip open your favourite cd burning package. Poke around it till you find the ASPI dll's. Nero includes it's own ASPI managers - others might use Windows own ones, so you might have to break a debugger or similar (hurtin' for ldd there) over them to spot it.
c f.carleton.ca/~aa571/aspi.htm
ASPI is a SCSI interface standard. It stands for SCSI Programing Interface - it's designed so that ASPI complient hardware can all use a single driver, for a specific type of device. If it's using the ASPI code, then it's working a SCSI device - at least in emulation.
A couple of links, to back up that cd burners use ASPI in windows:
http://aspi.radified.com/
http://www.n
There is only really module-init-tools, rather than modutils.
The main reason for this change is that there is now a kernel level module loader. This is for various changes, so that drivers will be handled in exactly the same manner whether they are loaded as a module, or included in the main kernel image. This makes a number of problems in driver writing, and a bunch of idiosyncrities just go away. For example, you should be able to load multiple copies of a driver, compiled into the main kernel. Previously, you had to use them as modules to work that trick. This is important in situations like three identical soundcards.
I believe that is the only required (significant and normally needed) chage to userland tools. Other tools will benefit from updating, to support new features, but that's always the case, and not required. Note that the kernel aught to boot without it - just be less useful if you use modules.
It's worth noting that the sound infrasturcture changed from OSS, to primerly ALSA. OSS is still in, but marked DEPRECATED, so at some point over 2.6, you aught to expect to shift to ALSA sound. It aught to be painless - ALSA supports OSS emulation, so you can phase apps through that. I can't think of any other userland level changes for 2.5 (at least, that impact on your average commodity PC desktop / server - If your're using LVM / md stuff, I think that there might be a shift in there).
One fun change is that you shouldn't need to use ide-scsi emulation to drive CD burners anymore (though that'll require updating userland tools). That's a really useful one, particulary for newcomers [0].
[0] Windows actually also does the 'pretend it's a SCSI device' trick too - but hides it a lot better.
Well, that's already covered by the current policies.
As it stands, (and this is pre attack on two towers) the door is ment to be locked. If anyone is held hostage, they are expendable until, and unless, the plane is safely landed.
That stands.
However, note that the pilots are in communication with air traffic control. The ability to communicate is powerful, but it also works to help the pilots. Put them on to an anti-terrorist specialist (as is, and has been, in the procedure for several years), and book an appointment with a counseller for the pilots.
The point of the 'no door' is to refuse the pilots options that will cause more harm. It's harsh, but you're dealing with people who are prepared to kill.
That's covered. It's a 'soft' wall - as you get ner to the wall, it generates a small opposition to the pilots actions, and that opposition increases as they get closer.
So, with a mid air collision scenario, unless both planes are right on the limit of the wall, then the pilots can steer fine. One direction will be slightly less preffered by the autopilot, but that should not be significant, at the outside of the area.
Note also: That aircraft should not be near the wall off area's anyway, so the situation aught not to arise. It's totally software controlled, so interfacing with teh current mid air collision systems [0] and breaking the wall in that case would be perfeclty feasable.
I think that's one of the lesser problems with the idea.
Personally, I'm with the 'bulkhead without a door school of thought (The pilots have a seperate external door. That makes it impossible to physically coerce pilots, because you can't get to them. Problem solved.
[0] As it stands, the computers in two aircraft nearing collision have a chat, and decide on the two optimal vectors, and then move the planes along those vectors automatically, after ensureing that they will not collide.
Not quite.
It will only adversly affect vision when consumed. Getting methanol on your hands has an unpleasent smell and leaves the skin feeling really yucky [0]. If you leave it there for prolonged times, then it can cross the skin, but I'm not convinced that's a significant danger in a consumer product (given that people will tend to go an wash it off should it get spilt).
Methanol/Ethanol solutions are available from my high street - it's not that dangerous.
In fact, I'd rate it about as dangrous as boiling water, or there abouts. Even if consumed, there is an appreciable quantity before the effects kick in [1]. So, yes, drinking the contents of a methanol cartidge will be really unpleasnt, and probably have perment nasty effects. Just like drinking the contents of your typical battery, in fact. [2]
[0] I was a lab chemist, that's from experience.
[1] The real problem is vodka that's contaniated with methanol. It's cheap, and the sort of people who tend to buy that drink enough to get retinal damage. It's not skin contact.
[2] Ok, yes, it would be easier to crack open a methanol cartridge and drink that. It's all about levels of risk.
The point with this is that currently you cannot buy one. This is (one of?) the first methanol fuel cells laptops. Give it a year (frankly, year an a half given typical engineering development time estimates), then, and only then, will you have a choice.
Now, all that aside, I'd rather have the fuel cell system. Let's assume that they weigh the same, and run for a similar time on one charge, like you suggest. With a methanol fuel cell, a replacement charge will weight, what, 100g, cost around a dollar or two, and be field recharageable. This means that I can carry enough fuel to last a day of use without falling over. To do that same trick with batteries, you'd have to carry 5 spare batteries, each costing, what, 50-75 dollars [0], and weigh the thick end of a kilogram each. Not only that, but spare batteries have an interenal discharge rate, meaning that they cannot be stored indefinitly (It's about a month for NiCd, less for NiMh, dunno about Li technologies).
Granted, if you break a methanol cartridge, then it's not pleasant stuff. Mind you, nethers the contents of your typical battery.
The trade off is then you can carry much more fuel, but you'll need to find a specialist to get more, vs the limited fuel and easy refilling for battery technologies.
Once the runtime of a single cartridge of methanol gets up, to me that's a no brainer. YMMV
[0] Off top of head, no actual idea how accurate that is - it's based of raw cells.
1.3 was a 'stable' series, in a manner of speaking.
The odd/even dev/stable thing only started with 2.0.
The new model is, indeed superior (it gives the developers a lot more freedom to do major changes, without adversly affecting the user experience).
It's just not the only dev model that's been used.
Sorry, I'm afraid that there is no exception clause. The lameness filter doesn't like in the diff output, so I've removed it. Each line of the diff output started with
sdjp@fermi:/usr/src/linux-2.4.21$ curl http://www.gnu.org/licenses/gpl.txt | diff COPYING -
[Curl output snipped for lameness filter reasons]
[Begin diff output]
1,16d0
NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the heading of "derived work".
Also note that the GPL below is copyrighted by the Free Software
Foundation, but the instance of code that it refers to (the Linux
kernel) is copyrighted by me and others who actually wrote it.
Also note that the only valid version of the GPL as far as the kernel
is concerned is _this_ particular version of the license (ie v2, not
v2.2 or v3.x or whatever), unless explicitly otherwise stated.
Linus Torvalds
[Line of hypthens the lameness filter doesn't like]
[End diff output]
The only difference between the liscence on Linux and the GPL is noted there, and it does not mention binary drivers.
So, either it's a breach of the Linux lisence to use them (because there is no exception clause), or no clause is required to use them legally.
Also, note that these actions by SCO do not involve distribution. They claim that they found some of thier IP [0] was illegally placed in Linux. They have then seperatly given a group of people a non-transferrable liscence to use that IP. I cannot see how that caused GPL to apply.
As I mentioned above, the fact that they distributed Linux puts them in a sticky situation. Note that it doesn't mean that they accepted the GPL - it means either they accepted the GPL, or were in breach of a software liscence.
No, emphatically not.
GPL applies to copyright'ed materials only. If SCO have other form of IP protection (such as patent, or, as they in fact claim, trade secret) the the GPL does not even interact with it. And see below.
Further, it is possible for SCO to liscence their copyrighted code such that all thier customers may use it. That does not make it GPL'd.
The GPL only applies upon redistribution - it is quite valid for me to link in code written under any sort of liscence to the Linux kernel. However, I may not freely redistribute it unless I can meet all the restrictions on it. From the GPl, section 7:
Granted, it is talking principly in terms of patent liscencing, but that's inconsequential.
As a case in point, conside the NVIDIA binary drivers. If you have an NVIDIA card, you have a liscence to use that copyrighted code. You do not have a liscence to re-distribute NVIDIA's code. Yet you may link the two systems together, just fine, provided you don't try to redistribute the combined work.
Now, SCO redistributing binaries from their ftp site, _after_ they make claims about thier code being in Linux is a whole different kettle of fish. That's a different issue however.
This patent has moved from the period where it was a novel, and powerful innovation, into textbook area. Part of the problem with software patents is that this take a year or so, compared with the 18 years patent life.
With chemistry, your looking at 15-20 years. That's one of the reasons why there is so much chemistry research - the patent lifespan is just right in that field.
The delaying of the patent for so long has crippled the use of this technique. This was not by bad buerocracy, but by deliberate intent. It is this deliberate intent to delay the onset of the patent that I object to - as this technique, novel and non-obvious in the 1960's, is commonplace now. The patent would have been, on balance, a good one in its time.
The loophole was plugged - to prevent more of this in the furture. The detritus from it's existance needs to be delt with.
Oh, and the patent does not apply to laser printers. It's quite specific about collimated beams of energy, and streams of matter to undergo chemical raction. Laser printers do not have a stream of matter, as defined in the patent. There is a reaction, which might be defined as chemical, on the photosensitive drum. However, I'm quite sure [0] the the motion of the drum will not qualify as a stream of matter.
[0] I'm not a patent lawyer. This is not legal advise. For legal advise, consult a professional liscened in your juristriction.
I'll go further than the above poster.
If the patent mentioned lasers (albeint by description, rather than by name) in 1957 then by Jove, that's worth a patent.
The advantages of using collimated and coherent light over other light sources in a chamical reaction are great, and certinally non-obvious back then.
The only thing I don't like about this patent is the submarine laywering over it. The content is quite reasonable, if not somewhat out of date.
Ok, firstly, please read the patent. It is not as trivial as it may appear from the few lines description.
It doesn't strike me as earth shatteringly novel, but then, most patents never have. It's written in usual obfuscated patent speak, which doesn't help.
The workaround: It is quite specific about collimated beams of radiation. So stick a lens in the way, de-collimate your beam, and the patent no longer applies.
If you are putting the laser through a window, then a couple of lenses, to de-focus the beam, and then focus it in the reaction zone will do the trick.
I'm not sure how this related to chip fabriacation, but I'm going to hazard a guess that it's in a CVD style deposition stage. The only time that precise focus would be needed is if your etching by laser onto a surface. In which case, you don't have a flow of matter.
This will not work if you are reflecting a collimated beam around so that it crosses the reaction zone multiple times.
Any fabiration engineers want to elucidate on where this patent might apply? Specifically, would a lens (I'm thinking of a power of around -1 uD) stop the system from working?
However, working around the patent may be considered a tacit admission of it's validity, and thus is a tatic in opposition to the legal challenge.
Unfortunatly, the H-bomb is not a chemical reaction, but rather a nuclear reaction. Thus, the patent does not apply.
Secondly, if your looking for prior art, best start by reading the patent. It's quite specific about streams of matter, and intersecting those streams with radient energy. Thus, the H-bomb, even were it chemical, would be well off.
You need to find stream of matter, and energy, inside a reaction vessel.
there are plugins for xine which will handle the css decoding. http://debianlinux.net/captain_css.html has one, for example.
You'll probably need to compile the plugin, but that's a small job.
I'm in the UK. No fires in the deep south here :P
I agree that some songs on the album are better than others [0]. However, I was replying to wether theme albums still exist, not wether every track on them was great. Even with my least favourite tracks, there presence on the album carries meaning, and I do not resent even it's inclusion (unlike tracks of a similar interest to me, on a non-themed album)
I would agree it's all about a negotiated contract. If the artist doesn't want to sell each track individually, that's fine by me. Like you said, if they don't sell, that's thier problem, not mine.
I would argue, however, that it would be rather rich to release a single, but not to allow that track to be sold separatly online.
[0] Was worth the cost for 'Travelin' solider' and 'Long time gone' alone though.
It is consitant.
Software patents are bad. See RTLinux for an example.
Copyright is good. Note that we are dying to find out what code SCO claims was missaproriated, so that it can be removed, ending an unintentional copyright violation.
IP is not a homogeneus entity. To consider it as such is to miss a very important point.
Patents say that because I thought of it before you, you cannot use the idea without paying me.
Copyright says that if you want to use this idea, either pay me for the right, or go away and do it yourself.
The latter encourages competition. The former anhiliates it.
Try a different player. That will identify and eliminate that aspect of the problem.
I'd reccomend Ogle - it's just a DVD player, and thus has the advantage of specialisation on it's side. Other than that, the other two media players are mplayer and xine. Xine is in debian, so that's probably the best bet. Mplayer is available from an alternate source (deb http://marillat.free.fr/ stable main), but I've had difficulty with audio decoding. Still, it'll help with problem identification.
Are you sure that it actually crashed the kernel? Or was it just X windows and input? I've had a couple of times that the only way I can unfreeze the system is to ssh in from another box, and do some kill -9 ing. Might be worht trying, if you can.
See if you can get a DVD-ROM from somewhere. Various magazines occasionally carry a DVD with programs on the front cover, so see if you can read one of those. Note that you may need UDF filesystem in the kernel (it's a loadable module if your using stock debian kernels).
Try instructing your player not to process the audio, and not to process the video. You may find that the problem is in the audio libraries, rather than video.
Quick aside: A bloated kernel will not slow the system down to any significant degree. The only reason to compile your own with a distro is to reduce the memory requirements, or for a different version of the kernel (new drivers, or experimetal / alternate patches). There is a slight slowdown at startup, but the fast path is not corrupted by additional options (Usually. There's a couple of minor exceptions, but they barely have any effect).
Beyond all that, I can't really help. But do try to narrow the problem down. You might also look from newer drive firmware - it sounds to me like the CSS firmware in the drive got a bit mangled, so a firmware update (even to the same version as it currently has) may help. May not, however - leave that as a last resort.
Hope that helps.
Dixie Chicks, Home.
Every song on the album revolves around the themes of friendship, belong and community, in some fashion. Granted, some are tied more strongly than others, and there's probably room for debate, but that's my opinion.
Surprised me too, but there you are.
Youy really want to talk about new albums by the way, rather than recently listened to ones, otherwise I can my Frank Sinatra and Alic Cooper collection's into the ring, along with a few others. I'll exclude all the opera cd's too.
Radiohead do tend to make albums that have a theme, so I'm not to concered by they talking like that. I'll leave noticable abscences there.
Lets separate what real nanotech offers from what nanotech does in SF stories.
Firstly, look at some of the stories set now, written 50 years ago. How many of them have an even part way accurate description of, well, anything?
So, when your talking about nanotech, what are you actually thinking of?
What I'm thinking of is something that will be a bit like a cross between mechanical engineering and chemistry - make the various mechanical parts small so that they tend to operate in a chemicaly relevent length scale. That's the sort of thing that these micro-engines are.
Think about biology for a moment, and about the sorts of biochemical reactions that go on in a living being. Those are the sort of things that nanotach can do. I do not believe that we will see a "Universal constructor" type device for many centuries, if ever.
Note that the two examples that you give have been solved without the use of nano tech. Superconducting powerlines are in use in europe. They are unfortunatly only cost effective for short range (around 100 miles or so) high power transfers - but that's improving.
The problem with fusion is not materials. You cannot get a material that will contain a fusion reaction - instead they use magnetic containment. And the problem is keeping the thing stable. I cannot see how nanotech devices would assist in this.
So, in sumary, you are thinking of the effects of something, but I've no idea what.
Probably not any exageration at all.
It's just very carefully selected semantical dodges.
It is talking about how much energy is contained inside these systems. (I'm assuming there's talking either per unit volume, or per unit mass. Other wise, well, it's totally meaningless).
That's a different number from how much energy you cet get out of the systems. In fact, my gut instinct is that they are comparing the energy you can get out of a battery to the total energy available from the fuel with the micro-engine. That's a false comparison either way, as the micro engine will not be 100 % efficent.
(Been over this kind of linguistic dodge many time with battery vs fuel cell arguments. It's very similar)
Um, DivX 5.06 for Mac?
Ok, don't use it myself (OSx doesn't run on any of my boxen). But I've never had a problem with Mplayer. Ocassional teething problems in compilation, but if your on Mac hardware, those nice people behind Fink have taken care of all that.
If there's something you don't like about mplayer, you could look at xine. Might be more to your tastes.
Huh?
It is an MPEG codec. DivX is an implementation of MPEG-4. If you want source code for a decoder see the ffmpeg (as libavcodec) or xvid codecs. Between then, I've not see an OS with a POSIX layer that's not been able to compile a decoder engine. Granted, there are large bunches of optional parts that the various decoders don't all cover, but I've not yet see any problems with ffmpeg decoder.
If by MPEGS you mean MPEG-1, then yes - that is slightly more portable than MPEG-4 codecs, but not noticably (better support on embeded systems). They do however, have poorer picture quality, and larger bitrates. So, it's not really a good choice for internet distribution. MPEG-2 would also be better than MPEG-1, but it's also not quite as good as MPEG-4, interms of low bitrate quality. And for a web demo, the lower the bitrate, the better.
If you've got a particular platform in mind, then drop a line, and I'll see if I can find a pre-compiled setup for it.
Can you enumerate them, because I can't see any.
(Aside: Award of damages depends on the claiment taking action to minisime harm (for example, a cease and desist notice). SCO have refused to allow the accused the opertunity to minimuse the harm.
Discliamer: I'm not liscenced to practice law in your juristriction. This is not legal advice. For legal advice, see a lawyer in your juristriction.)