There is a bug in the following Javascript on the page:
function validate(aForm) {
if (cookies_enabled() == true)
{
checkForSelection (aForm);
}
else
{
alert ("You must have cookies enabled to proceed.");
} }
Apparently, cookies_enabled() is unreliable under both Safari and OmniWeb. To fix this, either change the condition to true or use one of the direct download links someone has been kind enough to post below.
First of all note that OmniWeb is not affected by this bug. Outside of a lack of tabs, it's a very good Web Browser that should satisfy you until Apple patches this bug. Of course, I'm sure the Slashdot readership is aware of other options as well.
As for the discussion as to whether this is a bug in KHTML in general, it is not. The bug is in the way browsers parse the hostname out of a URL differently for cookies and the connection itself. So in Safari the url:
http://www.EvilSite.com%00.amazon.com/
will connect to www.EvilSite.com, but be considered in the domain of.amazon.com for the purpose of cookie security. This seems to be a bug in the code around KHTML, not KHTML itself, since vulnerable OmniWeb uses the same WebCore framework that is used by Safari without being vulnerable.
I've been setting up an OpenBSD web server for the past few days now, and had some time to finagle with chroot Apache. I've found it to be a wonderful idea that I've had to disable.
Why? No fault of OpenBSD, really. Simply that in order to do anything really interesting, I had to disable the chroot of httpd. Take perl scripts, for example: If a CGI script is supposed to be interpreted by/usr/bin/perl (as indicated with #!) it will fail unless you've placed a copy of the perl interpreter in the chroot environment. You can get around this with mod_perl to embed a perl interpreter directly into Apache, but one still will have to preload any shared libraries mod_perl uses (see section four of the paper).
As another example, PHP's mail() function [which is fairly important, I feel] relies on the presence of sendmail. Sendmail then, must be accessible from the chroot directory in order to work.
Someone above has commented that you can mount/usr in the chroot environment to solve most of these problems. But of course, as the paper says, the more binaries in the environment, the lower the security, so one must make sure there is no setuid binary available.
Ultimately, the paper does describe ways around this, basically preloading any shared library your Apache modules might need and populating the chroot jail with any binaries you want for CGI and their shared libraries. This mirroring however requires a good deal of maintenance and waste of space (following OpenBSD partitioning recommendations,/var and/usr will be on seperate partitions so hardlinks won't work. Symlinks can't break out of chroot). At this point, I think a lot of us will be unwilling to sacrifice simplicity (read: stability, maintainability) for this measure of security. The argument that this only affects those who CGI scripts is very correct, but ultimately a trivial point: To do anything interesting (like Slashdot) requires CGI.
The situation will get better, though, and they'll find a simple elegant maintenance system, as OpenBSD always has. Some things have to change: For example/etc/rc.conf is currently insufficient for preloading libraries. It should have an additional directive called httpd_preload for shared libraries. Also, apachectl may need to be modified or supplemented on OpenBSD.
"At the beginning of the class, each of you will pick either Superfly Johnson or Mikiko Ebihara as your lab partner. If they fail the course, you fail the course.
Don't worry though as your lab partners are coded with an advanced "node-based AI system", and should be a valuable and innovation part of your lab experience."
Knuth showed in his _Art of Computer Programming_ that the running time of GCD() is between O(n^2) and O(n). Since the factorial function is exponential, the arguments to GCD are exponential in size, and so your algorithm is exponential as well. It is no better than brute force.
Sorry, but post this magic algorithm as much as you want. The situation isn't going to become less bleak.
Sorry, but you're basically wrong, and everyone here really needs a better understanding of complexity theory before posting.
Factoring and solving discrete logarithms in a finite field have been shown to be not not NP-Complete, although they are believed to not be in P either (this operating under the assumption that NP != P) and so are called NP-Hard. Since they are not NP-Complete, given a polynomial running time algorithm which solves them, we can't change it into an algorithm which solves an NP-Complete problem in polynomial time.
However, since NP-Complete problems are harder than NP-hard problems the other way around works: If one can solve *any* of the NP-Complete problems (and hence, all of them) in polynomial in polynomial time, one could solve all NP-hard problems in polynomial time as well. So you'd still be screwed.
Interesting aside: While there are plenty of NP-Complete problems, and countless problems definitely in P, there are only two known NP-hard problems: Factoring and graph isomorphism. What is more interesting is that while there are successful crypto systems built off of both factoring and graph isomorphism, every crypto-system based off an NP-complete problem has failed (i.e. Knapsack problem). There seems to be something fundamental which makes NP-Complete problems inappropiate for crypto-systems, but no one's been able to quantify it yet.
I used to work in the MacBU at Microsoft and my officemate was on the Mac IE team.
One day we were experimenting with the download behavior of IE, and I noticed the problem. We discussed it and later brought it up to the higher ups on the team during lunch (The food in the Silicon Valley Campus Café is much better than Redmond's by the way):
"If a malicious web site designer were to use some method of redirection to get the browser to download a.hqx binary, the user might not even know that IE was downloading unless they watched the download manager very closely," I said. I believe some other members of the team had already noticed the problem as well.
We all agreed this was a serious security hole and it is being fixed in the next release.
In the meantime, you can turn off the "Automically decode BinHex files" under Download Options in the Explorer Preferences. We tested Mac IE's behavior with MacBinary files and there is no security hole there.
How did this bug slip by the team? Well, I am not on the IE team, so I couldn't say for certain. I believe the problem is that after IE uses its own.hqx decoding functionality, it should try to process the resulting file. This is good as it allows one to download and unstuff a.sit.hqx archive automatically.
Somehow this behavior was fubared, however: Instead of passing the file back through IE's file helper layer, it was apparently opened directly. This has acceptable behavior if the file downloaded was happyapp.sit.hqx, but not-so-acceptable behavior if the file downloaded is evilevilapp.hqx.
Anyway, someone clearly messed up. We're very sorry. Or rather, they are since I probably won't get rehired after this message.
It's pretty sad to see this kind of hypocrisy on Slashdot. The dichotomy between the attitude towards "Script Kiddies" and the attitude towards those considered truely elite is disgusting: Hackers are met with sympathy and understanding; script kiddies almsot face a lynch-happy slashdot posse.
Am I the only one who believes that this is a tad unfair? It is hypo-critical for us to push the ubiquetious adoption of Linux on one paw, and then attack Windows for the practice on the other.
The natural refute to what I've said, is that Linux will afford a greater degree of variety in each of its implementations, while Windows will likely be the same software, with the same vulnerabilities on every device that runs it.
That too, however is unfair. Witness the X-Box--A very slim kernel (it's smaller than WindowsCE) with extraneous functionality ripped out. Microsoft is capable of de-bloating their kernel.
Further, the idea that security exploits would exist across device implementations is pretty absurd. Beyond the possibility of bugs in, say, the Networking stack or race conditions in the kernel, this simply isn't likely to happen. A toaster would not need to run IIS, and so would not run IIS, hence it has no fear of Code Red.
This is akin to arguing against the ubiquetious (no, I do know how to spell that. My apologies) adoption of Linux because of say, the exploit in piranha from a while back.
Did they do this to such a beautiful machine? As a mac-lover this brings me to tears.
Seriously, though, a Mac can still be a decent LAN machine. It does runs Quake III (quite nicely under OS X) and Unreal Tournament. Starcraft and Myth II as well.
Beyond those, of course, you are going to have trouble.
Scope and what isn't shown
on
Mac Rants
·
· Score: 1
It is important to bear in mind the scope of this article; it is deriding what is obviously a flawed benchmark test. It should not be interpreted as a scathing review of all of Apple's innovations. In particular, it focuses only on hardware and skips over the great strides Apple has made in its software developement.
And the software is perhaps where the real appeal of the Mac lies, something even good benchmarks wouldn't reflect. And this has special significance to Linux users.
Install Linux alongside Mac OS and you have a much nicer Operating System to fall back on when something hasn't been Linuxized yet. Your alternative in the desktop market is basically Windows and we all know how painful that is. It's much nicer to boot back into OS X or OS 9. And since the new Macintoshes use Open Firmware, so you don't have to worry about mucking around with your boot blocks and Lilo.
Furthermore, the state of open source Mac emulation on Linux is, in my opinion, much nicer than the comparative Windows emulation (see http://www.maconlinux.net)
Of course, this won't solve your needs if you intend to dual boot for games, but if you want another operating system alongside Linux, Mac OS is very harmonious. But you're going to need a Mac to do so.
If that's the motivation here, congress is behavior with uncharacteristic guile.
Did you actually read through the report and Rep. Waxman's statement? There is no real focus on the legality of file sharing or copyright violations. If anything, the reports seem to have carefully avoided the subject because it would distract from their main point. Further I could find no recommendations for the use of legislation to control the technology, the usual congressional reaction to this sort of thing.
Instead they provided tips to parents on how to protect their children and pointed out the flaws in content filtering software. Isn't this the sort of thing/. has been recommending all along? Put parents in charge of protecting their kids and not hide legislation and ineffective content filtering software? So shouldn't we be encouraging them when someone as dense as a US Congressman seems to "get it"?
Granted, the whole thing could just be a small part of a vast plan to sweep in apocalyptic thought control to the Internet, carefully disguised as recommendations and information for parents, but I think that would be giving the US government too much credit.
Let's be clear here. Mac OS X is not a threat to most of Linux's most important markets. Programmers are unlikely to switch to it, webservers and the like are unlikely to run it, and geeks will probably want to stick to something which they have as much control over as Linux. The reasons have been pointed out quite eloquently above (cost of hardware, lack of control, not entirely open, etc.) so I won't repeat them here.
The market Linux does stand to lose is the one it never really had anyway: The desktop market. Let's face it, we don't have it. My mom doesn't run Linux and probably will never run Linux. I don't blame her; she doesn't know what repartitioning is and I don't think she should have to.
As geeks, some Slashdot readers probably don't see this as a big problem. But I think they should. We need the desktop market, not for profit, but for conquest: There shall be no World Domination without it. Besides, we all start out as computer newbies, and grew up into Linux. But why move to Linux if you can have the best of both worlds? Mac OS X has been described as a geek's playground under a candy coating, and having used it, I'm inclined to agree.
This has me concerned, but really, we in the Linux community have no one to blame than ourselves. We could have the most stable, practical, and usuable operating system around. We already have two out of the three. But attempts to make a loser--er, sorry--userfriendly distro have been derided and ignored for various reasons (Corel Linux comes to mind). Eazel's a good start, but I wonder if it's too little too late.
Don't brush off Mac OS X just because it's only for PPC based architecture; it's part of a growing trend. If Linux doesn't steal the desktop market, BSD might, and if they don't, Windows will keep it. Compaq's no longer as friendly to Linux as it used to be, Corel is rumoured to be dropping its Linux line, and so on. Linux should be gaining ground on the desktop market.
I prefer it this way:
(define fact
(letrec
((facto
(lambda (n t)
(if (< n 2)
t
(facto (- n 1) (* n t))))))
(lambda (n) (facto n 1))))
Note that by coding in this manner, one is coding tail-recursively--Nothing has to be saved on the stack from one recursive call to the next (in Scheme functions evaluate their arguments before applying the operator so (- n 1) and (* n t) are evaluated before recursion).
I've tried this in Python and got interesting results: A nontail recursive factorial will stack overflow. A tail-recursive implementation still overflows, but after more calls.
Most coders couldn't care less, but then most coders prefer an iterative approach to a recursive one. Which is a bleeding shame, because often recursion is so much cleaner. You can always make it iterative later.
A lot of people who grew up with imperative languages like C, seem to bear a lot of malice towards more functional languages like Python (it's almost first order and pretty functional) or Scheme. I don't really see why. The common whine is that it's the difference between theory and practice. But hey, this is computer science: Theory is practice.
Personally, I prefer Blacklab Linux as a professional solution, although unfortunately it is not free. Still, the expensive price of Apple PowerPC's makes this a viable solution only under a few conditions:
You need to do mega number crunching: Nothing can really beat an AltiVec PPC processor with compiled Fortran.
For some reason, the amount of wattage your cluster uses is important to you.
I can't really think of any others, unless you're a crazy mac user. But don't listen to me; I'm just a crazy mac user.
Didn't they remove OpenGL support in BeOS 5? I'm sure you can put it back, but still....
Be is very professional, I suppose, and refuses to put something in a distribution before it's completely polished.
It's interesting to read some of the things Schneier wrote some years ago and what he's writing now. In Applied Cryptography, he seemed to argue that widespread and careful adoption of good crypto would lead to better security.
Now the point seems to be that system security is simply too complicated--too many issues, too many variables. And that system is secure.
Despite this sentiment, however, OpenBSD seems to be doing quite well....
And just a reminder--Less than a week before the RSA patent expires.
You make a good point. However, it is important to note that this release is not targetting developers. As I iterated in my other posts (Mr. Lagos is in an endless loop!) there is no project builder, the OS X IDE, bundled in this relase. No debugging tools. Nada.
In fact looking at apple's MacOS X developement site there's a message specifically detering non-developers away from any developement information. It reads:
ATTENTION: This page provides resources for people developing applications for Mac OS X. If you are a customer participating in the Mac OS X Public Beta program please proceed to http://www.apple.com/macosx/ for customer information and updates.
In other words, the beta is designed mostly for people who should never see the inside of a developement site. Developers won't pick up the beta--They get a better package from the ADC.
So what this is actually targetting is testers. And while I see the point of having lots of testers and advertisering to obtain them, most of the people who will actually pay for this won't be expecting a testing job. They're doing it because they want to have MacOS X, even if they have to settle for a beta.
All it takes is a little reading of mac fanatical magazins (MacWorld, etc.) to realize how many non-developer mac users are obsessed with Mac OS X, and are planning to buy the beta and will probably, as you said, break their machines with it. Apple's online store was practically overloaded this morning.
Hey, I don't care. I'm a Mac Fanatic, so I'll probably buy it. But let's not delude ourselves, Apple isn't charging $30 as a deterent. They're charging $30 because they can.
It's $99 per year for students. Yes, that's affordable, and yes, I'm whining. But I don't feel like paying $99 per year for what basically amounts to do Apple a favor. =:p
And I still maintain that if apple wants to be successful they'll have to attract new developers to the new platform. A great way to do that would be try to attract BSD developers, even casual ones (like me). And I doubt they can do that if their developement tools aren't free.
I don't think anyone's pointed out yet that "Project Builder", the IDE for Mac OS X Cocoa developers, doesn't seem to be included in the beta.
This is truly a disappointment. In order to survive Apple must supplant its old OS with a better one. In order to do that, they need apps, and in order to get apps they need lots of developers.
Apple's fairly expensive Developer Registration fees (actually they're not much compared to Microsoft's, but they're still not free) has stopped a lot of potential developers from obtaining developers previews through official, legal channels. Isn't this just going to continue the trend?
Maybe it will be included, and Apple just doesn't want to confuse users. But if it isn't, it's going to be hard to convince people to develop for Cocoa. Come on Apple, get on the ball.
I am afraid that I distrust the subtle overtone of optimism in Katz' article.
All of his points seem valid enough, but I worry that we'd be setting ourselves up for disappointment should we believe that there's a chance that the publishing industry will accept Open Publishing, a kind of Darwinian experimental brain pool find the most popular new authors. Or, for that matter, if we convince ourselves that they should embrace open publishing.
To implement such a dynamic system would require the cooperation of the stodgy executives who do not understand the new world and its technology.
Even if they did understand the new paradigm of Open Thought, they might not like the idea: Quite simply it's probably not profitable.
Let me explain that last point: To some extent, the Open Source movement has been an economic success. Red Hat has yet to really turn an impressive profit, but as per Eric S. Raymond's suggestions we should wait until the first quarter of 2001 before passing judgement. That the Open Source movement succeeded was to be expected: Geeks love Open Thought, of course, and software is possibly the quintessence of geekdom. More importantly, the value of software comes from not from the code itself, but more often from the sservice one expects in the form of compatibility, updates, support, etc. Because of this Open Source can be profitable.
On the other hand, Open Publishing (that is the publication of prose, usually in an electronic medium, without charge for royalties) is not profitable. Precisely because it is not the stuff of Geekdom. Katz may focus on the success of works like House of Leaves (I absolutely love the book, btw) and the need of the technocratic community to experience interactive, iconoclastic literature, but we have to face up to reality: Most people simply do not care. Most people in the western world want the linear progression of books by authors like Crichton and King. Most could care less about interactivity in their novels. Most people probably couldn't stand House of Leaves.
In other words, most people don't read slashdot. And it's primarily because of this, one suspects, that Microsoft feels it can make a profit off e-books. Who cares if Geeks and college kids will pirate them like a Napster Feeding Frenzy? Sadly, geeks and college aren't the people who read the most books....
More importantly in the medium of the written word, all value of the work is intrinsic to the work itself. Whoever heard of rpm -Uhv Watership-Down.noarch.rpm? If the profit in the work is purely a matter of the content itself, there's really no economic point in Opening it, because there is no market for support from which to obtain revenue. If you're a FS-Fanatic, you might not care, but I think publishing executives might be a little more interested in the Green Stuff....
So while from our Silicon Tower, we may mope that the e-book revolution is foolhardy and missing its chance to be embraced by us, I think we should take a step back and realize that the rest of the world probably doesn't care.
At the same, one must consider the flip side of this audtiing--While new frills and whistles are not required or even necessarily desired by experienced users, there are are also some nontrivial utilities, providing excellent functunality, which are conspicuously absent due to lack of auditing.
For example, by default OpenBSD uses Bind4.x. Although a port of bind8 is available, it apparently has not completed the auditing procedure required before it can be part of the standard distribution. Yet the new features of Bind 8.x, are something in which I believe many experienced users would be interested.
Ultimately, this doesn't really matter--The Bind 4.x implementation included is probably quite secure. And the motivation for OpenBSD is security over functunality. Users can, of course, add that functunality should they wish (at the cost of security), but the question must be asked:
If you're going to run OpenBSD with the same unaudited binaries you'd run under NetBSD or Linux, why run OpenBSD at all?
--
Lagos
Thanks to nome for all significant content in this message. =:P
Slashdot Mirror
There is a bug in the following Javascript on the page:
function validate(aForm)
{
if (cookies_enabled() == true)
{
checkForSelection (aForm);
}
else
{
alert ("You must have cookies enabled to proceed.");
}
}
Apparently, cookies_enabled() is unreliable under both Safari and OmniWeb. To fix this, either change the condition to true or use one of the direct download links someone has been kind enough to post below.
First of all note that OmniWeb is not affected by this bug. Outside of a lack of tabs, it's a very good Web Browser that should satisfy you until Apple patches this bug. Of course, I'm sure the Slashdot readership is aware of other options as well.
.amazon.com for the purpose of cookie security. This seems to be a bug in the code around KHTML, not KHTML itself, since vulnerable OmniWeb uses the same WebCore framework that is used by Safari without being vulnerable.
As for the discussion as to whether this is a bug in KHTML in general, it is not. The bug is in the way browsers parse the hostname out of a URL differently for cookies and the connection itself. So in Safari the url:
http://www.EvilSite.com%00.amazon.com/
will connect to www.EvilSite.com, but be considered in the domain of
I've been setting up an OpenBSD web server for the past few days now, and had some time to finagle with chroot Apache. I've found it to be a wonderful idea that I've had to disable.
/usr/bin/perl (as indicated with #!) it will fail unless you've placed a copy of the perl interpreter in the chroot environment. You can get around this with mod_perl to embed a perl interpreter directly into Apache, but one still will have to preload any shared libraries mod_perl uses (see section four of the paper).
/usr in the chroot environment to solve most of these problems. But of course, as the paper says, the more binaries in the environment, the lower the security, so one must make sure there is no setuid binary available.
/var and /usr will be on seperate partitions so hardlinks won't work. Symlinks can't break out of chroot). At this point, I think a lot of us will be unwilling to sacrifice simplicity (read: stability, maintainability) for this measure of security. The argument that this only affects those who CGI scripts is very correct, but ultimately a trivial point: To do anything interesting (like Slashdot) requires CGI.
/etc/rc.conf is currently insufficient for preloading libraries. It should have an additional directive called httpd_preload for shared libraries. Also, apachectl may need to be modified or supplemented on OpenBSD.
Why? No fault of OpenBSD, really. Simply that in order to do anything really interesting, I had to disable the chroot of httpd. Take perl scripts, for example: If a CGI script is supposed to be interpreted by
As another example, PHP's mail() function [which is fairly important, I feel] relies on the presence of sendmail. Sendmail then, must be accessible from the chroot directory in order to work.
Someone above has commented that you can mount
Ultimately, the paper does describe ways around this, basically preloading any shared library your Apache modules might need and populating the chroot jail with any binaries you want for CGI and their shared libraries. This mirroring however requires a good deal of maintenance and waste of space (following OpenBSD partitioning recommendations,
The situation will get better, though, and they'll find a simple elegant maintenance system, as OpenBSD always has. Some things have to change: For example
"At the beginning of the class, each of you will pick either Superfly Johnson or Mikiko Ebihara as your lab partner. If they fail the course, you fail the course.
Don't worry though as your lab partners are coded with an advanced "node-based AI system", and should be a valuable and innovation part of your lab experience."
Knuth showed in his _Art of Computer Programming_ that the running time of GCD() is between O(n^2) and O(n). Since the factorial function is exponential, the arguments to GCD are exponential in size, and so your algorithm is exponential as well. It is no better than brute force.
Sorry, but post this magic algorithm as much as you want. The situation isn't going to become less bleak.
Sorry, but you're basically wrong, and everyone here really needs a better understanding of complexity theory before posting.
Factoring and solving discrete logarithms in a finite field have been shown to be not not NP-Complete, although they are believed to not be in P either (this operating under the assumption that NP != P) and so are called NP-Hard. Since they are not NP-Complete, given a polynomial running time algorithm which solves them, we can't change it into an algorithm which solves an NP-Complete problem in polynomial time.
However, since NP-Complete problems are harder than NP-hard problems the other way around works: If one can solve *any* of the NP-Complete problems (and hence, all of them) in polynomial in polynomial time, one could solve all NP-hard problems in polynomial time as well. So you'd still be screwed.
Interesting aside: While there are plenty of NP-Complete problems, and countless problems definitely in P, there are only two known NP-hard problems: Factoring and graph isomorphism. What is more interesting is that while there are successful crypto systems built off of both factoring and graph isomorphism, every crypto-system based off an NP-complete problem has failed (i.e. Knapsack problem). There seems to be something fundamental which makes NP-Complete problems inappropiate for crypto-systems, but no one's been able to quantify it yet.
I used to work in the MacBU at Microsoft and my officemate was on the Mac IE team.
.hqx binary, the user might not even know that IE was downloading unless they watched the download manager very closely," I said. I believe some other members of the team had already noticed the problem as well.
.hqx decoding functionality, it should try to process the resulting file. This is good as it allows one to download and unstuff a .sit.hqx archive automatically.
One day we were experimenting with the download behavior of IE, and I noticed the problem. We discussed it and later brought it up to the higher ups on the team during lunch (The food in the Silicon Valley Campus Café is much better than Redmond's by the way):
"If a malicious web site designer were to use some method of redirection to get the browser to download a
We all agreed this was a serious security hole and it is being fixed in the next release.
In the meantime, you can turn off the "Automically decode BinHex files" under Download Options in the Explorer Preferences. We tested Mac IE's behavior with MacBinary files and there is no security hole there.
How did this bug slip by the team? Well, I am not on the IE team, so I couldn't say for certain. I believe the problem is that after IE uses its own
Somehow this behavior was fubared, however: Instead of passing the file back through IE's file helper layer, it was apparently opened directly. This has acceptable behavior if the file downloaded was happyapp.sit.hqx, but not-so-acceptable behavior if the file downloaded is evilevilapp.hqx.
Anyway, someone clearly messed up. We're very sorry. Or rather, they are since I probably won't get rehired after this message.
--
Lagos
Gentle Bunny
It's pretty sad to see this kind of hypocrisy on Slashdot. The dichotomy between the attitude towards "Script Kiddies" and the attitude towards those considered truely elite is disgusting: Hackers are met with sympathy and understanding; script kiddies almsot face a lynch-happy slashdot posse.
He's a minor. I think 8 months is sufficent.
The natural refute to what I've said, is that Linux will afford a greater degree of variety in each of its implementations, while Windows will likely be the same software, with the same vulnerabilities on every device that runs it.
That too, however is unfair. Witness the X-Box--A very slim kernel (it's smaller than WindowsCE) with extraneous functionality ripped out. Microsoft is capable of de-bloating their kernel.
Further, the idea that security exploits would exist across device implementations is pretty absurd. Beyond the possibility of bugs in, say, the Networking stack or race conditions in the kernel, this simply isn't likely to happen. A toaster would not need to run IIS, and so would not run IIS, hence it has no fear of Code Red.
This is akin to arguing against the ubiquetious (no, I do know how to spell that. My apologies) adoption of Linux because of say, the exploit in piranha from a while back.
Did they do this to such a beautiful machine? As a mac-lover this brings me to tears. Seriously, though, a Mac can still be a decent LAN machine. It does runs Quake III (quite nicely under OS X) and Unreal Tournament. Starcraft and Myth II as well. Beyond those, of course, you are going to have trouble.
It is important to bear in mind the scope of this article; it is deriding what is obviously a flawed benchmark test. It should not be interpreted as a scathing review of all of Apple's innovations. In particular, it focuses only on hardware and skips over the great strides Apple has made in its software developement.
And the software is perhaps where the real appeal of the Mac lies, something even good benchmarks wouldn't reflect. And this has special significance to Linux users.
Install Linux alongside Mac OS and you have a much nicer Operating System to fall back on when something hasn't been Linuxized yet. Your alternative in the desktop market is basically Windows and we all know how painful that is. It's much nicer to boot back into OS X or OS 9. And since the new Macintoshes use Open Firmware, so you don't have to worry about mucking around with your boot blocks and Lilo.
Furthermore, the state of open source Mac emulation on Linux is, in my opinion, much nicer than the comparative Windows emulation (see http://www.maconlinux.net)
Of course, this won't solve your needs if you intend to dual boot for games, but if you want another operating system alongside Linux, Mac OS is very harmonious. But you're going to need a Mac to do so.
If that's the motivation here, congress is behavior with uncharacteristic guile.
/. has been recommending all along? Put parents in charge of protecting their kids and not hide legislation and ineffective content filtering software? So shouldn't we be encouraging them when someone as dense as a US Congressman seems to "get it"?
Did you actually read through the report and Rep. Waxman's statement? There is no real focus on the legality of file sharing or copyright violations. If anything, the reports seem to have carefully avoided the subject because it would distract from their main point. Further I could find no recommendations for the use of legislation to control the technology, the usual congressional reaction to this sort of thing.
Instead they provided tips to parents on how to protect their children and pointed out the flaws in content filtering software. Isn't this the sort of thing
Granted, the whole thing could just be a small part of a vast plan to sweep in apocalyptic thought control to the Internet, carefully disguised as recommendations and information for parents, but I think that would be giving the US government too much credit.
The market Linux does stand to lose is the one it never really had anyway: The desktop market. Let's face it, we don't have it. My mom doesn't run Linux and probably will never run Linux. I don't blame her; she doesn't know what repartitioning is and I don't think she should have to.
As geeks, some Slashdot readers probably don't see this as a big problem. But I think they should. We need the desktop market, not for profit, but for conquest: There shall be no World Domination without it. Besides, we all start out as computer newbies, and grew up into Linux. But why move to Linux if you can have the best of both worlds? Mac OS X has been described as a geek's playground under a candy coating, and having used it, I'm inclined to agree.
This has me concerned, but really, we in the Linux community have no one to blame than ourselves. We could have the most stable, practical, and usuable operating system around. We already have two out of the three. But attempts to make a loser--er, sorry--userfriendly distro have been derided and ignored for various reasons (Corel Linux comes to mind). Eazel's a good start, but I wonder if it's too little too late.
Don't brush off Mac OS X just because it's only for PPC based architecture; it's part of a growing trend. If Linux doesn't steal the desktop market, BSD might, and if they don't, Windows will keep it. Compaq's no longer as friendly to Linux as it used to be, Corel is rumoured to be dropping its Linux line, and so on. Linux should be gaining ground on the desktop market.
But I fear we're losing it.
--
Lagos
I prefer it this way:
(define fact
(letrec
((facto
(lambda (n t)
(if (< n 2)
t
(facto (- n 1) (* n t))))))
(lambda (n) (facto n 1))))
Note that by coding in this manner, one is coding tail-recursively--Nothing has to be saved on the stack from one recursive call to the next (in Scheme functions evaluate their arguments before applying the operator so (- n 1) and (* n t) are evaluated before recursion).
I've tried this in Python and got interesting results: A nontail recursive factorial will stack overflow. A tail-recursive implementation still overflows, but after more calls.
Most coders couldn't care less, but then most coders prefer an iterative approach to a recursive one. Which is a bleeding shame, because often recursion is so much cleaner. You can always make it iterative later.
A lot of people who grew up with imperative languages like C, seem to bear a lot of malice towards more functional languages like Python (it's almost first order and pretty functional) or Scheme. I don't really see why. The common whine is that it's the difference between theory and practice. But hey, this is computer science: Theory is practice.
--
Lagos
Well, there are some implementations of ML that I've seen which have continuations, but who can really say whether ML is functional or imperative?
I can't really think of any others, unless you're a crazy mac user. But don't listen to me; I'm just a crazy mac user.
--
Lagos
Didn't they remove OpenGL support in BeOS 5? I'm sure you can put it back, but still.... Be is very professional, I suppose, and refuses to put something in a distribution before it's completely polished.
Rijndael is harder to implement than, say Serpent, in my opinion.
Neither myself nor any of my hacker friends can pronounce Rijndalinjalel (let alone spell it).
So tonight I'm going out drinking until the entire world looks hashed.
--
Lagos
It's interesting to read some of the things Schneier wrote some years ago and what he's writing now. In Applied Cryptography, he seemed to argue that widespread and careful adoption of good crypto would lead to better security.
Now the point seems to be that system security is simply too complicated--too many issues, too many variables. And that system is secure.
Despite this sentiment, however, OpenBSD seems to be doing quite well....
And just a reminder--Less than a week before the RSA patent expires.
--
Lagos
You make a good point. However, it is important to note that this release is not targetting developers. As I iterated in my other posts (Mr. Lagos is in an endless loop!) there is no project builder, the OS X IDE, bundled in this relase. No debugging tools. Nada.
In fact looking at apple's MacOS X developement site there's a message specifically detering non-developers away from any developement information. It reads:
ATTENTION: This page provides resources for people developing applications for Mac OS X. If you are a customer participating in the Mac OS X Public Beta program please proceed to http://www.apple.com/macosx/ for customer information and updates.
In other words, the beta is designed mostly for people who should never see the inside of a developement site. Developers won't pick up the beta--They get a better package from the ADC.
So what this is actually targetting is testers. And while I see the point of having lots of testers and advertisering to obtain them, most of the people who will actually pay for this won't be expecting a testing job. They're doing it because they want to have MacOS X, even if they have to settle for a beta.
All it takes is a little reading of mac fanatical magazins (MacWorld, etc.) to realize how many non-developer mac users are obsessed with Mac OS X, and are planning to buy the beta and will probably, as you said, break their machines with it. Apple's online store was practically overloaded this morning.
Hey, I don't care. I'm a Mac Fanatic, so I'll probably buy it. But let's not delude ourselves, Apple isn't charging $30 as a deterent. They're charging $30 because they can.
--
Lagos
It's $99 per year for students. Yes, that's affordable, and yes, I'm whining. But I don't feel like paying $99 per year for what basically amounts to do Apple a favor. =:p
And I still maintain that if apple wants to be successful they'll have to attract new developers to the new platform. A great way to do that would be try to attract BSD developers, even casual ones (like me). And I doubt they can do that if their developement tools aren't free.
Just my two cents.
--
Lagos
According to the Darwin Developers list, Darwin is booting off Intels. If you're clever.
I don't think anyone's pointed out yet that "Project Builder", the IDE for Mac OS X Cocoa developers, doesn't seem to be included in the beta.
This is truly a disappointment. In order to survive Apple must supplant its old OS with a better one. In order to do that, they need apps, and in order to get apps they need lots of developers.
Apple's fairly expensive Developer Registration fees (actually they're not much compared to Microsoft's, but they're still not free) has stopped a lot of potential developers from obtaining developers previews through official, legal channels. Isn't this just going to continue the trend?
Maybe it will be included, and Apple just doesn't want to confuse users. But if it isn't, it's going to be hard to convince people to develop for Cocoa. Come on Apple, get on the ball.
--Lagos
I am afraid that I distrust the subtle overtone of optimism in Katz' article.
All of his points seem valid enough, but I worry that we'd be setting ourselves up for disappointment should we believe that there's a chance that the publishing industry will accept Open Publishing, a kind of Darwinian experimental brain pool find the most popular new authors. Or, for that matter, if we convince ourselves that they should embrace open publishing.
To implement such a dynamic system would require the cooperation of the stodgy executives who do not understand the new world and its technology.
Even if they did understand the new paradigm of Open Thought, they might not like the idea: Quite simply it's probably not profitable.
Let me explain that last point: To some extent, the Open Source movement has been an economic success. Red Hat has yet to really turn an impressive profit, but as per Eric S. Raymond's suggestions we should wait until the first quarter of 2001 before passing judgement. That the Open Source movement succeeded was to be expected: Geeks love Open Thought, of course, and software is possibly the quintessence of geekdom. More importantly, the value of software comes from not from the code itself, but more often from the sservice one expects in the form of compatibility, updates, support, etc. Because of this Open Source can be profitable.
On the other hand, Open Publishing (that is the publication of prose, usually in an electronic medium, without charge for royalties) is not profitable. Precisely because it is not the stuff of Geekdom. Katz may focus on the success of works like House of Leaves (I absolutely love the book, btw) and the need of the technocratic community to experience interactive, iconoclastic literature, but we have to face up to reality: Most people simply do not care. Most people in the western world want the linear progression of books by authors like Crichton and King. Most could care less about interactivity in their novels. Most people probably couldn't stand House of Leaves.
In other words, most people don't read slashdot. And it's primarily because of this, one suspects, that Microsoft feels it can make a profit off e-books. Who cares if Geeks and college kids will pirate them like a Napster Feeding Frenzy? Sadly, geeks and college aren't the people who read the most books....
More importantly in the medium of the written word, all value of the work is intrinsic to the work itself. Whoever heard of rpm -Uhv Watership-Down.noarch.rpm? If the profit in the work is purely a matter of the content itself, there's really no economic point in Opening it, because there is no market for support from which to obtain revenue. If you're a FS-Fanatic, you might not care, but I think publishing executives might be a little more interested in the Green Stuff....
So while from our Silicon Tower, we may mope that the e-book revolution is foolhardy and missing its chance to be embraced by us, I think we should take a step back and realize that the rest of the world probably doesn't care.
--Lagos
"There's no shame in shape."
At the same, one must consider the flip side of this audtiing--While new frills and whistles are not required or even necessarily desired by experienced users, there are are also some nontrivial utilities, providing excellent functunality, which are conspicuously absent due to lack of auditing.
For example, by default OpenBSD uses Bind4.x. Although a port of bind8 is available, it apparently has not completed the auditing procedure required before it can be part of the standard distribution. Yet the new features of Bind 8.x, are something in which I believe many experienced users would be interested.
Ultimately, this doesn't really matter--The Bind 4.x implementation included is probably quite secure. And the motivation for OpenBSD is security over functunality. Users can, of course, add that functunality should they wish (at the cost of security), but the question must be asked:
If you're going to run OpenBSD with the same unaudited binaries you'd run under NetBSD or Linux, why run OpenBSD at all?
--
Lagos
Thanks to nome for all significant content in this message. =:P