No. An American company selling in India is not subject to software patents in respect of the products sold in India because India has no software patents. An Indian company selling in America is subject to software patents in respect of the products sold in America because America does have software patents.
That's true, but what happens if I move my application servers to India, process my data there using all the patented techniques I need and then send it back to US?
Yeah it is insane, but it's just the latest in a long line of insanity. Notice how a lot of the technologies that are being touted recently are all about restricting what people can do with content. It's a growing trend, and I don't think it's right.
Just out of curiosity... Are ther any consumer rights organizations in the US? Any half-decent consumer org should be up in arms about this.
Subversion doesn't come close to being replacement for BitKeeper. Not that it's a bad tool - it just doesn't support distributed repositories at all. Different philosophy.
Subversion, of course. What else is there? RCS? CVS?
Defenders of the same point out that there are non computer-aided proofs that are also rather large and unverifiable, like the Classification of Simple Finite Groups.
That's why a different approach seems more appealing to me - humans write the proofs, computers check them. This approach is more promising, since verifying proofs is computable (well, except for some weirder logic systems), generating proofs is not (well, except for some weirder logic systems that are not very expressive).
Such proof verifiers already exist today, but they are too stupid to be used to verify non-trivial theorems. They don't understand such paper-savers as "... other cases follow from this one" or "without loss of generality...".
Of course, to allow such statements and still honestly check the proof, the verifier would have to generate some trivial parts of the proof itself - this is what human readers of mathematical papers do routinely. Are we thus back to square one (verification -> generation)? Well - proving the lemmas may be hard, but I think it's still much simpler than generating non trivial proofs.
Until you find out that you need to code most everything from scratch due to the lack of standardized libraries and frameworks, and you can throw the whole "productivity" argument out the window.
I'm curious about that, since my experience with Python is just the opposite - everything from http stack, unit testing framework to xml parsing is in the standard lib. Please name at least one area where Python standard library is lacking functionality.
Another high point is that when the government wants a skill set in the populace, it tends to be pushed a bit in schools. I would love to see the results of fifteen years of open source software use in schools in any country.
Microsoft understand this. You won't believe the pressure from them to turn universities into MS training centers. There is a constant stream of invitations to free conferences for the staff. I said free? Considering the tons of gadgets dumped at the participants they are more like 'paid'. Free books and licenses of MS software for staff and students are the norm.
Fortunately, Linux is strong where I happened to get my M.Sc. The OS-dependent subjects (Concurrent & Network programming, Operating Systems etc.) are taught on Linux. There is a.net course but it's outside the main curriculum.
honestly how many botnet operators are that sufisticated? yes some are, but most?
Perhaps even none. I was just pointing at the theoretical possibility of defeating a theoretical attack, mkay?
your also forgetting something else. Possesion of the Private key means that it is undeniable that you are in control of said bot net. in short a digitally signed order is a literal signiture of the controler of the botnet. forget the "i was hacked to" excuse or the "that was someone else's ip 24 hours ago" one. if you have the private key your signing those mesages.
The "i was hacked to" excuse still works. "I was hacked and the attacker left his stuff including the key on my computer". Not to mention the fact that any hacker able to implement this scheme wouldn't let the key sit unencrypted on his disk.
Allow one of your systems to be infected with the botnet - effectively join their network. Then sniff the network traffic to find out what IRC server and channel to join and any security codes that are necessary to control the botnet.
Yup, this might work. Until botnet creators get smart and start using asymmetric cryptography to work around this. Every bot can carry around a public key and check the received orders against it. The evil master has the private key and only he can sign the orders, thus joining the network doesn't let you order the other zombies around.
The only thing that makes me think it might not work is that it's similar to the stereotypical way of ridding the world of aliens in almost every sci-fi movie. Come to think of it, I might have gotten this idea from Independence Day.
Well, this brings the scenario closer to a fantasy movie with a powerful artifact to control an army of the undead... go figure:-)
Nice analysis David. I'd personally love to see Analog [analog.cx] (an oldie but googie) added to your table and my guess is that Urchin would be another popular one.
I'm not going to click on anything that starts with "anal" and ends with ".cx".
Poor replacement - when it comes to irritation, no install process, however tedious, is going to replace an annoying phone call! Microsoft wins here - live with it, you commie.
What the professional writters are really complaing about is that they no longer have a virtual monopoly on writting. It is now for everyone. And of course, we are getting better at it.
This is true only to a point. It's impossible for _everyone_ to become a popular creator of books, articles, blogs or any other communication forms. The entry barrier hasn't vanished, it just moved further north.
Some people - successful bloggers, who are actually (getting) better at writing - will break the virtual monopoly you mentioned, only to establish a new one. The rest will just get their 20 hits per month from relatives and random google searches.
Now back to the source of this thread - I think that this ALA guy has a point. The blogs are getting attention unproportional to their quality.
This isn't very surprising, given the fact that they are a relatively fresh niche. I think it is nothing to worry about. Some time will pass, stupid people will split their attention between stupid books, stupid TV shows, stupid newspapers and stupid blogs, while a bit more discriminate readers will probably find some good blogs to add to their daily dose of information.
The contractors, however, scare me sometimes. Not all of them, of course... but the "nuke the sonsofbitches and let God sort them out" attitude seems much more common among the people who get paid to make the bits that do the nuking yet don't have to be directly involved in the process.
The expressed support seems proportional to the expected benefit.
This is an indicator of the sad state of peoples' minds nowadays. Many people seem to have lost the difference between "I will benefit from this" and "This is right". A comment about a contractor opposing the war would probably score +5, Funny.
1. Mixed scripts can be legit.
2. Therefore, turning IDL/mixed scripts completely is bad.
3. So, let's just show an icon indicating a mixed script/IDL use/whatever.
Point 1. gives a clue why the "solution" won't work. It won't prevent spoofing a legit domain name that is mix-scripted. The user would have to notice that the accent over 'e' is tilted the wrong way or something equally hard to spot.
This "solution" actually makes matters worse by giving false sense of security, just like any half-baked security measure.
Ok, I checked Wikipedia: if the entry is right, factorization is known (of course) to be in NP and coNP.
What you described is called TFNP - total functions computable by a nondeterministic machine in polynomial time. For every input a solution is guaranteed to exist and can be computed nondeterministically in polynomial time (and is usually hard to find deterministically).
A classic example is finding two inputs to a n-input,(n-1)-output logic network that give the same output results. By the pigeonhole principle they must exist, but no deterministic algorithm is know to find the solution in polynomial time.
This is an interesting class - as far as I know no TFNP-complete problems have been found so far. Several sub-classes of TFNP have been defined, each having a complete problem.
1. Bastardized Pascal with an undocumented syntax. Yes, Delphi has no formal syntax definition other than the compiler. See this usenet post .
2. The broken type hierarchy. Deriving all the classes from TObject won't replace a decent templating system as the Java folks recently found out.
3. Libraries from the 80's. No dictionary (aka map) type in the libraries.
4. Hard to separate GUI from business logic. The visual components expect being connected directly to DB components (TDataSource & TDataset). This is good for quickly snapping up a simple app, but soon it bites back as your app grows.
5. Poor debugger. As far as I remember it doesn't let you view variables except for the top stack frame (I am 100% sure about that being true in Delphi 5, 90% about Delphi 7).
Not to sound too negative - Delphi has its uses - fast development of small applications. For anything bigger, I'd stick with Java.
I usually just say 'try it and you will see that subversion is way easier to use and the rare conflicts are easy to merge'.
Any recommendations?
Make sure you know how to handle conflicts on non-mergeable files. You don't live in the ideal world - sometimes you just have to deal with unmergeable files in the repository - icon bitmaps, proprietary screwed-up format of your (pointy haired bosses') favorite database modeler, some strange resource files etc.
That's why file locking is the #1 feature on the SVN to-do list. Meanwhile, where I work we just use the "tell others before modifying" locking scheme on those unfortunate files.
How on earth will applying a sticker to the plastic battery packaging do anything to the properties of the cell's discharge, recharge, memory effect and emotional intelligence? (I *might* have made that last one up)
Simple -
BatMax contains permeable material, which is able to directly affect the molecule level inside the battery and BatMax reintegrates the uncharged particles into the electrical circuit.
BatMax reduces electrical loss by optimizing the ions transfers between the battery cells and maintaining a stable voltage.
It probably also proactively optimizes business flow to maximize your return on investment using the newest state-of-the-art XML over HTTP via TCP/IP technology.
I once needed a few thousand names for test data. The only big list I could find was the list of men killed in Vietnam
Anyone have a less disturbing list of real or fake names? I suppose someone could grab some data from a geneology site, strip out just the names, and use that.
I would just scan and OCR a few pages from a phone book. As far as I know, the data in the phonebook cannot be copyrighted, although there might be some privacy protection laws that forbid keeping databases of personal data without some form of consent from the people whose data you gather. To be on the safe side I'd make a separate list of first names and family names and re-match them at random.
One of the problems I see with high levels of security without a superuser-style account is the possibility of someone leaving, dying, or forgetting his password, and not being able to get to critical business data.
How is this resolved without a superuser?
The "missing password" problem is orthogonal to having root vs not having one. After all, unix admins die too, although one might find it hard to believe.
There are interesting cryptographic methods that solve this problem in a tricky way. An algorithm of this sort encrypts data(for example the root password, or just the key giving you some important privileges) with n keys so that k keys (k<=n) are sufficient to decrypt the data and less than k keys are not. You can then distribute the n keys among n trusted persons (the members of the board or whatever) and hope that even if the admin dies, at least k of the n persons will survive to meet and decrypt the data. Of course you could just give the power-key to every of the n persons but then you'd have to worry about too much power in one hand.
This are similar to error correction algorithms (where at least some percent of uncorrupted bits lets you get the uncorrupted message) but in error correction you don't have to prevent people from receiving the message when there are too many errors. Both kinds of algorithms rely on similar principles (for example the fact, that recreating a k-th degree polynomial requires k+1 values in different points).
Slashdot Mirror
What next? "Serious Doubts About Pyramid Schemes"? "Scientist Uses Paper to Wipe Ass"?
Such proof verifiers already exist today, but they are too stupid to be used to verify non-trivial theorems. They don't understand such paper-savers as "... other cases follow from this one" or "without loss of generality...". Of course, to allow such statements and still honestly check the proof, the verifier would have to generate some trivial parts of the proof itself - this is what human readers of mathematical papers do routinely. Are we thus back to square one (verification -> generation)? Well - proving the lemmas may be hard, but I think it's still much simpler than generating non trivial proofs.
Fortunately, Linux is strong where I happened to get my M.Sc. The OS-dependent subjects (Concurrent & Network programming, Operating Systems etc.) are taught on Linux. There is a .net course but it's outside the main curriculum.
Well, this brings the scenario closer to a fantasy movie with a powerful artifact to control an army of the undead... go figure :-)
Some people - successful bloggers, who are actually (getting) better at writing - will break the virtual monopoly you mentioned, only to establish a new one. The rest will just get their 20 hits per month from relatives and random google searches.
Now back to the source of this thread - I think that this ALA guy has a point. The blogs are getting attention unproportional to their quality. This isn't very surprising, given the fact that they are a relatively fresh niche. I think it is nothing to worry about. Some time will pass, stupid people will split their attention between stupid books, stupid TV shows, stupid newspapers and stupid blogs, while a bit more discriminate readers will probably find some good blogs to add to their daily dose of information.
This is an indicator of the sad state of peoples' minds nowadays. Many people seem to have lost the difference between "I will benefit from this" and "This is right". A comment about a contractor opposing the war would probably score +5, Funny.
1. Mixed scripts can be legit.
2. Therefore, turning IDL/mixed scripts completely is bad.
3. So, let's just show an icon indicating a mixed script/IDL use/whatever.
Point 1. gives a clue why the "solution" won't work. It won't prevent spoofing a legit domain name that is mix-scripted. The user would have to notice that the accent over 'e' is tilted the wrong way or something equally hard to spot.
This "solution" actually makes matters worse by giving false sense of security, just like any half-baked security measure.
A classic example is finding two inputs to a n-input,(n-1)-output logic network that give the same output results. By the pigeonhole principle they must exist, but no deterministic algorithm is know to find the solution in polynomial time.
This is an interesting class - as far as I know no TFNP-complete problems have been found so far. Several sub-classes of TFNP have been defined, each having a complete problem.
1. Bastardized Pascal with an undocumented syntax. Yes, Delphi has no formal syntax definition other than the compiler. See this usenet post .
2. The broken type hierarchy. Deriving all the classes from TObject won't replace a decent templating system as the Java folks recently found out.
3. Libraries from the 80's. No dictionary (aka map) type in the libraries.
4. Hard to separate GUI from business logic. The visual components expect being connected directly to DB components (TDataSource & TDataset). This is good for quickly snapping up a simple app, but soon it bites back as your app grows.
5. Poor debugger. As far as I remember it doesn't let you view variables except for the top stack frame (I am 100% sure about that being true in Delphi 5, 90% about Delphi 7).
Not to sound too negative - Delphi has its uses - fast development of small applications. For anything bigger, I'd stick with Java.
That's why file locking is the #1 feature on the SVN to-do list. Meanwhile, where I work we just use the "tell others before modifying" locking scheme on those unfortunate files.
There are interesting cryptographic methods that solve this problem in a tricky way. An algorithm of this sort encrypts data(for example the root password, or just the key giving you some important privileges) with n keys so that k keys (k<=n) are sufficient to decrypt the data and less than k keys are not. You can then distribute the n keys among n trusted persons (the members of the board or whatever) and hope that even if the admin dies, at least k of the n persons will survive to meet and decrypt the data. Of course you could just give the power-key to every of the n persons but then you'd have to worry about too much power in one hand.
This are similar to error correction algorithms (where at least some percent of uncorrupted bits lets you get the uncorrupted message) but in error correction you don't have to prevent people from receiving the message when there are too many errors. Both kinds of algorithms rely on similar principles (for example the fact, that recreating a k-th degree polynomial requires k+1 values in different points).