Actually, for an ordinary phone line, since it is now considered an essential, they have to pay you for downtime on the actual phone line. Otherwise they can get in trouble because you had no access to emergency contacts (911, Police, Fire,...) while you had phone service. Of course, you can just not have phone service and they don't owe you anything, but if you do have service and it doesn't work, they have to reimburse you.
I know, it happened to me this past summer. Had no phone for 4 days. Of course, their reimbursement rate was pennies a day.
If I remember correctly there was a legal case on this issue. The judge decided that since you payed money for the software (either to purchase or license), that you expected it to do _something_. So, that section of the license made no sense, especially since it was packaged inside the box so you couldn't review it before paying money expecting it to do something.
This isn't so much about the first case of a bug being found. What happens when the bug is known to the manufacturer and they don't fix it? Shouldn't they be held liable for the damages incured due to the known defect. According to your logic, it'd be like a car manufacturer not being liable if the car is known to explode when it's turned on. Obviously the first time it happens, you can't say that the manufacturer knew. But, as soon as it happens more than once, you can pretty much be sure the manufacturer knew.
I believe you are interpreting the RFC's usage of protocol. It means you could use HTTP over say IPX. SMTP runs on TCP and while SMTP is a protocol, they are referring to the actual network transport protocol, be it IPX, AppleTalk, TCP. They are just saying you can run it on any sort of network system as long as you can guarantee a reliable connection.
Honestly, the 220Mhz band was never used for much. For local stuff, 2m works wonders, for metro areas, 70cm is great. 1.25m just didn't quite fill a niche and the equipment was really expensive.
The only thing that 220Mhz is going to be used for by the club I am a member of is PBBS forwarding. There are a few FM repeaters, but PBBS is about the only thing on 220, at least here.
Well, if they are trying to get the 70cm amatuer band, they most likely won't get it. For those who don't know, that's roughly 440MHz. It has become the next focus of local amatuer activity since 2m (147Mhz) is getting full of repeaters. Granted the FCC could just give it away anyway, but considering how us amatuers like to fight to keep our bands (read really hate when people try to take them claiming they aren't put to use), I doubt any company will ever get it.
Also, I bet the ARRL server won't be up for quite sometime. Yes, they are a big radio group, but internet wise slashdot probably blew their bandwidth cap for the next millenium.
You are looking at two different things though. Pinging a machine is okay. Attempting to connect to every possible port on a machine is not ok. The first is a standard test for availability of the system, the second is an obvious sign that you are looking for something to mess with.
Exactly, you would need a form of dialup to send your request, so your upload speed is dictated by your modem. With a V.90 modem, the 56k is only downstream. Due to the way V.90 works, the sending end of the 56k stream has to have a digital line (such as a T1/ISDN/PRI). So, you could only get 33.6k upload. 33.6k is the fastest a modem can go unless one end is digital.
Hmm, only HF radio I can think of that costs tens of thousands of dollars, is the Collins KW-1 that my radio club has sitting in it's club house, slowly being repaired.
And lets just kindly forget than the majority of the radio-based technology that is in commercial use was pioneered by Amatuer radio operators and that the bands we are given, yes, look at my nickname, were given to us because they were deemed unusable for any real purpose, until we got them. Now every amatuer band is busy with activity.
You may think Amatuer radio is a thing of the past, but I ask you to find a few local hams and visit them. You will find that in most areas, it's not just using the same old technology, but rather we are inventing new ways of using our bandwidth. I mean, we don't have the experimental section of our bands for nothing.
Actually, I know of many different DBs, but in this case, modifying the data would be simple through the use of SQL simply because there are already many programs that can communicate with say a Postgres server.
I'm not looking to use SQL for a root server, just for people who see the need to have it easy to update.
Why is SQL such a terrible idea? Yes it adds a bit of complexity to the code, but it's not nearly as complex as one would like to think. Also, why does the inclusion of a SQL backend mean you can't use a cache? I in no way implied that the cache should be done away with. The cache is the one part of the system that makes it extremely fast. Now, when the cache misses, yes, there will be a penalty for doing a lookup instead of searching a tree in RAM, but the added flexibility of being able to change the zone information and have it update automatically outweighs that cost for me.
Now, if you are running thousands and thousands of domains on one nameserver, with BIND your startup time is lengthened as it parses each zone file and loads it into RAM. With a SQL backend you wouldn't need to spend time loading the data into RAM. Also, most RDBMS cache queries anyway, so doing a lookup against data that hasn't changed should be just as fast as hitting from a RAM based system.
Maybe it's not the perfect idea for a root server or a extremely heavy usage server, but for a ISP or someone with a large amount of domains constantly changing information, you could provide access to the customer to modify their domain info and the server wouldn't have to be restarted. I see that as a benefit. I don't want a text file to be generated as a intermediary.
Funny you should mention the cache. I've actually been tossing that around with the ECECS department at my college. We're looking at a few different methods for storing it in RAM. BIND uses a red-black tree for the cache, and that should be pretty efficient, but we're wondering if there isn't a better way. I'm still putting in basic code to handle responding to requests properly and such. It answers to general things, but some of the not so commonly used things need to be implimented. Cache is coming though.
Ok, I knew someone would that one out. And yes it is better. But it can be a pain to maintain, just like BIND. Why does everyone thing DNS zone's must be contained in flat text files? I would like to see a nice SQL backed system. And yes, I've read up on BIND 9, and I really don't want to have to write my own SQL interface to the programming hooks given to make it work. I want it to compile and function.
(As a side note, that feature is part of the reason I've been researching DNS. And yes, my personal project does include SQL backed lookups. No it is not ready for anyone to look at.)
I have yet to find the great reason of why everyone uses BIND. I've been working on my own DNS server just for kicks. The protocol itself is trivial. It can be handled so easily, but yet, if you look at BIND's source code, you can't tell what is going on at all. So, why does everyone continue to use it? Or better question, why hasn't someone written a better alternative?
Actually, I grabed the eml file, un mime encoded the attached exe and gunziped it up on my site. If someone wants to disect it, feel free. It's at http://www.kc8apf.net/virus/readme.tgz
If i'm not mistaken, Linux was actually based on the POSIX standard, not the System V kernel. System V has things that are not in POSIX. Because it was based on a standard, the actual implimentation of the kernel itself is unique.
You are likening WINE to be a OS rip-off of Windows since it uses the same API. WINE is far from an OS, even though it uses the same API.
>Granted, the class interruption notion is pretty legitimate - simply put, there shouldn't be anything in a high school student's life that's worth being paged or called in the middle of the day about - these are school children, for Christ's sake.
Actually, my junior and senior year of high school, I was the only technician for a local ISP. As such, I had a pager. Of course, my school wouldn't allow me to have it in school, even on silent mode, so I left it in the car. There were a few days where everything died and they ended up calling the school's office so I could tell them how to fix it.
So, there are some legitimate uses of pagers in school. Now cell phones are a bit extreme.
>They have not granted you license to download (read this as "save") and redistribute any of their IP.
But as we all know, every modern internet browser downloads and saves a copy of the pages to your hard drive. So, is this violating the license? As for redistributing, isn't looking at the local copy a form of redistribution. I know i'm off on a tangent, but this is how companies will try to pass off their license agreements so they can squeeze the money from my nearly empty pockets a bit more.
I got hired at the college's IT department to administrate the faculty/student UNIX box meant for programming and web page hosting. A pretty good job for a college freshman. Anyway. The way UC has the IT setup is this. UCit is a commerical company owned by the non-profit school. So basically, UCit is contracted by the university to do the work for them, but UCit can make money this way. It has other benefits for the university, but that's not the point. Basically student employment is limited to helpers, people to assist the higher ups in their jobs, and to do the grunt work (ResNet setups). My job isn't too bad as I only have one direct boss, but the pains of administration are there. Each section runs on its own little setup of hierarchy. So in order to setup any sort of student run IT, deals would have to be made with each and every level of UCit. Not an easy task. I have been making progress in opening doors though. They are being pretty trustworthy in me. I've been given access to a lot of the more secure systems and have root access to a few of the servers. Overall, they like having the help, but wouldn't want to turn it over to completely students. Now if only they would listen to me about their password management. Well, the probably won't now, since I crashed my box this morning by accident.
I found a copy of some C version of the software at http://www.beau.lib.la.us/~jmorris/linux/cuecat/. They're intended for Linux (duh!) but I would think one could modify it. All I want is to have the barcode decoded. Would be really useful for say, UPS tracking codes. Scan, copy, paste, oh that's where my package is.
Now, if only I could find a windows alternative. I tried writting one, but screwed up the encoding somewhere. Oh well. Guess I actually need to start learning languages.
Slashdot Mirror
Actually, for an ordinary phone line, since it is now considered an essential, they have to pay you for downtime on the actual phone line. Otherwise they can get in trouble because you had no access to emergency contacts (911, Police, Fire,...) while you had phone service. Of course, you can just not have phone service and they don't owe you anything, but if you do have service and it doesn't work, they have to reimburse you.
I know, it happened to me this past summer. Had no phone for 4 days. Of course, their reimbursement rate was pennies a day.
If I remember correctly there was a legal case on this issue. The judge decided that since you payed money for the software (either to purchase or license), that you expected it to do _something_. So, that section of the license made no sense, especially since it was packaged inside the box so you couldn't review it before paying money expecting it to do something.
This isn't so much about the first case of a bug being found. What happens when the bug is known to the manufacturer and they don't fix it? Shouldn't they be held liable for the damages incured due to the known defect. According to your logic, it'd be like a car manufacturer not being liable if the car is known to explode when it's turned on. Obviously the first time it happens, you can't say that the manufacturer knew. But, as soon as it happens more than once, you can pretty much be sure the manufacturer knew.
I believe you are interpreting the RFC's usage of protocol. It means you could use HTTP over say IPX. SMTP runs on TCP and while SMTP is a protocol, they are referring to the actual network transport protocol, be it IPX, AppleTalk, TCP. They are just saying you can run it on any sort of network system as long as you can guarantee a reliable connection.
Honestly, the 220Mhz band was never used for much. For local stuff, 2m works wonders, for metro areas, 70cm is great. 1.25m just didn't quite fill a niche and the equipment was really expensive.
The only thing that 220Mhz is going to be used for by the club I am a member of is PBBS forwarding. There are a few FM repeaters, but PBBS is about the only thing on 220, at least here.
Well, if they are trying to get the 70cm amatuer band, they most likely won't get it. For those who don't know, that's roughly 440MHz. It has become the next focus of local amatuer activity since 2m (147Mhz) is getting full of repeaters. Granted the FCC could just give it away anyway, but considering how us amatuers like to fight to keep our bands (read really hate when people try to take them claiming they aren't put to use), I doubt any company will ever get it.
Also, I bet the ARRL server won't be up for quite sometime. Yes, they are a big radio group, but internet wise slashdot probably blew their bandwidth cap for the next millenium.
I know this is pretty obvious, but if everyone turns off sharing of files, then nothing will be available to download.
You are looking at two different things though. Pinging a machine is okay. Attempting to connect to every possible port on a machine is not ok. The first is a standard test for availability of the system, the second is an obvious sign that you are looking for something to mess with.
Exactly, you would need a form of dialup to send your request, so your upload speed is dictated by your modem. With a V.90 modem, the 56k is only downstream. Due to the way V.90 works, the sending end of the 56k stream has to have a digital line (such as a T1/ISDN/PRI). So, you could only get 33.6k upload. 33.6k is the fastest a modem can go unless one end is digital.
Hmm, only HF radio I can think of that costs tens of thousands of dollars, is the Collins KW-1 that my radio club has sitting in it's club house, slowly being repaired.
And lets just kindly forget than the majority of the radio-based technology that is in commercial use was pioneered by Amatuer radio operators and that the bands we are given, yes, look at my nickname, were given to us because they were deemed unusable for any real purpose, until we got them. Now every amatuer band is busy with activity.
You may think Amatuer radio is a thing of the past, but I ask you to find a few local hams and visit them. You will find that in most areas, it's not just using the same old technology, but rather we are inventing new ways of using our bandwidth. I mean, we don't have the experimental section of our bands for nothing.
>God engineered us.
Whew, talk about trying to start a flamewar. This borders on a vi vs emacs.
One question though, once you do a dynamic update to your domain, does the update get committed to the zone file?
Actually, I know of many different DBs, but in this case, modifying the data would be simple through the use of SQL simply because there are already many programs that can communicate with say a Postgres server.
I'm not looking to use SQL for a root server, just for people who see the need to have it easy to update.
Why is SQL such a terrible idea? Yes it adds a bit of complexity to the code, but it's not nearly as complex as one would like to think. Also, why does the inclusion of a SQL backend mean you can't use a cache? I in no way implied that the cache should be done away with. The cache is the one part of the system that makes it extremely fast. Now, when the cache misses, yes, there will be a penalty for doing a lookup instead of searching a tree in RAM, but the added flexibility of being able to change the zone information and have it update automatically outweighs that cost for me.
Now, if you are running thousands and thousands of domains on one nameserver, with BIND your startup time is lengthened as it parses each zone file and loads it into RAM. With a SQL backend you wouldn't need to spend time loading the data into RAM. Also, most RDBMS cache queries anyway, so doing a lookup against data that hasn't changed should be just as fast as hitting from a RAM based system.
Maybe it's not the perfect idea for a root server or a extremely heavy usage server, but for a ISP or someone with a large amount of domains constantly changing information, you could provide access to the customer to modify their domain info and the server wouldn't have to be restarted. I see that as a benefit. I don't want a text file to be generated as a intermediary.
Funny you should mention the cache. I've actually been tossing that around with the ECECS department at my college. We're looking at a few different methods for storing it in RAM. BIND uses a red-black tree for the cache, and that should be pretty efficient, but we're wondering if there isn't a better way. I'm still putting in basic code to handle responding to requests properly and such. It answers to general things, but some of the not so commonly used things need to be implimented. Cache is coming though.
Ok, I knew someone would that one out. And yes it is better. But it can be a pain to maintain, just like BIND. Why does everyone thing DNS zone's must be contained in flat text files? I would like to see a nice SQL backed system. And yes, I've read up on BIND 9, and I really don't want to have to write my own SQL interface to the programming hooks given to make it work. I want it to compile and function.
(As a side note, that feature is part of the reason I've been researching DNS. And yes, my personal project does include SQL backed lookups. No it is not ready for anyone to look at.)
I have yet to find the great reason of why everyone uses BIND. I've been working on my own DNS server just for kicks. The protocol itself is trivial. It can be handled so easily, but yet, if you look at BIND's source code, you can't tell what is going on at all. So, why does everyone continue to use it? Or better question, why hasn't someone written a better alternative?
Actually, I grabed the eml file, un mime encoded the attached exe and gunziped it up on my site. If someone wants to disect it, feel free. It's at http://www.kc8apf.net/virus/readme.tgz
Also, this will only be up till 5pm today.
If i'm not mistaken, Linux was actually based on the POSIX standard, not the System V kernel. System V has things that are not in POSIX. Because it was based on a standard, the actual implimentation of the kernel itself is unique.
You are likening WINE to be a OS rip-off of Windows since it uses the same API. WINE is far from an OS, even though it uses the same API.
>Granted, the class interruption notion is pretty legitimate - simply put, there shouldn't be anything in a high school student's life that's worth being paged or called in the middle of the day about - these are school children, for Christ's sake.
Actually, my junior and senior year of high school, I was the only technician for a local ISP. As such, I had a pager. Of course, my school wouldn't allow me to have it in school, even on silent mode, so I left it in the car. There were a few days where everything died and they ended up calling the school's office so I could tell them how to fix it.
So, there are some legitimate uses of pagers in school. Now cell phones are a bit extreme.
>They have not granted you license to download (read this as "save") and redistribute any of their IP.
But as we all know, every modern internet browser downloads and saves a copy of the pages to your hard drive. So, is this violating the license? As for redistributing, isn't looking at the local copy a form of redistribution. I know i'm off on a tangent, but this is how companies will try to pass off their license agreements so they can squeeze the money from my nearly empty pockets a bit more.
I got hired at the college's IT department to administrate the faculty/student UNIX box meant for programming and web page hosting. A pretty good job for a college freshman. Anyway. The way UC has the IT setup is this. UCit is a commerical company owned by the non-profit school. So basically, UCit is contracted by the university to do the work for them, but UCit can make money this way. It has other benefits for the university, but that's not the point. Basically student employment is limited to helpers, people to assist the higher ups in their jobs, and to do the grunt work (ResNet setups). My job isn't too bad as I only have one direct boss, but the pains of administration are there. Each section runs on its own little setup of hierarchy. So in order to setup any sort of student run IT, deals would have to be made with each and every level of UCit. Not an easy task. I have been making progress in opening doors though. They are being pretty trustworthy in me. I've been given access to a lot of the more secure systems and have root access to a few of the servers. Overall, they like having the help, but wouldn't want to turn it over to completely students. Now if only they would listen to me about their password management. Well, the probably won't now, since I crashed my box this morning by accident.
I found a copy of some C version of the software at http://www.beau.lib.la.us/~jmorris /linux/cuecat/. They're intended for Linux (duh!) but I would think one could modify it. All I want is to have the barcode decoded. Would be really useful for say, UPS tracking codes. Scan, copy, paste, oh that's where my package is.
Now, if only I could find a windows alternative. I tried writting one, but screwed up the encoding somewhere. Oh well. Guess I actually need to start learning languages.