In some cases it's the same motherboard, power supply and memory!
... which are the least relevant part of the price difference. The higher rate is for the faster system and I/O buses in Sun's Workgroup and Enterprise servers. You don't use Sun servers for processing, you use them for massive I/O. (You use Intel machines for processing these days, much as I wish it weren't so.)
This is quite deliberate. It's not possible to approve LGPL without opening up a hole that allows J. Random Megacorp to make an LGPL licensed librhpatents.so, which lets them use the patents with closed source proprietary apps. Why is this a problem? The company is not, even then, making money off of RedHat's patented software; they still have to distributed the LGPLed library (and any modifications to it) freely.
I can see how this would be a valid argument against including the BSD/MIT/etcetera licenses in the list (though I'd really rather RedHat reassure us that it won't sue FreeBSD if they make a RHN look-alike or something), but I don't see how it applies to the LGPL.
I learnt this lesson long ago when somebody tried to compile a C program I'd written on an Alpha machine, and it complained about casting pointers to ints (I'd wrongly assumed pointers and ints would be the same size on every architecture).
This is a really easy problem to solve: follow the POSIX standards on type names. If you want a u_int32_t, say so. If you want a pointer-to-something, declear it that way, rather than trying to stuff it in some architecture-dependently-sized variable.
(Note that NetBSD's code is primiarly arch-independent--the dependent stuff is mostly hardware initialization--and it compiles just fine on quite a wide array of processor architectures.)
Migration of a running process, even when going between identical processors, is expensive. Going even to a similar processor would be more so. (And going from, say, a Sparc to a m68k is totally out of the question, not that you're suggesting that.)
It's *really* hard to justify a policy of process migration in a cluster except with extremely long-running, massivley-parallel jobs. For most stuff, you'll waste less time just letting it finish. (GLUnix does do process migration. Note that when you come back to a workstation that's been horfed by GLUnix, you'll be waiting about two minutes before you get your UI back.)
As for *starting* IA32 binaries on an IA64 processor, that's doable, but most cross-platform clustering systems function by keeping binaries for all their constituent processor types and having a hacked shell to convert PATH to the architecture-dependent path. (And by "most cross-platform clustering systems", I mean most that have been designed, since I know of none that work.)
Well, Solaris sucks compared to Linux in the ease of use and ability to script your work easy, man pages, utilities,... and many more aspects.
What makes you say that?
You're using CDE, aren't you?
You're aware that OpenWindows will happily run any window manager, right? And that any utilities you want to install will almost definitely build straight out of the box? And that you can use NetBSD's Zoularis if you want package management?
Solaris is actually a very good OS for a workstation. Its X implementation is really fast. Granted, the window manger they ship completely blows, but nobody in their right mind would ever user CDE anyhow.
Give it a chance before you just presume it's crap because it looks like crap on the surface.
IDE hard drives are pushing the 50mb/s mark. If one should place two of them on a channel and run intense I/O on both you can come fairly close to the 100mb/s barrier imposed by the interface.
Hrm. So what about the fact that I get 160 MB/s out of the (third-party) LVD SCSI in our Suns, and ~200 MB/s off the FCAL array?
IDE is still nowhere in the running for anyone who actually uses real drive capacity and throughput.
ATA133 aleviates another barrier of ATA100 that the IDE drive manufacturers have already begun to run into: The 120gb limit. There are currently 160gb IDE drives on the market, and if one should only have an ATA100 controller in their box they would be losing 40gb. That's no good at all.
This is a *really* important point. I got bit by that one myself for/mp3 at home (where I don't consider my disk needs very significant, which means losing 40 GBs actually matters).
Also, again, IDE's nowhere in the running for real use. If I can't see 2TB+, it's a waste of my (employer's) money.
Actually, writing something to take advantage of Evolution's PGP handling wouldn't be much more complicated than writing something take advantage of Outlook's attachment handling.
(That is, Evolution ignores the PGP/MIME standard, instead dealing only with clear-signed messages, which means it's actually parsing message content... and then you run into trouble.)
Oh, okay, thanks for the solid advice, Attorney General.
Now is especially the time to defend a US citizen's basic freedoms, of which purchasing in a free market (controlled neither by the government nor by an oppressive marketer) is one.
No it isn't. My electric company (PECO in Philadelphia, PA) is required to provide me with notification of the availabity of other companies from whom I could be purchasing power rather than them. The system is arguably even more difficult for PECO than what Verizon has been told to make available to consumers, since PECO is the one who has to pay for the mailings to tell me about their competitors.
Anyway, back to my point... I don't think Verizon being the only game in town is necessarily a bad thing... as long as they're kept in check, rates are kept reasonable, customer service is a MUST, and they provide the services required.
You're forgetting the fact that Verizon didn't get where it is any more naturally than Microsoft has. It is one of the Bells, you know, the original case study for why monopolies should be broken up? And it just recombined with a long distance carrier to expand its still-extant monopoly vertically.
Why do you need defense against "Magic Lantern" if you're not doing anything illegal?
Three reasons:
It's the principle of the thing. My computer is just that; my computer. What I do with it is my business. I have paid for the hardware, and I have downloaded the software which I am using within the license permissions set out by the authors. It might be to the FBI's benefit to see (say) my private communication with people regarding (say) cryptography. I don't have to be suspect of anything for that, I just have to be associated with someone who is. They're claiming that they have a right to go through my email/files/whatever sans warrant should they see fit. I say that's a violation of my privacy, and it should not be legal, even though it would appear to be.
I do some things that could well be considered illegal or (at least) lead to a civil suit. I have a large collection of mp3s, the original CD for which I don't always own. These CDs belong to past roommates/friends/whatever. Never mind that I have found ways to get remuneration to artists whose work I appreciate (and always more than would have trickled down through a record label), the copyright laws say that's illegal. I think it's unreasonable. I have (and may still, since I pretty much don't pay attention to the legalities involved) trafficed in crypto that was disallowed for patent or export reasons. There are at least records of that still living on various of my computers. I think the crypto I've used or made available for download regardless of the remote location is of key importance to individual privacy, which the US at least claims to support. But the law of the land sez I can't do that. I'm not interested in being prosecuted over these things.
Federal agencies have a notoriously bad track record regarding information security. You can be sure that someone evil will find a way into this Magic Lantern backdoor and, when they do, it won't be the government (who's already questionably trustworthy), but someone random who probably does want to damage innocent people with access to this information. That is a truly Bad Thing.
The problem here is that appeals to common sense (which I feel all of these are, feel free to attack that if you think you can support it) won't work with a corrupt, bureaucratic system like the US government. (That last bit is an opinion, not a statement of truth, so let's not get in an argument over it, shall we?)
I don't know the exact details, but I've used older FHSS and DSSS WLAN technologies as well as 802.11b hardware and I believe it has something to do with the fact that one of Bluetooth or 802.11b is direct-signal and one is frequency-hopping and they therefore tend to obliterate each others signals intermittently.
Nice theory. 802.11B can be either depending on how you set your card and station up, so this couldn't be the only problem. (Though every 802.11B installation I've ever see uses FHSS.)
Not that this invalidates your point that the two still interfere with each other.:^>
If a change is made in the amiga tree, for example, my guess is that it's not automatically picked up by the other 68k ports.
Fortunately, that's utterly false. The majority of port-specific stuff is Makefiles and things that really are specific to a given platform. (The booter on mac68k is wildly different from that on amiga, for instance... and don't even get me started on various vendors' proprietary hardware buses.) The vast majority of the code works fine, especially as regards peripheral support. (If a "mac-only" Firewire card gets supported, it gets supported on everything with a PCI bus.)
That said, with the Linux port apparently stalled, NetBSD is currently the closest I have to getting a free Unix on my NeXT black hardware. It doens't work yet, because mine are the Turbo model, but it's the closest of the bunch...
I have that same motherboard in a cube, and I hope to be hacking on it within a few months. Drop me a line at gr at eclipsed dot net if you'd like to help (or just subscribe to port-next68k@netbsd.org and contribute).
Just by way of a specific example, here's the NetBSD sh3 port. Despite the port's name, SH4 evaluation boards, the Dreamcast, and "SH3/4-based WinCE machines" are all supported.
IIRC the OpenBSD crew got a hold of some old crufty "free" (as in license) ssh/sshd program, cleaned it up, added a ton of feartures, cleaned it up more, audited the source, released it and currently is maintaining it. IMHO the OpenBSD/OpenSSH team is doing a hell of a good job with this.
That "old crufty 'free'" SSH-1 implementation you mention is none other than Tatu Ylonen's (aka SSH.com's) SSH-1 implementation. And it was only any kind of crufty because the last version that had a forkable license was about 1.2.12 (I could be off by a minor version or two). OpenSSH set about reimplementing (on their own) the same features that were in the present release of SSH.com's ssh.
OpenSSH is not perfect. It has had interoperability problems with SSH.com's ssh (arguably because SSH.com had strayed from the SECSH reference design, but strict standards adherence does not always useabilty make). It also still supports the SSH-1 protocol, which is inherently flawed. While this is nice for sites transitioning to SSH-2 (or for people concientiously using SSH-2 but having to deal with admins elsewhere who are less on the ball), it's allowed the SSH-1 protocol to linger in the community longer than Tatu would have liked. And he's been very noisy about that fact. Even though there have been pretty much no reports of anyone actually exploiting SSH-1 just yet.
Point is, OpenSSH comes straight out of SSH.com's source, though its been much-updated, as opposed to other SSH (-1 and -2) implementations like FreSSH and ossh, which were reimplemented from the ground up.
More importantly, if everyone had fiber at their home, no one's connection would be any faster than when we were all using 14.4K modems.
All the widespread existence of ridiculously fast connections to the backbone will yield is a ridiculously clogged backbone. Running fiber to businesses and homes will just push the bandwidth block back a step. It won't fix jack.
Gee, wouldn't it be nice if it was clear where to get the NetBSD/dreamcast port?
Here and there. Oh, looks like there are no dreamcast-specific snapshots just yet, but you can use an hpcsh snap, as it is binary-compatible with the dreamcast (becuse the dreamcast runs off a Hitachi Super-H chip).
(I believe this port will be included in the 1.5.1 release when it becomes available, but don't quote me on that.)
Slashdot Mirror
This is quite deliberate. It's not possible to approve LGPL without opening up a hole that allows J. Random Megacorp to make an LGPL licensed librhpatents.so, which lets them use the patents with closed source proprietary apps. Why is this a problem? The company is not, even then, making money off of RedHat's patented software; they still have to distributed the LGPLed library (and any modifications to it) freely.
I can see how this would be a valid argument against including the BSD/MIT/etcetera licenses in the list (though I'd really rather RedHat reassure us that it won't sue FreeBSD if they make a RHN look-alike or something), but I don't see how it applies to the LGPL.
Might try actually reading those responses, eh?
(Some were positive.)
(Note that NetBSD's code is primiarly arch-independent--the dependent stuff is mostly hardware initialization--and it compiles just fine on quite a wide array of processor architectures.)
Extremely few PowerPC processors are 32-bit.
;^>)
Certainly none you're likely to be compiling software on with any kind of regularity. (By which I mean: Apple's never sold a 64-bit processor.
Unlikely.
Migration of a running process, even when going between identical processors, is expensive. Going even to a similar processor would be more so. (And going from, say, a Sparc to a m68k is totally out of the question, not that you're suggesting that.)
It's *really* hard to justify a policy of process migration in a cluster except with extremely long-running, massivley-parallel jobs. For most stuff, you'll waste less time just letting it finish. (GLUnix does do process migration. Note that when you come back to a workstation that's been horfed by GLUnix, you'll be waiting about two minutes before you get your UI back.)
As for *starting* IA32 binaries on an IA64 processor, that's doable, but most cross-platform clustering systems function by keeping binaries for all their constituent processor types and having a hacked shell to convert PATH to the architecture-dependent path. (And by "most cross-platform clustering systems", I mean most that have been designed, since I know of none that work.)
Whatchew talkin' 'bout, Willis?
PowerPC is 32-bit and IA64 is little endian.
Duh?
Well, Solaris sucks compared to Linux in the ease of use and ability to script your work easy, man pages, utilities, ... and many more aspects.
What makes you say that?
You're using CDE, aren't you?
You're aware that OpenWindows will happily run any window manager, right? And that any utilities you want to install will almost definitely build straight out of the box? And that you can use NetBSD's Zoularis if you want package management?
At least, you must know about http://www.sunfreeware.com/, I hope?
Solaris is actually a very good OS for a workstation. Its X implementation is really fast. Granted, the window manger they ship completely blows, but nobody in their right mind would ever user CDE anyhow.
Give it a chance before you just presume it's crap because it looks like crap on the surface.
Strikes me that Van Eck phreaking works better, since you don't have to rely on visibility...
Sure, you have to get closer, but since this seems to be aimed at TLAs for surveilance anyhow, that shouldn't be too hard.
IDE hard drives are pushing the 50mb/s mark. If one should place two of them on a channel and run intense I/O on both you can come fairly close to the 100mb/s barrier imposed by the interface.
/mp3 at home (where I don't consider my disk needs very significant, which means losing 40 GBs actually matters).
Hrm. So what about the fact that I get 160 MB/s out of the (third-party) LVD SCSI in our Suns, and ~200 MB/s off the FCAL array?
IDE is still nowhere in the running for anyone who actually uses real drive capacity and throughput.
ATA133 aleviates another barrier of ATA100 that the IDE drive manufacturers have already begun to run into: The 120gb limit. There are currently 160gb IDE drives on the market, and if one should only have an ATA100 controller in their box they would be losing 40gb. That's no good at all.
This is a *really* important point. I got bit by that one myself for
Also, again, IDE's nowhere in the running for real use. If I can't see 2TB+, it's a waste of my (employer's) money.
Actually, writing something to take advantage of Evolution's PGP handling wouldn't be much more complicated than writing something take advantage of Outlook's attachment handling.
(That is, Evolution ignores the PGP/MIME standard, instead dealing only with clear-signed messages, which means it's actually parsing message content... and then you run into trouble.)
OpenWindows (under Sun Solaris) can, NeXTStep does (but I'm presuming that's what you mean by Apple), some SGI Irix X stuff can.
Now is especially the time to defend a US citizen's basic freedoms, of which purchasing in a free market (controlled neither by the government nor by an oppressive marketer) is one.
You're forgetting the fact that Verizon didn't get where it is any more naturally than Microsoft has. It is one of the Bells, you know, the original case study for why monopolies should be broken up? And it just recombined with a long distance carrier to expand its still-extant monopoly vertically.
Three reasons:
The problem here is that appeals to common sense (which I feel all of these are, feel free to attack that if you think you can support it) won't work with a corrupt, bureaucratic system like the US government. (That last bit is an opinion, not a statement of truth, so let's not get in an argument over it, shall we?)
Nice theory. 802.11B can be either depending on how you set your card and station up, so this couldn't be the only problem. (Though every 802.11B installation I've ever see uses FHSS.)
Not that this invalidates your point that the two still interfere with each other.
Does it irritate you that Bearshare seems to be the only Gnutella client, just like Word is the only word processor?
It sure does me.
I have that same motherboard in a cube, and I hope to be hacking on it within a few months. Drop me a line at gr at eclipsed dot net if you'd like to help (or just subscribe to port-next68k@netbsd.org and contribute).
Just by way of a specific example, here's the NetBSD sh3 port. Despite the port's name, SH4 evaluation boards, the Dreamcast, and "SH3/4-based WinCE machines" are all supported.
OpenSSH is not perfect. It has had interoperability problems with SSH.com's ssh (arguably because SSH.com had strayed from the SECSH reference design, but strict standards adherence does not always useabilty make). It also still supports the SSH-1 protocol, which is inherently flawed. While this is nice for sites transitioning to SSH-2 (or for people concientiously using SSH-2 but having to deal with admins elsewhere who are less on the ball), it's allowed the SSH-1 protocol to linger in the community longer than Tatu would have liked. And he's been very noisy about that fact. Even though there have been pretty much no reports of anyone actually exploiting SSH-1 just yet.
Point is, OpenSSH comes straight out of SSH.com's source, though its been much-updated, as opposed to other SSH (-1 and -2) implementations like FreSSH and ossh, which were reimplemented from the ground up.
--
Which CD? (Artist, album, label, part number, so forth.)
Does it actually bear the standard CD logo?
--
More importantly, if everyone had fiber at their home, no one's connection would be any faster than when we were all using 14.4K modems.
All the widespread existence of ridiculously fast connections to the backbone will yield is a ridiculously clogged backbone. Running fiber to businesses and homes will just push the bandwidth block back a step. It won't fix jack.
--
Heard of MacOS X?
--
Gee, wouldn't it be nice if it was clear where to get the NetBSD/dreamcast port?
Here and there. Oh, looks like there are no dreamcast-specific snapshots just yet, but you can use an hpcsh snap, as it is binary-compatible with the dreamcast (becuse the dreamcast runs off a Hitachi Super-H chip).
(I believe this port will be included in the 1.5.1 release when it becomes available, but don't quote me on that.)
--
Strikes me as just a touch redundant, no?
(I mean, do you really need both %m and %M both in PS1, and both %d on the left and %~ on the right?)
--