Having used both CodeWarrior and ProjectBuilder, I'm going to disagree strongly with you here. I've found PB to be a very comfortable environment in which to work. Of course, I don't open twenty files at a time in PB. I edit with vi because it's more powerful than any pointy-clicky editor. Just MNSHO.
That having been said, if you think it sucks so badly, why don't you be responsible and file bugs about it instead of bitching about it anonymously on slashdot. If something doesn't work well, say so. If you don't complain, then it is -your- fault, not Apple's, that the developer tools are, in your words, "craptacularly bad".
Whether you like PB or not, I don't see MS giving away developer tools, good or bad. And therein, I believe, lay the original poster's point....
I agree with many of your points. I've always regarded PAM as a necessary evil (very evil).
I disagree, though, that the real workaround couldn't be made available. The more vague the information, the more likely fascist network admins are to block port 22 entirely. Being able to lose partial functionality is better than losing all functionality, but only if that loss of functionality actually solves the problem. Some companies and individuals would be unable to turn that feature off, which is unfortunate, but at least they would know up-front what they were dealing with and could make an informed decision about how to react.
I applaud OpenSSH for pushing people to use privilege separation. That's a very good feature, and I'm glad to see that people are actually working on making it work correctly. It's an important security feature.
A word of caution, though. Privsep will reduce the risk of a root attack, but not by 90%. Unprivilleged logins can still do an awful lot of damage if a system admin hasn't kept up with fixes for local root exploits. Sad, isn't it?:-)
However, there -is- a right way to do a security update of a piece of software that minimizes the odds of anyone's computer being compromised. It goes something like this:
1. Fix your own copy, make binary-only release available on your distribution. 2. Security announcement to vendors through whatever channel. Include patch. 3. Vendors build and release binary updates. Announce these updates. Keep source private, including vendor-modified versions. 4. At a scheduled date, official source release. Vendors concurrently release modified source.
Ideally, there should be about a week from the initial patch to the source release. This gives vendors a chance to react, while still providing security to OpenBSD users. It also ensures that end-users' systems are protected to the maximum extent possible as soon as possible while minimizing the changes of black hats getting information on the hack.
An alternate variation on this involves releasing the source and binaries at once, so that the particularly cautious could build their own. The point being that it takes vendors time to build and qualify something as complex as SSH, and expecting it to just happen instantly is not a reasonable expectation, even for a large vendor with large resources.
The whole bit about vendors leaking information to black hats is disconcerting. If there's cause to believe that this is occurring, then better steps need to be taken to qualify vendors for this sort of information rather than simply exluding vendors from the information. If there are infrastructure needs in this area, I'd be happy to help in any way I can (time permitting, of course.:-)
I currently have kernel patches in the kernels of three shipping operating systems, and have helped in the development of kernel code for two others.
I manage three open source code development projects, two of which involve kernel development (the third is an X11 app).
I'm an active contributor to seven, count them, 7, open source projects, and there are others that I've simply gotten too busy to continue contributing to.
With the help of a team of about two other people I maintain one of only two working distributions of Linux on the PowerMac, not because I want to make money from it (I haven't made one single penny from MkLinux EVER), but because it helps others and helps me keep my systems running as well.
No, I haven't made any useful patches to OpenSSH. It's one of about a thousand packages that we have to maintain. For a team of 2-3 people working in their spare time to supporting several THOUSAND users for free, there's only so much you can do.:-)
In short, if using a piece of software makes me a leech, then so be it. I'm a leech, and proud of it, as is nearly everyone else reading this thread. Last I checked, the purpose of an open source project was to help the end user, and treating vendors with contempt in a way that hurts their users is not socially acceptable behavior.
Now admittedly, MkLinux is in the minority here, being one of only a handful of such projects that are both free and contribute code changes back upstream periodically.
I fully agree with you that companies that make money off distributions should contribute time and effort to making these projects work. Those of us who are already giving our blood, sweat, and tears and getting nothing from it other than the thanks of our user base, however, cannot possibly be expected to do that, and to suggest otherwise is, quite frankly, ludicrous beyond belief.
Now, I wrote with legitimate complaints about poor security practices. I'd very much appreciate it if you'd stick to the topic at hand. While you're at it, you might actually read something about what someone does before accusing them of being a leech and a repackager.
The OpenSSH guys are guilty of the worst kind of underhanded dealing in this matter. As a vendor, I'm frankly, disgusted in every sense of the word. They deliberately compromised the security of other vendors through their actions by:
* posting a workaround that broke functionality but didn't fix the problem,
* failing to disclose (in advance) a workaround that does close the hole,
* failing to release the source code to vendors before detailing the vulerability to the general public,
* deliberately releasing the vulnerability five days earlier than expected, catching vendors off-guard, and
* using strong-arm scare tactics to force a very broken feature on the end-user community.
In short, they have made a mockery of reasonable procedure for security updates.
If this is what we should expect from OpenSSH when future security vulnerabilities arise, then I, for one, will be investigating alternatives to OpenSSH, and I strongly encourage other vendors to do the same. The security of our users' systems is too precious to be left in the hands of someone who does not have their best interests in mind.
Name one company other than Apple making desktop machines running Mac OSX.
IBM. Well, no, technically they're not making CHRP boxes any more. But it would take all of a couple of hours to make Mac OS X run on it, and since those parts of the OS are open source, you could do it, too.
How many companies' computers can you (as a consumer) port Windows to?
There's a flaw in that logic. Not all 256 possible values for a character represent printable or typable characters. A more realistic value would be
alpha (2*26) +
nums 10 +
shiftnums 10 +
syms 11 +
shiftsyms 11
or 94^8. Yes, it may be possible to use certain control characters and stuff to insert arbitrary high ascii values or an acute e or whatever, but if you do, you will run into compatibility problems when you move from machine to machine.
Though I suspect the largest projects aren't on that sucky sourcefourge site, since they usually have the resources to find another host
That's not really fair. I'm part of what was, at one time, a fairly large open source project. I have resources coming out the backside, but I still use SF for some things. SF has a relatively straightforward bug tracking system that's easier for users to understand than bugzilla (which has the most obscenely bad main search page that I've ever seen). And of course, I don't have to actually set it up or maintain it. It just works.
So of course, I use my own servers for things like web pages, and for most projects, my own servers handle downloads as well. But when it comes to bug tracking interfaces, there's still a little stub SF project.
The moral is, just because a project is mature and has resources doesn't mean it needs to waste them on something that SF provides for free.;-)
Not only are these guys blatant trolls, but they're also wrong. As anyone who has ever tried to crack a Mac will tell you, there are entire classes of buffer overflow attacks that can't be done on PowerPC that are instant root access on x86. And it's harder to write many other types of exploits on PowerPC.
Of course, that was before the Seagate/Conner merger. Seagate drives up to and including 2 gig drives or thereabouts sucked. There's just no other way to put it.
By contrast, I still have Conner 40 meg drives that work -now-. You figure that they were made about ten years ago, and that's pretty bloody cool.
After that merger, Seagate's quality improved a lot. I've had total success with their desktop drives since then. Their 5.25" drives haven't fared quite as well (I've had one drive become slightly flaky after about two years of continuous service), but are still pretty solid.
As a part-time songwriter and composer, who also
has dabbled in movie producing/directing, and
has about ten years of TV production experience,
I feel this is a good point for me to add to
this discussion.:-)
I agree wholeheartedly with the folks who find the
DMCA disgusting. When I distribute tapes to
people to watch, I assume they have VHS decks.
But if they don't, and their friend dubs it to
Beta for them, that's fine with me. I'd much
rather have the eyes watching the content than
be a pain in the backside about its format.
As for the whole songwriter thing, most folks
in music barely make any money when all is said
and done. Most of it's going into the pockets
of nameless, faceless corporate giants. The
unfortunate thing is that those of us who don't
give music to big companies can't get
airplay, because the stations are almost all
owned in whole or in part by a subsidiary of
one of those big companies.
Don't assume that it's just content users
that disagree with the DMCA. Most content
originators disagree with it, too. About the
only people I'm aware of who do agree with this
law are content distributors, because laws like
these are the only things keeping them in
business.
Those of us doing non-mainstream music, movies,
and TV LIKE open access like Napster,
because they are the "great leveler" that the
internet has always promised, but never
quite become. And while I've never made a DVD,
if I did, I would certainly not add ludicrous
half-hearted zones to prevent people from
viewing it.
The way I (and I suspect most creative people)
view the situation is this: the media keeps
telling us how many millions of dollars are
lost to pirated DVDs and videotapes and music.
What they seem to forget is that these are sold
to people who would probably not have purchased
the original tape/dvd/cd, whether for cost
reasons or simply because it wasn't sold in their
country. While that doesn't make the piracy
itself any more acceptable, viewing that material
is another matter. I'd much rather have my
material seen, even illegally in some user-chosen,
format than locked away in a storeroom somewhere
because people weren't willing to pay the
price.
In short, people who make music and movies for
the money are in the business for the wrong
reasons. Music and movies are to entertain. When
we forget that, we're making just as big a mistake
as those who pirate our works. As always, my
opinions are mine, and mine alone, not those
of my employers, etc.
I hate to second this, but... seconded. We
have plenty of open source streaming media,
such as QTSS from Apple and streaming MP3
from... a million open source folks.
I think the best way to fight this sort of bull
is to start a petition, not to the government,
but direct to Real Networks, and send a copy of
the final petition to as many national media
outlets as possible.
Basically the petition should be something on
the order of, "We the undersigned, in response
to the reprehensibly proprietary nature of
and the questionable legality of the defense of
the codecs by the aforementioned, henceforth
refuse all use of any product containing software
licensed from Real, Inc. until the cessation
of such unfair restraint of trade against the
public interest."
Or some such. The one thing that a company
fears the most is tens or hundreds of thousands
of people banding together and refusing to use
their products. No money, no company. They
either change their tune or they stop whistling.
Either way, Real will soon be relegated to
a footnote in history if they continue these
pointless attacks.
I believe there are two versions of the patch.
Based on the naming convention used, the one
you reference does not add the preemption
changes to a stock 2.4.0-test6 tree. It adds
it to a 2.4.0-test6 tree that has already been
patched with the RT scheduler patch (in the
same directory). If you're trying to patch
the stock tree, I belive you want the one that
doesn't have rtsched in its name.
The MontaVista "kernel" is a set of patches from
the current 2.4 test x tree. It's not a question
of domination, but a question of inclusion vs.
having to update the patches every release.
Way to go! Lets implement this on a processor
that isn't even available in the marketplace.
The article mentioned IA32, not
IA64. In other words, what most people know
as the x86 family, i.e. Pentium III, Athlon,
whatever. And of course, as with everything
else I've seen from MontaVista, it's 100%
free and Open Source. The patches to the kernel
are right there on the FTP site, so you should
be able to modify it to work on other platforms.
Its speed depends largely on what you're doing.
The 603's floating point scores are in the tank,
but its integer speeds, IIRC, are not bad. On
the average, it's just a little slower.
Also you have to take into account that the
7200 was probably running a newer (read bigger)
version of MacOS, unless the 5200 had been
upgraded. Finally, you have to consider whether
the performance was bounded by other factors
such as waiting for user input or the hard
drive speed or the speed of the bus between the
processor and RAM.
Also, I think most or all of the 5200s came from
the factory with a L2 cache, and I think only a
few 7200s did, which would also have a leveling
effect.:-)
Yeah. I just about jumped through the ceiling
when I first reached the "Unable to read
bootstrap.conf" message and was able to type
on the screen. That was a couple of weeks ago.
Down hill from there.
Some NuBus PowerMacs. Not AV machines, last I
heard from Takashi.. Pretty big caveat.
That's gonna be nasty to fix, as it involves
making sure every single eieio and sync (or was
it isync) uses the same standard macro to do
its work, everywhere it appears in the entire
kernel, then making that macro #ifdef'able
to wrap it with some really nasty code....
Amazing how one little hw bug and an obscure
feature of the 601 chip can cause Unix such
nightmares and yet not make MacOS even blink.
:-)
The 5300 is an all-in-one performa/powermac.
I don't remember which case style. I'm really
rather sloppy about the whole PowerMac vs.
Performa name thing on these models because
they're all the same basic motherboard, just
with different processor speeds (and thus
different bus speeds).
What's in a name? A Macintosh Apple by any other
name would taste as sweet.
Actually, it's the PPC 601 that keeps NetBSD
from supporting the 7200. The 7500 isn't
supported, either, unless you swap processor
cards. Unfortunately, the 7200 can't be
upgraded at all (or at least nobody has been
successful at building an upgrade yet).
Slashdot Mirror
Having used both CodeWarrior and ProjectBuilder, I'm going to disagree strongly with you here. I've found PB to be a very comfortable environment in which to work. Of course, I don't open twenty files at a time in PB. I edit with vi because it's more powerful than any pointy-clicky editor. Just MNSHO.
That having been said, if you think it sucks so badly, why don't you be responsible and file bugs about it instead of bitching about it anonymously on slashdot. If something doesn't work well, say so. If you don't complain, then it is -your- fault, not Apple's, that the developer tools are, in your words, "craptacularly bad".
Whether you like PB or not, I don't see MS giving away developer tools, good or bad. And therein, I believe, lay the original poster's point....
Or worse, 10.11.6, i.e. X.11 R6....
That may be the first time I've seen such a completely on-topic off-topic post....
I agree with many of your points. I've always regarded PAM as a necessary evil (very evil).
:-)
:-)
I disagree, though, that the real workaround couldn't be made available. The more vague the information, the more likely fascist network admins are to block port 22 entirely. Being able to lose partial functionality is better than losing all functionality, but only if that loss of functionality actually solves the problem. Some companies and individuals would be unable to turn that feature off, which is unfortunate, but at least they would know up-front what they were dealing with and could make an informed decision about how to react.
I applaud OpenSSH for pushing people to use privilege separation. That's a very good feature, and I'm glad to see that people are actually working on making it work correctly. It's an important security feature.
A word of caution, though. Privsep will reduce the risk of a root attack, but not by 90%. Unprivilleged logins can still do an awful lot of damage if a system admin hasn't kept up with fixes for local root exploits. Sad, isn't it?
However, there -is- a right way to do a security update of a piece of software that minimizes the odds of anyone's computer being compromised. It goes something like this:
1. Fix your own copy, make binary-only release available on your distribution.
2. Security announcement to vendors through whatever channel. Include patch.
3. Vendors build and release binary updates. Announce these updates. Keep source private, including vendor-modified versions.
4. At a scheduled date, official source release. Vendors concurrently release modified source.
Ideally, there should be about a week from the initial patch to the source release. This gives vendors a chance to react, while still providing security to OpenBSD users. It also ensures that end-users' systems are protected to the maximum extent possible as soon as possible while minimizing the changes of black hats getting information on the hack.
An alternate variation on this involves releasing the source and binaries at once, so that the particularly cautious could build their own. The point being that it takes vendors time to build and qualify something as complex as SSH, and expecting it to just happen instantly is not a reasonable expectation, even for a large vendor with large resources.
The whole bit about vendors leaking information to black hats is disconcerting. If there's cause to believe that this is occurring, then better steps need to be taken to qualify vendors for this sort of information rather than simply exluding vendors from the information. If there are infrastructure needs in this area, I'd be happy to help in any way I can (time permitting, of course.
I love it when someone calls me a leech....
:-)
I currently have kernel patches in the kernels of three shipping operating systems, and have helped in the development of kernel code for two others.
I manage three open source code development projects, two of which involve kernel development (the third is an X11 app).
I'm an active contributor to seven, count them, 7, open source projects, and there are others that I've simply gotten too busy to continue contributing to.
With the help of a team of about two other people I maintain one of only two working distributions of Linux on the PowerMac, not because I want to make money from it (I haven't made one single penny from MkLinux EVER), but because it helps others and helps me keep my systems running as well.
No, I haven't made any useful patches to OpenSSH. It's one of about a thousand packages that we have to maintain. For a team of 2-3 people working in their spare time to supporting several THOUSAND users for free, there's only so much you can do.
In short, if using a piece of software makes me a leech, then so be it. I'm a leech, and proud of it, as is nearly everyone else reading this thread. Last I checked, the purpose of an open source project was to help the end user, and treating vendors with contempt in a way that hurts their users is not socially acceptable behavior.
Now admittedly, MkLinux is in the minority here, being one of only a handful of such projects that are both free and contribute code changes back upstream periodically.
I fully agree with you that companies that make money off distributions should contribute time and effort to making these projects work. Those of us who are already giving our blood, sweat, and tears and getting nothing from it other than the thanks of our user base, however, cannot possibly be expected to do that, and to suggest otherwise is, quite frankly, ludicrous beyond belief.
Now, I wrote with legitimate complaints about poor security practices. I'd very much appreciate it if you'd stick to the topic at hand. While you're at it, you might actually read something about what someone does before accusing them of being a leech and a repackager.
The OpenSSH guys are guilty of the worst kind of underhanded dealing in this matter. As a vendor, I'm frankly, disgusted in every sense of the word. They deliberately compromised the security of other vendors through their actions by:
* posting a workaround that broke functionality but didn't fix the problem,
* failing to disclose (in advance) a workaround that does close the hole,
* failing to release the source code to vendors before detailing the vulerability to the general public,
* deliberately releasing the vulnerability five days earlier than expected, catching vendors off-guard, and
* using strong-arm scare tactics to force a very broken feature on the end-user community.
In short, they have made a mockery of reasonable procedure for security updates.
If this is what we should expect from OpenSSH when future security vulnerabilities arise, then I, for one, will be investigating alternatives to OpenSSH, and I strongly encourage other vendors to do the same. The security of our users' systems is too precious to be left in the hands of someone who does not have their best interests in mind.
IBM. Well, no, technically they're not making CHRP boxes any more. But it would take all of a couple of hours to make Mac OS X run on it, and since those parts of the OS are open source, you could do it, too.
How many companies' computers can you (as a consumer) port Windows to?
That makes it only 241 years. :-)
That's not really fair. I'm part of what was, at one time, a fairly large open source project. I have resources coming out the backside, but I still use SF for some things. SF has a relatively straightforward bug tracking system that's easier for users to understand than bugzilla (which has the most obscenely bad main search page that I've ever seen). And of course, I don't have to actually set it up or maintain it. It just works.
So of course, I use my own servers for things like web pages, and for most projects, my own servers handle downloads as well. But when it comes to bug tracking interfaces, there's still a little stub SF project.
The moral is, just because a project is mature and has resources doesn't mean it needs to waste them on something that SF provides for free. ;-)
Not only are these guys blatant trolls, but they're also wrong. As anyone who has ever tried to crack a Mac will tell you, there are entire classes of buffer overflow attacks that can't be done on PowerPC that are instant root access on x86. And it's harder to write many other types of exploits on PowerPC.
Umm... I started programming when I was 6.
Of course, that was before the Seagate/Conner merger. Seagate drives up to and including 2 gig drives or thereabouts sucked. There's just no other way to put it.
By contrast, I still have Conner 40 meg drives that work -now-. You figure that they were made about ten years ago, and that's pretty bloody cool.
After that merger, Seagate's quality improved a lot. I've had total success with their desktop drives since then. Their 5.25" drives haven't fared quite as well (I've had one drive become slightly flaky after about two years of continuous service), but are still pretty solid.
I agree wholeheartedly with the folks who find the DMCA disgusting. When I distribute tapes to people to watch, I assume they have VHS decks. But if they don't, and their friend dubs it to Beta for them, that's fine with me. I'd much rather have the eyes watching the content than be a pain in the backside about its format.
As for the whole songwriter thing, most folks in music barely make any money when all is said and done. Most of it's going into the pockets of nameless, faceless corporate giants. The unfortunate thing is that those of us who don't give music to big companies can't get airplay, because the stations are almost all owned in whole or in part by a subsidiary of one of those big companies.
Don't assume that it's just content users that disagree with the DMCA. Most content originators disagree with it, too. About the only people I'm aware of who do agree with this law are content distributors, because laws like these are the only things keeping them in business.
Those of us doing non-mainstream music, movies, and TV LIKE open access like Napster, because they are the "great leveler" that the internet has always promised, but never quite become. And while I've never made a DVD, if I did, I would certainly not add ludicrous half-hearted zones to prevent people from viewing it.
The way I (and I suspect most creative people) view the situation is this: the media keeps telling us how many millions of dollars are lost to pirated DVDs and videotapes and music. What they seem to forget is that these are sold to people who would probably not have purchased the original tape/dvd/cd, whether for cost reasons or simply because it wasn't sold in their country. While that doesn't make the piracy itself any more acceptable, viewing that material is another matter. I'd much rather have my material seen, even illegally in some user-chosen, format than locked away in a storeroom somewhere because people weren't willing to pay the price.
In short, people who make music and movies for the money are in the business for the wrong reasons. Music and movies are to entertain. When we forget that, we're making just as big a mistake as those who pirate our works. As always, my opinions are mine, and mine alone, not those of my employers, etc.
David
I think the best way to fight this sort of bull is to start a petition, not to the government, but direct to Real Networks, and send a copy of the final petition to as many national media outlets as possible.
Basically the petition should be something on the order of, "We the undersigned, in response to the reprehensibly proprietary nature of and the questionable legality of the defense of the codecs by the aforementioned, henceforth refuse all use of any product containing software licensed from Real, Inc. until the cessation of such unfair restraint of trade against the public interest."
Or some such. The one thing that a company fears the most is tens or hundreds of thousands of people banding together and refusing to use their products. No money, no company. They either change their tune or they stop whistling. Either way, Real will soon be relegated to a footnote in history if they continue these pointless attacks.
David
David
David
Look on the ftp site. The patches are right there, plain as day. :-)
David
The article mentioned IA32 , not IA64. In other words, what most people know as the x86 family, i.e. Pentium III, Athlon, whatever. And of course, as with everything else I've seen from MontaVista, it's 100% free and Open Source. The patches to the kernel are right there on the FTP site, so you should be able to modify it to work on other platforms.
David
Bzzt. MkLinux is also available for HP PA-RISC and can also be jammed into x86 systems (replacing the kernel in a RedHat install, for example). David
MkLinux works.
David
Its speed depends largely on what you're doing.
:-)
The 603's floating point scores are in the tank,
but its integer speeds, IIRC, are not bad. On
the average, it's just a little slower.
Also you have to take into account that the
7200 was probably running a newer (read bigger)
version of MacOS, unless the 5200 had been
upgraded. Finally, you have to consider whether
the performance was bounded by other factors
such as waiting for user input or the hard
drive speed or the speed of the bus between the
processor and RAM.
Also, I think most or all of the 5200s came from
the factory with a L2 cache, and I think only a
few 7200s did, which would also have a leveling
effect.
David
Yeah. I just about jumped through the ceiling
when I first reached the "Unable to read
bootstrap.conf" message and was able to type
on the screen. That was a couple of weeks ago.
Down hill from there.
David
Some NuBus PowerMacs. Not AV machines, last I
heard from Takashi.. Pretty big caveat.
That's gonna be nasty to fix, as it involves
making sure every single eieio and sync (or was
it isync) uses the same standard macro to do
its work, everywhere it appears in the entire
kernel, then making that macro #ifdef'able
to wrap it with some really nasty code....
Amazing how one little hw bug and an obscure
feature of the 601 chip can cause Unix such
nightmares and yet not make MacOS even blink.
:-)
David
The 5300 is an all-in-one performa/powermac.
I don't remember which case style. I'm really
rather sloppy about the whole PowerMac vs.
Performa name thing on these models because
they're all the same basic motherboard, just
with different processor speeds (and thus
different bus speeds).
What's in a name? A Macintosh Apple by any other
name would taste as sweet.
David
Actually, it's the PPC 601 that keeps NetBSD
from supporting the 7200. The 7500 isn't
supported, either, unless you swap processor
cards. Unfortunately, the 7200 can't be
upgraded at all (or at least nobody has been
successful at building an upgrade yet).
David