Ease of development, ease of testing, ease of debugging, and familiarity to developers are Microsoft's biggest selling points for Windows CE (otherwise, it's just a run-of-the-mill embedded kernel). But apparently, even with all those wonderful features, even companies like BMW, usually known for a commitment to quality, have a hard time developing good software. So, we have to conclude that Microsoft's main selling point for Windows CE probably doesn't make a difference.
Of course, people develop bad software with Linux as well. The difference is that Linux has no pretenses about it: software development is hard, GUI development is hard, and VisualFoobar doesn't make it much easier. If anything, VisualFoobar lets people who aren't sufficiently skilled do things they shouldn't be doing in the first place.
Yet you keep saying they have nothing better to do than recompile their code whenever Intel blesses them with a ne processor, like SPEC tells them to.
I have actually consistently argued against using Intel's Pentium 4 compiler (and Itanium as well), for pretty much the same reasons I think AltiVec is a bad idea.
But, hey, don't let little details like facts get in the way. After all, you are on a crusade, and if the cause is as worthy as Holy Apple, anybody who doesn't agree with you is a mortal enemy, and what do a few little lies matter then anyway?
Microsoft Windows is not just in phones but also in cars. Just imagine the possibilities when it also runs your Disposall, electric toothbrush, hair dryer, and microwave:
BANGKOK (Reuters) - Security guards smashed their way into an official limousine with sledgehammers on Monday to rescue Thailand's finance minister after his car's computer failed.
Suchart Jaovisidha and his driver were trapped inside the BMW for more than 10 minutes before guards broke a window. All doors and windows had locked automatically when the computer crashed, and the air conditioning stopped, officials said.
"We could hardly breathe for over 10 minutes," Suchart told reporters. "It took my guard a long time to realize that we really wanted the window smashed so that we could crawl out. It was a harrowing experience."
But for embedded systems, an alternative isn't a bad idea.
X11 is actually great for many (but no all) embedded systems applications. X11 applications can run on 8bit embedded machines and still display a nice GUI on a desktop. And X11 servers can be implemented in as little as 100-200k with little more memory than required for the frame buffer.
they could port aqua to linux, since it already compiled under gcc anyways.
Aqua is a GUI, like Gnome or KDE. The equivalent of X11 in the Mac world is Quartz. Quartz is a client/server system, like X11, it just happens to use PDF instead of X11's binary protocol. Aqua could easily run on top of X11 and look and behave the same (well, actually, Aqua-on-X11 would probably be a bit faster than Aqua-on-Quartz).
If you want Aqua, Cocoa, and Quartz for Linux, you can effectively already get it, minus Apple's fancy graphics design. The project is called GNUStep.
There seems to be a lot of life left in that corpse, given that Perl and Python have essentially become Lisp (lexical closures, dynamic typing, list comprehensions, etc.) and that O'CAML is thriving.
So, instead of an aging client/server, network-transparent window system, you can now be transported all the way back to 1960's technology: direct frame buffer access. If that isn't progress, I don't know what is.
Not true. Someone owns the bits that aren't SCO property, no judge can transfer that ownership. Regarless of how blatant or pervasive. SCO only has a claim to their copyrighted material (which may or not exist in the kernel).
The judge can't arbitrarily re-assign copyright. But a judge might decide that SCO is due some astronomical amount of compensation and penalties from a number of key Linux developers. When they don't pay up, he could seize their copyrighted code in compensation.
SCO might also be able to make an argument related to trade secrets. In most cases, once a trade secret has been disclosed, it can't be taken back. But if SCO takes the position that their source code is a trade secret and that Linux is substantially derived from those trade secrets, unlike most other trade secrets, they are in a position in which they can obtain relief, by halting distribution of Linux source code. That is, the Linux developers would retain copyright in their contributions, but they would be prohibited from publishing or distributing code. Then, the only way for Linux to get distributed would be with a license from SCO. This is not all that unusual: DeCSS and any open source software that infringes patents is in that sort of legal limbo.
Regardless of whether or not SCO does prove there are copied portions of their code (unauthorized I mean) that wouldn't give them ownership of the kernel as a whole.
A judge could, in theory, assign ownership of the entire Linux kernel to SCO if he finds that the copyright violation is particularly blatant and pervasive. But that's unrealistic, which is why I called it an "unrealistic worst case".
I'd imagine if someone did copy SCO code and used it in the kernel, it would be relatively easy to replace,
Since, given its size, the word "nut" in "nutshell" obviously can't refer to the hard covering of a seed, it must be referring to the user who is using it...
Using SIMD is intrinsically easier than using a cluster.
They are just different. Clustering allows program-level parallelism, which gives you nearly linear scaling for throughput for arbitrary programs with no programming effort. SIMD and vector processors are very specialized and require a lot of effort to use well, and that effort is usuall only worth it if you need to lower processing latencies.
(Note, incidentally, that one of the most important SIMD machines, the Connection Machine, was built as a network of processors.)
I guess it depends on how you define "end". In any case, I believe 1986 is when Berkeley started purging BSD of AT&T code, which is the important date for SCO.
Let's assume, just for the sake of argument, that there are bits of SCO source code somewhere in Linux. What does that mean?
I think in the realistic worst case, the offending code would get removed from the Linux kernel, whoever put it there would pay a steep fine, and that would be it. I don't see SCO having any legal basis, for example, for demanding royalties for the Linux kernel.
But even in an unrealistic worst case, in which ownership of Linux (meaning, some key portion of the Linux kernel) somehow went over to SCO, people would simply move over to a different kernel. We have BSD and Hurd. It would be a few months of pain to get drivers and some other kernel facilities ported or reimplemented, but that's all.
That's one of many reasons why it's good to have lots of similar projects in the wings.
"There is post-BSD UnixWare source code origined [sic] with SCO, and that is of issue."
What does "post-BSD" mean? After the end of the BSD project at Berkeley in 1986? And by "SCO origined", are they talking about code written by employees of SCO? I can't think of anything SCO has ever written that would be of interest to anyone; does anybody know what kind of substantial code SCO actually developed themselves? Drivers maybe?
It makes writing music with software instruments/fx bloody annoying as well.
If s/w developer spent the same amount of time on clustering as they do on AltiVec or MMX hacks, you wouldn't even notice. And it would be a hell of a lot easier to upgrade--just plug in another box when you need more power.
You simply do not necessarily need to work directly with BLAS (and LAPACK for that matter) to enjoy the fruits of excellent optimization!
Let's say you own a home worth $500000. Would you pay another $500000 to own a vacation home in Aspen that you use two weeks out of the year? Aspen is a really nice place to stay, after all, and it's so much more pleasant to stay at a place one owns. Or would it make more sense just to rent a place for the two weeks, and maybe even go to different places to vacation every year?
Just because something is nice and just because it is high quality doesn't mean that it is worth paying a premium for it.
If you spend $3800 on a high-end Mac, you get something that runs a small number of hand-optimized commercial programs really fast. That may be useful for some of Apple's core audience.
But if you spend the same $3800 on x86 hardware, you get a small compute cluster that runs a lot of software faster and without AltiVec optimizations. For most scientific applications, as well as most video and audio applications, that's probably a better deal in terms of bang-for-the-buck, but, admittedly, it's probably not something your average Mac user wants to set up.
Would you care to elaborate? I mean, if you're not writing against known ultra-optimized libraries, what business do you have expecting your software to run fast?
It's a simple cost/benefit analysis. I can spend a week shoe-horning something into the BLAS interface and possibly create obscure bugs in the process, or I can just write a reasonably efficient high-level loop and live with whatever the compiler gives me.
I would expect that most scientists DO care enough to use the fastest libraries at hand,
Scientists get paid to do science, not to hand-optimize inner loops or link to cumbersome libraries. If a regular compiler can't compile regular loops into efficient code for a processor, then that's a problem with the processor, not with the scientists using the compiler. The scientists may still decide to eat the dogfood, but that doesn't make it any better.
In any case, in this case, people can have their cake and eat it, too. For the price of a single 1GHz PPC Macintosh ($1500) or dual 1.25GHz PPC Macintosh ($2000), people can get two 2.4GHz Pentium4 machines, which gives them more compute power even using plain gcc than hand-optimized AltiVec code on the Macintosh. And, frankly, the 970 doesn't look like it's going to change that ratio whenever it may actually come out.
Every time someone asks a legal question on Slashdot, people like you come out of the woodwork and point out that Slashdot is the same as going to a lawyer. You don't say. Do you really think everybody else is stupid?
Discussing legal issues is not just a business for lawyers. Non-lawyers can give each other useful pointers. And non-lawyers actually have an obligation to determine whether their legislators are doing a good job with the laws they enact and judges they appoint, and a healthy discussion is a good start.
If the 970 were solely intended as a Linux desktop platform for IBM, they would've preferred to reduce the 970's die size, power consumption, time-to-market, etc. by just leaving out the Altivec unit altogether, instead of shoehorning it into the design the way they did.
This is probably true and rather unfortunate. AltiVec is important for Apple marketing because it lets them claim impressive performance figures without actually needing to push the state of the art in terms of processor design further than Intel. It's also important for a few special-purpose applications (PhotoShop filters, etc.).
But the reality of regular high-end computing is that people don't have the time to optimize their software for the latest oddball hardware platform. And even something like a hand-coded vectorized BLAS library doesn't help because most scientific software still doesn't use such libraries.
I think this tradeoff doesn't even work well for Apple. Imagine how much better it would be if Apple could ship systems based on the 970 today, rather than after a few months additional delay due to AltiVec. And every dollar and watt that is shaved off the AltiVec price makes it a much more viable processor for servers and blades, which would get volume up and prices down. Gimmicks like AltiVec cost much more than they are worth, even for Apple.
The only file system that is truely distributed, has a global namespace, replication, and fault tolerance is AFS.
Too bad that it also creates gaping security holes, has horrible performance for big files, and doesn't handle error conditions well.
Yes, AFS has a long feature list. That alone should be a warning to people to stick with something simpler. Like NFS, for example.
NFS is a point to point file system.
And that is what makes NFS superior to AFS: it concentrates on doing something simple that's already hard enough by itself. You can build replication, distribution, caching, global name spaces, and other features on top of NFS, and people have.
ACLs, properly managed, leave UNIX's user/group/all security settings in the dust.
Having spent a lot of time dealing with the mess that ACLs cause in a real-world environment, I would dispute that. But that isn't even the issue. The issue is that AFS does not even come close to implementing UNIX or Windows file system semantics. That makes AFS a poor choice as a network file system for UNIX or Windows.
And, despite the appearance of having more security, the failure of AFS to implement UNIX file system semantics actually creates gaping security holes as well, so all that AFS ACL stuff doesn't even accomplish what it is intended to accomplish.
Letting users have their own computers seems nice, but since it requires less planning and thinking (as a mainframe timeshare system requires) it will always become unmanageable. [...] (Note for the humour impaired: I'm parodying the above author's style.)
I fail to see the parody. Have you spent any time supporting PCs? They are almost unmanageable and soak up support time and resources like there is no tomorrow. Sometimes, it is worth paying that cost, but most businesses are trying so hard to lock down, secure, and standardize their PCs that they really would be better off with central compute resources. The only reason why that isn't a choice is because companies are also stuck in the Microsoft world, where centralizing compute resources is very expensive compared to buying individual machines.
Autocompletion in most popular order, rather than alphabetical order.
Autocompletion by most-frequent-phrase is old. It probably hasn't been applied to searching on an E-commerce site, but why stop there? We can have patents on "Using quicksort to sort the results from a search on an E-commerce site". There is no prior art for this, but this should be obvious to someone of ordinary skill in the field in light of prior art from closely related applications.
I can't quite figure out whether you are trying to be funny in some way and I don't get it, or whether you just don't understand technology and also can't spell. Can you enlighten us which one it is?
Slashdot Mirror
Of course, people develop bad software with Linux as well. The difference is that Linux has no pretenses about it: software development is hard, GUI development is hard, and VisualFoobar doesn't make it much easier. If anything, VisualFoobar lets people who aren't sufficiently skilled do things they shouldn't be doing in the first place.
I have actually consistently argued against using Intel's Pentium 4 compiler (and Itanium as well), for pretty much the same reasons I think AltiVec is a bad idea.
But, hey, don't let little details like facts get in the way. After all, you are on a crusade, and if the cause is as worthy as Holy Apple, anybody who doesn't agree with you is a mortal enemy, and what do a few little lies matter then anyway?
From Reuters
Here is Microsoft's proud announcement of their partnership with BMW.
X11 is actually great for many (but no all) embedded systems applications. X11 applications can run on 8bit embedded machines and still display a nice GUI on a desktop. And X11 servers can be implemented in as little as 100-200k with little more memory than required for the frame buffer.
Aqua is a GUI, like Gnome or KDE. The equivalent of X11 in the Mac world is Quartz. Quartz is a client/server system, like X11, it just happens to use PDF instead of X11's binary protocol. Aqua could easily run on top of X11 and look and behave the same (well, actually, Aqua-on-X11 would probably be a bit faster than Aqua-on-Quartz).
If you want Aqua, Cocoa, and Quartz for Linux, you can effectively already get it, minus Apple's fancy graphics design. The project is called GNUStep.
There seems to be a lot of life left in that corpse, given that Perl and Python have essentially become Lisp (lexical closures, dynamic typing, list comprehensions, etc.) and that O'CAML is thriving.
So, instead of an aging client/server, network-transparent window system, you can now be transported all the way back to 1960's technology: direct frame buffer access. If that isn't progress, I don't know what is.
The judge can't arbitrarily re-assign copyright. But a judge might decide that SCO is due some astronomical amount of compensation and penalties from a number of key Linux developers. When they don't pay up, he could seize their copyrighted code in compensation.
SCO might also be able to make an argument related to trade secrets. In most cases, once a trade secret has been disclosed, it can't be taken back. But if SCO takes the position that their source code is a trade secret and that Linux is substantially derived from those trade secrets, unlike most other trade secrets, they are in a position in which they can obtain relief, by halting distribution of Linux source code. That is, the Linux developers would retain copyright in their contributions, but they would be prohibited from publishing or distributing code. Then, the only way for Linux to get distributed would be with a license from SCO. This is not all that unusual: DeCSS and any open source software that infringes patents is in that sort of legal limbo.
A judge could, in theory, assign ownership of the entire Linux kernel to SCO if he finds that the copyright violation is particularly blatant and pervasive. But that's unrealistic, which is why I called it an "unrealistic worst case".
I'd imagine if someone did copy SCO code and used it in the kernel, it would be relatively easy to replace,
Wasn't that what I was saying?
Since, given its size, the word "nut" in "nutshell" obviously can't refer to the hard covering of a seed, it must be referring to the user who is using it...
They are just different. Clustering allows program-level parallelism, which gives you nearly linear scaling for throughput for arbitrary programs with no programming effort. SIMD and vector processors are very specialized and require a lot of effort to use well, and that effort is usuall only worth it if you need to lower processing latencies.
(Note, incidentally, that one of the most important SIMD machines, the Connection Machine, was built as a network of processors.)
I guess it depends on how you define "end". In any case, I believe 1986 is when Berkeley started purging BSD of AT&T code, which is the important date for SCO.
I think in the realistic worst case, the offending code would get removed from the Linux kernel, whoever put it there would pay a steep fine, and that would be it. I don't see SCO having any legal basis, for example, for demanding royalties for the Linux kernel.
But even in an unrealistic worst case, in which ownership of Linux (meaning, some key portion of the Linux kernel) somehow went over to SCO, people would simply move over to a different kernel. We have BSD and Hurd. It would be a few months of pain to get drivers and some other kernel facilities ported or reimplemented, but that's all.
That's one of many reasons why it's good to have lots of similar projects in the wings.
What does "post-BSD" mean? After the end of the BSD project at Berkeley in 1986? And by "SCO origined", are they talking about code written by employees of SCO? I can't think of anything SCO has ever written that would be of interest to anyone; does anybody know what kind of substantial code SCO actually developed themselves? Drivers maybe?
If s/w developer spent the same amount of time on clustering as they do on AltiVec or MMX hacks, you wouldn't even notice. And it would be a hell of a lot easier to upgrade--just plug in another box when you need more power.
Let's say you own a home worth $500000. Would you pay another $500000 to own a vacation home in Aspen that you use two weeks out of the year? Aspen is a really nice place to stay, after all, and it's so much more pleasant to stay at a place one owns. Or would it make more sense just to rent a place for the two weeks, and maybe even go to different places to vacation every year?
Just because something is nice and just because it is high quality doesn't mean that it is worth paying a premium for it.
But if you spend the same $3800 on x86 hardware, you get a small compute cluster that runs a lot of software faster and without AltiVec optimizations. For most scientific applications, as well as most video and audio applications, that's probably a better deal in terms of bang-for-the-buck, but, admittedly, it's probably not something your average Mac user wants to set up.
It's a simple cost/benefit analysis. I can spend a week shoe-horning something into the BLAS interface and possibly create obscure bugs in the process, or I can just write a reasonably efficient high-level loop and live with whatever the compiler gives me.
I would expect that most scientists DO care enough to use the fastest libraries at hand,
Scientists get paid to do science, not to hand-optimize inner loops or link to cumbersome libraries. If a regular compiler can't compile regular loops into efficient code for a processor, then that's a problem with the processor, not with the scientists using the compiler. The scientists may still decide to eat the dogfood, but that doesn't make it any better.
In any case, in this case, people can have their cake and eat it, too. For the price of a single 1GHz PPC Macintosh ($1500) or dual 1.25GHz PPC Macintosh ($2000), people can get two 2.4GHz Pentium4 machines, which gives them more compute power even using plain gcc than hand-optimized AltiVec code on the Macintosh. And, frankly, the 970 doesn't look like it's going to change that ratio whenever it may actually come out.
Discussing legal issues is not just a business for lawyers. Non-lawyers can give each other useful pointers. And non-lawyers actually have an obligation to determine whether their legislators are doing a good job with the laws they enact and judges they appoint, and a healthy discussion is a good start.
This is probably true and rather unfortunate. AltiVec is important for Apple marketing because it lets them claim impressive performance figures without actually needing to push the state of the art in terms of processor design further than Intel. It's also important for a few special-purpose applications (PhotoShop filters, etc.).
But the reality of regular high-end computing is that people don't have the time to optimize their software for the latest oddball hardware platform. And even something like a hand-coded vectorized BLAS library doesn't help because most scientific software still doesn't use such libraries.
I think this tradeoff doesn't even work well for Apple. Imagine how much better it would be if Apple could ship systems based on the 970 today, rather than after a few months additional delay due to AltiVec. And every dollar and watt that is shaved off the AltiVec price makes it a much more viable processor for servers and blades, which would get volume up and prices down. Gimmicks like AltiVec cost much more than they are worth, even for Apple.
Too bad that it also creates gaping security holes, has horrible performance for big files, and doesn't handle error conditions well.
Yes, AFS has a long feature list. That alone should be a warning to people to stick with something simpler. Like NFS, for example.
NFS is a point to point file system.
And that is what makes NFS superior to AFS: it concentrates on doing something simple that's already hard enough by itself. You can build replication, distribution, caching, global name spaces, and other features on top of NFS, and people have.
Having spent a lot of time dealing with the mess that ACLs cause in a real-world environment, I would dispute that. But that isn't even the issue. The issue is that AFS does not even come close to implementing UNIX or Windows file system semantics. That makes AFS a poor choice as a network file system for UNIX or Windows.
And, despite the appearance of having more security, the failure of AFS to implement UNIX file system semantics actually creates gaping security holes as well, so all that AFS ACL stuff doesn't even accomplish what it is intended to accomplish.
Letting users have their own computers seems nice, but since it requires less planning and thinking (as a mainframe timeshare system requires) it will always become unmanageable. [...] (Note for the humour impaired: I'm parodying the above author's style.)
I fail to see the parody. Have you spent any time supporting PCs? They are almost unmanageable and soak up support time and resources like there is no tomorrow. Sometimes, it is worth paying that cost, but most businesses are trying so hard to lock down, secure, and standardize their PCs that they really would be better off with central compute resources. The only reason why that isn't a choice is because companies are also stuck in the Microsoft world, where centralizing compute resources is very expensive compared to buying individual machines.
Autocompletion by most-frequent-phrase is old. It probably hasn't been applied to searching on an E-commerce site, but why stop there? We can have patents on "Using quicksort to sort the results from a search on an E-commerce site". There is no prior art for this, but this should be obvious to someone of ordinary skill in the field in light of prior art from closely related applications.
I can't quite figure out whether you are trying to be funny in some way and I don't get it, or whether you just don't understand technology and also can't spell. Can you enlighten us which one it is?
We prefer the legal uncertainty surrounding Linux to the commercial certainty of running an OS whose vendor will go bankrupt.