Just because Canada has made the RIAA's pound of fless into an official tax does not make it FREE.
Would you rather have the taxes in the US rise to absorb the problem, which the RIAA still gets paid? That's extremely "out of sight, out of mind".
So should it be free? Remember, there are people at the other end of this - artists. While I disagree with the RIAA's tactics, and the entire way the operate, I don't disagree there should be some kind of organization.
The record companies themselves are somewhat of a necessary evil. You can't walk into a bank and get a $1-millon loan to produce a record, that you may or may not be able to pay back. Record companies do this all the time, and a large percentage of bands can't actually pay back the advance. They basically bank on the fact that a small percentage is making a ton of money, giving them the ability to spend a few hundred thousand on a band that doesn't 'make it', and not care.
As far as this P2P stuff, the RIAA screwed themselves by not embracing it when it first started, and making it a profitable business. Think if Napster had charged a monthly access fee to use it (which I think was one of their original intentions). The RIAA could have used that to pay for royalties, and still would have been able to keep track of statistics for both royalty payment and popularity purposes*.
Instead, they ignored it, and litigated against it. And are now litigating against their customers (though, their argument is they aren't customers). I'm pretty sure that anyone who's just been forced to pay $12,000 to the RIAA is not going to be paying another $20 for a CD anytime soon.
As a Canadian, I really don't have a problem paying this 'CD tax' if it means it's legal for me to download the music I want without having to buy a CD full of stuff I don't. It's really not the best way to do it since it both affects people that are using CD's for other purposes, and misses the people that don't put music on CD's (and just store them as MP3's).
* They could get direct-from-consumer information about what people are listening to. Right now, the closest they can get is by looking at things like request shows - though that's only counting votes from people willing to call a 1-900 number. That's some seriously valuable information.
I didn't actually write any OPC code, though that would have been handy.
What I wrote is basically a messaging server, that uses a fairly simple protocol to talk over TCP sockets. Clients hook in, and can provides inputs, outputs and variables (there's really not much distinction between them, except variables have the option of being stored in an SQL database, and inputs can only be set by the client that provided them). Clients can request any value at any time, or request to be notified of certain values.
I have a client written to gather input from my hardware (opto22), provide output, another that logs values to a database, one that graphs values to rrdtool, one that compares values against alarm setpoints, one that dispatches to people based on time-of-day when an alarm is activated, etc.
Writing an OPC bridge would not be too difficult, I don't think, depending on how hard it is to use the OPC protocol. I started on a modbus interface (never finished it since I don't need it right now), and have plans to make a Profibus interface.
The system is pretty simple, but at the same time it's pretty powerful. I started developing it in March, and have had the vast majority of it running for a couple months now. Since it's so modular, it's very easy to test incrementally, a lot of the design was based on a rapid development time.
The user interface is web-based, and it's designed from the start to be remotely configurable and viewable. Alarms, variables, settings, logging and graphing options, etc, can all be set from the GUI. Some of the system setup is also done from the GUI, but control programs (ie, the things that actually 'do' system control) have to be written and set up manually, although I'm sure that could be done through GUI as well, I just haven't bothered yet.
I've been too busy lately to put any effort into thinking about how to release it to open source, but it's quite possible I will. Now- most of the code I've written is in PHP, which I'm sure will turn a lot of people off. In reality, using PHP has allowed me to write solid code very rapidly, and running on linux on modern hardware, performance is not an issue at all. Python would be my next choice, but I didn't know it well enough and thought it would take to long to learn and develop the system at the same time. C is out mostly for the fact that it would take at least twice as long to write the same quality code (and I'm sure some people will aruge that point).
PuffinPLC has quite a bit of work done, and I really did consider using and contributing to their stuff, but last I checked, they had been going for couple years, and were still only predicting the first usable release would be in a year. I was looking for a SCADA system for a specific task - they're trying to build one that can replace big commercial packages.
Anyways, if there is enough interest, I would definately be willing to open source it. Likely there could be some performance boosts by rewriting some stuff, espessaily the server, in another language, but I'm going for a stable, working solution first.
Has anyone followed up or concluded anything regarding the possibility of the power grid's SCADA systems (which habitually run a stripped down Win2K)
I've still never understood this. I think most systems are actually based on NT, but maybe they are migrating to 2k now. Either way, the fact that these automation systems are based on a system like windows is very strange to me. OPC (the protocol used to communicate between sensors and databases) is based on DDE (or OLE), which seems so incredibly strange to me.
I've been developing a linux-based SCADA system. I took a look at quite a few systems, and I just didn't feel comfortable running any of them for a number of reasons. Stability and security being two major issues. Another was cost - these are being deployed in small installations, mostly for remote monitoring, which wouldn't typically have a SCADA system due to the cost. Between a mixture of existing open source software, some nice hardware, and in-house development (mostly me), the system has cost us about $20k to develop, which is less than it would cost to licence most software per site.
Anyways, that was a bit OT, but the point is, very early on we decided that deploying on windows would be a pain. These are all remote installations, with no one on site that can service them. If something goes down, I want to be able to remotely fix it as much as possible. I just don't feel comfortable deploying a remote windows system and relying on it to stay running, not to mention the fact that people's health could be affected (water treatment). To me, windows is not the proper platform to be using for this situation.
When I had a land-line at the house I didn't own an answering machine. Caller ID let me know who called and I could decide if a return call was warranted because once a message is left the onus is on you to call back.
If everyone thought like you, no one would ever talk to each other.
Why is leaving a message such a bad thing? At home, I have an answering machine (CID is too expensive, I pay Bell enough money as it is). If I'm there, and not busy, I answer. Otherwise, I let the machine get it. I can even hear the message as people are leaving it - if I was busy, but hear it's someone I want to talk to, then I can answer it. If someone doesn't leave a message, then it obviously wasn't important. If they do, then I can call them back and deal with it when it's convienent to me.
On my cell I have both CID and voice mail. I have my cell with me pretty much 24/7. If I'm working, and out at a client's site, for example, I won't usually answer when one of my friends calls, but if it's the office, then I will. At the same time though, like you, I don't give out my cell number to very many people. If it's for work, people can call the office and they can patch them through to me.
It's very easy to get a hold of me, but at the same time, it doesn't intrude on my life (except when someone calls early in the morning on Saturday and wakes me up -- though I just turn the ringer off and go back to sleep).
IT could very well be that they're saying that queries for www.sometyponame.com will return an IP address, but sometyponame.com will return a negative result.
That's another misuse of standards though. The "www" prefix is just a 'common' way of setting up websites. It's not required. It's no different from any other zone, for that matter.
If Verisign is going to only do these for 'www.' prefixed records, it may be a bit less of a problem, but it's still a problem. Among the things I can think up off the top of my head (I'm sure other people have mentioned these, and there are many more)
Proxies would be caching extra data
Web applications (or non-web) that validate user input by checking for existance of a domain are going to break
For sites that don't have a www prefix, it could confuse users, since they'll see a (different) browser specific error message.
Obviously, lockin to a certain vendor - suddenly verisign decides who you use for searches, and what happens when you make a typo, instead of your browser settings.
this is just YASTAPTDE (yet another solution to a problem that doesn't exist)
Nothing quite as annoying as a network that cancels a great show like Futurama and then airs something like that. It's bad enough they show reality show after reality show..
"Fox turned into a hardcore pornography channel so gradually I hardly noticed"
One of the most common variations of the phony invoice scheme are solicitations disguised as invoices. These documents, which are actually solicitations for the purchase of goods or services, are carefully designed to look like legitimate invoices for goods or services ordered and received.
I remember getting a few of these from Verisign. Our bookkeeper almost paid one, then decided she should ask me first, when I of course said to totally disregard it. Not that I would have approved the transfer request anyways.
It would be very unfortuntate if his real phone number were to accidentally get entered into a fax machine field. Some of those junk faxes get sent at all hours of the night, that would be really annoying.
That'd probably make recognition work better, but I'm not sure people will wait in endless lines on top of the metal detectors and other security procedures to be asked to remove any offending headgear, jewelry, etc. to stare into a camera.
It could be right at the same time as the metal detector. "Walk through please. Take off your hat, look at the camera, sir, thank you."
They also get a mugshot of that person that day, that can be used to later match to security cameras, or whatever.
so that Finance people can restrict access to sensitive salary documents and such.
Is saving sensitive documents in a directory that's read/write restricted to people in the Finance group not good enough? It seems to work just fine here.
it requires configuring Windows Server 2003 and ensuring both the creator and reader of the document have access/accounts on the Rights server.
So you have to upgrade to server 2003 to take advantage of this, and lock in further to one company. This sounds like a bad solution to a problem that's already been solved for years..
This is likely a very bad move on MS's behalf - most companies will probably not want to upgrade, knowing that it will break their compatibility with others. Unless it offers some real compelling reasons to upgrade, will people even bother?
Even the dumbest PHB's have a no-brainer here: spend lots of money upgrading, and lose the ability to exchange documents to/from many other companies, or save the money, continue being able to use whatever they currently have, and continue being able to communicate with other companies.
Once an infected machine is found, it should be blocked from the net immediately, physically disconnected, shut down, and reinstalled from scratch, including all applications.
So you'd have no problems if you were living in a dorm, and one day a syadmin told you that you have to reinstall your machine and you're not allowed back on the network until you do? It's one thing to apply this sort of strategy to corporate networks, it's quite another in a univeristy residence.
Sure, for a while. Back in the 70's, I'm sure they figured that 12-bit barcodes were plenty. According to the article, they're now starting to run out.
It's called thinking ahead: Design a system that will last at least twice as long as you think you'll need. Yeah, 64 bits is incredibly huge. They're talking about serializing every product made by every company with a unique id. So say we plan on it lasting 100 years. That's still like 184,400,000,000,000,000 unique id numbers, per year (64bit). Actually, that does seem pretty damn excessive.
But who knows - maybe there will be other uses for this space as well. Using a few bits to encode sizing/weight information, color, hazards, if it's flamable, disposal instructions, etc, to allow simpler devices to read it without having to link to a database somewhere. A good example of this is the licence scanners some bars use: they swipe your drivers licence, and it shows the info encoded on the card, and they compare it against the info printed on the card. It doesn't link back to a database to verify anything, its just a simple device to help prevent fake id's. Same sort of thing could apply here for shipping purposes, and probably lots of other things, too.
It's a lot easier to just use 96 bits now, than switching to 64 now, and then having to switch to 96 again in a few (or many) years.
So all that is needed to fix the system is for any patent applicant to pay at least 100000 deposit when applying (I think that it should be more). If the application succeds he gets back 80% filled up further by government small business innovation grants (they are around 0.5-1M$ in the US for example). If the app fails he gets shit. Clerks are payed per application submitted and application failed and they are payed at least 10000 for application whacked. They are not payed for applications that have been accepted.
While you have some good ideas, I'm not sure this will solve anything.
Like someone else pointed out, $100k for an application is going to be extremely hard for an inventor or small startup to come up with, considering theres a chance they won't get it back (investors are less likely to fund this). At the same time, $100k for a patent for a large company is a lot easier. And if you're talking a company like MS, it's chump change.
If they're getting paid per application rejected, then what do you think is mostly going to happen? Yes, there's going to be a lot less patents issued. The clerks don't have anything to gain from accepting an application. One of the first things that comes to my mind is the word 'Payola'. If a company like MS is applying for a patent, how hard is it for them to drop another $100k to the clerk to make sure it gets approved?
I think what is needed is to get away from the commission system altogether. I don't know a whole lot about how the patent office works, but wouldn't putting the clerks on salary get rid of all of these problems? Each patent should be independently reviewed by two different clerks that have absolutely no contact, and only granted if they both agree.
It would be nice to have some kind of public input, but that also opens things up for corruption as well, not to mention stealing trade secrets and getting an unfair jump on the competition.
I don't think your system allows anything extra... so I'm intrigued about your approach.
Using a catch-all (mail to ANY address at that domain gets forwarded) means I don't have to set up anything in an alias file or whatever. I just have to enter it, and it works. If one address gets overly-spammed, I can block that specific address, while the catch-all continues to work.
Using a regular domain (domain.com) for that purpose just means you also get all the dictonary spam. Often spammers will try info@ sales@ administrator@ bob@ etc. If it's a sub-domain, they're a lot less likely to try that, if at all. If you do end up getting a large-scale dictionary attack on the subdomain, you can just make a new one. Though I think those large-scale attacks are targeted - one of my friends works at an ISP, and he says they get them quite a bit, where they just try thousands of common usernames.
Basically, using a sub-domain makes a bit less work, and gives you a bit more protection, if you need it.
get your own domain and your own email server and go that way.
I set up a subdomain from one of my domains, that forwards all mail to one of my real addresses. Everytime I have to use my email, I use something at that subdomain, for example, slashdot@catch.domain.com. If I get spam to that address, 1) I can block the address without affecting anything else, and 2), I know who got my name on the list.
Particularily useful when you have to register to get access to download or use something. I'm careful about giving out those addresses anyways, and always "opt-out", so I get a surprisingly small amount of spam to them. I've yet to recieve spam for an address I gave to a company that said it wouldn't spam me.
Re:dan bernstein's position on this
on
DNSSEC: Good Enough?
·
· Score: 4, Insightful
djb's points about dnssec seem reasonable, but his proposed solution `nym' seems quite nutty.
in my experience, djb's stuff has always been interesting. He has good ideas about things, and they work nicely, but his implementations are just wacky. Don't get me wrong, I use a lot of it (qmail and daemontools, namely), but the way it fits together, and the way he does things.. it's out there. qmail in particular.. there's like 30 programs messages run through on their way.
Although I use daemontools, in order to change pathnames (since I wanted to put it in it's own path), I had to manually change a whole bunch of things hardcoded in the source. His build system is also very cooky.. it works, it's just totally different from the way you compile anything else and thus takes a lot of learning to figure it out.
I've never tried his DNS implementation, but I've heard it works nicely.
One of the interesting aspect of downloadable music I've heard is the artists complaining that they want people to experience the full album, as a whole, while a lot of people only want to hear singles. I think there were even a couple bands that pulled their music off of iTunes because they didn't like people just getting the singles.
What is your take on this situation? Should people be forced to buy a full album just to get one song (or ocasionally two) they like, or should they be buying the album with the theory that they liked the single, they'll like the rest?
Has "the album" been ruined by the filler that so many of the top40 one-hit-wonder bands put on their albums? What needs to be done to make people willing to try entire albums (ratings, reccomendations, better music..)?
Doesn't the creation of Linux tools for interfacing with Windows just further validate a needlessly Microsoftian System?
One of the steps towards linux-only is getting the servers on linux. Linux servers are becoming very popular, but that doesn't mean that every place has them yet, let alone linux workstations.
Many IT departments have already replaced some (or all) windows servers with linux servers, running Samba to provide the same services to their workstations. If Samba didn't exist, they wouldn't be switching their servers to it, since it would be incompatible with their existing windows servers. Nobody is going to upgrade if it means they lose features (namely, all the features samba provides).
There is just beginning to be a move towards linux on the desktop, and there have been a few articles on/. about it recently. My personal view is that it's not quite there yet, but close. I just work at a small company, but likely within a year I will have linux on the desktops. Some companies are beginning to roll out linux workstations, but not that many. And certainly not many enterprises.
You even say it yourself:
I've already gone 100% Linux on any networks I can.
Why not all of them? Without samba, it would basically be either 100% linux networks, or 0% linux networks. At the most, linux would be limited to being a router, NAS, webserver, etc.. which isn't bad, but it's leaving a monopoly on a fairly critical service (authentication) to one platform.
Slashdot Mirror
Would you rather have the taxes in the US rise to absorb the problem, which the RIAA still gets paid? That's extremely "out of sight, out of mind".
So should it be free? Remember, there are people at the other end of this - artists. While I disagree with the RIAA's tactics, and the entire way the operate, I don't disagree there should be some kind of organization.
The record companies themselves are somewhat of a necessary evil. You can't walk into a bank and get a $1-millon loan to produce a record, that you may or may not be able to pay back. Record companies do this all the time, and a large percentage of bands can't actually pay back the advance. They basically bank on the fact that a small percentage is making a ton of money, giving them the ability to spend a few hundred thousand on a band that doesn't 'make it', and not care.
As far as this P2P stuff, the RIAA screwed themselves by not embracing it when it first started, and making it a profitable business. Think if Napster had charged a monthly access fee to use it (which I think was one of their original intentions). The RIAA could have used that to pay for royalties, and still would have been able to keep track of statistics for both royalty payment and popularity purposes*.
Instead, they ignored it, and litigated against it. And are now litigating against their customers (though, their argument is they aren't customers). I'm pretty sure that anyone who's just been forced to pay $12,000 to the RIAA is not going to be paying another $20 for a CD anytime soon.
As a Canadian, I really don't have a problem paying this 'CD tax' if it means it's legal for me to download the music I want without having to buy a CD full of stuff I don't. It's really not the best way to do it since it both affects people that are using CD's for other purposes, and misses the people that don't put music on CD's (and just store them as MP3's).
* They could get direct-from-consumer information about what people are listening to. Right now, the closest they can get is by looking at things like request shows - though that's only counting votes from people willing to call a 1-900 number. That's some seriously valuable information.
I didn't actually write any OPC code, though that would have been handy. What I wrote is basically a messaging server, that uses a fairly simple protocol to talk over TCP sockets. Clients hook in, and can provides inputs, outputs and variables (there's really not much distinction between them, except variables have the option of being stored in an SQL database, and inputs can only be set by the client that provided them). Clients can request any value at any time, or request to be notified of certain values.
I have a client written to gather input from my hardware (opto22), provide output, another that logs values to a database, one that graphs values to rrdtool, one that compares values against alarm setpoints, one that dispatches to people based on time-of-day when an alarm is activated, etc.
Writing an OPC bridge would not be too difficult, I don't think, depending on how hard it is to use the OPC protocol. I started on a modbus interface (never finished it since I don't need it right now), and have plans to make a Profibus interface.
The system is pretty simple, but at the same time it's pretty powerful. I started developing it in March, and have had the vast majority of it running for a couple months now. Since it's so modular, it's very easy to test incrementally, a lot of the design was based on a rapid development time.
The user interface is web-based, and it's designed from the start to be remotely configurable and viewable. Alarms, variables, settings, logging and graphing options, etc, can all be set from the GUI. Some of the system setup is also done from the GUI, but control programs (ie, the things that actually 'do' system control) have to be written and set up manually, although I'm sure that could be done through GUI as well, I just haven't bothered yet.
I've been too busy lately to put any effort into thinking about how to release it to open source, but it's quite possible I will. Now- most of the code I've written is in PHP, which I'm sure will turn a lot of people off. In reality, using PHP has allowed me to write solid code very rapidly, and running on linux on modern hardware, performance is not an issue at all. Python would be my next choice, but I didn't know it well enough and thought it would take to long to learn and develop the system at the same time. C is out mostly for the fact that it would take at least twice as long to write the same quality code (and I'm sure some people will aruge that point).
PuffinPLC has quite a bit of work done, and I really did consider using and contributing to their stuff, but last I checked, they had been going for couple years, and were still only predicting the first usable release would be in a year. I was looking for a SCADA system for a specific task - they're trying to build one that can replace big commercial packages.
Anyways, if there is enough interest, I would definately be willing to open source it. Likely there could be some performance boosts by rewriting some stuff, espessaily the server, in another language, but I'm going for a stable, working solution first.
I've still never understood this. I think most systems are actually based on NT, but maybe they are migrating to 2k now. Either way, the fact that these automation systems are based on a system like windows is very strange to me. OPC (the protocol used to communicate between sensors and databases) is based on DDE (or OLE), which seems so incredibly strange to me.
I've been developing a linux-based SCADA system. I took a look at quite a few systems, and I just didn't feel comfortable running any of them for a number of reasons. Stability and security being two major issues. Another was cost - these are being deployed in small installations, mostly for remote monitoring, which wouldn't typically have a SCADA system due to the cost. Between a mixture of existing open source software, some nice hardware, and in-house development (mostly me), the system has cost us about $20k to develop, which is less than it would cost to licence most software per site.
Anyways, that was a bit OT, but the point is, very early on we decided that deploying on windows would be a pain. These are all remote installations, with no one on site that can service them. If something goes down, I want to be able to remotely fix it as much as possible. I just don't feel comfortable deploying a remote windows system and relying on it to stay running, not to mention the fact that people's health could be affected (water treatment). To me, windows is not the proper platform to be using for this situation.
If everyone thought like you, no one would ever talk to each other.
Why is leaving a message such a bad thing? At home, I have an answering machine (CID is too expensive, I pay Bell enough money as it is). If I'm there, and not busy, I answer. Otherwise, I let the machine get it. I can even hear the message as people are leaving it - if I was busy, but hear it's someone I want to talk to, then I can answer it. If someone doesn't leave a message, then it obviously wasn't important. If they do, then I can call them back and deal with it when it's convienent to me.
On my cell I have both CID and voice mail. I have my cell with me pretty much 24/7. If I'm working, and out at a client's site, for example, I won't usually answer when one of my friends calls, but if it's the office, then I will. At the same time though, like you, I don't give out my cell number to very many people. If it's for work, people can call the office and they can patch them through to me.
It's very easy to get a hold of me, but at the same time, it doesn't intrude on my life (except when someone calls early in the morning on Saturday and wakes me up -- though I just turn the ringer off and go back to sleep).
That's another misuse of standards though. The "www" prefix is just a 'common' way of setting up websites. It's not required. It's no different from any other zone, for that matter.
If Verisign is going to only do these for 'www.' prefixed records, it may be a bit less of a problem, but it's still a problem. Among the things I can think up off the top of my head (I'm sure other people have mentioned these, and there are many more)
- Proxies would be caching extra data
- Web applications (or non-web) that validate user input by checking for existance of a domain are going to break
- For sites that don't have a www prefix, it could confuse users, since they'll see a (different) browser specific error message.
- Obviously, lockin to a certain vendor - suddenly verisign decides who you use for searches, and what happens when you make a typo, instead of your browser settings.
this is just YASTAPTDE (yet another solution to a problem that doesn't exist)Hm, great example of what happens when you use GUAGE instead of COUNTER.
Nothing quite as annoying as a network that cancels a great show like Futurama and then airs something like that. It's bad enough they show reality show after reality show..
"Fox turned into a hardcore pornography channel so gradually I hardly noticed"
I remember getting a few of these from Verisign. Our bookkeeper almost paid one, then decided she should ask me first, when I of course said to totally disregard it. Not that I would have approved the transfer request anyways.
I wonder if/when the FTC will investigate SCO?
It would be very unfortuntate if his real phone number were to accidentally get entered into a fax machine field. Some of those junk faxes get sent at all hours of the night, that would be really annoying.
Drew Auman
/. effect can you think of?
113 Hunt Club Dr
Copley, OH 44321-2759
330-666-7625
Just to save you some time.. randomly pick a couple.. it only takes a couple minutes. And what better use of the
catalog request
It could be right at the same time as the metal detector. "Walk through please. Take off your hat, look at the camera, sir, thank you."
They also get a mugshot of that person that day, that can be used to later match to security cameras, or whatever.
Is saving sensitive documents in a directory that's read/write restricted to people in the Finance group not good enough? It seems to work just fine here.
it requires configuring Windows Server 2003 and ensuring both the creator and reader of the document have access/accounts on the Rights server.
So you have to upgrade to server 2003 to take advantage of this, and lock in further to one company. This sounds like a bad solution to a problem that's already been solved for years..
Even the dumbest PHB's have a no-brainer here: spend lots of money upgrading, and lose the ability to exchange documents to/from many other companies, or save the money, continue being able to use whatever they currently have, and continue being able to communicate with other companies.
So you'd have no problems if you were living in a dorm, and one day a syadmin told you that you have to reinstall your machine and you're not allowed back on the network until you do? It's one thing to apply this sort of strategy to corporate networks, it's quite another in a univeristy residence.
Just what I need. Someone DDoS'ing my pants.
No, it's free, under the GPL, until SCO proves otherwise in a court of law.
Of course, if you pay your protection money on time, the SCO goon- excuse me, lawyers - won't have to break your leg- I mean, take you to court.
Sure, for a while. Back in the 70's, I'm sure they figured that 12-bit barcodes were plenty. According to the article, they're now starting to run out.
It's called thinking ahead: Design a system that will last at least twice as long as you think you'll need. Yeah, 64 bits is incredibly huge. They're talking about serializing every product made by every company with a unique id. So say we plan on it lasting 100 years. That's still like 184,400,000,000,000,000 unique id numbers, per year (64bit). Actually, that does seem pretty damn excessive.
But who knows - maybe there will be other uses for this space as well. Using a few bits to encode sizing/weight information, color, hazards, if it's flamable, disposal instructions, etc, to allow simpler devices to read it without having to link to a database somewhere. A good example of this is the licence scanners some bars use: they swipe your drivers licence, and it shows the info encoded on the card, and they compare it against the info printed on the card. It doesn't link back to a database to verify anything, its just a simple device to help prevent fake id's. Same sort of thing could apply here for shipping purposes, and probably lots of other things, too.
It's a lot easier to just use 96 bits now, than switching to 64 now, and then having to switch to 96 again in a few (or many) years.
While you have some good ideas, I'm not sure this will solve anything.
Like someone else pointed out, $100k for an application is going to be extremely hard for an inventor or small startup to come up with, considering theres a chance they won't get it back (investors are less likely to fund this). At the same time, $100k for a patent for a large company is a lot easier. And if you're talking a company like MS, it's chump change.
If they're getting paid per application rejected, then what do you think is mostly going to happen? Yes, there's going to be a lot less patents issued. The clerks don't have anything to gain from accepting an application. One of the first things that comes to my mind is the word 'Payola'. If a company like MS is applying for a patent, how hard is it for them to drop another $100k to the clerk to make sure it gets approved?
I think what is needed is to get away from the commission system altogether. I don't know a whole lot about how the patent office works, but wouldn't putting the clerks on salary get rid of all of these problems? Each patent should be independently reviewed by two different clerks that have absolutely no contact, and only granted if they both agree.
It would be nice to have some kind of public input, but that also opens things up for corruption as well, not to mention stealing trade secrets and getting an unfair jump on the competition.
Using a catch-all (mail to ANY address at that domain gets forwarded) means I don't have to set up anything in an alias file or whatever. I just have to enter it, and it works. If one address gets overly-spammed, I can block that specific address, while the catch-all continues to work.
Using a regular domain (domain.com) for that purpose just means you also get all the dictonary spam. Often spammers will try info@ sales@ administrator@ bob@ etc. If it's a sub-domain, they're a lot less likely to try that, if at all. If you do end up getting a large-scale dictionary attack on the subdomain, you can just make a new one. Though I think those large-scale attacks are targeted - one of my friends works at an ISP, and he says they get them quite a bit, where they just try thousands of common usernames.
Basically, using a sub-domain makes a bit less work, and gives you a bit more protection, if you need it.
I set up a subdomain from one of my domains, that forwards all mail to one of my real addresses. Everytime I have to use my email, I use something at that subdomain, for example, slashdot@catch.domain.com. If I get spam to that address, 1) I can block the address without affecting anything else, and 2), I know who got my name on the list.
Particularily useful when you have to register to get access to download or use something. I'm careful about giving out those addresses anyways, and always "opt-out", so I get a surprisingly small amount of spam to them. I've yet to recieve spam for an address I gave to a company that said it wouldn't spam me.
after installing divx..
in my experience, djb's stuff has always been interesting. He has good ideas about things, and they work nicely, but his implementations are just wacky. Don't get me wrong, I use a lot of it (qmail and daemontools, namely), but the way it fits together, and the way he does things.. it's out there. qmail in particular.. there's like 30 programs messages run through on their way.
Although I use daemontools, in order to change pathnames (since I wanted to put it in it's own path), I had to manually change a whole bunch of things hardcoded in the source. His build system is also very cooky.. it works, it's just totally different from the way you compile anything else and thus takes a lot of learning to figure it out.
I've never tried his DNS implementation, but I've heard it works nicely.
What is your take on this situation? Should people be forced to buy a full album just to get one song (or ocasionally two) they like, or should they be buying the album with the theory that they liked the single, they'll like the rest?
Has "the album" been ruined by the filler that so many of the top40 one-hit-wonder bands put on their albums? What needs to be done to make people willing to try entire albums (ratings, reccomendations, better music..)?
One of the steps towards linux-only is getting the servers on linux. Linux servers are becoming very popular, but that doesn't mean that every place has them yet, let alone linux workstations.
Many IT departments have already replaced some (or all) windows servers with linux servers, running Samba to provide the same services to their workstations. If Samba didn't exist, they wouldn't be switching their servers to it, since it would be incompatible with their existing windows servers. Nobody is going to upgrade if it means they lose features (namely, all the features samba provides).
There is just beginning to be a move towards linux on the desktop, and there have been a few articles on /. about it recently. My personal view is that it's not quite there yet, but close. I just work at a small company, but likely within a year I will have linux on the desktops. Some companies are beginning to roll out linux workstations, but not that many. And certainly not many enterprises.
You even say it yourself:
I've already gone 100% Linux on any networks I can.
Why not all of them? Without samba, it would basically be either 100% linux networks, or 0% linux networks. At the most, linux would be limited to being a router, NAS, webserver, etc.. which isn't bad, but it's leaving a monopoly on a fairly critical service (authentication) to one platform.
firewalls are like condoms for the internet