And legally, a concept and an idea are not distinct. Copyright protects the expression of an idea, not the idea, and patent protects the application of an idea to a specific device or business process. This is also why software patents in general rest on some pretty shaky legal grounds.
Someone else suggests that it is based on trade secrets, but it is difficult to imagine how code can be widely licensed for the creation of derivative products and still remain a trade secret. Even if the licenses have language about requirements to maintain the trade secrets, SCO would have to prove that it was IBM who actually let the cat out of the bag. This is particularly weak since AT&T routinely allowed for academic access to the UNIX source (very openly before the break up, and after that as well). I may still have a copy of the version 7 sources that was published (i.e. printed form). There was restrictive language relating to actually controlling the distributed copies, but I'm sure I'm not the only one to get access this way.
As I understand it, they aren't even alleging this much. The claim is that IBM employees who once worked with AT&T licensed code (licenses now owned by SCO), are now working on Linux and must have used IP owned by SCO in Linux. The just assert this as if it proves the case.
IANAL, but the reason that organizations use a "clean room" process where one group of engineers extracts specifications from a piece of licensed technology, and a totally different one with no direct exposure the the original IP does the new product is to make sure that nothing "accidentally" infringes on the original license. This is to avoid the possiblity of a lawsuit and to strengthen their case if they are sued. The plantiff still has to prove the specifics of the infringement based on actual code in the infringing product. As pointed out by the Dennis Richie newsgroup posting linked in a comment, the court didn't see much merrit when AT&T sued over BSD. The outcome could be different this time, but that is very unlikely with IBM's legal resources.
That's right, but not because SCO might target them because Sun's claim to have a clear title to Solaris is valid, but because it shows them to be petty, short sighted and stupid. Sun has a lot of good-will amoung the/. demographic, but being a fair weather friend to Linux will only hurt them in the long run by turning people off. IBM will win big with this crowd if they can crush SCO and their lawsuit quickly, and they are more likely to be taking Sun's market share than anybody elses.
OTOH, I wouldn't count Sun out already an an earlier comment does.
Well, I was more thinking about race routes, but you are right on about the other trade offs. And yes, untill the late schooners and clippers, very few ships did well to windward, and it's always hard on the crew and the boat.
By "Bolger sqare boats", you mean scows, right? I'm from the Midwest where they are (or at least were) very popular on the small lakes. They have most of the advantages of multihulls as long as you don't have any waves. I am partial to cats, although tris seem to be in vougue these days. I try to follow what's going on with the "maxi-multis" built for The Race a few years back. I know Playstation II set a new trans-atlantic record, but broke gear and dropped out early in the big one. There's something to be said for not pushing the envelope too much in size (105' x 60' is just huge), nobody had experience with sails of that size, particularly with the higher rig loadings that multihulls produce. If they can make it reliable, it will be unbeatable.
To get a little more on-topic... It's amazing what Poincare did on the problem before computers. He really started Chaos theory before it had a name, but the complexity was so great it was difficult to go much further until the computer came along.
are probably a better analogy to this, but the highway one is familiar to more people. The other way it works is with the idea that the Lagrange points act like interchanges where manifolds to/from different places come close so you can easily exit one and enter another.
WRT sailing routes from England to NYC, it really depends on your boat. Multi-hulls pioneered the southern passage because they are much faster on a reach or broad reach, and not quite as good to windward. Some modern overpowerd monohulls might be faster on the southern route, but it is more of a toss up.
They don't really go into the details of the actual paths because of how hard it is to picture the multi-dimensional spaces that would make it clear. It is remarkable how everything changes with the third body in what seems like a simple system at first glance. I think I get some of the fundamentals intuitively. The "stable" manifold leading to L1 would be a group of orbits that tend to pump the spacecraft into more and more excentric orbits, while the "unstable" manifold leading to L2 does the oposite. On the other hand, the physics is reversible, so there are trajectories taking you toward the unstable L2 state and away from the stable L1.
When they start talking about orbit transfers, you are trying to find where the systems from neighboring planets link together. This involves considering seperate 3-body problems of Sun-Spaceship-Planet for each planet where the manifolds of each system are rotating with the planets, and are only synchronized at certain times. They don't really say why the link ups are harder to find (or longer to wait for) for Earth/Mars than the outer planets. If I had to guess, it is probably related more to the scaling the the orbit distances and the planet masses. The Earth and Mars aren't that massive, but it still might be more related to the closer orbital periods.
To me, it is just fascinating that there can be so much to investigate and study in the pure mathematics of a few simple equations. Most of this was just about the near equilibrium equations for uncontrolled objects. The slingshot trajectories represent another group of solutions that have some special characteristics. Very cool stuff. It really points the way for a lot of robotic missions over the coming centuries. With solar power, the fact that it take a long time to get there doesn't matter as much as the fact that you can keep manuvering for new missions long after the initial mission planning.
Well, actually, Interactive UNIX was a SCO competitor from way back. The OS part of Interactive was merged with Sun in the early 90s. The main reason for wanting Interactive was for the driver library, as the core of Solaris x86 was no doubt pretty much pure Solaris.
But, it is pretty funny to see SCO claim to be the *only* x86 based UNIX. That may have been true for a year or two with XENIX in the 286 days, but I doubt even that. I dare say that IBM has way more patents relating to running all sorts of OSs very fast on all sorts of multi-processing architectures. They don't even know all the patents they have, but their lawyers can certainly find a few for this and similar situations.
And I agree that when IBM wins this, a line will be drawn that makes people a lot less nervous about reading someone elses code before implementing something. This also points to something about Free/Open Source. Almost nobody would try to keep you from reading a Free/Open Source program and creating your own version under any license you want. The principle is that it is all about sharing ideas, and freeing them up to be widely applied.
Paying for incoming bandwidth as a default situation seems pretty odd to start with. Are these typically client accounts (as apposed to server)? The default for phones is that the caller pays unless you have a toll-free line, and even here, if you don't pick up the line, there won't be any charge. Seems to me that the ISP is responsible to not count rejected packets. Of course, they would only know about packets actually "rejected", since "denied" packets are just dropped without any reply. On second thought, if they actually tracked acknowledgements, but that's probably too complex to require.
This issue brings up the whole issue of whether you can actually trust the ISP's metering software/hardware to fairly account for your bandwidth. To me, and probably most courts, charging for rejected packets is going to be viewed very negatively, but if a customer really pressed a dispute, it would probably be a nightmare to actually validate that the metering system is indeed fair and accurate, and there is no possibility that someone "adjusted" anything. After all, the entire system (the metering) is under the control of the ISP and the customer has no access. As a customer, how would you go about showing that the bandwidth measurements were wrong? Even if you had metering built into your firewall or something, it would be hard to validate your data (just like with the ISP side), and you aren't likely to set this up before the dispute arises.
And, yes, you are losing all sorts of potential bandwidth to this sort of thing, and generally, the congestion from a DOS attack is considered much more a problem than who gets billed for the traffic. If your firewall is busy rejecting attack packets, there is less bandwidth available to the purpose your system was put in for, and in some cases this could be almost none (i.e. the DOS is successful, at least for some time). With the recent problems, it wasn't just the systems being attacked and attacking that were slowed down or unavailable. That's the nature of a DDOS attack, the aggregate bandwidth consumed by the activities of the attack can flood out network resources, not just the endpoints.
In point 1, you are talking about a weaker sense of backdoor, really just a raw administrative interface or hook to do some specific thing easier. This is not really what this discussion is about. In any case, if you have root, you can dole out sub-root priviledges anyway.
Point 2 is totally invalid. With physical access, rooting most systems is trivial, and the rest are just slightly harder. Worst case, you pull the disk and put it in a system you have root on as a second disk. What if the miscreant disabled your backdoor before leaving too?
Maybe I wasn't clear enough - back doors are not in and of themselves an indication of bad ethics.
If it isn't bad ethics, then it is at least bad admin practice. At the very least it should be documented so that management knows and can have someone access it if needed. OTOH, there are ways to set up alternate access that I would not characterize as a backdoor. I've had hundreds of machines at a site that all could be accessed without password via an ssh login (with host authentication, of course) from a specific set of machines. In one environment, machines with this capability where refered to as "super-root" machines.
Thanks for clarifying my comment. This is exactly what I mean.
To the AC that just got 84.50 after a long delay; do you actually wish you had installed alarm code that disabled something? Clients have lots of reasons to delay paying, but they only don't pay at all if they aren't happy with the work or they go out of business. Obviously, you have kept your risk low and will lower it by requiring pre-pay from clients like this. That is good business, but auto-disable a system and not only could you ruin your rep, you might even be liable for damages. The fact that they have not paid you yet will not help you if the failure caused damage.
1. most people don't give a shit, don't have a clue...
Most, probably. However, most systems people do care about this, and MS is in the process of learning this the hard way. The issue comes up first with the technical people who know about it, but more and more this stuff is getting into mainstream press, and a lot of people do care about their privacy once they understand the issues.
2. if your app does what it's supposed to, they won't care about any back doors...
Bull. Many organizations have strong security policies, and if they discover you have violated them, you won't be getting any more work there. Looked at another way, "does what it's supposed to" includes protecting the customer's information.
3. the first time they screw up, they'll be glad there was a back door!
This does not require a "back door", and even if that is your solution for lost password recovery, it had better be documented and not introduce a blatant security hole.
4. if they can't trust you to refrain from abusing any back door you put in, they shouldn't be using you anyway!!!...
If you can't just tell them about any access provisions you have made, then you shouldn't be creating any. Frankly, I can't think of any situations where root access isn't all the backdoor you need. If the system is secure enough to requre one-way cryptography, then a backdoor of any kind would be a clear breach of policies. In this case, write them down and put them in a safe.
If someone who did work for me ever tried to pull something like this, they would never do work for me again. Holding your customers hostage is not a good business practice. Yes, there is a risk that you don't get paid, or have to sue, etc., but you are much better off minimizing the risk in other ways. Besides, isn't source code an essential part of any custom code? Ok, so maybe you could hold the source hostage until paid, but I would never put in "expiration code".
At least Unix gives you a fighting chance since configuration files are all individually named and occupy different places on the disk.
I'm hoping this has actually been fixed by now (I'm still on RH 7.3), but I have a number of periodic problems with Gnome configuration. It took me a while to figure out that the biggest problem is that if the system crashes (typically from kicking the plug out or some such, I rarely have a system hang), you have to be sure to remove the lock files in both.gconfd and.gconf so that gconfd starts up correctly. It also has blown away my configuration a number of times, although I'm not completely sure that this isn't related to having the same user logged in from multiple machines (to an NFS home dir).
Of course, at least this is just my user's desktop settings and not the entire machine config, but it is annoying enough when it bites you. By the time this is as mature as the Windows registry, I fully expect this to be pretty much flawless and better documented (well, if it is fixed, I probably don't need the docs anyway).
Re:Trading disk latency for network latency
on
RAMdisk RAID?
·
· Score: 1
That's why he's thinking of using Gigabit Ethernet. That should be faster than the transfer rate of typical disks, and the latency of waiting for your sector to come around is way more than any network delay.
It does seem like a waste of hardware, though. If you are going to drop some money into buying RAM for these systems, I would think it would be way better to figure out a way to attach that RAM locally. Somebody must make something like a PCI or Fast SCSI RAMdisk card that takes the cheapest memory modules. This would be likely to have some sort of battery built in to make it non-volitile as well.
And given that we haven't seen Amazon moving to enforce any of the very basic patents they have been accumulating, I'd guess that these are defensive patents. After all, if the patent office will grant a patent for almost anything, a strategy of patenting the core processes of your business, even if you don't think they deserve patent protection, will serve you well in protecting you from opportunists who might patent it and go after you.
It would be nice if they stated as much explicitely and maybe join the many voices asking that the patent office reject trivial patents like this. Even if you believe in strong IP protections, it can be argued that this trend is a very bad thing. If it continues, it is entirely possible that a groundswell of protests will emerge against patents in general, and I'm not just talking about/. because industry will start to see the entire systems and its costs as parasitic.
If you want a Java solution, don't try to use the broken JVM from MS. Recent legal decisions require MS to put a real JVM in their distributions, so it should be available.
You don't really say what your support situation is. Are these internal clients that you have some control over, or is this something for the general public to access from the Internet? Also, you imply but don't say that this is limited to Windows clients, so the suggestion of compiling the Java down to a binary and distributing the app itself is viable. What's the point of using a portable technology if you want it to run on un-improved Windows boxes?
I'm always interested in new and better search engines, but you're not even saying it is better. Is it better in some ways, but not overall better? Otherwise, what's the point.
It is interesting that this is the first comment I've seen mentioning alternatives, and one comment joked, "are there any others?". I don't use any others right now, and I'm wondering if there are even others that people would recomend (besides teoma).
I mean exactly what you stated "different algorithms and other differences". For most people, this is very significant, particularly WRT the issues like "pay for position" and other nasty problems.
In truth, it could go either way, and you would probably have to do a survey to find out. I maintain that most people mean "search Google.com" when they use "google" as a verb, and they would not use it to mean "search Yahoo.com" or any other engine. Generically, saying "web search" or something else suitably generic isn't more complex than saying "google it", so why not be accurate. People say "google" because that is the engine they use, and people hearing "google" can and to translate to "may favorite search engine", but I don't think people would say it if they aren't using it.
I would never use "to google" to generically mean use any search engine to find something on the Net. The fact is that anyone who actually uses search engines knows that they don't work the same, and they don't have the same databases of links to search. It's just not like Kleenex or Xerox where the equivalent products really aren't easily differentiated. In fact, it is quite a tribute to their success that most people use "to google" literally to mean go do a search at google.com. Of course, it wasn't that long ago that Yahoo had the same status, and now they aren't really that significant. It is always possible that Google will suffer the same fate someday, possibly soon. I doubt that "to google" will remain the popular phrase it is today when/if that happens.
Yes, and the truely objectionable thing about this is as long as the "major tax software distributors" are in control, there is zero prospect that we will be able to do our taxes securly on our OS platforms. I don't even care whether they give away the actual tax software, but what the IRS should do for us is create an open tax platform so they can release all the rules, regulations, forms and proceedures in a form that can be used directly by "generic" tax software.
What I am imagining here is a system of XML files and XML document types that would have all the data that changes year to year as they update tax laws. This would make and OS tax program practical because you would just have to implement the generic software that uses this raw data, and you wouldn't need an army of tax lawyers and accountants to first digest the tax laws (and do this again each year). Most people would still use the commercial packages on the typical platforms, and this isn't even a guarantee that and OS version would emerge, but at least it would be possible.
A full OS reference platform might be nice too, but it isn't a requirement.
While the theoretical core of CS is not typically of day-to-day value in most industry jobs, a solid background in the fundamentals is part of what makes you a professional and more than a hacker finding things out by trial and error. You don't have to be able to prove things about computability with Turing machines, but you'd better understand the implications of this stuff in terms of what can be computed in a reasonable time (or at all). The bottom line is, it depends on the specifics of your work (job); if you stick to programming and development vs. doing more systems and network engineering jobs, you are going to use a different knowledge set. Of course, the broader your foundation knowledge, the better you will be at the "big picture" stuff, and the more you will be able to function as a system designer and architect.
So, yes, all the "discrete stuff", as you say, but I view these more as the basic tool box for a programmer, and most people who are cut out for this work will pick up what they need in this area without a lot of formal training. The main reason to go deeper with this area is for a better understanding of cryptology and related stuff, and if you are getting into the "guts" of runtimes and garbage collectors, a more formal understanding of these ideas will be important, but I would say that the "Formal Languages" sutff is more important to programming work.
We create new "languages" all the time in the course of our work, so knowing what can be recognized and parsed with regular expressions (and the equiv. finite state automatons) vs. context free grammers helps when trying to specify something that is consistent and unambiguous.
I would also say that the math core (18.01-03 in my day, calculus through differential equations) isn't really essential to much, but probablity and statistics is a lot more important. I would also say that I didn't get much in my formal training that covered the topics important to analysing systems performance. I'm talking about the areas relating to latency vs bandwidth and throughput.
In retrospect, the "Computational Structures" course (6.032 in my day, which became 6.003 after I took it but before I graduated) lost it's relevance very quickly, or maybe I just forgot what I learned in this course. This was before the emergence of RISC architectures, and there has been enormous change in these areas since then, and I expect this to continue and maybe even intesify in the near future, so I would put more emphasis on these areas. IMHO, one of the main reasons that a lot of interesting new architectures fail (e.g. the connection machine) is that we don't have the basic mental and programming tools to deal with non-vonneuman architectures. Well, this really goes way beyond anything you can address with a course of study, but it would help.
I am in fact a boat owner, but I sail in fresh water, so I'm not as familiar with the actual practical aspects of long term salt exposure. I know it's bad, but I was more responding the idea that a salt coating would build up and interfere with transmisive properties and such. As I understand it, the issue is more one of corosive effects than actual build-up, but as I said, salt water isn't big in my world. I'm sure a good rain is welcome for rinsing everything off as long as it doesn't come with too much of a blow.
Everyone wants to spell my name as Jerry, but since my full name is Gerald, I have always gone with Gerry, and don't let people change it on me. Of course, another approach is to let them spell it wrong so it is easier to recognize the junk mail derived from taking your name.
For a restaurant situation, obviously any easy to say token will do, and can be funny as well.
All three of your points are correct, of course. 1. Right, a $50/mo electric bill is $3000 over 5 years, so you have to be able to a) generate enough for the load equiv. of $50/mo, b) handle the variation (storage, or trading your surplus at peak to buy back at night and cloudy days from the utility), and c) cost less than $3000.
2. AC is greate for transmission and doing voltage/current conversions (which is why it is good for transmission), but DC is just as easy to use for most applications. If you are pure DC, you are still going to lose in voltage changes for specific devices, and DC to DC is just as inefficient DC to AC inversion. If you go full solar, you could wire the house anyway you want, but it could get pretty complicated, and might not be worth the hassles unless some significant percentage of people also start switching to DC.
3. Environmental is a consideration beyond just the lifetime, you always have to consider the full circle including the recycle/reuse phase. See 3a above as well, if it doesn't have a life expectency of at least double the payback period, it won't be cost effective either, so it better last 10 years, or be proportionally cheaper.
The part 2 was there when the first story appeared on/., so anyone who was interested already read the whole thing. Further, both parts are mostly fluff and stuff that we already know from following these developments.
No, if salt spray was that big of a problem, it would be a huge maintanance problem with ordinary sails. Salt spray is a big corrosion problem with some materials, but I've never heard of significant build-up of salt on sails of other parts of a boat.
The problem with this material for sails is going to be that it alters the strength and weight of the the materials, and extra weight aloft carries a big penalty in performance. The deck is the right place for this technology. I would think it would be excellent for multi-hulls with large deck areas that maintain faily constant angles. The sides of the hull might be good on a monohull to take advantage of certain courses and heal angles, but you'd always have part of the array where the sun isn't shining.
Slashdot Mirror
Someone else suggests that it is based on trade secrets, but it is difficult to imagine how code can be widely licensed for the creation of derivative products and still remain a trade secret. Even if the licenses have language about requirements to maintain the trade secrets, SCO would have to prove that it was IBM who actually let the cat out of the bag. This is particularly weak since AT&T routinely allowed for academic access to the UNIX source (very openly before the break up, and after that as well). I may still have a copy of the version 7 sources that was published (i.e. printed form). There was restrictive language relating to actually controlling the distributed copies, but I'm sure I'm not the only one to get access this way.
IANAL, but the reason that organizations use a "clean room" process where one group of engineers extracts specifications from a piece of licensed technology, and a totally different one with no direct exposure the the original IP does the new product is to make sure that nothing "accidentally" infringes on the original license. This is to avoid the possiblity of a lawsuit and to strengthen their case if they are sued. The plantiff still has to prove the specifics of the infringement based on actual code in the infringing product. As pointed out by the Dennis Richie newsgroup posting linked in a comment, the court didn't see much merrit when AT&T sued over BSD. The outcome could be different this time, but that is very unlikely with IBM's legal resources.
That's right, but not because SCO might target them because Sun's claim to have a clear title to Solaris is valid, but because it shows them to be petty, short sighted and stupid. Sun has a lot of good-will amoung the /. demographic, but being a fair weather friend to Linux will only hurt them in the long run by turning people off. IBM will win big with this crowd if they can crush SCO and their lawsuit quickly, and they are more likely to be taking Sun's market share than anybody elses.
OTOH, I wouldn't count Sun out already an an earlier comment does.
By "Bolger sqare boats", you mean scows, right? I'm from the Midwest where they are (or at least were) very popular on the small lakes. They have most of the advantages of multihulls as long as you don't have any waves. I am partial to cats, although tris seem to be in vougue these days. I try to follow what's going on with the "maxi-multis" built for The Race a few years back. I know Playstation II set a new trans-atlantic record, but broke gear and dropped out early in the big one. There's something to be said for not pushing the envelope too much in size (105' x 60' is just huge), nobody had experience with sails of that size, particularly with the higher rig loadings that multihulls produce. If they can make it reliable, it will be unbeatable.
To get a little more on-topic ... It's amazing what Poincare did on the problem before computers. He really started Chaos theory before it had a name, but the complexity was so great it was difficult to go much further until the computer came along.
WRT sailing routes from England to NYC, it really depends on your boat. Multi-hulls pioneered the southern passage because they are much faster on a reach or broad reach, and not quite as good to windward. Some modern overpowerd monohulls might be faster on the southern route, but it is more of a toss up.
They don't really go into the details of the actual paths because of how hard it is to picture the multi-dimensional spaces that would make it clear. It is remarkable how everything changes with the third body in what seems like a simple system at first glance. I think I get some of the fundamentals intuitively. The "stable" manifold leading to L1 would be a group of orbits that tend to pump the spacecraft into more and more excentric orbits, while the "unstable" manifold leading to L2 does the oposite. On the other hand, the physics is reversible, so there are trajectories taking you toward the unstable L2 state and away from the stable L1.
When they start talking about orbit transfers, you are trying to find where the systems from neighboring planets link together. This involves considering seperate 3-body problems of Sun-Spaceship-Planet for each planet where the manifolds of each system are rotating with the planets, and are only synchronized at certain times. They don't really say why the link ups are harder to find (or longer to wait for) for Earth/Mars than the outer planets. If I had to guess, it is probably related more to the scaling the the orbit distances and the planet masses. The Earth and Mars aren't that massive, but it still might be more related to the closer orbital periods.
To me, it is just fascinating that there can be so much to investigate and study in the pure mathematics of a few simple equations. Most of this was just about the near equilibrium equations for uncontrolled objects. The slingshot trajectories represent another group of solutions that have some special characteristics. Very cool stuff. It really points the way for a lot of robotic missions over the coming centuries. With solar power, the fact that it take a long time to get there doesn't matter as much as the fact that you can keep manuvering for new missions long after the initial mission planning.
Well, actually, Interactive UNIX was a SCO competitor from way back. The OS part of Interactive was merged with Sun in the early 90s. The main reason for wanting Interactive was for the driver library, as the core of Solaris x86 was no doubt pretty much pure Solaris.
But, it is pretty funny to see SCO claim to be the *only* x86 based UNIX. That may have been true for a year or two with XENIX in the 286 days, but I doubt even that. I dare say that IBM has way more patents relating to running all sorts of OSs very fast on all sorts of multi-processing architectures. They don't even know all the patents they have, but their lawyers can certainly find a few for this and similar situations.
And I agree that when IBM wins this, a line will be drawn that makes people a lot less nervous about reading someone elses code before implementing something. This also points to something about Free/Open Source. Almost nobody would try to keep you from reading a Free/Open Source program and creating your own version under any license you want. The principle is that it is all about sharing ideas, and freeing them up to be widely applied.
This issue brings up the whole issue of whether you can actually trust the ISP's metering software/hardware to fairly account for your bandwidth. To me, and probably most courts, charging for rejected packets is going to be viewed very negatively, but if a customer really pressed a dispute, it would probably be a nightmare to actually validate that the metering system is indeed fair and accurate, and there is no possibility that someone "adjusted" anything. After all, the entire system (the metering) is under the control of the ISP and the customer has no access. As a customer, how would you go about showing that the bandwidth measurements were wrong? Even if you had metering built into your firewall or something, it would be hard to validate your data (just like with the ISP side), and you aren't likely to set this up before the dispute arises.
And, yes, you are losing all sorts of potential bandwidth to this sort of thing, and generally, the congestion from a DOS attack is considered much more a problem than who gets billed for the traffic. If your firewall is busy rejecting attack packets, there is less bandwidth available to the purpose your system was put in for, and in some cases this could be almost none (i.e. the DOS is successful, at least for some time). With the recent problems, it wasn't just the systems being attacked and attacking that were slowed down or unavailable. That's the nature of a DDOS attack, the aggregate bandwidth consumed by the activities of the attack can flood out network resources, not just the endpoints.
Point 2 is totally invalid. With physical access, rooting most systems is trivial, and the rest are just slightly harder. Worst case, you pull the disk and put it in a system you have root on as a second disk. What if the miscreant disabled your backdoor before leaving too?
Maybe I wasn't clear enough - back doors are not in and of themselves an indication of bad ethics.
If it isn't bad ethics, then it is at least bad admin practice. At the very least it should be documented so that management knows and can have someone access it if needed. OTOH, there are ways to set up alternate access that I would not characterize as a backdoor. I've had hundreds of machines at a site that all could be accessed without password via an ssh login (with host authentication, of course) from a specific set of machines. In one environment, machines with this capability where refered to as "super-root" machines.
To the AC that just got 84.50 after a long delay; do you actually wish you had installed alarm code that disabled something? Clients have lots of reasons to delay paying, but they only don't pay at all if they aren't happy with the work or they go out of business. Obviously, you have kept your risk low and will lower it by requiring pre-pay from clients like this. That is good business, but auto-disable a system and not only could you ruin your rep, you might even be liable for damages. The fact that they have not paid you yet will not help you if the failure caused damage.
Most, probably. However, most systems people do care about this, and MS is in the process of learning this the hard way. The issue comes up first with the technical people who know about it, but more and more this stuff is getting into mainstream press, and a lot of people do care about their privacy once they understand the issues.
2. if your app does what it's supposed to, they won't care about any back doors ...
Bull. Many organizations have strong security policies, and if they discover you have violated them, you won't be getting any more work there. Looked at another way, "does what it's supposed to" includes protecting the customer's information.
3. the first time they screw up, they'll be glad there was a back door!
This does not require a "back door", and even if that is your solution for lost password recovery, it had better be documented and not introduce a blatant security hole.
4. if they can't trust you to refrain from abusing any back door you put in, they shouldn't be using you anyway!!! ...
If you can't just tell them about any access provisions you have made, then you shouldn't be creating any. Frankly, I can't think of any situations where root access isn't all the backdoor you need. If the system is secure enough to requre one-way cryptography, then a backdoor of any kind would be a clear breach of policies. In this case, write them down and put them in a safe.
If someone who did work for me ever tried to pull something like this, they would never do work for me again. Holding your customers hostage is not a good business practice. Yes, there is a risk that you don't get paid, or have to sue, etc., but you are much better off minimizing the risk in other ways. Besides, isn't source code an essential part of any custom code? Ok, so maybe you could hold the source hostage until paid, but I would never put in "expiration code".
I'm hoping this has actually been fixed by now (I'm still on RH 7.3), but I have a number of periodic problems with Gnome configuration. It took me a while to figure out that the biggest problem is that if the system crashes (typically from kicking the plug out or some such, I rarely have a system hang), you have to be sure to remove the lock files in both .gconfd and .gconf so that gconfd starts up correctly. It also has blown away my configuration a number of times, although I'm not completely sure that this isn't related to having the same user logged in from multiple machines (to an NFS home dir).
Of course, at least this is just my user's desktop settings and not the entire machine config, but it is annoying enough when it bites you. By the time this is as mature as the Windows registry, I fully expect this to be pretty much flawless and better documented (well, if it is fixed, I probably don't need the docs anyway).
It does seem like a waste of hardware, though. If you are going to drop some money into buying RAM for these systems, I would think it would be way better to figure out a way to attach that RAM locally. Somebody must make something like a PCI or Fast SCSI RAMdisk card that takes the cheapest memory modules. This would be likely to have some sort of battery built in to make it non-volitile as well.
It would be nice if they stated as much explicitely and maybe join the many voices asking that the patent office reject trivial patents like this. Even if you believe in strong IP protections, it can be argued that this trend is a very bad thing. If it continues, it is entirely possible that a groundswell of protests will emerge against patents in general, and I'm not just talking about /. because industry will start to see the entire systems and its costs as parasitic.
You don't really say what your support situation is. Are these internal clients that you have some control over, or is this something for the general public to access from the Internet? Also, you imply but don't say that this is limited to Windows clients, so the suggestion of compiling the Java down to a binary and distributing the app itself is viable. What's the point of using a portable technology if you want it to run on un-improved Windows boxes?
It is interesting that this is the first comment I've seen mentioning alternatives, and one comment joked, "are there any others?". I don't use any others right now, and I'm wondering if there are even others that people would recomend (besides teoma).
In truth, it could go either way, and you would probably have to do a survey to find out. I maintain that most people mean "search Google.com" when they use "google" as a verb, and they would not use it to mean "search Yahoo.com" or any other engine. Generically, saying "web search" or something else suitably generic isn't more complex than saying "google it", so why not be accurate. People say "google" because that is the engine they use, and people hearing "google" can and to translate to "may favorite search engine", but I don't think people would say it if they aren't using it.
I would never use "to google" to generically mean use any search engine to find something on the Net. The fact is that anyone who actually uses search engines knows that they don't work the same, and they don't have the same databases of links to search. It's just not like Kleenex or Xerox where the equivalent products really aren't easily differentiated. In fact, it is quite a tribute to their success that most people use "to google" literally to mean go do a search at google.com. Of course, it wasn't that long ago that Yahoo had the same status, and now they aren't really that significant. It is always possible that Google will suffer the same fate someday, possibly soon. I doubt that "to google" will remain the popular phrase it is today when/if that happens.
What I am imagining here is a system of XML files and XML document types that would have all the data that changes year to year as they update tax laws. This would make and OS tax program practical because you would just have to implement the generic software that uses this raw data, and you wouldn't need an army of tax lawyers and accountants to first digest the tax laws (and do this again each year). Most people would still use the commercial packages on the typical platforms, and this isn't even a guarantee that and OS version would emerge, but at least it would be possible.
A full OS reference platform might be nice too, but it isn't a requirement.
So, yes, all the "discrete stuff", as you say, but I view these more as the basic tool box for a programmer, and most people who are cut out for this work will pick up what they need in this area without a lot of formal training. The main reason to go deeper with this area is for a better understanding of cryptology and related stuff, and if you are getting into the "guts" of runtimes and garbage collectors, a more formal understanding of these ideas will be important, but I would say that the "Formal Languages" sutff is more important to programming work.
We create new "languages" all the time in the course of our work, so knowing what can be recognized and parsed with regular expressions (and the equiv. finite state automatons) vs. context free grammers helps when trying to specify something that is consistent and unambiguous.
I would also say that the math core (18.01-03 in my day, calculus through differential equations) isn't really essential to much, but probablity and statistics is a lot more important. I would also say that I didn't get much in my formal training that covered the topics important to analysing systems performance. I'm talking about the areas relating to latency vs bandwidth and throughput.
In retrospect, the "Computational Structures" course (6.032 in my day, which became 6.003 after I took it but before I graduated) lost it's relevance very quickly, or maybe I just forgot what I learned in this course. This was before the emergence of RISC architectures, and there has been enormous change in these areas since then, and I expect this to continue and maybe even intesify in the near future, so I would put more emphasis on these areas. IMHO, one of the main reasons that a lot of interesting new architectures fail (e.g. the connection machine) is that we don't have the basic mental and programming tools to deal with non-vonneuman architectures. Well, this really goes way beyond anything you can address with a course of study, but it would help.
I am in fact a boat owner, but I sail in fresh water, so I'm not as familiar with the actual practical aspects of long term salt exposure. I know it's bad, but I was more responding the idea that a salt coating would build up and interfere with transmisive properties and such. As I understand it, the issue is more one of corosive effects than actual build-up, but as I said, salt water isn't big in my world. I'm sure a good rain is welcome for rinsing everything off as long as it doesn't come with too much of a blow.
For a restaurant situation, obviously any easy to say token will do, and can be funny as well.
2. AC is greate for transmission and doing voltage/current conversions (which is why it is good for transmission), but DC is just as easy to use for most applications. If you are pure DC, you are still going to lose in voltage changes for specific devices, and DC to DC is just as inefficient DC to AC inversion. If you go full solar, you could wire the house anyway you want, but it could get pretty complicated, and might not be worth the hassles unless some significant percentage of people also start switching to DC.
3. Environmental is a consideration beyond just the lifetime, you always have to consider the full circle including the recycle/reuse phase. See 3a above as well, if it doesn't have a life expectency of at least double the payback period, it won't be cost effective either, so it better last 10 years, or be proportionally cheaper.
The part 2 was there when the first story appeared on /., so anyone who was interested already read the whole thing. Further, both parts are mostly fluff and stuff that we already know from following these developments.
The problem with this material for sails is going to be that it alters the strength and weight of the the materials, and extra weight aloft carries a big penalty in performance. The deck is the right place for this technology. I would think it would be excellent for multi-hulls with large deck areas that maintain faily constant angles. The sides of the hull might be good on a monohull to take advantage of certain courses and heal angles, but you'd always have part of the array where the sun isn't shining.