The choice of distro doesn't even really matter. It just serves to confirm that the machine will infact work with Linux
It confirms that it works with _that distro_ - if that distro happens to ship with various non-Free drivers then that won't do you a blind bit of good if you want it to work with a completely Free distro.
Infact, I was looking around B&Q this weekend for a shower and found that for some crazy reason, the electric showers on show were _cheaper_ than mixer showers (electric showers were 120-200ukp, mixer showers were more like 180-300ukp).
Meanwhile, electric on-demand water heaters to replace a hot water cylinder + immersion heater are nowhere to be found... very strange.
you are almost forced to use third party repositories like freshrpms or dag because the repositories just plain suck.
How do they suck? They have most of the Free software I use in them - external repositories are mainly needed for non-Free software, and frankly if you don't like that maybe you should stop using a distribution who's stated aim is to ship only Free software.
And where the hell is Firefox 2 for Fedora anyway? They decided that we don't need it and they're going to hold out for Firefox 3? What the hell's that all about anyway?
FireFox 2 was released after Fedora Core 6 had started going to mirrors (it was basically released a couple of days before FC6). They had a few choices: 1. Quickly slap in a FireFox 2 package with no testing. This would've involved stopping the release, respinning and pushing it back to the mirrors, resulting in FC6 being delayed of probably about a week and no real certainty of the quality of the release. 2. Delay the whole release while it goes through the QA cycle again. That's going to be massive delays. 3. Release without FireFox 2 and let anyone who cares install the package from rawhide (which is what I did and it worked fine).
They chose to go with option 3 - to me it seems like the best plan. If you delay the release of a distribution every time one of the packages is out of date you'll never get a new distro out of the door. And if you skip the QA in order to push in some last minute feature then the quality of the release is going to go down the tubes. Yes, the timing of the FF2 and FC6 releases sucked because they were so close together, but that isn't anyone's fault, it's just the way the schedules fell.
My second thought was 'Wait, there are people who still use Fedora Core?'
Still, I'm glad it's been posted on Slashdot; now we can put all the trolls and flames under one article
Looks like a troll, sounds like a troll... oh wait, it is a troll...
Whilest Ubuntu seems to be gaining a lot of support from home-users these days, I'm afraid the corporate world still makes far more use of Red Hat based distributions than Ubuntu. I'm sure this is to a large extent down to the proliferation of RHEL and CentOS in industry for server applications - people are used to the structure of these systems and want to use something similar on their desktops - Fedora wins in those stakes.
since you are in the UK, perhaps here at Ace Hardware online would help?
Do you want to explain how that website is useful to anyone living in the UK, given that they are selling US bulbs with US fittings for US voltage? Nor can I see any mention of the bulbs being dimmable.
I think you mean using CFLs designed to work with dimmer switches. Like the ones made by GE and numerous others?
I searched around last year to try and get hold of a dimmable CFL - whilest I could find a few places selling them in the US I was unable to find any here in the UK. Infact the only real reference to them in the UK that I could find was one of the power companies having a FAQ stating that they are available (unsurprisingly I got no reply to the email I sent to them asking _where_ I could get them).
So I guess what I'm saying is that whilest it's possible to make dimmable CFLs, it's pretty hard to actually get hold of one.
I wonder how much the lack of routable endpoint addresses in IPv4 will hold back native IP systems from replacing legacy FAX, security, and other devices that currently depend on the POTS.
I'm certainly a big proponent of IPv6 and see peer-to-peer applications such as VoIP being a major driver for it's adoption. However, in this case I'm not convinced you need many routable endpoint addresses.
From a technical perspective, fax can more or less be replaced with MIME email immediately - there's no particular reason to invent new protocols, all you're doing is sending bitmaps over the internet, whcih is something that is done regularly anyway. And if you still want to send/receive standard faxes through your normal phone system your PABX can easilly send and receive faxes and gateway them to/from email.
How long is the FIR filter used for canceling echo and crosstalk then? I have always figured it was long enough to account for effects at the far end of the POTS connection
I'm not familiar enough with the design of modern modems to tell you. I would imagine that they can cope with echo on the far end, but in normal conditions shouldn't need to. Even for voice communications over high latency connections you need to remove the echo wherever you go from separate rx/tx (e.g. digital) to rx/tx over the same wire (e.g. POTS) - having a 200ms+ echo on the line is so distracting it makes it very difficult to hold a conversation.
This is what I thought when I first looked into the problem but I found many cases where even when compression was disabled and high bit rates above 64 kbit/s were used, the modem to modem connection over VOIP failed.
I've seen 9.6Kbps fax successfully running over a G.711 SIP connection, but I wouldn't want to comment on how reliable it is. That was with a softmodem program receiving the G.711 RTP packets directly on one side, so there's far less to go wrong since the demodulator effectively gets access to the original PCM data without any timebase mangling, so only has to deal with dropped packets.
Would this actually cause a high speed modem to fail though or just negotiate a lower speed?
I'm not sure how low a modem will go when doing retraining. If it could keep dropping the speed all the way down to 300baud FSK then I can't see any reason why it wouldn't be able to find a (low) speed where the tollerances are great enough to make it work. However, I'm pretty sure that modems will give up long before they get down to the really low speeds (doesn't retraining only happen for speeds over about 14.4Kbps?). If you force the connection to be established at a low speed in the first place it'll probably work.
In any case, I think that trying to put a modulated data signal over VoIP is an incredibly daft idea - far better to either plug directly into the network, or demodulate it locally and then just send the raw demodulated data over the network and remodulate it on the other side (if necessary). The VoIP network doing the demodulating/remodulating needs no knowledge of any higher level protocols - it doesn't even need to do the error correcting protocols, it just needs to shove raw data (errors and all) across the network - should be pretty cheap to do that.
For instance, the latency itself even if constant may exceed the length of the FIR filter used to adjust for far end crosstalk and echo.
There shouldn't be any far-end crosstalk and echo since that should've been removed by the hybred. With POTS at both ends you basically have 2 places where echo can be introduced (for audio you transmit):
1. the analogue segment on your side (your modem should remove the echo here as usual, which is simply a case of subtracting the transmitted signal from the received signal). 2. the analogue segment on the recipient's side (the telco's hybred should remove the echo here)
Between the two analogue segments you have a full-duplex digital circuit, so no chance of crosstalk/echo there.
If you are using digital (i.e. ISDN, VoIP, etc) on the sending side then that completely removes problem (1) anyway. Sure, if the telco's equipment is buggered then you could have problems, but in practice VoIP is lower latency than a satellite link, and modems will usually work over satellite links (although satellite is rarely used for the PSTN these days).
I think the real problems with running a modem over a VoIP link can be narrowed down to: 1. Compression (this isn't a problem if you use G.711) 2. Packet loss - VoIP systems can usually work like GSM and fill in for missing audio packets. This helps reduce how noticable the loss is to humans, but for modems it just won't cut it. 3. Jitter - if a packet arrives too late then it's going to be handled the same way as a lost packet. 4. PCM timing stability - even if you have no dropped packets, the stability of the PCM timing is not going to be anywhere near as good as you get on POTS. The sender and receiver's timers aren't synchronised so the receiver has to adjust its output to compensate for the data arriving marginally too quickly or slowly. This might be done by adjusting the actual PCM timing, but more frequently it will just delete a sample or insert an interpolated sample every so often.
Also, the better VoIP phones employ dynamic jitter buffers whereby the amount of time the data is buffered for before being played is dynamically adjusted in order to balance the number of packets arriving late against the latency of the link. In this case, not only does the link latency vary throughout the call, but in order to adjust the size of the jitter buffer on-the-fly, it must distort the PCM timing slightly.
That was GP's point -- that a bunch of players are offline, and so there is no way to patch them to make them able to play newer discs.
Only if they share the same key. My understanding of AACS is that a key would apply to only a few (or maybe one) player, so revoking the key won't break lots of players that haven't been compromised. Yes, the players will still have the flaw to _allow_ them to be compromised, but it you don't take advantage of that flaw then your player's key won't get revoked. This is a key difference between AACS and CSS - CSS allowed key revokation but the key was shared between a vast number of players (e.g. all players of the same model would share the same key) so the industry never made use of the revokation feature.
There is quite a good analysis of AACS on Freedom To Tinker that talks about this stuff.
Of course, I would be very interested to know how many key revokations AACS can handle. Since the title keys have to be encoded so that they can be extracted by all players except the revoked ones I imagine there must be some practical limit to how many revoked players can be excluded from a single disc. Maybe it'll get to the point where there are so many revoked keys that they have to start un-revoking some of the older ones...
all that DRM is going to amount to doing is preventing the 'average joe' from copying en-mass.
The thing is that DRM doesn't just stop you breaking the law - it stops a lot of very technical people from using their *legally purchased* content in a way that they feel is completely legitimate. And so once you've made sure these really technical people *have* to crack the DRM in order to use their content they are going to go out and produce tools that even the average joe can use to break the law.
Here's an example: I am required to crack the DRM on all of my legally purchased DVDs in order to use them on my DVD player (MythTV). Why does the industry thing that I shouldn't be allowed to play my DVDs on my own choice of player?
In theory yes, but how easy do you believe it is to update all those specialized video players, all offline?
You don't need the hardware to be networked in order to do key revokation - all the current discs continue to work just fine, but future discs will be encoded so they cannot be decoded with this key (this is the basis of AACS key revokation).
This is definately not "fully broken" - fully broken is when I can use the crack indefinately *without* having to get a new player and extract a key from it every so often. i.e. it involves finding a flaw in the algorithm that allows you to decode the disc without needing to extract any data from a legitimate player to do so.
And the problem with TPM is that you still have access to the hardware. If you've got that and enough time and skill, TPM eventually won't matter, either.
Presumably you don't even need access to the hardware - just emulate all the hardware (including the TPM) and you can poke around at the hardware's innards all you want then.
The word you're looking for is 'never'. If the car is unroadworthy by not being properly maintained, it's the driver's responsibility, period.
At what point was not being properly maintained mentioned? I explicitly said "through no fault of their own" infact.
There are any number of reasons that a car could be dangerous. The reasons that immediately spring to mind are:
Poor maintenance by the owner
Poor maintenance by the mechanic contracted by the owner
Damage which has happened after the last roadworthyness check (maybe even on the journey where the driver has an accident)
Manufacturing flaws
Design flaws
Maybe there was nothing wrong with the car - the driver might've lost control when he hit a pothole in the road, or whilest swerving to avoid another danger
And good luck proving who's at fault - it's often hard enough proving that there is a design flaw even when a large number of cars of the same design exhibit the same failure if the manufacturer doesn't admit to there being a problem.
If you think that all accidents where a driver hits someone who has right of way are the fault of the driver, you either lack imagination or haven't lived in this thing we call "the real world".
the "observer" metaphor is just a fancy way to say that the wave propagation of a particle collapses when it interacts with another particle.
What is the definition of "interacting"? Take, for example the double-slit experiment - you can fire electrons through a double slit and plot their distribution probabilities to show an interference pattern. Put a detector on one of the slits so you can tell which slit the electron went through and the interference disappears. In the case where you have a detector on one of the slits the interaction with the detector causes the wave function to collapse, but why aren't the electrons considered to be interacting with the slits themselves?
When two particles (spheres) touch each other, they collapse back to being single-point particles
My understanding is that even in a vacuume, there are so called "virtual" particles randomly popping in and out of existance - how do these affect it? It seems that the wave function of any particle is liable to spontaneously collapse at random even in a hard vacuume.
(I'm not a physicist and I don't try to pretend my brain is warped enough to properly grasp quantum mechanics:)
Not very frequently, but that's hardly the point - this kind of thing *does* happen. Whether through manufacturing flaws, design flaws or damage. Why else would car recalls happen if dangerous flaws didn't make it into production cars through no fault of the owner?
Cars are weapons and should be treated as such. Running over a pedestrian in a crosswalk is murder, and should be resulting in hanging.
Why is executing someone who's brakes failed through no fault of their own a good thing? They are probably already going through hell with the guilt of accidentally killing someone anyway. (In any case, accidentally killing someone is _not_ murder - it's manslaughter).
Accidents happen - sometimes noone is to blame. Everyone should be responsible for doing what they can to reduce accidents, even if it's not their fault. If you see a driver heading for you with obviously no intention of stopping then are you just gonna stand there while he runs into you? If so you probably deserve to be removed from the gene pool through gross stupidity.
You can take a pretty big impact almost anywhere in your body, and you'd still heal perfectly, at least most of the time.
The ability for the human body to endure high-speed crashes is something that I find pretty amazing. I'm fairly active, doing sports that are perceived as being reasonably dangerous due to the high speeds involved - windsurfing, skiing, etc. And I've wiped out pretty frequently while doing these sports and never seriously injured myself <touches a piece of wood>. When windsurfing I can get up to speeds of 35 knots or so, and can quite happilly do well over 70Km/h when skiing - certainly speeds that you would expect to get some injuries if you crash a car. The difference is that when you're out in the open, rather than sitting in a metal box (a car), the energy of the crash is dissipated by tumbling rather than just stopping in a short distance. So long as you don't hit something while you're tumbling you stand a good chance of coming out of it reasonably unscathed.
Either interactively to disambiguate, or several for redundancy, or other solutions to other problems the limited URL creates in its limited solution.
I'm not sure what problem you are trying to solve by throwing away an existing infrastructure whereby an address points at a specific resource location and replacing it with an infrastructure that identifies resources but not their locations. It doesn't resolve the domain parking problem since you will just get URN parking instead.
The ISBN is used with infosystems like bookseller or libarary databases to return the equivalents of URLs to find instances of the book, among other info about the class of copies of that book.
A URL identifies the location of a resource globally. A URN *may* be resolvable into a single location locally, but certainly not globally. Globally a URN would resolve into many locations. Citing the example of an ISBN, that globally resolves to every possible location of the book (i.e. every book shop, library, etc.), which is generally not useful.
URNs cannot replace URLs - the two types of address are for very different purposes. By all means, you can search for an object within a restricted environment by it's URN, but this is really no different to what we have at the moment - I can go to the Amazon website and put an ISBN in the search box.
The real solution is to move from misleadingly narrow UR L s, locators of the precise info resource, to the UR N s
This isn't a solution. Whilest a URN uniquely identifies a resource, it doesn't tell you where to _find_ that resource, so it is pretty useless for a system like the world wide web.
For example, you can form a URN out of a book's ISBN number, but that doesn't tell you where to find information about that book (e.g. the publisher's website) - it only tells you which book to look for once you have found a website with information about books in general.
Actually I thought Microsoft had some sort of deal with PC vendors in that they had to ship all PC's with a working OS.
This certainly used to be the case, but have the various antitrust cases against MS removed that agreement? (The Dell website actually states that they ship with FreeDOS, *not* unformatted, so the answer is probably "no").
Machine engineering is far easier than biological engineering, more replaceable, more durable, and eventually more versatile.
More durable? When was the last time you saw a significantly complex machine that could run non-stop for 80 years or more?
Sure, it might be easier to replace broken parts on a machine, but those parts generally wear out a _lot_ faster than biological parts (which are usually inherently being replaced cell by cell throughout their life).
Slashdot Mirror
The choice of distro doesn't even really matter. It just serves to confirm that the machine will infact work with Linux
It confirms that it works with _that distro_ - if that distro happens to ship with various non-Free drivers then that won't do you a blind bit of good if you want it to work with a completely Free distro.
And they ARE cheap.
Infact, I was looking around B&Q this weekend for a shower and found that for some crazy reason, the electric showers on show were _cheaper_ than mixer showers (electric showers were 120-200ukp, mixer showers were more like 180-300ukp).
Meanwhile, electric on-demand water heaters to replace a hot water cylinder + immersion heater are nowhere to be found... very strange.
you are almost forced to use third party repositories like freshrpms or dag because the repositories just plain suck.
How do they suck? They have most of the Free software I use in them - external repositories are mainly needed for non-Free software, and frankly if you don't like that maybe you should stop using a distribution who's stated aim is to ship only Free software.
And where the hell is Firefox 2 for Fedora anyway? They decided that we don't need it and they're going to hold out for Firefox 3? What the hell's that all about anyway?
FireFox 2 was released after Fedora Core 6 had started going to mirrors (it was basically released a couple of days before FC6). They had a few choices:
1. Quickly slap in a FireFox 2 package with no testing. This would've involved stopping the release, respinning and pushing it back to the mirrors, resulting in FC6 being delayed of probably about a week and no real certainty of the quality of the release.
2. Delay the whole release while it goes through the QA cycle again. That's going to be massive delays.
3. Release without FireFox 2 and let anyone who cares install the package from rawhide (which is what I did and it worked fine).
They chose to go with option 3 - to me it seems like the best plan. If you delay the release of a distribution every time one of the packages is out of date you'll never get a new distro out of the door. And if you skip the QA in order to push in some last minute feature then the quality of the release is going to go down the tubes. Yes, the timing of the FF2 and FC6 releases sucked because they were so close together, but that isn't anyone's fault, it's just the way the schedules fell.
FireFox 2 will of course be in Fedora 7.
My second thought was 'Wait, there are people who still use Fedora Core?'
Still, I'm glad it's been posted on Slashdot; now we can put all the trolls and flames under one article
Looks like a troll, sounds like a troll... oh wait, it is a troll...
Whilest Ubuntu seems to be gaining a lot of support from home-users these days, I'm afraid the corporate world still makes far more use of Red Hat based distributions than Ubuntu. I'm sure this is to a large extent down to the proliferation of RHEL and CentOS in industry for server applications - people are used to the structure of these systems and want to use something similar on their desktops - Fedora wins in those stakes.
since you are in the UK, perhaps here at Ace Hardware online would help?
Do you want to explain how that website is useful to anyone living in the UK, given that they are selling US bulbs with US fittings for US voltage? Nor can I see any mention of the bulbs being dimmable.
I think you mean using CFLs designed to work with dimmer switches. Like the ones made by GE and numerous others?
I searched around last year to try and get hold of a dimmable CFL - whilest I could find a few places selling them in the US I was unable to find any here in the UK. Infact the only real reference to them in the UK that I could find was one of the power companies having a FAQ stating that they are available (unsurprisingly I got no reply to the email I sent to them asking _where_ I could get them).
So I guess what I'm saying is that whilest it's possible to make dimmable CFLs, it's pretty hard to actually get hold of one.
I wonder how much the lack of routable endpoint addresses in IPv4 will hold back native IP systems from replacing legacy FAX, security, and other devices that currently depend on the POTS.
I'm certainly a big proponent of IPv6 and see peer-to-peer applications such as VoIP being a major driver for it's adoption. However, in this case I'm not convinced you need many routable endpoint addresses.
From a technical perspective, fax can more or less be replaced with MIME email immediately - there's no particular reason to invent new protocols, all you're doing is sending bitmaps over the internet, whcih is something that is done regularly anyway. And if you still want to send/receive standard faxes through your normal phone system your PABX can easilly send and receive faxes and gateway them to/from email.
How long is the FIR filter used for canceling echo and crosstalk then? I have always figured it was long enough to account for effects at the far end of the POTS connection
I'm not familiar enough with the design of modern modems to tell you. I would imagine that they can cope with echo on the far end, but in normal conditions shouldn't need to. Even for voice communications over high latency connections you need to remove the echo wherever you go from separate rx/tx (e.g. digital) to rx/tx over the same wire (e.g. POTS) - having a 200ms+ echo on the line is so distracting it makes it very difficult to hold a conversation.
This is what I thought when I first looked into the problem but I found many cases where even when compression was disabled and high bit rates above 64 kbit/s were used, the modem to modem connection over VOIP failed.
I've seen 9.6Kbps fax successfully running over a G.711 SIP connection, but I wouldn't want to comment on how reliable it is. That was with a softmodem program receiving the G.711 RTP packets directly on one side, so there's far less to go wrong since the demodulator effectively gets access to the original PCM data without any timebase mangling, so only has to deal with dropped packets.
Would this actually cause a high speed modem to fail though or just negotiate a lower speed?
I'm not sure how low a modem will go when doing retraining. If it could keep dropping the speed all the way down to 300baud FSK then I can't see any reason why it wouldn't be able to find a (low) speed where the tollerances are great enough to make it work. However, I'm pretty sure that modems will give up long before they get down to the really low speeds (doesn't retraining only happen for speeds over about 14.4Kbps?). If you force the connection to be established at a low speed in the first place it'll probably work.
In any case, I think that trying to put a modulated data signal over VoIP is an incredibly daft idea - far better to either plug directly into the network, or demodulate it locally and then just send the raw demodulated data over the network and remodulate it on the other side (if necessary). The VoIP network doing the demodulating/remodulating needs no knowledge of any higher level protocols - it doesn't even need to do the error correcting protocols, it just needs to shove raw data (errors and all) across the network - should be pretty cheap to do that.
For instance, the latency itself even if constant may exceed the length of the FIR filter used to adjust for far end crosstalk and echo.
There shouldn't be any far-end crosstalk and echo since that should've been removed by the hybred. With POTS at both ends you basically have 2 places where echo can be introduced (for audio you transmit):
1. the analogue segment on your side (your modem should remove the echo here as usual, which is simply a case of subtracting the transmitted signal from the received signal).
2. the analogue segment on the recipient's side (the telco's hybred should remove the echo here)
Between the two analogue segments you have a full-duplex digital circuit, so no chance of crosstalk/echo there.
If you are using digital (i.e. ISDN, VoIP, etc) on the sending side then that completely removes problem (1) anyway. Sure, if the telco's equipment is buggered then you could have problems, but in practice VoIP is lower latency than a satellite link, and modems will usually work over satellite links (although satellite is rarely used for the PSTN these days).
I think the real problems with running a modem over a VoIP link can be narrowed down to:
1. Compression (this isn't a problem if you use G.711)
2. Packet loss - VoIP systems can usually work like GSM and fill in for missing audio packets. This helps reduce how noticable the loss is to humans, but for modems it just won't cut it.
3. Jitter - if a packet arrives too late then it's going to be handled the same way as a lost packet.
4. PCM timing stability - even if you have no dropped packets, the stability of the PCM timing is not going to be anywhere near as good as you get on POTS. The sender and receiver's timers aren't synchronised so the receiver has to adjust its output to compensate for the data arriving marginally too quickly or slowly. This might be done by adjusting the actual PCM timing, but more frequently it will just delete a sample or insert an interpolated sample every so often.
Also, the better VoIP phones employ dynamic jitter buffers whereby the amount of time the data is buffered for before being played is dynamically adjusted in order to balance the number of packets arriving late against the latency of the link. In this case, not only does the link latency vary throughout the call, but in order to adjust the size of the jitter buffer on-the-fly, it must distort the PCM timing slightly.
That was GP's point -- that a bunch of players are offline, and so there is no way to patch them to make them able to play newer discs.
Only if they share the same key. My understanding of AACS is that a key would apply to only a few (or maybe one) player, so revoking the key won't break lots of players that haven't been compromised. Yes, the players will still have the flaw to _allow_ them to be compromised, but it you don't take advantage of that flaw then your player's key won't get revoked. This is a key difference between AACS and CSS - CSS allowed key revokation but the key was shared between a vast number of players (e.g. all players of the same model would share the same key) so the industry never made use of the revokation feature.
There is quite a good analysis of AACS on Freedom To Tinker that talks about this stuff.
Of course, I would be very interested to know how many key revokations AACS can handle. Since the title keys have to be encoded so that they can be extracted by all players except the revoked ones I imagine there must be some practical limit to how many revoked players can be excluded from a single disc. Maybe it'll get to the point where there are so many revoked keys that they have to start un-revoking some of the older ones...
all that DRM is going to amount to doing is preventing the 'average joe' from copying en-mass.
The thing is that DRM doesn't just stop you breaking the law - it stops a lot of very technical people from using their *legally purchased* content in a way that they feel is completely legitimate. And so once you've made sure these really technical people *have* to crack the DRM in order to use their content they are going to go out and produce tools that even the average joe can use to break the law.
Here's an example: I am required to crack the DRM on all of my legally purchased DVDs in order to use them on my DVD player (MythTV). Why does the industry thing that I shouldn't be allowed to play my DVDs on my own choice of player?
In theory yes, but how easy do you believe it is to update all those specialized video players, all offline?
You don't need the hardware to be networked in order to do key revokation - all the current discs continue to work just fine, but future discs will be encoded so they cannot be decoded with this key (this is the basis of AACS key revokation).
This is definately not "fully broken" - fully broken is when I can use the crack indefinately *without* having to get a new player and extract a key from it every so often. i.e. it involves finding a flaw in the algorithm that allows you to decode the disc without needing to extract any data from a legitimate player to do so.
And the problem with TPM is that you still have access to the hardware. If you've got that and enough time and skill, TPM eventually won't matter, either.
Presumably you don't even need access to the hardware - just emulate all the hardware (including the TPM) and you can poke around at the hardware's innards all you want then.
At what point was not being properly maintained mentioned? I explicitly said "through no fault of their own" infact.
There are any number of reasons that a car could be dangerous. The reasons that immediately spring to mind are:
And good luck proving who's at fault - it's often hard enough proving that there is a design flaw even when a large number of cars of the same design exhibit the same failure if the manufacturer doesn't admit to there being a problem.
If you think that all accidents where a driver hits someone who has right of way are the fault of the driver, you either lack imagination or haven't lived in this thing we call "the real world".
the "observer" metaphor is just a fancy way to say that the wave propagation of a particle collapses when it interacts with another particle.
:)
What is the definition of "interacting"? Take, for example the double-slit experiment - you can fire electrons through a double slit and plot their distribution probabilities to show an interference pattern. Put a detector on one of the slits so you can tell which slit the electron went through and the interference disappears. In the case where you have a detector on one of the slits the interaction with the detector causes the wave function to collapse, but why aren't the electrons considered to be interacting with the slits themselves?
When two particles (spheres) touch each other, they collapse back to being single-point particles
My understanding is that even in a vacuume, there are so called "virtual" particles randomly popping in and out of existance - how do these affect it? It seems that the wave function of any particle is liable to spontaneously collapse at random even in a hard vacuume.
(I'm not a physicist and I don't try to pretend my brain is warped enough to properly grasp quantum mechanics
And that happens how often?
Not very frequently, but that's hardly the point - this kind of thing *does* happen. Whether through manufacturing flaws, design flaws or damage. Why else would car recalls happen if dangerous flaws didn't make it into production cars through no fault of the owner?
Cars are weapons and should be treated as such. Running over a pedestrian in a crosswalk is murder, and should be resulting in hanging.
Why is executing someone who's brakes failed through no fault of their own a good thing? They are probably already going through hell with the guilt of accidentally killing someone anyway. (In any case, accidentally killing someone is _not_ murder - it's manslaughter).
Accidents happen - sometimes noone is to blame. Everyone should be responsible for doing what they can to reduce accidents, even if it's not their fault. If you see a driver heading for you with obviously no intention of stopping then are you just gonna stand there while he runs into you? If so you probably deserve to be removed from the gene pool through gross stupidity.
50kg human * 1.5 m/s = 56 J of energy. 1000kg car * 20 m/s = 200,000 J of energy
Isn't kinetic energy proportional to the square of velocity, or am I just going crazy?
You can take a pretty big impact almost anywhere in your body, and you'd still heal perfectly, at least most of the time.
The ability for the human body to endure high-speed crashes is something that I find pretty amazing. I'm fairly active, doing sports that are perceived as being reasonably dangerous due to the high speeds involved - windsurfing, skiing, etc. And I've wiped out pretty frequently while doing these sports and never seriously injured myself <touches a piece of wood>. When windsurfing I can get up to speeds of 35 knots or so, and can quite happilly do well over 70Km/h when skiing - certainly speeds that you would expect to get some injuries if you crash a car. The difference is that when you're out in the open, rather than sitting in a metal box (a car), the energy of the crash is dissipated by tumbling rather than just stopping in a short distance. So long as you don't hit something while you're tumbling you stand a good chance of coming out of it reasonably unscathed.
Either interactively to disambiguate, or several for redundancy, or other solutions to other problems the limited URL creates in its limited solution.
I'm not sure what problem you are trying to solve by throwing away an existing infrastructure whereby an address points at a specific resource location and replacing it with an infrastructure that identifies resources but not their locations. It doesn't resolve the domain parking problem since you will just get URN parking instead.
The ISBN is used with infosystems like bookseller or libarary databases to return the equivalents of URLs to find instances of the book, among other info about the class of copies of that book.
A URL identifies the location of a resource globally. A URN *may* be resolvable into a single location locally, but certainly not globally. Globally a URN would resolve into many locations. Citing the example of an ISBN, that globally resolves to every possible location of the book (i.e. every book shop, library, etc.), which is generally not useful.
URNs cannot replace URLs - the two types of address are for very different purposes. By all means, you can search for an object within a restricted environment by it's URN, but this is really no different to what we have at the moment - I can go to the Amazon website and put an ISBN in the search box.
The real solution is to move from misleadingly narrow UR L s, locators of the precise info resource, to the UR N s
This isn't a solution. Whilest a URN uniquely identifies a resource, it doesn't tell you where to _find_ that resource, so it is pretty useless for a system like the world wide web.
For example, you can form a URN out of a book's ISBN number, but that doesn't tell you where to find information about that book (e.g. the publisher's website) - it only tells you which book to look for once you have found a website with information about books in general.
Actually I thought Microsoft had some sort of deal with PC vendors in that they had to ship all PC's with a working OS.
This certainly used to be the case, but have the various antitrust cases against MS removed that agreement? (The Dell website actually states that they ship with FreeDOS, *not* unformatted, so the answer is probably "no").
Actually they aren't without anything. They come with FreeDOS. And FreeDOS is open source.
Looks like the Slashdot article lies - it states the hard drive comes unformatted, but the Dell website clearly says they come with FreeDOS installed.
Machine engineering is far easier than biological engineering, more replaceable, more durable, and eventually more versatile.
More durable? When was the last time you saw a significantly complex machine that could run non-stop for 80 years or more?
Sure, it might be easier to replace broken parts on a machine, but those parts generally wear out a _lot_ faster than biological parts (which are usually inherently being replaced cell by cell throughout their life).
The patterns in the meat of your brain do not have some kind of universal or raw format.
:)
You mean my brain doesn't use OOXML? But Microsoft told me....