Depends on where you are in the band (college end or commercial end), where you are geographically (flat land, mountains, hills, depressions), where your nearest adjacents are (first and second adjacents), and the distance to the nearest station on your same frequency. All these things impact how much power is needed to go a particular distance, and may also impact how much power you would be allowed to use.
If memory serves, in a rural area about an hour from a city, expect to need about 300 Watts to carry 15-20 miles with a frequency around 90 MHz. Closer to a city, make it closer to a kilowatt. In the mountains, more power. In a hole... well, build the tower somewhere else and add the cost of a relay. Want to broadcast in a way that reaches people who live in a hole, raise the power.
I can't think of any case where you'd reasonably get 20 miles on 30 watts unless you live somewhere that's completely flat with few or no stations nearby. At least not in the FM band. One of the lower frequency HAM bands, sure, but not in the FM band.
1. Get your school to set one up. Because it is an educational institution, it could probably find a frequency in the bottom end of the spectrum where the spectrum is less dense, which means that A. they'd be more likely to be able to -get- a license, and B. they'd have less interference problems at lower wattage. A typical college station is 300-600 watts and can reach about a 20 mile radius. (The advantage of being at a lower frequency and having less adjacent stations.)
2. There's the issue of the site survey, filing for a construction permit with the FCC, getting said permit, building the tower and getting it up and running within a year, and REMEMBERING TO UPGRADE YOUR LICENSE WHEN CONSTRUCTION IS FINISHED! I can't emphasize that enough. Failing to notify the FCC of completion of construction is the surest way to get pulled off the air, fined, or both.
3. Decide on how many hours you will broadcast. You don't have to broadcast all day, but if you don't, someone else could insist on taking over your spectrum slice the rest of the day. It is better to defend it by broadcasting 24x7 unless you are in a rural area and can't afford to do so.
4. Make sure you buy a transmitter with automated monitoring capabilities. You do not want to have to have an engineer on-site at all times.
5. The college must hire an engineer to be on call.
6. Set up the on-air studio. Lots of other people have commented on that, so I'll keep this brief. For the on-air studio: decent mixer, decent CD players, decent cassette deck, decent on-air automation computer, decent microphone, and at least two cart machines. They don't have to be new digicarts. Find a couple of old ones that a commercial station is throwing out. This is important because you need to be able to broadcast liners even if your automation goes down.
7. Set up the production studio. Similar equipment to the on-air studio. Networking between them, preferrably not part of the campus network to avoid hacking issues.
8. Automation software and possibly hardware. Scott Systems makes a decent system, as do several others, but they're all exorbitantly expensive for a new station. If you don't mind getting your hands dirty in either Mac OS X or Linux to set it up, there's always songcue. It's open source, runs on top of MySQL or PostGreSQL, and knows how to drive a slightly hacked mpg123, ogg123, or esdcat. Requires esound. Ideally, you should dedicate a machine to this, and I'll note that the Mac OS X version does a better job at avoiding dropouts in the audio.:-)
9. Talent. You'll need on-air talent to staff the station. A good way to do this is to get your school's communications department to make learning the system (say as a news reader) a mandatory part of a radio broadcasting class and to provide course credit for people who stay on and work at the station.
10. BMI -and- ASCAP reporting. You'll need to check with them to find out what needs to be reported to each.
11. As mentioned, you may also consider either a carrier current AM (extremely low power) or a cable radio (soundtrack for campus information channel) setup. That's a good way to get started initially, since you don't have to mess with the transmitter and FCC licensing. However -all- of the other costs and issues remain true, so the cost is not really that different. It does, however, allow you to get something up and running much more quickly, which can be good as a proof-of-concept for getting additional non-recurring funding the next year for equipment improvements, something which is essential in a college environment.
I'm pretty sure that hasn't been the case for many years. While this is still suggested, it is flexible if content requires it. For example, if you're broadcasting an opera live, you can cut in at a convenient place, say at an intermission, whether or not it is at the top of the hour. I believe you still have to average once per hour, etc.
Not true. You may not be able to blanketly give up your right to sue, but you can give up your right to sue for particular reasons. If that were not the case, then no software license or employment contract would be binding, since I have yet to see one that doesn't include a limitation of liability.
There's a fine line, though, and in cases of fraud or negligence, these sorts of things do become non-binding as I understand it. As always, the usual "IANAL" disclaimer applies.
That's not true. An open network is completely unlike an open door. An door is installed for the purposes of keeping people out. An access point is installed for the purposes of letting people in. A doorway, by contrast, exists to let people in, in the absence of a door. This is a critical distinction.
The company or sysadmin took explicit action to install that access point and to install that DHCP server. In so doing, they granted access to their network. A similar situation would exist if someone explicitly sawed a hole in the side of his or her house and put up a "Come In, We're Open" sign.
The DHCP server, since it was explicitly installed, acts as a proxy for the administrator of the system, carrying out explicit policy decisions as dictated by that administrator. Even if that policy decision amounts to failing to limit access, there was an explicit action needed to grant access.
Since the installation of the DHCP server, and hence, your access to the network, required explicit action on the part of the administrator, it most certainly -is- consent as a result of a direct action on their part to grant access. Period.
Repeat to yourself: This is not a grey area. This is not a grey area. This is not a grey area.
Terrible analogy. You are trespassing on private property and stealing things from that private property. The famous "your home is your castle" principle applies. In a similar fashion, if someone used that warchalked wireless network to crack into the company's internal network computers, then yeah, they're breaking the law, but not because they used the wireless network to do it.
A much better physical analogy is that of a walkway beside one's house. For example, at the beach, it is not uncommon to see wooden walkways a few feet above the sand for the purpose of beach acess from the road. If a person puts such a walkway on his or her property, it can be reasonably assumed that this gives people permission to use it to cross between the public road and the public beach. If the owner does not want that, they put a locked gate at one or both ends. If someone picks that lock, they are trespassing.
Similarly, if someone puts up an access point that does nothing but provide access between the public airwaves and the public internet, it can be assumed that its use is public unless the owner puts up a lock one one or both ends. A lock on the wireless end would be WEP or MAC address restriction on the router. A lock on the other end would include MAC address checking on the DHCP server or the router. If someone works around one of these, they are basically trespassing. If no such reasonable attempts are made to limit public ingress and egress, it can be considered public.
The only major drawback to this system is that window resizing can be very slow, since you need to re-allocate the offscreen buffer each time the window changes size.
That doesn't necessarily have to be the case. It depends on the design used for the backing store. If it were practical to completely represent the screen as a series of operations (for example, a list of 3D primitives and operations on them) instead of as a pixel buffer, the problem disappears, and the application has only to modify the data as appropriate to fill up the rest of the larger window. At that point, the only time you need to resize is when your buffer can't hold all the primitives. (Yes, this is a little far-fetched.:-)
See my follow-on comments to another poster. It's nearly impossible to completely eliminate the client-server paradigm. I was primarily referring to the notion of doing so over a socket-like mechanism. A better design would involve using message passing/sockets/foo for as little as possible and doing 99% of the work through shared memory and similar.
I should probably start by clarifying something. There must, to some extent, always a client-server model for anything remotely resembling a window system, insofar as you have a window server program providing access to the display, without which you'd only be able to run a single app. However, with shared memory regions, the use of message passing in the traditional sense can be limited to events (mouse click notification, foregrounding of windows, etc.) rather than moving all the graphics data through sockets.
I guess my point was that a complete client-server model has a lot of problems, the largest of which is speed. I can think of two good reasons for such a model:
The first is if you have data on the server that you're trying to work with, and if the data is substantially larger than the traffic generated by passing around all that X11 traffic. Yes, it happens, particularly in scientific fields, but no, it isn't typical use.
The second is if you have an application that is closed-source and only runs on your Solaris box (for example), but you want to use it on your local machine.
In both cases, with the exception of the memory usage, this can be done equally well by running the application on the server machine, then provide a tap at a higher level in the API for inserting a VNC-like protocol to send the graphics data to the display machine.
The advantages to such a model are numerous. First, you get the remote accessability when it is needed without penalizing local use (much). Second, because it occurs at a window server level, you get some nice optimizations for free because of the design decisions implicit in my earlier description.
For example, since you would have the window's complete description in the display machine's memory, an application wouldn't need to redraw parts of a window when it gets brought to the foreground. It could just send a refresh message up through the API, which would be sent across to the other machine, which would dutifully refresh the window.
Of course, there are cases where you'd want to do a full refresh, but these are less common than needing to simply change a window's visibility. As a result, your data traffic, even for client-server-style communications, should drop.
Most of the time, yes, but not always. Drive manufacturers sometimes just have bad runs. I managed to have an IBM laptop drive experience accoustic failure (i.e. the drive works but sounds like a chainsaw) after just a couple of months in a laptop in normal daily use on a desk surface. I have a stack of dead Quantum drives of various vintages (mostly laptop, but at least one desktop), and one very old Seagate. Most of those drives were treated like babies.
By contrast, I have desktop drives that have been running 24x7 for nearly four years in everything from a temperature controlled environment to a tiny closet with no ventillation without a hiccup. In the case of the tiny closet drive, that 5.25" monstrosity was a fossil when I got it used on eBay.
If that isn't twisted enough, the machine to which the 5.25" monstrosity is attached... rode around tipping and bouncing back and forth in the back of my van for about three months. You should be both horrified and amazed that those 10+ year old drives are still working flawlessly almost two years later....
So yes, when you look at general trends, drives that are abused are more likely to fail, but early failure does not necessarily require abuse, nor does long life necessarily mean that the drive was treated kindly.:-)
merchantability for a certain purpose is one thing they usually cannot disclaim
I think you're mostly right, but there are a few edges that are rough. I'll explain:
Here in California, you are mostly correct, in that California has laws that explicitly protect consumers against "fitness for a particular purpose" exemptions in warranties. Most states don't have such restrictions, though, AFAIK.
Merchantability, however, refers to fitness for the product's general purpose use, i.e. does your car drive (where fitness for a particular purpose might be "can you tow your motor home behind your Pinto"). I'm not sure if that can be disclaimed.
If a company buys a delivery truck and it just breaks down, the seller doesn't owe what the company is losing while it's getting repaired.
Actually, under certain circumstances, it does. It isn't uncommon for dealers (at least in rural areas) to give someone a "loaner" car while their vehicle was being repaired if the repair was expected to take more than a day.
Now, part of that is a belief that people are more likely to buy things in the future from a dealer that treats their customers with respect. But not all states allow for limitation of liability in the case of loss of business due to defects in manufacture, particularly if lemon laws come into play. And, of course, you won't know if the car is a lemon until it has been repaired several times, at which point the dealer can't go back in time and give them a loaner for the previous repairs....
California, for example, explicitly allows for recovery of consequential damages in the case of a lemon. Which might work for a delivery truck, particularly if the dealer doesn't provide a loaner.
For a hard drive, though, it would be extremely difficult to prove that you couldn't reasonably protect yourself from such a loss, which as best I can tell, is one of the requirements. In short, with a hard drive, you might be able to get consequential damages for the loss of productivity while the drive is being repaired, but it seems unlikely that you'd be able to get money for the loss of data unless you could prove that the company shipped defective drives with malice of forethought, and maybe not even then.
I'm probably going to get modded down for this, but....:-)
It occurs to me that what the Linux community needs is not another hacked-up KDE knock-off, but a real ground-up GUI. By GUI, I don't mean an X11 WM, I mean a complete GUI. Some lessons can be learned from Mac OS X's graphics system.
Point 1: Dump X11 entirely. It's a lot easier to write libraries to display X11 apps in a different environment than it is to make X11 into a modern graphics environment. Its development began 18 years ago (released 14 years ago), and frankly, its age shows, both in performance and in functionality.
Point 2: OpenGL compositing a la Quartz Extreme. Windows become patterns mapped onto a plane. 3D graphics are tightly integrated into the same screen model.
Point 3: With the exception of bitmaps (which you map as a pattern), draw all the 2d windows using 3d primitives, say as a variant of splines that have thickness, located just in front of a 2d plane.
I'm not sure how hard this would be, but the basic thinking behind this idea is to take a traditional PDF or PostScript-style bezier curve model and map it into 3d primitives so that it can be rendered in hardware.
I suspect that such a design may go farther than is practical given current graphics hardware speeds, but if someone were to write such software, eventually the hardware would catch up and such a thing would then become practical, assuming it isn't already.
Point 4: Do not use a client-server model. It made sense in 1984. It doesn't make sense in 2002. Most people don't have graphical terminals connected to big centralized servers these days. A client-server model can easily be grafted onto a local model if it is designed correctly. By contrast, local communication via a client-server model tends to cause a speed penalty.
Before you ask, no, I don't have the time to design such a system, and it would be a conflict of interest if I did. That having been said, I certainly think it would be cool if someone pulled it off....:-)
I'm going to play devil's advocate here. He could argue that his mail relay -is- sufficiently closed. Why? Because any spam that gets sent through it will require someone blatantly pretending to be him.
Now figure that 1% of those people are going to -reply- to the message. Guess where the replies are going to go? That's right. To him. Guess what a lawyer is going to do when he finds out that someone is claiming to be him?
Can you say fraud, defamation through identity theft, theft of computing resources, and best of all, since the automated tagging of email with information abut the sender is designed for the purpose of making it easy to track the creator of written messages, which is necessary for protection of copyright, hell, they're even violating the DMCA.:-p
So in a perverse way, by keeping this guy on the blackhole list, his ability to take action against people who falsify their identity (which -is- illegal) is weakened, and as such, the blackhole list is inadvertantly hurting the cause that it is trying to promote.
Of course, this would not be true in the non-lawyer case, and it's kind of hard to special case things like this for one person, which is why the rules are written in the way that they are. And that should be the argument being made against this semi-open relay.
A good counter-example would be a million dollar donation to overturn an anti-gang law, one of those that defines a gang go be any group of three or more people under 21 out after 8 p.m. Most of us would probably agree that such laws should be overturned even if you couch it as an "anti-violence" law.
I recall being told of auction and sale activity going on on the UnderNet back when I was in high school, which would make it no later than June of '95, and since it was obviously established when I heard about it... you do the math.
I'm out of mod points this week, so I can't mod the parent up, but I thought I'd explain why this joke is funny and on-topic. Maybe somebody with mod points left can bump it up.
Back about a year ago, Taco Bell offered to give free tacos for a day if the Mir space station (then decomissioned) hit a particular target (floating in the ocean... Pacific Ocean, I think, but maybe Indian Ocean) when it fell out of space.
The joke was that if they strap boosters onto satellites, then one would assume that no satellites will fall, thus there's no chance for free tacos in the future. Of course, this really doesn't affect satellites that are decomissioned for other reasons, like obsolescence, nor was the Mir a satellite. Regardless, though, it's funny, if a bit inaccurate.:-)
That and the fact that the external tank, unlike the SRBs, if memory serves, isn't reusable. The paint costs money, serves no useful purpose (like it's really going to rust while it sits on the pad...), and hurts the fuel economy. No brainer.:-)
Worse. AFAIK, the INIT loading code used in the startup process is still 68k code even in 9.2.x. As I understand it, it would have been impossible to change it without breaking existing extensions in incompatible ways.
PCI devices can do DMA, too. AGP probably does DMA differently, but PCI most assuredly supports DMA transactions between PCI devices and the memory bus. If it didn't, your hard drive performance would be no faster when you turn UDMA on.
There used to be VCRs from Panasonic, probably others, that would do standards conversion for PAL/NTSC. Now SECAM, yeah, that kind of... umm... sucks. But for PAL, it really wasn't that hard.
Of course, VHS LP is generally actually worse quality than SLP due to the way the tracks end up overlapping. SLP moved to narrower heads to remove the problem, but this prevented recording LP in a compatible way, if memory serves.
Slashdot Mirror
Depends on where you are in the band (college end or commercial end), where you are geographically (flat land, mountains, hills, depressions), where your nearest adjacents are (first and second adjacents), and the distance to the nearest station on your same frequency. All these things impact how much power is needed to go a particular distance, and may also impact how much power you would be allowed to use.
If memory serves, in a rural area about an hour from a city, expect to need about 300 Watts to carry 15-20 miles with a frequency around 90 MHz. Closer to a city, make it closer to a kilowatt. In the mountains, more power. In a hole... well, build the tower somewhere else and add the cost of a relay. Want to broadcast in a way that reaches people who live in a hole, raise the power.
I can't think of any case where you'd reasonably get 20 miles on 30 watts unless you live somewhere that's completely flat with few or no stations nearby. At least not in the FM band. One of the lower frequency HAM bands, sure, but not in the FM band.
1. Get your school to set one up. Because it is an educational institution, it could probably find a frequency in the bottom end of the spectrum where the spectrum is less dense, which means that A. they'd be more likely to be able to -get- a license, and B. they'd have less interference problems at lower wattage. A typical college station is 300-600 watts and can reach about a 20 mile radius. (The advantage of being at a lower frequency and having less adjacent stations.)
:-)
2. There's the issue of the site survey, filing for a construction permit with the FCC, getting said permit, building the tower and getting it up and running within a year, and REMEMBERING TO UPGRADE YOUR LICENSE WHEN CONSTRUCTION IS FINISHED! I can't emphasize that enough. Failing to notify the FCC of completion of construction is the surest way to get pulled off the air, fined, or both.
3. Decide on how many hours you will broadcast. You don't have to broadcast all day, but if you don't, someone else could insist on taking over your spectrum slice the rest of the day. It is better to defend it by broadcasting 24x7 unless you are in a rural area and can't afford to do so.
4. Make sure you buy a transmitter with automated monitoring capabilities. You do not want to have to have an engineer on-site at all times.
5. The college must hire an engineer to be on call.
6. Set up the on-air studio. Lots of other people have commented on that, so I'll keep this brief. For the on-air studio: decent mixer, decent CD players, decent cassette deck, decent on-air automation computer, decent microphone, and at least two cart machines. They don't have to be new digicarts. Find a couple of old ones that a commercial station is throwing out. This is important because you need to be able to broadcast liners even if your automation goes down.
7. Set up the production studio. Similar equipment to the on-air studio. Networking between them, preferrably not part of the campus network to avoid hacking issues.
8. Automation software and possibly hardware. Scott Systems makes a decent system, as do several others, but they're all exorbitantly expensive for a new station. If you don't mind getting your hands dirty in either Mac OS X or Linux to set it up, there's always songcue. It's open source, runs on top of MySQL or PostGreSQL, and knows how to drive a slightly hacked mpg123, ogg123, or esdcat. Requires esound. Ideally, you should dedicate a machine to this, and I'll note that the Mac OS X version does a better job at avoiding dropouts in the audio.
9. Talent. You'll need on-air talent to staff the station. A good way to do this is to get your school's communications department to make learning the system (say as a news reader) a mandatory part of a radio broadcasting class and to provide course credit for people who stay on and work at the station.
10. BMI -and- ASCAP reporting. You'll need to check with them to find out what needs to be reported to each.
11. As mentioned, you may also consider either a carrier current AM (extremely low power) or a cable radio (soundtrack for campus information channel) setup. That's a good way to get started initially, since you don't have to mess with the transmitter and FCC licensing. However -all- of the other costs and issues remain true, so the cost is not really that different. It does, however, allow you to get something up and running much more quickly, which can be good as a proof-of-concept for getting additional non-recurring funding the next year for equipment improvements, something which is essential in a college environment.
I'm pretty sure that hasn't been the case for many years. While this is still suggested, it is flexible if content requires it. For example, if you're broadcasting an opera live, you can cut in at a convenient place, say at an intermission, whether or not it is at the top of the hour. I believe you still have to average once per hour, etc.
Not true. You may not be able to blanketly give up your right to sue, but you can give up your right to sue for particular reasons. If that were not the case, then no software license or employment contract would be binding, since I have yet to see one that doesn't include a limitation of liability.
There's a fine line, though, and in cases of fraud or negligence, these sorts of things do become non-binding as I understand it. As always, the usual "IANAL" disclaimer applies.
The company or sysadmin took explicit action to install that access point and to install that DHCP server. In so doing, they granted access to their network. A similar situation would exist if someone explicitly sawed a hole in the side of his or her house and put up a "Come In, We're Open" sign.
The DHCP server, since it was explicitly installed, acts as a proxy for the administrator of the system, carrying out explicit policy decisions as dictated by that administrator. Even if that policy decision amounts to failing to limit access, there was an explicit action needed to grant access.
Since the installation of the DHCP server, and hence, your access to the network, required explicit action on the part of the administrator, it most certainly -is- consent as a result of a direct action on their part to grant access. Period.
Repeat to yourself: This is not a grey area. This is not a grey area. This is not a grey area.
A much better physical analogy is that of a walkway beside one's house. For example, at the beach, it is not uncommon to see wooden walkways a few feet above the sand for the purpose of beach acess from the road. If a person puts such a walkway on his or her property, it can be reasonably assumed that this gives people permission to use it to cross between the public road and the public beach. If the owner does not want that, they put a locked gate at one or both ends. If someone picks that lock, they are trespassing.
Similarly, if someone puts up an access point that does nothing but provide access between the public airwaves and the public internet, it can be assumed that its use is public unless the owner puts up a lock one one or both ends. A lock on the wireless end would be WEP or MAC address restriction on the router. A lock on the other end would include MAC address checking on the DHCP server or the router. If someone works around one of these, they are basically trespassing. If no such reasonable attempts are made to limit public ingress and egress, it can be considered public.
That doesn't necessarily have to be the case. It depends on the design used for the backing store. If it were practical to completely represent the screen as a series of operations (for example, a list of 3D primitives and operations on them) instead of as a pixel buffer, the problem disappears, and the application has only to modify the data as appropriate to fill up the rest of the larger window. At that point, the only time you need to resize is when your buffer can't hold all the primitives. (Yes, this is a little far-fetched. :-)
See my follow-on comments to another poster. It's nearly impossible to completely eliminate the client-server paradigm. I was primarily referring to the notion of doing so over a socket-like mechanism. A better design would involve using message passing/sockets/foo for as little as possible and doing 99% of the work through shared memory and similar.
I guess my point was that a complete client-server model has a lot of problems, the largest of which is speed. I can think of two good reasons for such a model:
The first is if you have data on the server that you're trying to work with, and if the data is substantially larger than the traffic generated by passing around all that X11 traffic. Yes, it happens, particularly in scientific fields, but no, it isn't typical use.
The second is if you have an application that is closed-source and only runs on your Solaris box (for example), but you want to use it on your local machine.
In both cases, with the exception of the memory usage, this can be done equally well by running the application on the server machine, then provide a tap at a higher level in the API for inserting a VNC-like protocol to send the graphics data to the display machine.
The advantages to such a model are numerous. First, you get the remote accessability when it is needed without penalizing local use (much). Second, because it occurs at a window server level, you get some nice optimizations for free because of the design decisions implicit in my earlier description.
For example, since you would have the window's complete description in the display machine's memory, an application wouldn't need to redraw parts of a window when it gets brought to the foreground. It could just send a refresh message up through the API, which would be sent across to the other machine, which would dutifully refresh the window.
Of course, there are cases where you'd want to do a full refresh, but these are less common than needing to simply change a window's visibility. As a result, your data traffic, even for client-server-style communications, should drop.
By contrast, I have desktop drives that have been running 24x7 for nearly four years in everything from a temperature controlled environment to a tiny closet with no ventillation without a hiccup. In the case of the tiny closet drive, that 5.25" monstrosity was a fossil when I got it used on eBay.
If that isn't twisted enough, the machine to which the 5.25" monstrosity is attached... rode around tipping and bouncing back and forth in the back of my van for about three months. You should be both horrified and amazed that those 10+ year old drives are still working flawlessly almost two years later....
So yes, when you look at general trends, drives that are abused are more likely to fail, but early failure does not necessarily require abuse, nor does long life necessarily mean that the drive was treated kindly. :-)
David, Killer of Drives
I think you're mostly right, but there are a few edges that are rough. I'll explain:
Here in California, you are mostly correct, in that California has laws that explicitly protect consumers against "fitness for a particular purpose" exemptions in warranties. Most states don't have such restrictions, though, AFAIK.
Merchantability, however, refers to fitness for the product's general purpose use, i.e. does your car drive (where fitness for a particular purpose might be "can you tow your motor home behind your Pinto"). I'm not sure if that can be disclaimed.
Caveat emptor: IANAL, either.
Bet this one is, though. :-)
Actually, under certain circumstances, it does. It isn't uncommon for dealers (at least in rural areas) to give someone a "loaner" car while their vehicle was being repaired if the repair was expected to take more than a day.
Now, part of that is a belief that people are more likely to buy things in the future from a dealer that treats their customers with respect. But not all states allow for limitation of liability in the case of loss of business due to defects in manufacture, particularly if lemon laws come into play. And, of course, you won't know if the car is a lemon until it has been repaired several times, at which point the dealer can't go back in time and give them a loaner for the previous repairs....
California, for example, explicitly allows for recovery of consequential damages in the case of a lemon. Which might work for a delivery truck, particularly if the dealer doesn't provide a loaner.
For a hard drive, though, it would be extremely difficult to prove that you couldn't reasonably protect yourself from such a loss, which as best I can tell, is one of the requirements. In short, with a hard drive, you might be able to get consequential damages for the loss of productivity while the drive is being repaired, but it seems unlikely that you'd be able to get money for the loss of data unless you could prove that the company shipped defective drives with malice of forethought, and maybe not even then.
Caveat Emptor, IANAL.
It occurs to me that what the Linux community needs is not another hacked-up KDE knock-off, but a real ground-up GUI. By GUI, I don't mean an X11 WM, I mean a complete GUI. Some lessons can be learned from Mac OS X's graphics system.
Point 1: Dump X11 entirely. It's a lot easier to write libraries to display X11 apps in a different environment than it is to make X11 into a modern graphics environment. Its development began 18 years ago (released 14 years ago), and frankly, its age shows, both in performance and in functionality.
Point 2: OpenGL compositing a la Quartz Extreme. Windows become patterns mapped onto a plane. 3D graphics are tightly integrated into the same screen model.
Point 3: With the exception of bitmaps (which you map as a pattern), draw all the 2d windows using 3d primitives, say as a variant of splines that have thickness, located just in front of a 2d plane.
I'm not sure how hard this would be, but the basic thinking behind this idea is to take a traditional PDF or PostScript-style bezier curve model and map it into 3d primitives so that it can be rendered in hardware.
I suspect that such a design may go farther than is practical given current graphics hardware speeds, but if someone were to write such software, eventually the hardware would catch up and such a thing would then become practical, assuming it isn't already.
Point 4: Do not use a client-server model. It made sense in 1984. It doesn't make sense in 2002. Most people don't have graphical terminals connected to big centralized servers these days. A client-server model can easily be grafted onto a local model if it is designed correctly. By contrast, local communication via a client-server model tends to cause a speed penalty.
Before you ask, no, I don't have the time to design such a system, and it would be a conflict of interest if I did. That having been said, I certainly think it would be cool if someone pulled it off.... :-)
Now figure that 1% of those people are going to -reply- to the message. Guess where the replies are going to go? That's right. To him. Guess what a lawyer is going to do when he finds out that someone is claiming to be him?
Can you say fraud, defamation through identity theft, theft of computing resources, and best of all, since the automated tagging of email with information abut the sender is designed for the purpose of making it easy to track the creator of written messages, which is necessary for protection of copyright, hell, they're even violating the DMCA. :-p
So in a perverse way, by keeping this guy on the blackhole list, his ability to take action against people who falsify their identity (which -is- illegal) is weakened, and as such, the blackhole list is inadvertantly hurting the cause that it is trying to promote.
Of course, this would not be true in the non-lawyer case, and it's kind of hard to special case things like this for one person, which is why the rules are written in the way that they are. And that should be the argument being made against this semi-open relay.
A good counter-example would be a million dollar donation to overturn an anti-gang law, one of those that defines a gang go be any group of three or more people under 21 out after 8 p.m. Most of us would probably agree that such laws should be overturned even if you couch it as an "anti-violence" law.
I recall being told of auction and sale activity going on on the UnderNet back when I was in high school, which would make it no later than June of '95, and since it was obviously established when I heard about it... you do the math.
Back about a year ago, Taco Bell offered to give free tacos for a day if the Mir space station (then decomissioned) hit a particular target (floating in the ocean... Pacific Ocean, I think, but maybe Indian Ocean) when it fell out of space.
The joke was that if they strap boosters onto satellites, then one would assume that no satellites will fall, thus there's no chance for free tacos in the future. Of course, this really doesn't affect satellites that are decomissioned for other reasons, like obsolescence, nor was the Mir a satellite. Regardless, though, it's funny, if a bit inaccurate. :-)
That and the fact that the external tank, unlike the SRBs, if memory serves, isn't reusable. The paint costs money, serves no useful purpose (like it's really going to rust while it sits on the pad...), and hurts the fuel economy. No brainer. :-)
About as easy as finding an earth ground at 36,000 feet.
Worse. AFAIK, the INIT loading code used in the startup process is still 68k code even in 9.2.x. As I understand it, it would have been impossible to change it without breaking existing extensions in incompatible ways.
iPaq is a family of machines ranging from desktop s to handhelds with a variety of processors, so you're both right, IIRC.
PCI devices can do DMA, too. AGP probably does DMA differently, but PCI most assuredly supports DMA transactions between PCI devices and the memory bus. If it didn't, your hard drive performance would be no faster when you turn UDMA on.
There used to be VCRs from Panasonic, probably others, that would do standards conversion for PAL/NTSC. Now SECAM, yeah, that kind of... umm... sucks. But for PAL, it really wasn't that hard.
Of course, VHS LP is generally actually worse quality than SLP due to the way the tracks end up overlapping. SLP moved to narrower heads to remove the problem, but this prevented recording LP in a compatible way, if memory serves.