It is the default in many unix-like systems
OpenBSD's ports include source signatures, I assume the other BSDs do the same.
Lunar and smgl (the forks of sorcerer) both have md5 checksums on by default.
Gentoo uses md5s and has caught some backdoored sources.
You made the assertion. I simply was pointing out that your access to data islimited unless you work for IBM (and if you did this is not data you would be permitted to discuss).
I'm not a starry-eyed advocate, I use Unix (and Linux) 'cause it gets the job done, and I've been around long enough to know that yes large organizations can be myopic. I know for a fact that IBM used to limit any technology developed inside that might cut into their mainframe business.
However your browsing of a dubious sample set does not a single viable statistic make. You're extrapolating from a dozen or so laptops you've bought and linux forums. I could equally cite the (tiny) volume of linux-related questions asked by IBM's customers in their thinkpad support forums.
I don't think you have the faintest idea what's involved in releasing / supporting continually new products in a market where each new model is fundamentally obsolete (from a new sales perspective) in 6 months or less.
That means that whatever the latest and greatest thinkpad release has a driver set for w2k/xp which has been tested for reliability to minimize support costs.
And I believe you're totally glossing the real difficulties of running linux on laptops, e.g.:
e.g. At least on my thinkpad the prism drivers needed to run the 802.11 card are to this day broken in several ways (bugs not present in the win2k or OpenBSD drivers).
e.g. Linux has no hibernate support.
e.g. Linux has poor support for swapping Ultrabay or similar laptop hotswap devices.
e.g. Neither sound nor the video card on my thinkpad was (correctly) supported by the kernel or by a released version of X11 for 3-6 months after I bought it. X11-cvs was the only solution.
e.g. From kernel 2.4.12 I could only get better than an hour uptime on the thinkpad with a kernel patch, (finally) 2.4.17 worked acceptably and at.22 the only outstanding bug are the wireless drivers.
On WinX the laptop vendors can at least work against a known release of the relevant OS (as compared to who knows which version of the kernel, what distribution, what extra drivers.... in the Linux market. All of this is basic engineering and market economics driving the envelope of what is a profitable product.
No, by my logic they should and do put a lot of effort into Linux. Most of that effort to date has been where the market is using linux - servers.
The parent/. article is *about* IBM's work on the desktop, but laptops are going to be the last segment precisely because laptops are so damned fussy / tend to have bleeding edge hardware.
When enough people are installing linux, the drivers will get written / improved. but today that market simply doesn't have a return.
You have access to IBM's data?
Sorry, I think IBM probably has a pretty good feel for how many machines get linux post-install. After all they take all the hardware tech-support calls.
Well yeah, you're talking laptops, which are still a far cry from well supported by Linux. Look at their servers, Netfinity units I picked up on ebay nearly 3 years ago used Linux-boot cds w/ java for Raid-controller configuration.
1. the number of buyers for thinkpads with linux is tiny. IBM has in fact shipped some models with linux pre-installed but as a general move, linux on laptops is still pretty chancy, why should they put all that effort into somthing that obviously will generate no return.
2. See 1, if the market for Linux on laptops is small, the market for fbsd on laptops is that much smaller. As it happens I have installed fbsd on my Thinkpad, don't use usb so don't care but I do/did care that it corrupted my linux partitions and completely fails to recognize the OpenBSD disklabel.
3. See 1. latest-hardware drivers on Linux has always lagged. with 99% of the market, sure windows drivers get written right off. Funny how revenue will cause code to get written.
with all the crap they've *added* to the trilogy I most certainly will not be wasting money on the Two Towers or Return of the King dvds.
Perhaps I don't count as a fan, lets see I've read the trilogy through about 30 times?
I completely lost faith in Jackson and company on learning that they were cutting the final chapter entirely from the book.
If you're at say Princeton, Stanford or MIT I daresay the lectures (e.g.
18.0118.01418.01a
) are plenty fast enough thanks.
Re:After 20+ years of buffer overflow exploits...
on
Remote Root Exploit In lsh
·
· Score: 3, Informative
There are several available solutions to this
Libsafe, one of the oldest use LD_PRELOAD to replace the dozen-odd most often problematic library functions with safe/checked versions. It's been available for several years. Requires no code modifications (beyond setting the LD_PRELOAD env).
Propolice, stackguard, patches to Gcc / kernel provide various stack protections. Propolice has been built into OBSD for about a year now. These require object recompilation. PaX provides various randomizations thru the kernel. All fo these significantly complicate the attakers task.
Compiled with gcc 3.2.3 it throws an FPE on actual
source trees.
Compiled with gcc 3.3+ it will actually run the analysis but it won't generate the output files if used against something larger than the 20 source files he includes in the tarball.
I wrote this in perl + shell commands a few months ago, haven't optimized it and it's in the same range of fast as 'comparator' and actually works. -- of course software that just works isn't anywhere near as exciting, or press-release worthy.
Discussing this with SCO they've indicated the disclosures will be in-person, and you can't take the code back to your office for analysis.
Yeah, comments being duplicated sounds damning but without a copy to
work with I don't know how I'm going to check this against the BSD or other sources.
<shrug>
The only problem is
on
PeltierBeer
·
· Score: 5, Insightful
that their research seems to have missed:
Guinness is supposed to be drunk at room temp not 8-10 Deg C.
<doh>
Re:Saw this on Google News a while back
on
OSI vs SCO
·
· Score: 1
Hmm, I agree there's remarkably little data on this found in google... here's what I'm (reasonably) certain of
Aix is a microkernel design, At the time I started using it ('93 / aix 3.1) this was 'common knowlege' and the basis was Mach. I beleive that's with extensive IBM mods. Yes I also remember the time when 'Workplace shell' was going to sit on a microkernel under aix, os/2... That was also the days of IBM's SAA:-).
You may also remember that the (ca) '96 timeframe was when IBM was offering it's microkernel investment to competitors. I (still) beleive that this was on the basis that they had migrated os/400 off of it's mini-platform onto RISC and DEC and HP were looking at the same problem with a need to move VMS and MPE respectively onto their RISC platforms.
I know for a fact that the AIX VM has the same design (benefits and limitations) that Hurd has been dealing with in their Mach underpinning. IT's an approach to the VM which to my knowlege is unique to Mach/osf1.
I'll offer the following assertions that AIX is based on Mach.
AIX/ESA, runs native on S/370 and S/390 mainframes, based on OSF/1. AIX [rs/6k] was to have been base for OSF/1 until Mach was chosen instead. I hope this subsection is
converging :
ref
The Mach microkernel technology developed at Carnegie Mellon
University serves as the basis for IBM's microkernel work. On the
Mach base IBM is experimenting with new ways of implementing low-end
environments, developing stand-alone file servers, integrating
multiple operating system personalities on a single computer,...
For instance, the
low-end AIX implementation on Mach currently runs as a dominant
personality and supports an environment for running DOS programs
as a secondary personality.
ref
MACH isn't a UNIX system either but is the basis for interesting UNIX kernel dev
elopments. The DEC UNIX kernel is build on MACH (as well as the GNU Hurd, NextSt
ep/OpenStep, Apple's forthcoming Rhapsody and IBM's OS/2 for the RS/6000).
ref
IBM's own AIX operating system is based on a different Unix kernel, called the
Mach kernel, which was created at Carnegie Mellon University in Pittsburgh, but
many of the layers of Unix functions that ride on top of this kernel are apparen
tly based on Unix System V
ref
Re:Saw this on Google News a while back
on
OSI vs SCO
·
· Score: 4, Interesting
As much as people daydream that IBM is "on our side... not because they have some kind of conviction that OSI is morally good
Err well making money is arguably morally good.
SCO is far less trying to fsck over linux than IBM, yes they've made noises toward the Distributions, but a primary thrust of their suit is to revoke IBM's Unix license. Even a very small likelihood of that happening will grab the attention of people running AIX.
Naturally we expect IBM to address this with the court and if the court considers it likely they will prevail, then IBM will be allowed to continue shipping AIX.
The reasons I think SCO loses this case, amplifying OSI's discussion:
AIX as a kernel is the Mach microkernel, (derived from BSD not SysV) and among unixes it's the one which outwardly seems to have the most rewriting. The same kernel and hardware have been the basis of os/400 for half a decade.
AIX as an OS mostly uses bsd-flavored commands (and only adopted sysV-style init as Linux's SysV-style became the lingua-franca)
IBM is supporting thier Unix clients by building linux compatibility on top of the (far more solid) AIX kernel. This means middleware. Does anyone doubt that IBM has done a GPL-free interface? No way do I believe they'd risk opening AIX source by directly incorporating GPL.
Basing AIX on Mach didn't come cheap. For instance AIX took longer than it's competitors to get 64-bit clean for the same reasons that the Hurd (also Mach-based) just got set-back a year, the 32bit limitations are in the microkernel, not the bolted-on subsystems. One thing they bought with that investment, however was a very strong position in the event that SYS-V's inheritors ever wanted to raise this particular ruckus.
Personally I'm hoping SCO gets tapped for IBM's legal fees when they inevitably lose this case. The only winners I can see are SCO's lawyers, and perhaps to a lesser degree microsoft and Sun.
First, I don't really see where in the PDF this guy is claiming to represent OSS in general (as if such a thing were possible).
Now zealotry from someone in the Debian arena is hardly a surprise. I know deb for:
Questioning whether Linus's kernel tree is pure enough to coexist with their "social contract"
Thinking it can do a better BSD than the existing 3
being the platform for the Hurd?
(unintentionally) spawning other ill-concieved projects such as "TrustedDebian" founded by someone who's not got the sense to check in with the Deb project for use of their TM.
Pushing 'deb' as the one and only best solution and focussing on writing non-portable deb-specific code
Running about the 'net proclaiming that GPL 'trumps' patents where the two are mixed (?? a license of unknown legal standing takes precedence over a codified/legal IP construct??)
And of course all that's just a subset of the FSF noise. "information wants to be free" "patents are bad"... ho-hum.
As I've pointed out before on/. a patent does exactly what GPL does, exchanges the disclosure of the details necessary to practice an invention or idea. Yes the details differ, Patents are used to grant a temporary monopoly, GPL is (nominally) forever.
Looking on another side of the OSS fence, OpenBSD refuses to consider GPL'd JFS and uses decidedly (imho, ymmv) inferior Kerberos & AFS implementations on the basis of license/patent stances.
Well all these people are quite free(tm) to run thier projects however they want. I'm not all that enamored of the numerous duplications of effort, but it's their projects and while I certainly have views on the damage done by zealotry and politics, I know my views probably aren't gonna change the stances.
However. When Mr Perens wants to claim to speak for the community at large. Well I'm sorry. Yes we all like a slugfest/catfight but at the end of the day I mostly care about the systems I work with running on a daily basis.
As Mr Perens says himself: "One problem we have in holding off software patents is that we have little damage to show so far. Although at least one company has made its plans clear, there has been little prosecution of Open Source developers for patent infringement to date"
Now I assume that "one company" is SCO and I've observed that Mr Perens is happy to look askance at IBM for the purposes of the current discussion?. While proclaiming that the sky will soon fall, in spite of the fact that the company with the largest patent inventory in the world is also the one most often hailed as a positive force in OSS?
I'm sorry but Patents (software and otherwise) are part of the landscape. Yes some crap gets past the examiners, this is no different from any other legislation, or government regulation.
However the OSS 'community' seems to be in general denial on this. I don't see software patents going away, and the EC seems to be taking an oss-friendly approach. And no Mr Perens does not speak for me on this (or any other) issue.
Versus a nerdy kid who hasn't studied theory? Mitnick doesn't place enough value in his personal integrity to keep 'defensivethinking.com' free from the simplest root-compromise (do I want to hire a 'security company' hawking memorabilia on it's front page?) and once free has switched from contrition to bemoaning the unfairness of his prosecution.
He that is taught only by himself, has a fool for a Master. - Ben Johnson
I imagine there are indeed some recent grads with enough credentials. People enter MIT and similar calibre schools each year with more smarts than I would attribute to Mitnick today. Anyone who's actually applied themselves to study of theory for the same period that Kevin was stealing source code, reversing what he could and social engineering the rest probably is a far better choice for securing your systems.
He clearly can 'social' the 2600 crowd, let them hire him. Me hire a kid who has the brass to complain about forfeiting his hardware as a penalty for not decrypting the contents of his hard drives? Not likely. I assume we'll never know if that data would have convicted him of less 'benign' intrusions.
To top all that this is a repeat felon who hasn't formally studied theory but has tried to refer to himself as a hacker in the classical (MIT/LCS/AI-lab) sense. It'd be a cold day in hell I'll acknowlege that as a hacker.
1. Local root exploit. The experts(sic) posting here have been saying this means "has access to a user account".
Wrong. "local" in this sense means able to run a shell under any UID. Yes this means any user with an account may be able to escalate to root. It also means that any non-root hole can probably then be escalated to root.
2. That doesn't only encompass flawed daemons (apache, bind... all run as non-root), it includes poorly written CGI/php and other server parsed scripts. If a script allows remotely controlled data to be passed to a shell, that's now a potential root compromise.
2. Plus this flaw probably isn't countered by any of the various approaches to kernel hardening (gr-sec and the like).
So it's potentially serious if you weren't serious about security of your Linux servers.
Now let's look at the current understanding of the "WebDAV"/IIS exploit
I think it's already well known that the this was discovered *after* an army server was compromised. If you don't already believe that Opensource works better then my $0.02 probably isn't going to convince you, however *very* few *nix problems are found *&* applied by the vandals before a patch is available / developed.
1. Because by *default* IIS is installed on w2k servers, and installed with Administrator (root) access, many IIS boxes are rooted.
2. Yes the Lockdown tool is supposed to fix this, however it's being reported that it doesn't in all cases. Thus the patch is strongly advised, whatever workarounds you're using.
3. The actual flaw is in ntdll.dll This library is loaded by nearly every process running on w2k.
a. This is about as central to NT/w2k as you might care to get.
b. MS *thinks* that iis/webdav is the only vector into this flaw "They're researching it"
If they're wrong it's going to be a nightmare. Even if they're right, it's pretty darned bad.
Sure, security is a process, not a product, but part of that process is choosing systems that you actually have some ability to evaluate and predict and manage problems.
Was basically, "if you can control the developers, you control the customers (killing off cp/m, os/2...)"
That carried them to a point where the leverage point was effectively "if you control the desktop you can win the servers (killing off novell, banyan...). This in turn led to "if you control the desktop and departmental servers, you can muscle into the enterprise" -- fortunately (imo) they've had less luck - despite considerable effort - in killing off Unix/Linux/BSD.
So far at least. I don't think this games very predictable, (and the LW article is *very* thin on data, but there certainly is a deep groundswell of good things happening in OSS, and virtually all big-iron oriented code now targets Linux along with Unix).
However it's perfectly reasonable that as developers move (back) to *nix, eventually the market will follow.
(Remembering Grace Slick of the Starship singing about 'egg-snatchers' -- dunno the Borg's a big target, and elephants are best eaten a bite at a time)
How very like rms
on
RMS Turns 50
·
· Score: 4, Interesting
50th birthday--not ordinarily an occasion for joy.
But your support will make it a happy birthday.
To take even the occaision of his birthday as something political.
I can't get all that excited about this. Looking at an open,
internet connected site, no firewalls and about 4 hosts I've recorded
roughly 1 million snort detects spanning 1.5 years of on&off operation
I count about 35 total external nmap scans from only 9 unique IP #s.
Only a couple of those then tried to follow up with some attack traffic
and one was either a very confused kiddie trying to hit a unix box with
netbios-ns.
So ractically speaking, 99.999% mundane risks (kiddies, scripts, worms)
out there do minimal OS detection, and pretty much shoot attacks at
random IP's. Those that do some form of detection before trying to
attack certainly aren't using NMAP to scan (server version detection
is far more common, and is not limited to version strings.
For my money the time spent on stack-signature obfuscation would
be far better invested in actual security measures (e.g. staying up
to date on patches, implementing defense-in-depth or deploying
hardened OS's.
Sure, if you're going to put your servers behind a load ballancer,
packet filter or proxy, then you may well get a measure of obfuscation
for free, but if the security implementation on the screened
systems is no good you're going to get rooted anyway.
1. That McBreen is a co-author of 'Questioning extreme programming'
2. That the/. review(sic) is incomplete, biased and (imo) less useful than the reviews on Amazon/BN.
His credentials seem ok, the excerpts looked interesting and relevant and I think his approach is a viable one (which is not to say it's the only or best one for any given circumstance).
Modern software engineering(sic) doesn't seem equal to the challenge that many (cough-MS) organizations developing software emphasize absolutely as many features as can be crammed into the deployment space, with reliability criteria seemingly like "if it's not so unstable that the customer will ask for his money back, we ship it".
Ok that's the current market and goodness knows people keep buying and writing bloated, buggy software is by no means limited to commercial/priprietary, it's become all too common in free/oss projects also. (See my related
views about that).
The mantra that seems to drive the market is "More features". Personally I beleive the best programs result from the alternate view: "The best program is the smallest program that fits the need".
So wherever the statement "If buildings were constructed the way software is constructed, the first ant to come along would destroy civilization overnight" remains true, I think the applicability of "software engineering" is (nil).
the Siteplayer is bigger but does more and is easily afforded by nearly anyone at $29.00
Not exactly comparable, yeah the siteplayer has some features.
item SP Xport
D i/o 8 3
RAM 768B 256KB
flash 48Kb 385KB
Also the Xport includes the ethernet filter/magnetics and (Optionally) offers AES encryption, good feature if you want to use this for support on anything remotely critical.
Yes linux has 'dependency hell'... Win has 'DLL hell' which imo/imx is far worse.
Most (nearly all) of those install-sheild routines install the versions of dlls that the vendor has found it needs to work, and it's standard(sic) that winX applications install libraries into system areas.
That's just plain ugly, and why Win32 can be a very solid system iff you stay in the realm of well-engineered server applications, and So, so unstable when you turn lusers loose on it ('Ohh I really must have this latest whizbang screensaver or desktop doodad....).
Imo this idiocy directly stems from the DOS/win16 programming(sic) history where there was no isolation at all from the hardware and many (most?) programss were coded to do all sorts of inane low-level calls to bios/hardware.
This just isn't allowed in Unix(linux,bsd...) and it's as much a social/cultural issue as a technical one. Unix has 2 decades of enforcing the distinction between what's in the 'OS' hierarchy and what's in application space. Whether you want to discuss source-builds, defaulting to install in/usr/local/ or commercial installations which usually go into/opt, I've yet to see an application which would overwrite system libraries.
<RANT>
It's my observation that much of the shoddy coding that's found it's way into opensource in recent years is the direct result of windows coders bringing these bad habits into Linux.
The vast majority is being written without thought for portability and works only Linux and assuming the GNU toolchain (and often relying on version-specific features within same). Even within Linux, the difficulties associated with building code from source has taken many steps back into the past. Try building Gnome directly from sources.
A decade ago it was like this installing free / pd / gnu / oss software on the various proprietary Unixes. Sadly, after a period of big gains in portability, software builds are moving in the other direction. The complexity (often useless/needless imo) of much modern oss code has benefits, it also has drawbacks.
</RANT>
Thier exhibitE available on the SCOsource site notifies IBM that they must correct the (claimed) contract breaches within 100 days or cease shipping AIX --- *this* is the FUD that SUN is capitalizing on.
On the Linux side, SCO is claiming that IBM didn't directly incorporate SCO trade secrets, but actively 'encouraged others' to do so.
Slashdot Mirror
It is the default in many unix-like systems OpenBSD's ports include source signatures, I assume the other BSDs do the same. Lunar and smgl (the forks of sorcerer) both have md5 checksums on by default. Gentoo uses md5s and has caught some backdoored sources.
You made the assertion. I simply was pointing out that your access to data islimited unless you work for IBM (and if you did this is not data you would be permitted to discuss).
I'm not a starry-eyed advocate, I use Unix (and Linux) 'cause it gets the job done, and I've been around long enough to know that yes large organizations can be myopic. I know for a fact that IBM used to limit any technology developed inside that might cut into their mainframe business.
However your browsing of a dubious sample set does not a single viable statistic make. You're extrapolating from a dozen or so laptops you've bought and linux forums. I could equally cite the (tiny) volume of linux-related questions asked by IBM's customers in their thinkpad support forums.
I don't think you have the faintest idea what's involved in releasing / supporting continually new products in a market where each new model is fundamentally obsolete (from a new sales perspective) in 6 months or less.
That means that whatever the latest and greatest thinkpad release has a driver set for w2k/xp which has been tested for reliability to minimize support costs.
And I believe you're totally glossing the real difficulties of running linux on laptops, e.g.:
e.g. At least on my thinkpad the prism drivers needed to run the 802.11 card are to this day broken in several ways (bugs not present in the win2k or OpenBSD drivers).
e.g. Linux has no hibernate support.
e.g. Linux has poor support for swapping Ultrabay or similar laptop hotswap devices.
e.g. Neither sound nor the video card on my thinkpad was (correctly) supported by the kernel or by a released version of X11 for 3-6 months after I bought it. X11-cvs was the only solution.
e.g. From kernel 2.4.12 I could only get better than an hour uptime on the thinkpad with a kernel patch, (finally) 2.4.17 worked acceptably and at .22 the only outstanding bug are the wireless drivers.
On WinX the laptop vendors can at least work against a known release of the relevant OS (as compared to who knows which version of the kernel, what distribution, what extra drivers .... in the Linux market. All of this is basic engineering and market economics driving the envelope of what is a profitable product.
The parent /. article is *about* IBM's work on the desktop, but laptops are going to be the last segment precisely because laptops are so damned fussy / tend to have bleeding edge hardware.
When enough people are installing linux, the drivers will get written / improved. but today that market simply doesn't have a return.
You have access to IBM's data? Sorry, I think IBM probably has a pretty good feel for how many machines get linux post-install. After all they take all the hardware tech-support calls.
1. the number of buyers for thinkpads with linux is tiny. IBM has in fact shipped some models with linux pre-installed but as a general move, linux on laptops is still pretty chancy, why should they put all that effort into somthing that obviously will generate no return.
2. See 1, if the market for Linux on laptops is small, the market for fbsd on laptops is that much smaller. As it happens I have installed fbsd on my Thinkpad, don't use usb so don't care but I do/did care that it corrupted my linux partitions and completely fails to recognize the OpenBSD disklabel.
3. See 1. latest-hardware drivers on Linux has always lagged. with 99% of the market, sure windows drivers get written right off. Funny how revenue will cause code to get written.
with all the crap they've *added* to the trilogy I most certainly will not be wasting money on the Two Towers or Return of the King dvds. Perhaps I don't count as a fan, lets see I've read the trilogy through about 30 times? I completely lost faith in Jackson and company on learning that they were cutting the final chapter entirely from the book.
newline/jackson can forget getting any money from this quarter.
the 8 inch floppy drives (weighing easily 10 lb @ were probably manufacturee in the mid-70s.
Still boots, can't say I use it often but the Vedit+ editor isn't 1/2 bad and is setup to emulate Emacs.
If you're at say Princeton, Stanford or MIT I daresay the lectures (e.g. 18.01 18.014 18.01a ) are plenty fast enough thanks.
Libsafe, one of the oldest use LD_PRELOAD to replace the dozen-odd most often problematic library functions with safe/checked versions. It's been available for several years. Requires no code modifications (beyond setting the LD_PRELOAD env).
Propolice, stackguard, patches to Gcc / kernel provide various stack protections. Propolice has been built into OBSD for about a year now. These require object recompilation. PaX provides various randomizations thru the kernel. All fo these significantly complicate the attakers task.
Compiled with gcc 3.3+ it will actually run the analysis but it won't generate the output files if used against something larger than the 20 source files he includes in the tarball.
I wrote this in perl + shell commands a few months ago, haven't optimized it and it's in the same range of fast as 'comparator' and actually works. -- of course software that just works isn't anywhere near as exciting, or press-release worthy.
ho hum
Yeah, comments being duplicated sounds damning but without a copy to work with I don't know how I'm going to check this against the BSD or other sources.
<shrug>
that their research seems to have missed:
Guinness is supposed to be drunk at room temp not 8-10 Deg C.
<doh>
Aix is a microkernel design, At the time I started using it ('93 / aix 3.1) this was 'common knowlege' and the basis was Mach. I beleive that's with extensive IBM mods. Yes I also remember the time when 'Workplace shell' was going to sit on a microkernel under aix, os/2 ... That was also the days of IBM's SAA :-).
You may also remember that the (ca) '96 timeframe was when IBM was offering it's microkernel investment to competitors. I (still) beleive that this was on the basis that they had migrated os/400 off of it's mini-platform onto RISC and DEC and HP were looking at the same problem with a need to move VMS and MPE respectively onto their RISC platforms.
I know for a fact that the AIX VM has the same design (benefits and limitations) that Hurd has been dealing with in their Mach underpinning. IT's an approach to the VM which to my knowlege is unique to Mach/osf1.
I'll offer the following assertions that AIX is based on Mach.
AIX/ESA, runs native on S/370 and S/390 mainframes, based on OSF/1. AIX [rs/6k] was to have been base for OSF/1 until Mach was chosen instead. I hope this subsection is converging : ref
The Mach microkernel technology developed at Carnegie Mellon University serves as the basis for IBM's microkernel work. On the Mach base IBM is experimenting with new ways of implementing low-end environments, developing stand-alone file servers, integrating multiple operating system personalities on a single computer, ...
For instance, the
low-end AIX implementation on Mach currently runs as a dominant
personality and supports an environment for running DOS programs
as a secondary personality.
ref
MACH isn't a UNIX system either but is the basis for interesting UNIX kernel dev elopments. The DEC UNIX kernel is build on MACH (as well as the GNU Hurd, NextSt ep/OpenStep, Apple's forthcoming Rhapsody and IBM's OS/2 for the RS/6000). ref
IBM's own AIX operating system is based on a different Unix kernel, called the Mach kernel, which was created at Carnegie Mellon University in Pittsburgh, but many of the layers of Unix functions that ride on top of this kernel are apparen tly based on Unix System V ref
See also e2[microkernel]
Err well making money is arguably morally good.
SCO is far less trying to fsck over linux than IBM, yes they've made noises toward the Distributions, but a primary thrust of their suit is to revoke IBM's Unix license. Even a very small likelihood of that happening will grab the attention of people running AIX.
Naturally we expect IBM to address this with the court and if the court considers it likely they will prevail, then IBM will be allowed to continue shipping AIX.
The reasons I think SCO loses this case, amplifying OSI's discussion:
- AIX as a kernel is the Mach microkernel, (derived from BSD not SysV) and among unixes it's the one which outwardly seems to have the most rewriting. The same kernel and hardware have been the basis of os/400 for half a decade.
- AIX as an OS mostly uses bsd-flavored commands (and only adopted sysV-style init as Linux's SysV-style became the lingua-franca)
- IBM is supporting thier Unix clients by building linux compatibility on top of the (far more solid) AIX kernel. This means middleware. Does anyone doubt that IBM has done a GPL-free interface? No way do I believe they'd risk opening AIX source by directly incorporating GPL.
Basing AIX on Mach didn't come cheap. For instance AIX took longer than it's competitors to get 64-bit clean for the same reasons that the Hurd (also Mach-based) just got set-back a year, the 32bit limitations are in the microkernel, not the bolted-on subsystems. One thing they bought with that investment, however was a very strong position in the event that SYS-V's inheritors ever wanted to raise this particular ruckus.Personally I'm hoping SCO gets tapped for IBM's legal fees when they inevitably lose this case. The only winners I can see are SCO's lawyers, and perhaps to a lesser degree microsoft and Sun.
Now zealotry from someone in the Debian arena is hardly a surprise. I know deb for:
- Questioning whether Linus's kernel tree is pure enough to coexist with their "social contract"
- Thinking it can do a better BSD than the existing 3
- being the platform for the Hurd?
- (unintentionally) spawning other ill-concieved projects such as "TrustedDebian" founded by someone who's not got the sense to check in with the Deb project for use of their TM.
- Pushing 'deb' as the one and only best solution and focussing on writing non-portable deb-specific code
- Running about the 'net proclaiming that GPL 'trumps' patents where the two are mixed (?? a license of unknown legal standing takes precedence over a codified/legal IP construct??)
And of course all that's just a subset of the FSF noise. "information wants to be free" "patents are bad"As I've pointed out before on /. a patent does exactly what GPL does, exchanges the disclosure of the details necessary to practice an invention or idea. Yes the details differ, Patents are used to grant a temporary monopoly, GPL is (nominally) forever.
Looking on another side of the OSS fence, OpenBSD refuses to consider GPL'd JFS and uses decidedly (imho, ymmv) inferior Kerberos & AFS implementations on the basis of license/patent stances.
Well all these people are quite free(tm) to run thier projects however they want. I'm not all that enamored of the numerous duplications of effort, but it's their projects and while I certainly have views on the damage done by zealotry and politics, I know my views probably aren't gonna change the stances.
However. When Mr Perens wants to claim to speak for the community at large. Well I'm sorry. Yes we all like a slugfest/catfight but at the end of the day I mostly care about the systems I work with running on a daily basis.
As Mr Perens says himself: "One problem we have in holding off software patents is that we have little damage to show so far. Although at least one company has made its plans clear, there has been little prosecution of Open Source developers for patent infringement to date"
Now I assume that "one company" is SCO and I've observed that Mr Perens is happy to look askance at IBM for the purposes of the current discussion?. While proclaiming that the sky will soon fall, in spite of the fact that the company with the largest patent inventory in the world is also the one most often hailed as a positive force in OSS?
I'm sorry but Patents (software and otherwise) are part of the landscape. Yes some crap gets past the examiners, this is no different from any other legislation, or government regulation.
However the OSS 'community' seems to be in general denial on this. I don't see software patents going away, and the EC seems to be taking an oss-friendly approach. And no Mr Perens does not speak for me on this (or any other) issue.
He that is taught only by himself, has a fool for a Master.
- Ben Johnson
I imagine there are indeed some recent grads with enough credentials. People enter MIT and similar calibre schools each year with more smarts than I would attribute to Mitnick today. Anyone who's actually applied themselves to study of theory for the same period that Kevin was stealing source code, reversing what he could and social engineering the rest probably is a far better choice for securing your systems.
He clearly can 'social' the 2600 crowd, let them hire him. Me hire a kid who has the brass to complain about forfeiting his hardware as a penalty for not decrypting the contents of his hard drives? Not likely. I assume we'll never know if that data would have convicted him of less 'benign' intrusions.
To top all that this is a repeat felon who hasn't formally studied theory but has tried to refer to himself as a hacker in the classical (MIT/LCS/AI-lab) sense. It'd be a cold day in hell I'll acknowlege that as a hacker.
Wrong. "local" in this sense means able to run a shell under any UID. Yes this means any user with an account may be able to escalate to root. It also means that any non-root hole can probably then be escalated to root.
2. That doesn't only encompass flawed daemons (apache, bind ... all run as non-root), it includes poorly written CGI/php and other server parsed scripts. If a script allows remotely controlled data to be passed to a shell, that's now a potential root compromise.
2. Plus this flaw probably isn't countered by any of the various approaches to kernel hardening (gr-sec and the like).
So it's potentially serious if you weren't serious about security of your Linux servers.
Now let's look at the current understanding of the "WebDAV"/IIS exploit
I think it's already well known that the this was discovered *after* an army server was compromised. If you don't already believe that Opensource works better then my $0.02 probably isn't going to convince you, however *very* few *nix problems are found *&* applied by the vandals before a patch is available / developed.
1. Because by *default* IIS is installed on w2k servers, and installed with Administrator (root) access, many IIS boxes are rooted.
2. Yes the Lockdown tool is supposed to fix this, however it's being reported that it doesn't in all cases. Thus the patch is strongly advised, whatever workarounds you're using.
3. The actual flaw is in ntdll.dll This library is loaded by nearly every process running on w2k.
If they're wrong it's going to be a nightmare. Even if they're right, it's pretty darned bad.
Sure, security is a process, not a product, but part of that process is choosing systems that you actually have some ability to evaluate and predict and manage problems.
That carried them to a point where the leverage point was effectively "if you control the desktop you can win the servers (killing off novell, banyan ...). This in turn led to "if you control the desktop and departmental servers, you can muscle into the enterprise" -- fortunately (imo) they've had less luck - despite considerable effort - in killing off Unix/Linux/BSD.
So far at least. I don't think this games very predictable, (and the LW article is *very* thin on data, but there certainly is a deep groundswell of good things happening in OSS, and virtually all big-iron oriented code now targets Linux along with Unix).
However it's perfectly reasonable that as developers move (back) to *nix, eventually the market will follow.
(Remembering Grace Slick of the Starship singing about 'egg-snatchers' -- dunno the Borg's a big target, and elephants are best eaten a bite at a time)
To take even the occaision of his birthday as something political.
I guess it's his party and all :-)
So ractically speaking, 99.999% mundane risks (kiddies, scripts, worms) out there do minimal OS detection, and pretty much shoot attacks at random IP's. Those that do some form of detection before trying to attack certainly aren't using NMAP to scan (server version detection is far more common, and is not limited to version strings.
For my money the time spent on stack-signature obfuscation would be far better invested in actual security measures (e.g. staying up to date on patches, implementing defense-in-depth or deploying hardened OS's.
Sure, if you're going to put your servers behind a load ballancer, packet filter or proxy, then you may well get a measure of obfuscation for free, but if the security implementation on the screened systems is no good you're going to get rooted anyway.
2. That the /. review(sic) is incomplete, biased and (imo) less useful than the reviews on Amazon/BN.
His credentials seem ok, the excerpts looked interesting and relevant and I think his approach is a viable one (which is not to say it's the only or best one for any given circumstance).
Modern software engineering(sic) doesn't seem equal to the challenge that many (cough-MS) organizations developing software emphasize absolutely as many features as can be crammed into the deployment space, with reliability criteria seemingly like "if it's not so unstable that the customer will ask for his money back, we ship it".
Ok that's the current market and goodness knows people keep buying and writing bloated, buggy software is by no means limited to commercial/priprietary, it's become all too common in free/oss projects also. (See my related views about that).
The mantra that seems to drive the market is "More features". Personally I beleive the best programs result from the alternate view: "The best program is the smallest program that fits the need".
So wherever the statement "If buildings were constructed the way software is constructed, the first ant to come along would destroy civilization overnight" remains true, I think the applicability of "software engineering" is (nil).
Not exactly comparable, yeah the siteplayer has some features.
item SP Xport
D i/o 8 3
RAM 768B 256KB
flash 48Kb 385KB
Also the Xport includes the ethernet filter/magnetics and (Optionally) offers AES encryption, good feature if you want to use this for support on anything remotely critical.
Most (nearly all) of those install-sheild routines install the versions of dlls that the vendor has found it needs to work, and it's standard(sic) that winX applications install libraries into system areas.
That's just plain ugly, and why Win32 can be a very solid system iff you stay in the realm of well-engineered server applications, and So, so unstable when you turn lusers loose on it ('Ohh I really must have this latest whizbang screensaver or desktop doodad ....).
Imo this idiocy directly stems from the DOS/win16 programming(sic) history where there was no isolation at all from the hardware and many (most?) programss were coded to do all sorts of inane low-level calls to bios/hardware.
This just isn't allowed in Unix(linux,bsd ...) and it's as much a social/cultural issue as a technical one. Unix has 2 decades of enforcing the distinction between what's in the 'OS' hierarchy and what's in application space. Whether you want to discuss source-builds, defaulting to install in /usr/local/ or commercial installations which usually go into /opt, I've yet to see an application which would overwrite system libraries.
<RANT>
It's my observation that much of the shoddy coding that's found it's way into opensource in recent years is the direct result of windows coders bringing these bad habits into Linux.
The vast majority is being written without thought for portability and works only Linux and assuming the GNU toolchain (and often relying on version-specific features within same). Even within Linux, the difficulties associated with building code from source has taken many steps back into the past. Try building Gnome directly from sources.
A decade ago it was like this installing free / pd / gnu / oss software on the various proprietary Unixes. Sadly, after a period of big gains in portability, software builds are moving in the other direction. The complexity (often useless/needless imo) of much modern oss code has benefits, it also has drawbacks.
</RANT>
Thier exhibitE available on the SCOsource site notifies IBM that they must correct the (claimed) contract breaches within 100 days or cease shipping AIX --- *this* is the FUD that SUN is capitalizing on.
On the Linux side, SCO is claiming that IBM didn't directly incorporate SCO trade secrets, but actively 'encouraged others' to do so.
Load of horsedung imho.