Well, unfortunately for Intel the IA64 has been an embarrasment so far. It's godawfully slow, and it looks to remain that way for a while longer. That's probably why AMD isn't all that worried by it right now. The lead engineer at HP responsible for IA64 had tried to market VLIW a decade ago with his Multiflow company. The company flopped very quickly. They made some very useful advancements in compiler technology, but it wasn't enough to get VLIW to RISC performance levels. EPIC is a reformulated VLIW. It tries to overcome some of the efficiences of VLIW.
But in order to gain any benefit from EPIC, you need a compiler with a really awesome global scheduler that will consistently schedule large numbers of instructions for execution in the same cycle. Otherwise you just get hurt by the drawbacks of VLIW. And that compiler technology has still not seen the light of day.
AMD really has all the time in the world now. The smartest thing they can do is snatch up as much as the x86 market share they can while Intel continues to bust their brains on IA64. If Intel and HP can deliver a compiler that proves IA64, AMD could design an IA64 processor which the compiler will run on. And while they're developing an IA64 processor, they'd still have the IA32 market open to them. Even if Intel releases a fast IA64 processor, they won't be able to eliminate the IA32 market right away.
"(Existing versions of Microsoft's audio software don't allow consumers to record music as MP3 files of any quality.)"
Ok, so if everyone is using other software to record MP3's, why would people suddenly start using Microsoft's MP3 Encoder? Especially when it's bit rate limited? The people who rip CDs will simply continue to use the software they've always been using.
And if wma is trying to restrict privacy, music pirates wouldn't use Microsoft's encoder even if it provided better quality than the best mp3 encoder.
Whether or not you think it's morally wrong doesn't matter in the corporate world. You are just one consumer. Now if an enormous percentage of Windows users and programmers were to share your opinion, then it would be a different story.
A microprocessor manufacturer that shells out billions and billions of dollars in design and production is not going to act on what a few people perceive as moral. They're going to try to produce something that people will buy. People won't buy a system that doesn't run the software they like. And software manufacturers chose to write software for the system that has the largest marketshare because that equates to more potential consumers for them. And programmers will work for software companies that produce profit and can pay them.
If you want to convince people to support free software products, you need to demonstrate profitability. Morality means squat.
Any chance you're in range of MCI or Sprint's wireless broadband? Sprint's service isn't all that it's cracked up to be, but it's still better than this.
And depending on where you live there may be other local microwave providers. I've heard good things about Wavepath (wavepath.com) . I know someone who's been happy with the service. His Wavepath ISP is LaunchNet Wireless (launchnet.com). They serve the SF Bay Area. It's more expensive that Sprint Broadband, but it's much better.
If low latency (rather than high bandwidth) is what is important to you, then maybe you're in range of IDSL. It's ISDN speeds only (128k), but it's a cheaper than ISDN. Rhythms is the provider around here.
And check out dslreports.com, they have an ISP search engine based on home address.
He should be friendly when contacting his "opponents". He owes it to the open source community that anyone even used ssh. If people knew he was going to turn it into a non-open source product, no one would have used ssh. Ssh became popular only because it was open. It could be universally supported because of that. The open source community helped him test his code and provided bug fixes. And now this is how he repays our support. Sure, he's got every legal right to do what he's doing. But it's still backstabbing in my book.
But in the end it will be his loss. People will just stop using his product, and use only OpenSSH. Though I suppose we won't be able to call it ssh anymore. So instead not only will people not use his product, they'll forget he had anything to do with it because they'll be using it under a different name. The end.
SMT is supposed to alleviate the cost of thread context switches. There are multiple register files on the processor. Each executing thread takes one of them. The Tera/Cray MTA, for example, executes each of these threads round-robin style, but doesn't have to save and restore registers. And a superscalar SMT could just execute the threads simultaneously without the need to switch. I/O contention seems to be the main problem with SMT.
Don't worry it. The idea has been around for longer. One of my profs at UCSD (Dean Tullsen) has been advocating it for many years now. And there has already been an implementation of it: Terra has 2-way SMT supercomputer.
Having a 4-way SMT single CPU is a lot cheaper than 4 separate processors. Basically, you can think of it as a bridge between SMP and single CPU. There aren't enough applications out there that utilize SMP enough for most people to want to spend money on multiple processors. And because so few people use multi-processors, there haven't been enough application developers willing to make their code multithreaded. A typical catch-22 situation. But supporting multiple register sets on a single CPU doesn't cost all that much, and there are already multiple functional units on superscalar processors.
So that brings us to a second reason. Wide-issue superscalar processors end up using very little of that issue width most of the time. You just can't get enough parallelism out of single threaded applications. SMT offers the ability to use that wasted issue width by scheduling different threads onto the wasted functional units.
A third benefit to SMT is that it drives the industry in the right direction. Writing code to take advantage of SMT is basically the same as for SMP. You want to find ways to break your application into separate threads. If SMT becomes a common feature on CPU's, then perhaps we'll have lots more SMP-favorable code. There will also be greater incentive to write efficient parallelizing compilers. CMP is more efficient that SMT for high levels of parallism. So in future, people will probably be moving from SMT to CMP.
It's true that SMT doesn't help with standard single-threaded benchmarks. That's probably what's delayed the industry in adopting it. But the industry is finding out that it's running out of ways to speed up processors. Increasing clock rate isn't enough because your memory latency becomes a greater bottleneck. So increased parallelism becomes more and more crucial
Re:Poor article & microkernels arch. are dead
on
JKH on OS X
·
· Score: 1
I'm sorry, but what you're saying is all completely irrelevant. Really, I'm sure Apple could care less about this microkernel vs monolithic debate. Yes, Mach is not a good microkernel. Yes, Mach's system call overhead is excessive. And yes, there are more efficient microkernels available today (like L4, QNX's). But it's not a big enough factor for Apple to need to care. Apple isn't trying to compete with Ultra Enterprise servers here. They're trying to make a desktop operating system. Besides, Digital UNIX (OSF/1) is Mach based, and it's worked well enough.
Apple's choice of Mach made sense, and I'll tell you why because it isn't very obvious. First, Apple didn't have the resources to build an operating system from scratch. They wanted something free, which basically restricted them to BSD, Linux, Mach+BSD, or Mach+Linux. But they also wanted to be able to make proprietary modifications and not have to release the source code. That eliminates Linux. So now they're left with BSD, or a Mach/BSD combo. Now the problem with plain BSD is that there is still no kernel multithreading available. And FreeBSD SMP is still primitive, and will be completely overhauled when it's merged with BSD/OS. Apple needed something already proven. Mach gives you kernel multithreading and SMP, and it's BSD licensed. Mach 3.0 was finished years ago. It's known to work. And there has been a BSD-licensed BSD servers for Mach (called Lites) ever since 4.4BSD was released. So Apple didn't have to put much work into porting FreeBSD onto Mach either.
And then, of course, OpenStep/NeXTStep are Mach/BSD, so there isn't much application level porting to be done.
I'm not going to tell you that Darwin will be as fast and efficient as Linux. But even if it isn't, it doesn't matter. The performance difference will not be an important issue. The important issue is that Apple is able to focus more of their talent on what they know best: GUI design. And Darwin is still plenty compatible with FreeBSD and Linux. Mac OS X will sell because of Aqua, not because it used Darwin over some other UNIX OS.
People should really stop making a big deal out of this Mach thing. You're making mountains out of mole hills.
"If you use a GPL library, your code MUST be GPL."
But wait, how is using a GPL'd library different from using GPL'd code? Linux, for example shares some code with FreeBSD. That shared code is still BSD licensed. The GPL requires that the code linked in to be GPL compatible-only, not GPL'd itself. But the sum total of the code is now GPL'd. As long as your code is less restrictive in all ways in comparison to the GPL (like the BSD license) it is GPL compatible. The QPL requires that the library can only be used to develop "open source software". They're not explicitly saying linkage is derivation, but they're still restricting what you can link to it. The code has to be "open source" for you to use the QPL. The only difference I see is that the QPL's requirements for open source differ from the requirements for GPL-compatibility.
I'm confused, why would the QPL be preferable over the GPL? If you BSD license an application that uses a GPL'd library, anyone can still take your BSD code and use it in a closed source application. It's just that the closed source developer can't use the GPL'd library. But that's the same with the QPL. No closed source developer can use a QPL'd qt, they'd need to buy the commercial license. Whether Qt/X11 or Qt/Embedded is QPL'd or GPL'd, the closed source vender has to pay for the commercial license. I see no difference from the aspect of the BSD-licensed application. Both QPL and GPL restrict usage equally.
So one year is always enough to go from announcement to release? How long was DVD worked on before it was released? Years. It's not enough that the technology works. It has to actually get accepted. The 140GB format requires a bluer, more expensive laser. They came out with a 25GB format months after that which would work with normal DVD lasers. But you still need to convince people to burn and sell FMD discs. The drive is useless unless there is FMD media people can use. It's not going to be a writable media in the beginning. And they also don't plan on making the drives themselves, they want to license the technology to the big CD/DVD drive makers. That requires a lot of convincing. The DVD consortium members (especially Sony and Toshiba) get royalties off DVD. Those companies won't like the idea of losing that revenue stream. FMD could be a competitor to HD-DVD, and they may not like that.
Close. NeXTStep predated 4.4BSD. NeXTStep 1.0 was released in 1989. They were using a 4.3BSD server on top of Mach 2.5 . 4.4BSD-Lite was released March 1, 1994. Rhapsody was the first NeXT OS that incorporated 4.4BSD-Lite. It incorporated Lite-2. But it's not so big a deal, the differences between 4.3BSD and 4.4BSD is mostly the stuff that SunOS 4 contributed back. Stuff like vnodes. From the user and application perspective, they pretty much look identical.
With Mac OS X DP2 the BSD server was updated to FreeBSD 3.2 . So Darwin looks like FreeBSD for the most part, but uses Mach SMP and provides Mach kernel-threads. Mac OS X also supposedly has some XML stuff hidden in/etc configuration files to make it easier for the GUI config tools to maintain consistency. Well, at least that's what Ars Technica claims. I haven't seen it firsthand.
No, the real bottleneck is the latency of memory. People just settle for raising bandwidth because they don't know how to reduce the latency. Few applications natively need large amounts of bandwidth. The rest have to find ways of prefetching data, and most often they can't do that. Processors stall waiting on memory loads and stores. Most of the time they ask for small amounts of data. They don't always know in advance where they'll be loading from, and the data isn't always ready long in advance. So they can't always find things to do while waiting for memory. High bandwidth doesn't help you here. You're limited by the latency of the first access.
An example: RAMBUS currently has higher bandwidth than SDRAM, but it also has larger latency. It wins for high end 3D rendering software but loses for everything else. Bandwidth at the expense of latency is only beneficial to a small market segment.
Playstation and the N64 are NOT PC's. Sony's reasons for using RAMBUS don't apply in the PC world. The PSX2 needs only 2 16MB RAMBUS chips, and you could keep adding chips. And RAMBUS involves fewer chips. In the case of the PSX2, you can just solder 2 chips onto the main board. So Rambus is simpler and more compact in this case. SDRAM DIMMS contain larger numbers of chips, and have a larger pincount. But this doesn't matter for PCs, there's enough space involved that the issue is moot. But Nintendo is abandoning RAMBUS for their next system, apparently the price of RAMBUS wasn't enough to justify the simplicity.
Main Entry: coerce
Pronunciation: kO-'&rs
Function: transitive verb
Inflected Form(s): coerced; coercing
Etymology: Latin coercEre, from co- + arcEre to shut up, enclose -- more at ARK
Date: 15th century
1 : to restrain or dominate by force
2 : to compel to an act or choice
3 : to bring about by force or threat
synonym see FORCE
- coercible/-'&r-s&-b&l/ adjective
Force != Violence. Coercion means to force someone to do something against their will. Obviously, the threat of violence is one way to coerce someone. The threat of losing your job or going out of business is another way.
Bullshit. The "rest of the world" does not consider the United States an enemy. The U.S. is the sole reason that Soviet Bloc only included Eastern Europe. People in Europe may bitch about the U.S. a lot and charge the U.S. with acting unilaterally, but they're also glad they weren't the ones to go into debt fighting the Cold War. Japan and Taiwan are glad the U.S. protects them from mainland China. Russia has gratitude for the fact we give them billions of dollars in aid. Israel thanks the U.S. for their continued existence. It's only the Islamic fundamentalists that regard the U.S. an enemy.
But the government of mainland China isn't even a friend to their own people. They'll sell arms to any country that they perceive isn't a direct threat to them, which includes any country that isn't within a thousand miles of their borders (like Serbia) and nearby weak countries which are permanently embroiled in conflict (Pakistan, North Korea). They sell arms to Pakistan to keep India preoccupied, so that India won't have the energy to protest China's maneuverings in Asia. Also it's punishment for giving asylum to the Dalai Lama.
Why bother? BSD has nothing that hasn't already been leeched away by the commercial UNIXs. AIX has advanced SMP, kernel level multithreading, and journalled filesystems. Besides, if IBM just wants to avoid a code fork, BSD isn't going to help any. BSD is all about code forking. Just look at the new branding policy FreeBSD/BSDi put out. If you want to put FreeBSD on the name of a FreeBSD based distribution, you need to provide the Walnut Creek CDs pristine. If you want to change the installer or packaging system, you'll just have to call it something other than FreeBSD.
But leeching is considered ok, because everyone who works on BSD can do it too. The Walnut Creek/BSDi employees who run FreeBSD will incorporate everything good into closed source BSD/OS. The closed source version will always have the most advanced features.
The model is sound, it's the model BSD has used for 20 years. It's helped commercial UNIX venders, and UNIX venders rewarded Berkeley with equipment donations, research grants, and jobs for BSD developers. BSD code became a shared resource, a skeleton which commercial closed source venders can use to make a finished product. The model just has nothing to do with promoting open source over closed source.
Re:Hurd is based on the Mach microkernel, BSD lice
on
HURD For 'Big Iron'?
·
· Score: 1
Doesn't matter. Remember, Mach is a _micro_ kernel. That means it can't do squat by itself. The Hurd is a bunch of GPL'd servers built on top of Mach 4 that implements all the rest of the essential features of a kernel. The only part of Hurd that's BSD licensed is Mach 4. So if you're trying to avoid GPL'd code, you might as well say screw it to Hurd and just get Mach 4 from Univ of Utah. And maybe use one of the BSD licensed 4.4BSD-Lite servers that have been around for a decade.
But Mach is a poor performing microkernel to begin with. The system call overhead is immense. The only reason RMS went for it was because it was already there. Apple is using it because Mach-BSD is the only proprietary-friendly open source OS that will provide SMP and kernel-level multithreading. But there's no reason for IBM to be interested in it, when they already have a superior UNIX to begin with. Upward scalability is NOT a problem with AIX.
In this case the problem isn't with choosing open source, the problem is with their design decisions. Open source or not, when Netscape engineers run the project it's still going to be Netscape that decides how much bloat they want in there. It'll probably still end up being more stable than if Netscape did this closed source in house. But that unfortunately isn't saying much. It seems that most of the problems are with their XPCOM cross platform GUI thing. If they only cared about supporting X11, they could have just used GNOME or KDE UI components and have been much further ahead by now. But their goal isn't to create a web browser for linux, it's to create some web browser/application-server/OS monstrosity that runs on every operating system with a single code base.
On the other hand, the typical by-the-people-for-the-people open source project tend to have a more conservative focus. They don't feel embarassed in trying to reimplement something that's already been done. If you can do it better or provide the capabilities more openly, then that's reason enough. There are a lot of people who would have preferred a stable open source web browser which only had the capabilities of Navigator 4. Just because we're sick of dealing with buggy proprietary software on operating systems that are highly stable. But a company like Netscape wouldn't do that. Stability isn't enough of a selling point, you have to claim more features. And they wouldn't admit that navigator4 was unstable in the first place.
I'm getting more and more interested in the idea of switching from x86 Linux to Alpha Linux in the home. It seems that from a software perspective, AlphaLinux is just as viable as x86-Linux. And Compaq/DEC actually supports Linux users unlike Apple. But I have a question for the AlphaLinux people here: how much does it cost to build/buy a "low-end" Alpha system? A lot of people seem to be arguing that Alpha's are just as cost effective as PC's. Is it true? I've looked around for system prices, and everything I've seen as been in order of $6,000 or $11,000 .
But is it really that more expensive? I thought the only things that needed to be different for an Alpha system are the motherboard and processor? And it seems the new motherboards are using AMD's 750 Athlon chipset now. So shouldn't the mobos be cheap, like under $300? Is the processor very expensive?
Is it possible to get a 21264 system with SCSI for under $3000?
I was one of the etrade screw-ees, but have no idea how this law stuff works =P. Sounds like they're saying the requirement of passing the questionaire was illegal. Would that mean everyone who received the mailing from redhat had the right to invest? Would it make sense to attempt a class action lawsuit?
Hell yeah it affects the lives of slashdot readers. I was one of the guys fucked by E*Trade on this thing. And I read slashdot a whole lot. I'm a college student who got picked by redhat maybe because I bought a copy of redhat linux 4.1 way back when. Lots of nobodies like me got picked by redhat for this thing. Redhat picked loads of linux developers and random customers. Lots of us ended up setting up etrade accounts and putting down $1200+ on this thing, only to be turned away. Took me a month to get money back from E*Trade. I'm glad this was posted, now to figure out what to do about it...
Slashdot Mirror
Well, unfortunately for Intel the IA64 has been an embarrasment so far. It's godawfully slow, and it looks to remain that way for a while longer. That's probably why AMD isn't all that worried by it right now. The lead engineer at HP responsible for IA64 had tried to market VLIW a decade ago with his Multiflow company. The company flopped very quickly. They made some very useful advancements in compiler technology, but it wasn't enough to get VLIW to RISC performance levels. EPIC is a reformulated VLIW. It tries to overcome some of the efficiences of VLIW.
But in order to gain any benefit from EPIC, you need a compiler with a really awesome global scheduler that will consistently schedule large numbers of instructions for execution in the same cycle. Otherwise you just get hurt by the drawbacks of VLIW. And that compiler technology has still not seen the light of day.
AMD really has all the time in the world now. The smartest thing they can do is snatch up as much as the x86 market share they can while Intel continues to bust their brains on IA64. If Intel and HP can deliver a compiler that proves IA64, AMD could design an IA64 processor which the compiler will run on. And while they're developing an IA64 processor, they'd still have the IA32 market open to them. Even if Intel releases a fast IA64 processor, they won't be able to eliminate the IA32 market right away.
Take a look at the article again:
"(Existing versions of Microsoft's audio software don't allow consumers to record music as MP3 files of any quality.)"
Ok, so if everyone is using other software to record MP3's, why would people suddenly start using Microsoft's MP3 Encoder? Especially when it's bit rate limited? The people who rip CDs will simply continue to use the software they've always been using.
And if wma is trying to restrict privacy, music pirates wouldn't use Microsoft's encoder even if it provided better quality than the best mp3 encoder.
Whether or not you think it's morally wrong doesn't matter in the corporate world. You are just one consumer. Now if an enormous percentage of Windows users and programmers were to share your opinion, then it would be a different story.
A microprocessor manufacturer that shells out billions and billions of dollars in design and production is not going to act on what a few people perceive as moral. They're going to try to produce something that people will buy. People won't buy a system that doesn't run the software they like. And software manufacturers chose to write software for the system that has the largest marketshare because that equates to more potential consumers for them. And programmers will work for software companies that produce profit and can pay them.
If you want to convince people to support free software products, you need to demonstrate profitability. Morality means squat.
now how about a ximian gnome release for freebsd?
Any chance you're in range of MCI or Sprint's wireless broadband? Sprint's service isn't all that it's cracked up to be, but it's still better than this.
And depending on where you live there may be other local microwave providers. I've heard good things about Wavepath (wavepath.com) . I know someone who's been happy with the service. His Wavepath ISP is LaunchNet Wireless (launchnet.com). They serve the SF Bay Area. It's more expensive that Sprint Broadband, but it's much better.
If low latency (rather than high bandwidth) is what is important to you, then maybe you're in range of IDSL. It's ISDN speeds only (128k), but it's a cheaper than ISDN. Rhythms is the provider around here.
And check out dslreports.com, they have an ISP search engine based on home address.
He should be friendly when contacting his "opponents". He owes it to the open source community that anyone even used ssh. If people knew he was going to turn it into a non-open source product, no one would have used ssh. Ssh became popular only because it was open. It could be universally supported because of that. The open source community helped him test his code and provided bug fixes. And now this is how he repays our support. Sure, he's got every legal right to do what he's doing. But it's still backstabbing in my book.
But in the end it will be his loss. People will just stop using his product, and use only OpenSSH. Though I suppose we won't be able to call it ssh anymore. So instead not only will people not use his product, they'll forget he had anything to do with it because they'll be using it under a different name. The end.
SMT is supposed to alleviate the cost of thread context switches. There are multiple register files on the processor. Each executing thread takes one of them. The Tera/Cray MTA, for example, executes each of these threads round-robin style, but doesn't have to save and restore registers. And a superscalar SMT could just execute the threads simultaneously without the need to switch. I/O contention seems to be the main problem with SMT.
Don't worry it. The idea has been around for longer. One of my profs at UCSD (Dean Tullsen) has been advocating it for many years now. And there has already been an implementation of it: Terra has 2-way SMT supercomputer.
Having a 4-way SMT single CPU is a lot cheaper than 4 separate processors. Basically, you can think of it as a bridge between SMP and single CPU. There aren't enough applications out there that utilize SMP enough for most people to want to spend money on multiple processors. And because so few people use multi-processors, there haven't been enough application developers willing to make their code multithreaded. A typical catch-22 situation. But supporting multiple register sets on a single CPU doesn't cost all that much, and there are already multiple functional units on superscalar processors.
So that brings us to a second reason. Wide-issue superscalar processors end up using very little of that issue width most of the time. You just can't get enough parallelism out of single threaded applications. SMT offers the ability to use that wasted issue width by scheduling different threads onto the wasted functional units.
A third benefit to SMT is that it drives the industry in the right direction. Writing code to take advantage of SMT is basically the same as for SMP. You want to find ways to break your application into separate threads. If SMT becomes a common feature on CPU's, then perhaps we'll have lots more SMP-favorable code. There will also be greater incentive to write efficient parallelizing compilers. CMP is more efficient that SMT for high levels of parallism. So in future, people will probably be moving from SMT to CMP.
It's true that SMT doesn't help with standard single-threaded benchmarks. That's probably what's delayed the industry in adopting it. But the industry is finding out that it's running out of ways to speed up processors. Increasing clock rate isn't enough because your memory latency becomes a greater bottleneck. So increased parallelism becomes more and more crucial
I'm sorry, but what you're saying is all completely irrelevant. Really, I'm sure Apple could care less about this microkernel vs monolithic debate. Yes, Mach is not a good microkernel. Yes, Mach's system call overhead is excessive. And yes, there are more efficient microkernels available today (like L4, QNX's). But it's not a big enough factor for Apple to need to care. Apple isn't trying to compete with Ultra Enterprise servers here. They're trying to make a desktop operating system. Besides, Digital UNIX (OSF/1) is Mach based, and it's worked well enough.
Apple's choice of Mach made sense, and I'll tell you why because it isn't very obvious. First, Apple didn't have the resources to build an operating system from scratch. They wanted something free, which basically restricted them to BSD, Linux, Mach+BSD, or Mach+Linux. But they also wanted to be able to make proprietary modifications and not have to release the source code. That eliminates Linux. So now they're left with BSD, or a Mach/BSD combo. Now the problem with plain BSD is that there is still no kernel multithreading available. And FreeBSD SMP is still primitive, and will be completely overhauled when it's merged with BSD/OS. Apple needed something already proven. Mach gives you kernel multithreading and SMP, and it's BSD licensed. Mach 3.0 was finished years ago. It's known to work. And there has been a BSD-licensed BSD servers for Mach (called Lites) ever since 4.4BSD was released. So Apple didn't have to put much work into porting FreeBSD onto Mach either.
And then, of course, OpenStep/NeXTStep are Mach/BSD, so there isn't much application level porting to be done.
I'm not going to tell you that Darwin will be as fast and efficient as Linux. But even if it isn't, it doesn't matter. The performance difference will not be an important issue. The important issue is that Apple is able to focus more of their talent on what they know best: GUI design. And Darwin is still plenty compatible with FreeBSD and Linux. Mac OS X will sell because of Aqua, not because it used Darwin over some other UNIX OS.
People should really stop making a big deal out of this Mach thing. You're making mountains out of mole hills.
"If you use a GPL library, your code MUST be GPL."
But wait, how is using a GPL'd library different from using GPL'd code? Linux, for example shares some code with FreeBSD. That shared code is still BSD licensed. The GPL requires that the code linked in to be GPL compatible-only, not GPL'd itself. But the sum total of the code is now GPL'd. As long as your code is less restrictive in all ways in comparison to the GPL (like the BSD license) it is GPL compatible. The QPL requires that the library can only be used to develop "open source software". They're not explicitly saying linkage is derivation, but they're still restricting what you can link to it. The code has to be "open source" for you to use the QPL. The only difference I see is that the QPL's requirements for open source differ from the requirements for GPL-compatibility.
I'm confused, why would the QPL be preferable over the GPL? If you BSD license an application that uses a GPL'd library, anyone can still take your BSD code and use it in a closed source application. It's just that the closed source developer can't use the GPL'd library. But that's the same with the QPL. No closed source developer can use a QPL'd qt, they'd need to buy the commercial license. Whether Qt/X11 or Qt/Embedded is QPL'd or GPL'd, the closed source vender has to pay for the commercial license. I see no difference from the aspect of the BSD-licensed application. Both QPL and GPL restrict usage equally.
The red laser format (as of June) can only do 25GB:
http://www.c-3d.net/press22.html
(sorry I don't know how to make links work!)
But I suppose that's not an important issue, they claim their next gen's will be able to do terabytes. (More layers I guess?)
But very interesting point about shelf life. I never knew about that. Someone mod this poster up!
So one year is always enough to go from announcement to release? How long was DVD worked on before it was released? Years. It's not enough that the technology works. It has to actually get accepted. The 140GB format requires a bluer, more expensive laser. They came out with a 25GB format months after that which would work with normal DVD lasers. But you still need to convince people to burn and sell FMD discs. The drive is useless unless there is FMD media people can use. It's not going to be a writable media in the beginning. And they also don't plan on making the drives themselves, they want to license the technology to the big CD/DVD drive makers. That requires a lot of convincing. The DVD consortium members (especially Sony and Toshiba) get royalties off DVD. Those companies won't like the idea of losing that revenue stream. FMD could be a competitor to HD-DVD, and they may not like that.
That's cuz there is no "IBM Open Source" license. OpenAFS is released under the IBM Public License.
Close. NeXTStep predated 4.4BSD. NeXTStep 1.0 was released in 1989. They were using a 4.3BSD server on top of Mach 2.5 . 4.4BSD-Lite was released March 1, 1994. Rhapsody was the first NeXT OS that incorporated 4.4BSD-Lite. It incorporated Lite-2. But it's not so big a deal, the differences between 4.3BSD and 4.4BSD is mostly the stuff that SunOS 4 contributed back. Stuff like vnodes. From the user and application perspective, they pretty much look identical.
/etc configuration files to make it easier for the GUI config tools to maintain consistency. Well, at least that's what Ars Technica claims. I haven't seen it firsthand.
With Mac OS X DP2 the BSD server was updated to FreeBSD 3.2 . So Darwin looks like FreeBSD for the most part, but uses Mach SMP and provides Mach kernel-threads. Mac OS X also supposedly has some XML stuff hidden in
No, the real bottleneck is the latency of memory. People just settle for raising bandwidth because they don't know how to reduce the latency. Few applications natively need large amounts of bandwidth. The rest have to find ways of prefetching data, and most often they can't do that. Processors stall waiting on memory loads and stores. Most of the time they ask for small amounts of data. They don't always know in advance where they'll be loading from, and the data isn't always ready long in advance. So they can't always find things to do while waiting for memory. High bandwidth doesn't help you here. You're limited by the latency of the first access.
An example: RAMBUS currently has higher bandwidth than SDRAM, but it also has larger latency. It wins for high end 3D rendering software but loses for everything else. Bandwidth at the expense of latency is only beneficial to a small market segment.
Playstation and the N64 are NOT PC's. Sony's reasons for using RAMBUS don't apply in the PC world. The PSX2 needs only 2 16MB RAMBUS chips, and you could keep adding chips. And RAMBUS involves fewer chips. In the case of the PSX2, you can just solder 2 chips onto the main board. So Rambus is simpler and more compact in this case. SDRAM DIMMS contain larger numbers of chips, and have a larger pincount. But this doesn't matter for PCs, there's enough space involved that the issue is moot. But Nintendo is abandoning RAMBUS for their next system, apparently the price of RAMBUS wasn't enough to justify the simplicity.
from m-w.com:
/-'&r-s&-b&l/ adjective
Main Entry: coerce
Pronunciation: kO-'&rs
Function: transitive verb
Inflected Form(s): coerced; coercing
Etymology: Latin coercEre, from co- + arcEre to shut up, enclose -- more at ARK
Date: 15th century
1 : to restrain or dominate by force
2 : to compel to an act or choice
3 : to bring about by force or threat
synonym see FORCE
- coercible
Force != Violence. Coercion means to force someone to do something against their will. Obviously, the threat of violence is one way to coerce someone. The threat of losing your job or going out of business is another way.
Bullshit. The "rest of the world" does not consider the United States an enemy. The U.S. is the sole reason that Soviet Bloc only included Eastern Europe. People in Europe may bitch about the U.S. a lot and charge the U.S. with acting unilaterally, but they're also glad they weren't the ones to go into debt fighting the Cold War. Japan and Taiwan are glad the U.S. protects them from mainland China. Russia has gratitude for the fact we give them billions of dollars in aid. Israel thanks the U.S. for their continued existence. It's only the Islamic fundamentalists that regard the U.S. an enemy.
But the government of mainland China isn't even a friend to their own people. They'll sell arms to any country that they perceive isn't a direct threat to them, which includes any country that isn't within a thousand miles of their borders (like Serbia) and nearby weak countries which are permanently embroiled in conflict (Pakistan, North Korea). They sell arms to Pakistan to keep India preoccupied, so that India won't have the energy to protest China's maneuverings in Asia. Also it's punishment for giving asylum to the Dalai Lama.
Why bother? BSD has nothing that hasn't already been leeched away by the commercial UNIXs. AIX has advanced SMP, kernel level multithreading, and journalled filesystems. Besides, if IBM just wants to avoid a code fork, BSD isn't going to help any. BSD is all about code forking. Just look at the new branding policy FreeBSD/BSDi put out. If you want to put FreeBSD on the name of a FreeBSD based distribution, you need to provide the Walnut Creek CDs pristine. If you want to change the installer or packaging system, you'll just have to call it something other than FreeBSD.
But leeching is considered ok, because everyone who works on BSD can do it too. The Walnut Creek/BSDi employees who run FreeBSD will incorporate everything good into closed source BSD/OS. The closed source version will always have the most advanced features.
The model is sound, it's the model BSD has used for 20 years. It's helped commercial UNIX venders, and UNIX venders rewarded Berkeley with equipment donations, research grants, and jobs for BSD developers. BSD code became a shared resource, a skeleton which commercial closed source venders can use to make a finished product. The model just has nothing to do with promoting open source over closed source.
Doesn't matter. Remember, Mach is a _micro_ kernel. That means it can't do squat by itself. The Hurd is a bunch of GPL'd servers built on top of Mach 4 that implements all the rest of the essential features of a kernel. The only part of Hurd that's BSD licensed is Mach 4. So if you're trying to avoid GPL'd code, you might as well say screw it to Hurd and just get Mach 4 from Univ of Utah. And maybe use one of the BSD licensed 4.4BSD-Lite servers that have been around for a decade.
But Mach is a poor performing microkernel to begin with. The system call overhead is immense. The only reason RMS went for it was because it was already there. Apple is using it because Mach-BSD is the only proprietary-friendly open source OS that will provide SMP and kernel-level multithreading. But there's no reason for IBM to be interested in it, when they already have a superior UNIX to begin with. Upward scalability is NOT a problem with AIX.
In this case the problem isn't with choosing open source, the problem is with their design decisions. Open source or not, when Netscape engineers run the project it's still going to be Netscape that decides how much bloat they want in there. It'll probably still end up being more stable than if Netscape did this closed source in house. But that unfortunately isn't saying much. It seems that most of the problems are with their XPCOM cross platform GUI thing. If they only cared about supporting X11, they could have just used GNOME or KDE UI components and have been much further ahead by now. But their goal isn't to create a web browser for linux, it's to create some web browser/application-server/OS monstrosity that runs on every operating system with a single code base.
On the other hand, the typical by-the-people-for-the-people open source project tend to have a more conservative focus. They don't feel embarassed in trying to reimplement something that's already been done. If you can do it better or provide the capabilities more openly, then that's reason enough. There are a lot of people who would have preferred a stable open source web browser which only had the capabilities of Navigator 4. Just because we're sick of dealing with buggy proprietary software on operating systems that are highly stable. But a company like Netscape wouldn't do that. Stability isn't enough of a selling point, you have to claim more features. And they wouldn't admit that navigator4 was unstable in the first place.
I'm getting more and more interested in the idea of switching from x86 Linux to Alpha Linux in the home. It seems that from a software perspective, AlphaLinux is just as viable as x86-Linux. And Compaq/DEC actually supports Linux users unlike Apple. But I have a question for the AlphaLinux people here: how much does it cost to build/buy a "low-end" Alpha system? A lot of people seem to be arguing that Alpha's are just as cost effective as PC's. Is it true? I've looked around for system prices, and everything I've seen as been in order of $6,000 or $11,000 .
But is it really that more expensive? I thought the only things that needed to be different for an Alpha system are the motherboard and processor? And it seems the new motherboards are using AMD's 750 Athlon chipset now. So shouldn't the mobos be cheap, like under $300? Is the processor very expensive?
Is it possible to get a 21264 system with SCSI for under $3000?
Thanks in advance.
I was one of the etrade screw-ees, but have no idea how this law stuff works =P. Sounds like they're saying the requirement of passing the questionaire was illegal. Would that mean everyone who received the mailing from redhat had the right to invest? Would it make sense to attempt a class action lawsuit?
Hell yeah it affects the lives of slashdot readers. I was one of the guys fucked by E*Trade on this thing. And I read slashdot a whole lot. I'm a college student who got picked by redhat maybe because I bought a copy of redhat linux 4.1 way back when. Lots of nobodies like me got picked by redhat for this thing. Redhat picked loads of linux developers and random customers. Lots of us ended up setting up etrade accounts and putting down $1200+ on this thing, only to be turned away. Took me a month to get money back from E*Trade. I'm glad this was posted, now to figure out what to do about it...