... Sure, Apache != GPL, but still... it's Free Software in both forms.
Oh, I get it now! "We don't like free software, except on our terms - i.e. when we're using it exclusively, it's O.K., but otherwise, get rid of it already!"
Geez. They must really, really want to be disliked...
They can simply go around and demand liscense fees from anybody using Linux, without ever telling anyone exactly what it is they're paying for, and the Linux community would be more or less helpless to remove the offending code short of re-writing anything in the kernal whose origin can't be totally nailed down.
In Australia, at least, that would land SCOG in very, very hot water (being Australian and by extension, not from the US, I don't know what the law provides for there). Claiming ownership -- and license fees -- on something you don't provably own is misrepresentation, and will see you up against the various state Offices of Fair Trading and/or the Australian Consumer and Competition Commission quicker than you can say "pay me." You can ask for donations and/or provide a service in return for payment, but you can't go around claiming rights to stuff for no material or immaterial benefit of any kind, much less threatening (veiled or otherwise) legal action if payment isn't forthcoming.
I'm still waiting for SCO Australia to try it on here. They're welcome to use me as a guinea-pig; I'd be only too happy to send a copy of all correspondence to the ACCC.
... when I read "camping" I immediately thought of a particular activity, considered by some to be abhorrent, which is usually associated with CounterStrike and other games in a similar genre.
or did anyone else read the "category" of this story as from the they-stole-our-pants dept.?
I was beginning to wonder where they'd gone...
No, just me? Oh. Oops.
Re:Wait a second...
on
Son of Concorde
·
· Score: 5, Informative
I'm not an aeronautical engineer; just a plane nut. I may therefore have some of this wrong, and I'd welcome corrections.
Supercruise is a fairly easy-to-understand phenomenon; in effect, it requires two things:
lots of thrust from the powerplant;
subsonic airflow in high quantities through the engine due to the way a "conventional" turbine operates, with slightly supersonic exhaust flows.
Normally, a turbine can't attain supercruise because of the latter; the airflow needs to be slowed considerably going through the powerplant in order to stop a shock stall (where the supersonic shockwave suffocates the powerplant).
The powerplant behind the F-22 (Pratt&Whitney F119-PW-200) attains this primarily though a few good engineering tricks such as single-crystal-cast blades with a slightly shallower angle of attack than most; thus allowing the engine to operate at a higher temperature and pressure internally than is "normal". It has a lower bypass ratio (the ratio of cool air passing around the engine to that going through the engine) than most fighter-class engines; thus, it needs a smaller front fan, which in turn reduces the area causing a shock stall. It also wears out quicker, but that's another matter entirely.:)
High bypass ratios are great for fuel efficiency at subsonic speeds, but by virtue of the way these turbines work and their tendency to shock-stall when confronted with a supersonic airflow, are not much good for supersonic flight, and not for the nearly-supersonic airflows that supercruise requires.
A typical mid-to-high bypass turbine used in a fighter will have a bleed air system to reduce the airspeed running through the turbine; this has to be counteracted by dumping raw fuel into the bypass & exhaust (i.e. afterburner). Indeed, to get much over M1.0 the F22 needs to employ this same trick. A low bypass turbine can operate with input airspeeds closer to M1.0, which in turn means less air needs to be bled, while still producing a slightly supersonic exhaust out the rear end.
Excellent point. I've been through similar (cane farmer putting a disc through a fairly shallow cable!), so rather disappointed that I forgot about it.
Always, always assume that the one thing you can't or won't make redundant will fail. If hardware doesn't pop, then you can absolutely guarantee that the software or firmware will make it.:)
Never take manufacturer's reliability figures with less than an entire salt mine full of salt. Systems always fail more often than quoted.
Never underestimate the power of full backups, and preferably a standing image in GHOST format or similar of each critical system. Being able to restore a machine without having to sit through an install will help your sanity infinitely.
Never, ever overload a UPS. Bear in mind, in fact, that as UPSen age, the alternate supplies (typically gel batteries) degrade in performance, and so "100%" when new becomes "110%" when about three to four years old. The rule of thumb we use here is no more than 60% load on any UPS.
Make everything - everything critical to the mission, that is (power to building, UPSen, generators, network kit, servers, disks) - fully redundant. Much like this post, in fact.:)
Make sure that redundant PSUs in computers are truly redundant - that is, they are completely separate all the way down to the motherboard (some use a common input bus, which is, well, stupid). If a PSU blows, it's really bad if it takes out not just one whole circuit, but both...
Use two separate phase supplies, if available, for your datacentre. Power here in Australia is three-phase; I'm sure it's similar over where you are. Often an upstream transformer blowing will knock out one of the three phases completely and leave the other two partially intact or completely intact; ensuring that you're on fairly separated circuits is a damn good thing.
Never underestimate surge protection. UPSes are great, but make sure that they isolate input power from output, and only pass through when/if passthrough knife relays are available or used (i.e. when offlining the UPS for maintenance).
Network redundancy means having separate cables, separate switches, separate NICs, separate, well, as much as the budget will allow. I've personally had to look after a system that had fully redundant switching and cabling, but then relied on single paired-outlet NICs - and the loss of one "half" of the NIC took out the whole system. This was an NT4 PDC too, and that's a bad situation to be in...
Longer term, if you're really into reliability and money becomes not much of an object, you probably want to look at having geographically separated datacentres, and again, duplication of everything at each. Eh, I can dream.:)
They're the main things. Redundancy is the key here. Did I mention that yet?
A front page slashdot article with a grand total of eight comments.
Shows what the average slashdotter thinks of "blogging"... can't say I'm surprised (and not in a negative way).
I wonder, if the term "blog" and derivatives (which I personally detest, but that's another matter for another forum...), put people off - if it had been omitted, I wonder if more people would have read and commented.
I was going to write one of these for my couple of sites, but instead, I came to the conclusion that I'd be better off disabling comments.
The more I think about it, the less I think comments are actually, you know, useful in a personal web-space of any kind. Few of the comments I get at least are of any real value, other than to indicate that either (a) I'm being spammed again or (b) someone human is actually reading my site (for which I'm always grateful, although I have other ways to find that out anyway).
Perhaps, just perhaps, we have a different definition of what perfectly means.:)
It certainly makes it easier to protect against buggy software, but I wouldn't say that a microkernel makes it impossible for a buggy program to take out the system, or for a buggy program to be rendered useless by the "right" kind of attack. And of course there's the whole issue of making your microkernel itself defect-free, but that's a whole other issue.
To make any one piece of software reliable, you need to be sure that it, in and of itself, has no major defects. Over-engineering doesn't help. Modularisation, privilege separation, chrooting, etc certainly help if your only concern is ensuring that the system's hard to break into - they don't do a heck of a lot to assure the system's availability. These things - and all the other techniques to help make software systems reliable - do not in and of themselves, or when all combined, make for software which can be considered reliable.
Even Tandem - who were, in their time, reknowned for making reliable computing software and systems, and did "all the right things" - have had their fair share of system-crippling software-induced failures. It doesn't take a security bug to bring down a system into an unusable state, and one software-reliability-related lawsuit can always be used as a precedent in any future software-reliability-related lawsuit.
(Disclaimer: I am
not a Microsoft sympathiser. I'll use whatever's best - most cost effective, reliable, whatever else defines "best" at the specific point in time, often the customer - for a given task. Sometimes, that's Windows, oftentimes not. Also, I'm no lawyer.)
As much as I'm pissed off at the most recent vulnerabilities and the problems that they've caused, I see this lawsuit as causing massive problems for the entire industry, including the open source crowd.
Should this class action go through the courts and succeed, it sets a hell of a precedent. Specifically, it implies that software should be thoroughly engineered and reasonably defect-free prior to release, with no damaging defects at the point of release. It essentially also says that releasing patches after the fact is not good enough (and that it's not the customer's responsibility to apply them), which causes two minefields I'll try and touch on later.
Trying to enforce defect-free software is a great idea - except that, as we all know, software exhibits weak-link behaviour, and that in turn suggests that you'd need to get rid of 100% of defects to be absolutely certain that no damaging defects exist. You can't over-engineer software in the way you can, say, a building, to protect against potentially damaging structural defects. Oftentimes, over-engineering software makes it more prone to the kind of defect that makes the software useless.
This precedent I percieve in turn means that the open source community - specifically, the people "managing" a given software project - are open to the same kind of litigation as, well, Microsoft are facing. I sure as hell don't want to be sued because my software's not perfect...
As for basically disregarding patches, well, that raises one major issue: it makes the vendor responsible for deploying those, which in turn either requires a "returns" policy on software (unworkable!), or requires that they have the ability to deploy software (privacy issues).
In short, this disquiets me. While I've been waiting for this kind of legal action to happen for a while, and in the long term it'll probably lead to much more reliable, much better software, I don't think the software industry as a whole is really ready for this kind of thing yet. Frankly, we still suck at making reliable software, and that's not just something Microsoft can take the hit for...
SCO are perfectly welcome to approach me. I use Linux on three workstations and two servers in my home environment.
Details on how to contact me can be found on my site, so, Darl McBride and cronies, if you want to try this on in an Australian court, you're perfectly welcome to try it on here.
Bear in mind that Australia has quite good barratry laws, but if you're happy that your case is watertight, I'll see you here.
Sorry, mate, but as much as I dislike abuse of copyright (I've had some of my own works pillaged in the past), if you don't take steps to protect it, you can assume someone will copy it and use it illegitimately.
The best you can do is chase - legally if necessary - those who steal your work, and gain whatever compensation you can. Oh, and make sure that copyright is broadly proclaimed in the first instance, too.
No, the `bot shouldn't crawl past robots.txt (rfc-ignorant, anyone?). But, given that it does, the next best bet is to IP/domain/UA block it, and/or password protect (using whatever passwords you like, if it's meant to be somewhat viewable).
It's a simple, albeit should-be-unnecessary, rule. And yes, it's sad that there are unscrupulous people out there, but that's the way it is.
Slashdot Mirror
Oh, I get it now! "We don't like free software, except on our terms - i.e. when we're using it exclusively, it's O.K., but otherwise, get rid of it already!"
Geez. They must really, really want to be disliked...
The only reason it's exported is because nobody's silly enough to drink it here.
In Australia, at least, that would land SCOG in very, very hot water (being Australian and by extension, not from the US, I don't know what the law provides for there). Claiming ownership -- and license fees -- on something you don't provably own is misrepresentation, and will see you up against the various state Offices of Fair Trading and/or the Australian Consumer and Competition Commission quicker than you can say "pay me." You can ask for donations and/or provide a service in return for payment, but you can't go around claiming rights to stuff for no material or immaterial benefit of any kind, much less threatening (veiled or otherwise) legal action if payment isn't forthcoming.
I'm still waiting for SCO Australia to try it on here. They're welcome to use me as a guinea-pig; I'd be only too happy to send a copy of all correspondence to the ACCC.
I really need to get out more.
I was beginning to wonder where they'd gone...
No, just me? Oh. Oops.
Supercruise is a fairly easy-to-understand phenomenon; in effect, it requires two things:
- lots of thrust from the powerplant;
- subsonic airflow in high quantities through the engine due to the way a "conventional" turbine operates, with slightly supersonic exhaust flows.
Normally, a turbine can't attain supercruise because of the latter; the airflow needs to be slowed considerably going through the powerplant in order to stop a shock stall (where the supersonic shockwave suffocates the powerplant).The powerplant behind the F-22 (Pratt&Whitney F119-PW-200) attains this primarily though a few good engineering tricks such as single-crystal-cast blades with a slightly shallower angle of attack than most; thus allowing the engine to operate at a higher temperature and pressure internally than is "normal". It has a lower bypass ratio (the ratio of cool air passing around the engine to that going through the engine) than most fighter-class engines; thus, it needs a smaller front fan, which in turn reduces the area causing a shock stall. It also wears out quicker, but that's another matter entirely. :)
High bypass ratios are great for fuel efficiency at subsonic speeds, but by virtue of the way these turbines work and their tendency to shock-stall when confronted with a supersonic airflow, are not much good for supersonic flight, and not for the nearly-supersonic airflows that supercruise requires.
A typical mid-to-high bypass turbine used in a fighter will have a bleed air system to reduce the airspeed running through the turbine; this has to be counteracted by dumping raw fuel into the bypass & exhaust (i.e. afterburner). Indeed, to get much over M1.0 the F22 needs to employ this same trick. A low bypass turbine can operate with input airspeeds closer to M1.0, which in turn means less air needs to be bled, while still producing a slightly supersonic exhaust out the rear end.
Or larger breasts for that matter...
Touch screen display. Rather than fishing around for the right key on a QWERTY or dv keyboard to push to do a given task, or fiddle with a touchpad...
Excellent point. I've been through similar (cane farmer putting a disc through a fairly shallow cable!), so rather disappointed that I forgot about it.
Never take manufacturer's reliability figures with less than an entire salt mine full of salt. Systems always fail more often than quoted.
Never underestimate the power of full backups, and preferably a standing image in GHOST format or similar of each critical system. Being able to restore a machine without having to sit through an install will help your sanity infinitely.
- Never, ever overload a UPS. Bear in mind, in fact, that as UPSen age, the alternate supplies (typically gel batteries) degrade in performance, and so "100%" when new becomes "110%" when about three to four years old. The rule of thumb we use here is no more than 60% load on any UPS.
- Make everything - everything critical to the mission, that is (power to building, UPSen, generators, network kit, servers, disks) - fully redundant. Much like this post, in fact.
:)
- Make sure that redundant PSUs in computers are truly redundant - that is, they are completely separate all the way down to the motherboard (some use a common input bus, which is, well, stupid). If a PSU blows, it's really bad if it takes out not just one whole circuit, but both...
- Use two separate phase supplies, if available, for your datacentre. Power here in Australia is three-phase; I'm sure it's similar over where you are. Often an upstream transformer blowing will knock out one of the three phases completely and leave the other two partially intact or completely intact; ensuring that you're on fairly separated circuits is a damn good thing.
- Never underestimate surge protection. UPSes are great, but make sure that they isolate input power from output, and only pass through when/if passthrough knife relays are available or used (i.e. when offlining the UPS for maintenance).
- Network redundancy means having separate cables, separate switches, separate NICs, separate, well, as much as the budget will allow. I've personally had to look after a system that had fully redundant switching and cabling, but then relied on single paired-outlet NICs - and the loss of one "half" of the NIC took out the whole system. This was an NT4 PDC too, and that's a bad situation to be in...
- Longer term, if you're really into reliability and money becomes not much of an object, you probably want to look at having geographically separated datacentres, and again, duplication of everything at each. Eh, I can dream.
:)
They're the main things. Redundancy is the key here. Did I mention that yet?Shows what the average slashdotter thinks of "blogging"... can't say I'm surprised (and not in a negative way).
I wonder, if the term "blog" and derivatives (which I personally detest, but that's another matter for another forum...), put people off - if it had been omitted, I wonder if more people would have read and commented.
The more I think about it, the less I think comments are actually, you know, useful in a personal web-space of any kind. Few of the comments I get at least are of any real value, other than to indicate that either (a) I'm being spammed again or (b) someone human is actually reading my site (for which I'm always grateful, although I have other ways to find that out anyway).
It certainly makes it easier to protect against buggy software, but I wouldn't say that a microkernel makes it impossible for a buggy program to take out the system, or for a buggy program to be rendered useless by the "right" kind of attack. And of course there's the whole issue of making your microkernel itself defect-free, but that's a whole other issue.
To make any one piece of software reliable, you need to be sure that it, in and of itself, has no major defects. Over-engineering doesn't help. Modularisation, privilege separation, chrooting, etc certainly help if your only concern is ensuring that the system's hard to break into - they don't do a heck of a lot to assure the system's availability. These things - and all the other techniques to help make software systems reliable - do not in and of themselves, or when all combined, make for software which can be considered reliable.
Even Tandem - who were, in their time, reknowned for making reliable computing software and systems, and did "all the right things" - have had their fair share of system-crippling software-induced failures. It doesn't take a security bug to bring down a system into an unusable state, and one software-reliability-related lawsuit can always be used as a precedent in any future software-reliability-related lawsuit.
Should this class action go through the courts and succeed, it sets a hell of a precedent. Specifically, it implies that software should be thoroughly engineered and reasonably defect-free prior to release, with no damaging defects at the point of release. It essentially also says that releasing patches after the fact is not good enough (and that it's not the customer's responsibility to apply them), which causes two minefields I'll try and touch on later.
Trying to enforce defect-free software is a great idea - except that, as we all know, software exhibits weak-link behaviour, and that in turn suggests that you'd need to get rid of 100% of defects to be absolutely certain that no damaging defects exist. You can't over-engineer software in the way you can, say, a building, to protect against potentially damaging structural defects. Oftentimes, over-engineering software makes it more prone to the kind of defect that makes the software useless.
This precedent I percieve in turn means that the open source community - specifically, the people "managing" a given software project - are open to the same kind of litigation as, well, Microsoft are facing. I sure as hell don't want to be sued because my software's not perfect...
As for basically disregarding patches, well, that raises one major issue: it makes the vendor responsible for deploying those, which in turn either requires a "returns" policy on software (unworkable!), or requires that they have the ability to deploy software (privacy issues).
In short, this disquiets me. While I've been waiting for this kind of legal action to happen for a while, and in the long term it'll probably lead to much more reliable, much better software, I don't think the software industry as a whole is really ready for this kind of thing yet. Frankly, we still suck at making reliable software, and that's not just something Microsoft can take the hit for...
Oh, and apparently EFA are there purely to support the "immoral" industries... go figure.
Yes, the anti-spam bill is a good step, but he's still a Luddite.
Details on how to contact me can be found on my site, so, Darl McBride and cronies, if you want to try this on in an Australian court, you're perfectly welcome to try it on here.
Bear in mind that Australia has quite good barratry laws, but if you're happy that your case is watertight, I'll see you here.
I await your contact.
a faster tapwould require a faster pipe.
Two words: profit margin.
I'm sure they can sell 1.1's for the price of 2.0's (but buy them for the price of 1.1's) if they mislead the public through clever marketing.
"There, isn't that better? I mean, at least you can't feel your finger any more..."
Thanks, I'll be here all week.
The best you can do is chase - legally if necessary - those who steal your work, and gain whatever compensation you can. Oh, and make sure that copyright is broadly proclaimed in the first instance, too.
No, the `bot shouldn't crawl past robots.txt (rfc-ignorant, anyone?). But, given that it does, the next best bet is to IP/domain/UA block it, and/or password protect (using whatever passwords you like, if it's meant to be somewhat viewable).
It's a simple, albeit should-be-unnecessary, rule. And yes, it's sad that there are unscrupulous people out there, but that's the way it is.