At least a couple of motorcycle makers (notably the french Megola) in the '30s produced engines within the wheel rim. They used a fixed crankshaft and revolving cylinders built into the wheel. A couple thousand such units were produced.
Low horsepower diesel-electric is probably well suited to inner-city bus service, allowing batteries to charge during the frequent stops. I have no idea whether this is likely to become practical for other vehicle classes.
Then you (like the pos(t)er of this article and most of the comments) probably don't follow what the value is here.
Maintaining high performance code across cpu achitectures is bad enough (and I know of some supercomputing centers which are continuing with technically inferior AMD64/Xeon clusters rather than switch to PPC970 precisely because they know they can't afford to re-optimize for that arch).
Factor in that today most numerically intensive code is still written in FORTRAN because competing languages simply can't be as easily optimized.
Now let's think about SMP, while POSIX threads are portable, the best performace probably requires different threading code depending on arch/unix varriant. (And of course NPTL for linux is still in CVS.)
Now let's think about massively parallel, where inter-cpu communication will be handled a bit differently on every platform.
So the payoffs to developing an efficient cross-platform language layer are pretty substantial. (Which does not imply that I expect IBM to jump on to Sun's bandwagon on this:-))
Read the decision, and the dissenting opinions, all of which are distinct in delineating what is and is not the court's defined role.
Interpreting Laws (and sometimes) refferenda are very much the role of the courts. In this particular instance it is the MA SJC court, which like the US Supreme Court gets to determine questions pertaining to the Commonwealth's constitution.
As for the question of who I should be paying attention to with respect to my individual freedoms I personally place far higher faith in the courts than I do our legislatures, which in my experience routinely pass bad (in the sense of unconstitutional, ambiguously worded.....) statutes.
I suggest you read the Massachusetts SJC decision (which is more strongly worded than the earlier Vermont decision in specifically designating the term *marriage*).
It is clear in that it does not affect religious union or compel any church to marry any couple (same by the way as with heterosexual marriage).
It is also clear that the decision is specifically concerned with the civil aspects of marriage (which are the only aspects under the jurisdition of the state anyway).
As for forcing beliefs on others, it is my observation that the principal opponents of this decision are indeed certain churches who are lobbying hard for a constitutional ammendment. (Being as it is fairly clear that a majority of the residents of MA favor this change I doubt that that will be passing.)
$700/cpu extortion as a one-time fee is small potatoes compared against the alternatives. Windows and Unix licenses cost more than that up front. And purchase cost is dwarfed against annual maintenance/support fees, whether done in house or paid to a third party.
If Linux has an advantage, it's the impressive pace of development of both the kernel and dependent application software (both free and proprietary) that runs on it.
While I'm certain that some deployments have been affected, I'm equally certain that the degree of press attention and analysis has made Linux just that much more visible, which will probably turn out to be a good thing[tm] over the long haul.
As somebody suggested above, the likely actual motivation for this is probably Mitnick's restriction from profiting on describing his own criminal activities.
As I see it Mitnick remains of the same mindset as when he first showed off his cracking skills to a group of peers and was surprised when they turned him in.
Among his various complaints about his treatment by the Feds are that he was held without bail (gee, can you say 'established flight-risk'?), and that they held onto all of his computers (gee, after he declined to provide the encryption keys needed to access them as evidence?).
He's also clear about being bitter toward the author of 'Takedown' (advice, "never get in an argument with someone who buys ink by the barrel and paper by the train-car") and Shimomura(sp?) (Let's see, you break into lots of machines, eventually you come up against someone better'n you and now you complain that they exact some revenge?)
His notoriety seemingly guarantees a certain audience for he and his publisher to profit.
Personally I've got no desire to help this guy along. In the excerpts from his book he has the brass to include himself in the 'hacker' ethic of places like LCS, Berkeley, JPL. Sorry, that image doesn't pass.
Ahh I see you're right, clearly I didn't rtfa closely enough. It was obvious enough that all of the x86 things were vpc, I'd figured that the OS's noted that are ppc-capable were running native.
The corollary is that a craftsman will also ensure that he has the right tool for the job at hand.
I happen to agree with the article / Tufte, Powerpoint is not the right tool for any job except 'sales'. (Big surprise that Microsoft's got a better knack for packaging a sales pitch than useful technology?).
You may not agree with the article but that was its thrust.
A synflood is an attack on CPU resources, not bandwidth.
TCP is a stateful protocol. This means that the kernel of the target machine needs to allocate memory for each connection (about a K @ if memory serves)
Even with countermeasures in place (e.g. syncookies) the target needs to devote some resources (exercise left to the reader) to each incoming SYN.
Thus, yes it is quite possible to effectively shutdown a target without cutting off bandwidth. See also the CAIDA graph where they show the FTP server coming under an identical attack later.
if it was a DDOS, who did it?...Maybe somebody with a DS3 or two available
a. Kiddies (self-labeled elite hackers) break into machines (perhaps machines rooted by viri/worms they had nothing to do with).
b. These 'owned' machines have a control channel either to the worm author(s) or whatever lowlife manages to wrest control, usually irc.
c. Upload ddos agent and switch it on.
Of course the system owners will often notice *something* has gone wrong and either shut the attack slaves down or if they're a bit sharper realize they're owned and fix it but I imagine most of 'em come back up still infected, ready for next time.
Yes, SCO are pretty low on the karma totem, however the 'experts' quoted on groklaw, as well as the far more numerous 'experts' who replied that yes they must be faking it.... were drawing their speculations on very little data.
If you cared to measure you sure didn't need to be CAIDA, many snort, pf and netfilter logs are showing the backscatter of this attack.
And to all the experts who've been holding that a large synflood is easy to fix by blocking the attacker IPs: get a fscking clue.
Both syn and bandwidth attacks use forged addresses children (which is why there is backscatter), each incoming syn is from a random IP, the ack goes to the forged addr, not the originator.
The best way I've seen to handle this involves sensors at enough upstream locations to measure the packet count ratio skewing which results. This isn't generally deployed
Now technically SCO could probably manage to forge that kind of data (just send out all the expected response traffic) but again there are enough sensor platforms out there now that such a deception would certainly be unmasked eventually.
Aircraft use HUD's principally because there is so much information the pilot needs to have. Especially flying IFR the pilot is *only* relying on the equipment for control of the aircraft. Current production commercial aircraft now use displays which give the pilot direct view of the controls he needs at any given time to improve reaction times and reduce stress.
This is not even vaguely related to the conditions of riding a motorcycle (or bicycle), where the rider needs to be continuously evaluating what cage driver may not see him/her, road surface conditions, etc. Yes, you have to look at the guages also but that's a hell of a lot less important than the continuous sweep of your riding environment for where's the next hazard.
I do 10k miles annually riding mostly in Boston, year round in all weather conditions and have exactly one accident, courtesy of a limo-driver who ran a Stop sign. I'll pass on the HUD device thanks.
XFS has been in service with SGI for over a decade. Arguably it has seen more heavy duty action than most every other filesystem in Linux.
Not quite. "In late 1994, SGI released an advanced, journaled file system called XFS on IRIX"> I was managing SGI engineering stations ca '96 when sgi's workstations still by default installed efs. At that time I had been streaming engineering analysis data 24x7 on rs/6000-jfs for months at a time since '93 (when we thought of continuous read/write at 5MB/s as fast:-)) JFS was released with rs/6000/aix3.1 in 1990.
I have to wonder what all Gentoo is doing in their kernel.
I know what all cruft gentoo puts in thier kernel, yes that's probably the culprit in the gentoo case. This has nothing to do with my point, that XFS is liable to lose data in crash / powerloss situations.
Indeed. Would those be the kids at fermilab... [snip]
Obviously not, from my post it should be clear I agree XFS is a good choice for server environments (AC, UPS...). Not so (repeat *imx*) joe blow running it on the gaming box in his bedroom.
Please also offer some pointers on which parts of the "interface" you feel should be cleaned up.
Again obviously that would be Marcello's call, I believe he mentioned xfs touching things he doesn't want touched.
I remember SGI trying and failing to get the audit hooks they wanted into LSM, and moaning bitterly about the process when they were told unequivocally that the kernel devs would not acceped the 300 necessary additional hooks (This because these couldn't be implemented without a combination of semantics changes to existing syscalls, and performance penalties incurred even to users not utilizing the audit functionality.)
We only recommend using this filesystem on Linux systems with high-end SCSI and/or fibre channel storage and a uninterruptible power supply. Because XFS aggressively caches in-transit data in RAM, improperly designed programs (those that don't take proper precautions when writing files to disk and there are quite a few of them) can lose a good deal of data if the system goes down unexpectedly.
And this from one of the more bleeding-edge dists no less.
The kernel maintainers have been clear on their reasons *not* accepting xfs into linus's tree (see prior posts in this thread). Considering that so many of the people who clamor for xfs (imx) are kids who're principally attracted to it's rep for high performance, yet have no concept of the tradeoffs delineated above -- well I can see why it's not being accepted into mainline. I'm sure if SGI actually cleans up the interface it'll go in but who knows if _that_ will ever happen.
Marcello on XFS:
JFS did not touch generic code as I remember.....
Come one, it is not so hard to maintain a patch in a distros kernel.....
Distros maintain hundreds of patches (even I did maintain hundreds of
patches while maintaining Conectiva's RPM). One more patch is not that
hard....
Fine, so people who want XFS go compile 2.6.0 by hand. I'm using test11 on
several boxes and its working very well.....
Also I'm not completly sure if the generic changes are fine and I dont like the XFS code in general.
Are there sysadmins who've never coded, not highly skilled at what they do who are a drag to work with? Of course. Sysadmins run the gamut, the best (and probably most productive) have enough coding experience to know and work with the dev side also. The very best can run circles around the average dev imx. Naturally the very best devs are int the same class.
There are just as many 'developers' who don't have the first idea how to perform adequate testing, let along consider the constraints of running in a production environment let alone writing portable, consistent or maintainable code.
The author of this article is quick to bitch about a sysadmin losing his working files. Sure it happens. What the hell is with a developer who doesn't bother to keep any working copies of 2 weeks work? (In my own time managing a corp. network I'm pleased to be able to say I had exactly one instance of unrecoverable data loss -- where two users hadn't realized that NFS did not provide pc clients with any form of locking)
As a distribution maintainer (lunar) I see several OSS packages a week breaking reasonble build schemes or changing thier tarballs, (breaking MD5/PGP checks) without updating version info. So I'm sorry but there are no shortage of sloppy developers out there.
In my own engineering practice I've found over the years that all work goes better if the people doing it know they'll be held accountable for it over the long haul. Too many devs are allowed to get away with a 'throw it over the wall' mentality, going on to the next project and never having to deal with some of their cruft. Of course the same logic applies to the sysadms, I've seen lots of the behaviors the article rants about it but I gotta say ranting and pointing fingers ain't the solution.
Neither article mentions boo about safety or privacy.
As already pointed out, this is entirely about an attempt to control cost, providing the contractors a tool to measure miles.
Given the task of monitoring the routes covered by a thousand contractors' trucks it sounds like a decent solution too.
Yes I live in boston, and we're about to get hammered by a predicted 16"+ of snow. Oh joy
Re:SCO seems uneducated about IP rights
on
SCOrched Earth
·
· Score: 1
Actually I can't offhand remember ever seeing SCO specifically say anything about GPL's 'viral' nature.
I have (many times) heard GPL described as 'viral', by Microsoft, a certain number of BSD users, and a bunch of others.
A license is just a tool, as I said above the same tool is used differently by different authors. The GPL is undoubtedly 'viral' depending on how it's used. Nothing in GPL, for instance prevents the copyright holder from using dual-license, or explicitly allowing users to do so.
And some of the underpinnings are a bit shakey these days. GPL2 was, after all written with careful distinctions about linking and the difference between 'aggregation' and 'derivative work'. And back when nearly all functional distribution was in binary form. That's not applicable of course to things like scripted languages
The GPL's distinction between static and dynamic linking. It seems clear to me that I could construct cases where dynamically linked code is *or* is not a derivative work, and similarly, cases where static linking of libraries would not necessarily entail a derivative work.
When GPLv2 was written (1991) static linking was probably a decent guideline (dynamic linking may've existed then but it was not anywhere near as heavily used today). Today I'm not sure this distinction is as it was back then. I am sure that Linus, for instance 'gets' the distinctions. He's very clear that non-GPL kernel modules must not in fact be derivative works of Linux.
SCO seems uneducated about IP rights
on
SCOrched Earth
·
· Score: 5, Interesting
From the Lessig commentary:
If he chooses to give his property away, that does not make it any less a property right. If he chooses to sell it for $1,000,000, that doesn't make it any less a property right. And if he chooses to license it on the condition that source code be made free, that doesn't make it any less a property right.
Precedent: Rudolf Diesel patented the Diesel cycle engine in 1898. One of the reasons that the far less efficent Otto cycle (4-stroke gasoline) engine was/is more widely deployed is that Diesel would only license his patent for what he considered 'best use', requiring that Diesel engines must inject fuel continuously into the combustion chamber thoughout the combustion/power stroke.
This dictated a much lower power:weight ratio in early Diesel engines, which is appropriate to stationary power genaration but represented a distinct disadvantage for traction-power and automotive use.
Diesel's approach to license was probably not the most lucrative either for himself or society at large, however the *property right* granted by patent (and copyright) law let him make that determination.
To my mind whether commercial EULA, BSD, GPL, Artistic, all licenses fundamentally serve the purpose of allowing the *Author* a degree of control over the application and distribution of his/her work.
This is also how we get an OSS environment where two different Authors (say Linus Torvalds and Richard Stallman) have the right to apply the same license (GPL) according to their own wishes.
Process rights are a good thing. SCO's making the best case it can but I really think it's going to backfire on them. Their rhetoric really doesn't stand up to analysis.
I'm not so sure that keypair enforcement (unless it were enforced globally) would have helped in this instance, it seems that this developer's password was gotten when he gave it on a hacked box. Yes, skey/opie would serve, so would kerberized rlogin.
Of course there seems to be no better way to grab the ire of todays average crop of open / free software developers than to suggest that anything other than ssh is the correct solution to a problem.
In this instance to the best of our knowlege enforcing the use of cleartext protocols with encrypted authentication could have helped prevent the situation (e.g. as you say opie/skey over telnet or kerberized rlogin)
Additionally iff development work had been done over plaintext then all developer sessions could have been captured with snort/tcpdump and then the methods used by the miscreants would be accessible.
Of course your better class of miscreant is going to recognize this, but that's just part of the game.
It's a pretty sad thing that we're left with such a dilemma, I'm sorry to see it happen to the Debian project, simply because so many folks rely on it. Talk about putting the whole community on the horns of a dilemma (quadrilemma?):
Unknown kernel exploit --- details sometime?
There is some other hole introduced in the debian machines (side-note, it's odd/interesting that deb servers are seemingly running kernels not distributed by the debian project)
An attacker suffieciently inept to have been discovered in 24 hrs has access to one of the above two posited exploits.
(least palatable) These machines were priorly penetrated and the miscreant's have had an opportunity to place backdoors into Deb.
I beleive the additional details of this exploit are roughly:
A debian developer (who I'm not going to name but it's not exactly a secret) revealed his password by logging into some machine that had been rooted. Shame on him for using the same password, and the Debian project for not policing that kind of thing. (That said, people do this all the time, even people who do/ought to know better.)
The password 'sniffing' being referenced is not sniffing network packets but rather session IO. If you read the 'developer cleanup' instructions it will be clear that they beleive that the 4 dev boxes that were rooted were being used to collect account and password info from developer's sessions. (Another procedure error, the systems in question probably should not be allowing users with shell access to ssh out to other machines.)
There has been a LOT of speculation that there's a privilege-escalation vulnerability in the kernel version running on the target systems and/or up to the 2.4.22 kernel (I'm dubious, however 2.4.23 has just been released today so who knows).
As many here and elsewhere have wondered, it seems unlikely that a 'kiddie would have access to somthing not yet observed in the wild, and if this is the work of more capable 'bad guys' then it seems equally unlikely that they would have been so noisy as to have been caught in less than a day.
Leaving us really not knowing much about the state of either debian or the kernel at this time. I certainly hope that a more complete complete 'explantaion' will be coming, hopefully soon.
2. Gut the plot, Chapters involving nuance (Bombadil, Scouring of the Shire) are removed. Reduce all cast memebers outside fo the original fellowship to 1-dimensional supporting roles. (Denethor and sons as an '80's flavor dysfunctional family? please!)
3. Release EE's to rake in money from the more die-hard fans, replete with further plot deviations.
4. Enlarge Liv Tyler's <gag> role to be big enough to sign her sorry ass to the film.
Sorry, for my money (and Newline won't be getting any more of it) the Matrix trilogy as *film* stands head and shoulders over what they've done to Tolkein's work. The Fellowship film was well done IMO, the Two Towers film less so and my expectations for the final... well I'm not going.
Is actually far easier said than done. In all of the instances cited, the linux/bsd organizations create their own signatures. They never reside on the machine which hosts the source tarball.
Additionally, distribution of the MD5 database and the sources is separate. This means that a very large number of end-users have recieved MD5's that were *at the time* trusted.
So how is an attacker going to get around this? Simply put, it's going to be a challenge.
All the systems I know send out the checksum data separate from the source code (and obviously doing it the other way would be a weakness). Temporal distance is the key here.
In response to the other reply here, sure pgp sig anchoring the whole thing is great, but poorly implemented pgp is no panacea
Slashdot Mirror
Low horsepower diesel-electric is probably well suited to inner-city bus service, allowing batteries to charge during the frequent stops. I have no idea whether this is likely to become practical for other vehicle classes.
Maintaining high performance code across cpu achitectures is bad enough (and I know of some supercomputing centers which are continuing with technically inferior AMD64/Xeon clusters rather than switch to PPC970 precisely because they know they can't afford to re-optimize for that arch).
Factor in that today most numerically intensive code is still written in FORTRAN because competing languages simply can't be as easily optimized.
Now let's think about SMP, while POSIX threads are portable, the best performace probably requires different threading code depending on arch/unix varriant. (And of course NPTL for linux is still in CVS.)
Now let's think about massively parallel, where inter-cpu communication will be handled a bit differently on every platform.
So the payoffs to developing an efficient cross-platform language layer are pretty substantial. (Which does not imply that I expect IBM to jump on to Sun's bandwagon on this :-))
Read the decision, and the dissenting opinions, all of which are distinct in delineating what is and is not the court's defined role.
Interpreting Laws (and sometimes) refferenda are very much the role of the courts. In this particular instance it is the MA SJC court, which like the US Supreme Court gets to determine questions pertaining to the Commonwealth's constitution.
As for the question of who I should be paying attention to with respect to my individual freedoms I personally place far higher faith in the courts than I do our legislatures, which in my experience routinely pass bad (in the sense of unconstitutional, ambiguously worded .....) statutes.
It is clear in that it does not affect religious union or compel any church to marry any couple (same by the way as with heterosexual marriage).
It is also clear that the decision is specifically concerned with the civil aspects of marriage (which are the only aspects under the jurisdition of the state anyway).
As for forcing beliefs on others, it is my observation that the principal opponents of this decision are indeed certain churches who are lobbying hard for a constitutional ammendment. (Being as it is fairly clear that a majority of the residents of MA favor this change I doubt that that will be passing.)
Linux will remain the better financial choice.
$700/cpu extortion as a one-time fee is small potatoes compared against the alternatives. Windows and Unix licenses cost more than that up front. And purchase cost is dwarfed against annual maintenance/support fees, whether done in house or paid to a third party.
If Linux has an advantage, it's the impressive pace of development of both the kernel and dependent application software (both free and proprietary) that runs on it.
While I'm certain that some deployments have been affected, I'm equally certain that the degree of press attention and analysis has made Linux just that much more visible, which will probably turn out to be a good thing[tm] over the long haul.
As I see it Mitnick remains of the same mindset as when he first showed off his cracking skills to a group of peers and was surprised when they turned him in.
Among his various complaints about his treatment by the Feds are that he was held without bail (gee, can you say 'established flight-risk'?), and that they held onto all of his computers (gee, after he declined to provide the encryption keys needed to access them as evidence?).
He's also clear about being bitter toward the author of 'Takedown' (advice, "never get in an argument with someone who buys ink by the barrel and paper by the train-car") and Shimomura(sp?) (Let's see, you break into lots of machines, eventually you come up against someone better'n you and now you complain that they exact some revenge?)
His notoriety seemingly guarantees a certain audience for he and his publisher to profit.
Personally I've got no desire to help this guy along. In the excerpts from his book he has the brass to include himself in the 'hacker' ethic of places like LCS, Berkeley, JPL. Sorry, that image doesn't pass.
Microsoft is going to become more centralized to better compete with a competitor based highly distributed, decentralized development.
I'm amused, of course the proof will be in the bits.
doh
A friend who's got a tibook mentiond recently that the only v. of linux that doesn't void Apple's warranty is Yellow Dog.
The corollary is that a craftsman will also ensure that he has the right tool for the job at hand. I happen to agree with the article / Tufte, Powerpoint is not the right tool for any job except 'sales'. (Big surprise that Microsoft's got a better knack for packaging a sales pitch than useful technology?). You may not agree with the article but that was its thrust.
A synflood is an attack on CPU resources, not bandwidth.
TCP is a stateful protocol. This means that the kernel of the target machine needs to allocate memory for each connection (about a K @ if memory serves)
Even with countermeasures in place (e.g. syncookies) the target needs to devote some resources (exercise left to the reader) to each incoming SYN.
Thus, yes it is quite possible to effectively shutdown a target without cutting off bandwidth. See also the CAIDA graph where they show the FTP server coming under an identical attack later.
if it was a DDOS, who did it?...Maybe somebody with a DS3 or two available
a. Kiddies (self-labeled elite hackers) break into machines (perhaps machines rooted by viri/worms they had nothing to do with).
b. These 'owned' machines have a control channel either to the worm author(s) or whatever lowlife manages to wrest control, usually irc.
c. Upload ddos agent and switch it on.
Of course the system owners will often notice *something* has gone wrong and either shut the attack slaves down or if they're a bit sharper realize they're owned and fix it but I imagine most of 'em come back up still infected, ready for next time.
Yes, SCO are pretty low on the karma totem, however the 'experts' quoted on groklaw, as well as the far more numerous 'experts' who replied that yes they must be faking it .... were drawing their speculations on very little data.
If you cared to measure you sure didn't need to be CAIDA, many snort, pf and netfilter logs are showing the backscatter of this attack.
And to all the experts who've been holding that a large synflood is easy to fix by blocking the attacker IPs: get a fscking clue.
Both syn and bandwidth attacks use forged addresses children (which is why there is backscatter), each incoming syn is from a random IP, the ack goes to the forged addr, not the originator.
The best way I've seen to handle this involves sensors at enough upstream locations to measure the packet count ratio skewing which results. This isn't generally deployed
Now technically SCO could probably manage to forge that kind of data (just send out all the expected response traffic) but again there are enough sensor platforms out there now that such a deception would certainly be unmasked eventually.
This is not even vaguely related to the conditions of riding a motorcycle (or bicycle), where the rider needs to be continuously evaluating what cage driver may not see him/her, road surface conditions, etc. Yes, you have to look at the guages also but that's a hell of a lot less important than the continuous sweep of your riding environment for where's the next hazard.
I do 10k miles annually riding mostly in Boston, year round in all weather conditions and have exactly one accident, courtesy of a limo-driver who ran a Stop sign. I'll pass on the HUD device thanks.
Not quite. "In late 1994, SGI released an advanced, journaled file system called XFS on IRIX"> I was managing SGI engineering stations ca '96 when sgi's workstations still by default installed efs. At that time I had been streaming engineering analysis data 24x7 on rs/6000-jfs for months at a time since '93 (when we thought of continuous read/write at 5MB/s as fast :-)) JFS was released with rs/6000/aix3.1 in 1990.
I know what all cruft gentoo puts in thier kernel, yes that's probably the culprit in the gentoo case. This has nothing to do with my point, that XFS is liable to lose data in crash / powerloss situations.
Indeed. Would those be the kids at fermilab ... [snip]
Obviously not, from my post it should be clear I agree XFS is a good choice for server environments (AC, UPS...). Not so (repeat *imx*) joe blow running it on the gaming box in his bedroom.
Please also offer some pointers on which parts of the "interface" you feel should be cleaned up.
Again obviously that would be Marcello's call, I believe he mentioned xfs touching things he doesn't want touched.
I remember SGI trying and failing to get the audit hooks they wanted into LSM, and moaning bitterly about the process when they were told unequivocally that the kernel devs would not acceped the 300 necessary additional hooks (This because these couldn't be implemented without a combination of semantics changes to existing syscalls, and performance penalties incurred even to users not utilizing the audit functionality.)
Sounds like a similar case.
The kernel maintainers have been clear on their reasons *not* accepting xfs into linus's tree (see prior posts in this thread). Considering that so many of the people who clamor for xfs (imx) are kids who're principally attracted to it's rep for high performance, yet have no concept of the tradeoffs delineated above -- well I can see why it's not being accepted into mainline. I'm sure if SGI actually cleans up the interface it'll go in but who knows if _that_ will ever happen.
Marcello on XFS:
Are there sysadmins who've never coded, not highly skilled at what they do who are a drag to work with? Of course. Sysadmins run the gamut, the best (and probably most productive) have enough coding experience to know and work with the dev side also. The very best can run circles around the average dev imx. Naturally the very best devs are int the same class.
There are just as many 'developers' who don't have the first idea how to perform adequate testing, let along consider the constraints of running in a production environment let alone writing portable, consistent or maintainable code.
The author of this article is quick to bitch about a sysadmin losing his working files. Sure it happens. What the hell is with a developer who doesn't bother to keep any working copies of 2 weeks work? (In my own time managing a corp. network I'm pleased to be able to say I had exactly one instance of unrecoverable data loss -- where two users hadn't realized that NFS did not provide pc clients with any form of locking)
As a distribution maintainer (lunar) I see several OSS packages a week breaking reasonble build schemes or changing thier tarballs, (breaking MD5/PGP checks) without updating version info. So I'm sorry but there are no shortage of sloppy developers out there.
In my own engineering practice I've found over the years that all work goes better if the people doing it know they'll be held accountable for it over the long haul. Too many devs are allowed to get away with a 'throw it over the wall' mentality, going on to the next project and never having to deal with some of their cruft. Of course the same logic applies to the sysadms, I've seen lots of the behaviors the article rants about it but I gotta say ranting and pointing fingers ain't the solution.
As already pointed out, this is entirely about an attempt to control cost, providing the contractors a tool to measure miles.
Given the task of monitoring the routes covered by a thousand contractors' trucks it sounds like a decent solution too.
Yes I live in boston, and we're about to get hammered by a predicted 16"+ of snow. Oh joy
I have (many times) heard GPL described as 'viral', by Microsoft, a certain number of BSD users, and a bunch of others.
A license is just a tool, as I said above the same tool is used differently by different authors. The GPL is undoubtedly 'viral' depending on how it's used. Nothing in GPL, for instance prevents the copyright holder from using dual-license, or explicitly allowing users to do so.
And some of the underpinnings are a bit shakey these days. GPL2 was, after all written with careful distinctions about linking and the difference between 'aggregation' and 'derivative work'. And back when nearly all functional distribution was in binary form. That's not applicable of course to things like scripted languages
The GPL's distinction between static and dynamic linking. It seems clear to me that I could construct cases where dynamically linked code is *or* is not a derivative work, and similarly, cases where static linking of libraries would not necessarily entail a derivative work.
When GPLv2 was written (1991) static linking was probably a decent guideline (dynamic linking may've existed then but it was not anywhere near as heavily used today). Today I'm not sure this distinction is as it was back then. I am sure that Linus, for instance 'gets' the distinctions. He's very clear that non-GPL kernel modules must not in fact be derivative works of Linux.
Precedent: Rudolf Diesel patented the Diesel cycle engine in 1898. One of the reasons that the far less efficent Otto cycle (4-stroke gasoline) engine was/is more widely deployed is that Diesel would only license his patent for what he considered 'best use', requiring that Diesel engines must inject fuel continuously into the combustion chamber thoughout the combustion/power stroke.
This dictated a much lower power:weight ratio in early Diesel engines, which is appropriate to stationary power genaration but represented a distinct disadvantage for traction-power and automotive use.
Diesel's approach to license was probably not the most lucrative either for himself or society at large, however the *property right* granted by patent (and copyright) law let him make that determination.
To my mind whether commercial EULA, BSD, GPL, Artistic, all licenses fundamentally serve the purpose of allowing the *Author* a degree of control over the application and distribution of his/her work.
This is also how we get an OSS environment where two different Authors (say Linus Torvalds and Richard Stallman) have the right to apply the same license (GPL) according to their own wishes.
Process rights are a good thing. SCO's making the best case it can but I really think it's going to backfire on them. Their rhetoric really doesn't stand up to analysis.
Of course there seems to be no better way to grab the ire of todays average crop of open / free software developers than to suggest that anything other than ssh is the correct solution to a problem.
In this instance to the best of our knowlege enforcing the use of cleartext protocols with encrypted authentication could have helped prevent the situation (e.g. as you say opie/skey over telnet or kerberized rlogin)
Additionally iff development work had been done over plaintext then all developer sessions could have been captured with snort/tcpdump and then the methods used by the miscreants would be accessible.
Of course your better class of miscreant is going to recognize this, but that's just part of the game.
It's a pretty sad thing that we're left with such a dilemma, I'm sorry to see it happen to the Debian project, simply because so many folks rely on it. Talk about putting the whole community on the horns of a dilemma (quadrilemma?):
A debian developer (who I'm not going to name but it's not exactly a secret) revealed his password by logging into some machine that had been rooted. Shame on him for using the same password, and the Debian project for not policing that kind of thing. (That said, people do this all the time, even people who do/ought to know better.)
The password 'sniffing' being referenced is not sniffing network packets but rather session IO. If you read the 'developer cleanup' instructions it will be clear that they beleive that the 4 dev boxes that were rooted were being used to collect account and password info from developer's sessions. (Another procedure error, the systems in question probably should not be allowing users with shell access to ssh out to other machines.)
There has been a LOT of speculation that there's a privilege-escalation vulnerability in the kernel version running on the target systems and/or up to the 2.4.22 kernel (I'm dubious, however 2.4.23 has just been released today so who knows).
As many here and elsewhere have wondered, it seems unlikely that a 'kiddie would have access to somthing not yet observed in the wild, and if this is the work of more capable 'bad guys' then it seems equally unlikely that they would have been so noisy as to have been caught in less than a day.
Leaving us really not knowing much about the state of either debian or the kernel at this time. I certainly hope that a more complete complete 'explantaion' will be coming, hopefully soon.
2. Gut the plot, Chapters involving nuance (Bombadil, Scouring of the Shire) are removed. Reduce all cast memebers outside fo the original fellowship to 1-dimensional supporting roles. (Denethor and sons as an '80's flavor dysfunctional family? please!)
3. Release EE's to rake in money from the more die-hard fans, replete with further plot deviations.
4. Enlarge Liv Tyler's <gag> role to be big enough to sign her sorry ass to the film.
Sorry, for my money (and Newline won't be getting any more of it) the Matrix trilogy as *film* stands head and shoulders over what they've done to Tolkein's work. The Fellowship film was well done IMO, the Two Towers film less so and my expectations for the final ... well I'm not going.
Is actually far easier said than done. In all of the instances cited, the linux/bsd organizations create their own signatures. They never reside on the machine which hosts the source tarball.
Additionally, distribution of the MD5 database and the sources is separate. This means that a very large number of end-users have recieved MD5's that were *at the time* trusted.
So how is an attacker going to get around this? Simply put, it's going to be a challenge.
All the systems I know send out the checksum data separate from the source code (and obviously doing it the other way would be a weakness). Temporal distance is the key here.
In response to the other reply here, sure pgp sig anchoring the whole thing is great, but poorly implemented pgp is no panacea