Feel free to rebut them. I'd be facinated to hear what, if any, evidence you can produce.
As for being a spammer...heh. Not bloodly likely. Not everyone annoyed by swaths of IPs being blocked is a spammer. As I said, spammers and overreaching antispammers both piss me off. You're as justified in that claim as I would be in saying that you were a member of the DUL-producing group.
They're *just merging it in*! Thousands of packages being combined! Fedora never *used* up2date! You bet your ass there's going to be some interesting times as the two are combined.
I don't mind running Debian Testing, but I'm very selective about what I accept from unstable.
Fedora *has* stable, unstable, testing, etc. I'm not involved with the team, but I'd be somewhat surprised if they don't place the ol' RH packages in a "core"/"redhat-produced" category so that you can just use RH-produced packages, same as before, if you want. Or RH+Fedora stable. Or RH+Fedora stable+Fedora unstable. You name it.
The problem is that the article submitted was *wildly* inaccurate. (...RH going away...pointing people to the free Fedora project...) It'll take months for people to figure out that it was a load of BS.
My guess is that the decision to re-name the free version came from the marketing group.
Actually, RH *tried* to set up the "Red Hat Linux Project", got a bunch of people confused, said "forget this" and happily merged with the largest person already doing what they wanted to do -- Fedora.
As RH has pointed out, no, that's not the case. RHLP, like Fedora, is a community project that lots of folks have been happily packaging things for for ages. You don't have to pay money for it, you don't have to conform with ideas of the maintainers any more than you would Debian maintainers or the old Fedora maintainers.
For a long time, people have been maintaining RPM package repositories. Fedora became the largest, but there was also dag, freshrpms, and a number of others. These rapidly became incompatible with each other, and only stayed compatible with Red Hat. Basically, you only got to choose one.
Red Hat got a lot of griping from RH users (including myself) that they wanted all these non-RH packages to work properly. So RH runs out and sets up a big repository with their own testing system and whatnot that anyone that wants to can maintain packages for.
The "seeding system for RHEE" is *ridiculous*. *Nobody* uses RHEE on the desktop or for anything but the sort of thing you'd normally use OpenBSD for -- not many updates, small package set, emphasis on binary compatibility and security. Not very much fun to use, but there are folks that want this, and the fluid, rapidly-changing Linux community hasn't traditionally made these folks happy. Since a large number of them have money, RH started selling a server setup to them. Guess where that money goes...back into paying full-time developers to work on gcc, XFree86, GNOME, etc, on the less exciting things that people aren't already working on. Just as Debian has people like Jeff Garzick (sp?) that work on software, so does Red Hat have people like Alan Cox.
Nobody would ever transition from RH to RHEE. They're totally different systems. A developer's system would be an exceptionally poor place to install RHEE, even ignoring the price.
That being said, Debian is quite politically different from RH and Mandrake and everyone else. It's a unique and interesting place. But neither is RH some corporate, evil, nasty set of people. Maybe someday it'll get there (SCO did, but I'm not entirely sure that Caldera wasn't always like that).
Rather than paying people to develop a free version they are getting other to do it for free.
You didn't even *read* the parent's post, did you? RH *still* pays their developers to package the *same goddamn* code that always have. On the *other* hand, there is a large number of things that are not packaged. Previously, volunteers have produced a lot of duplication and incompatibility in tiny repositories all over the Internet. RH is simply saying that they're hosting and trying to make it easier to use these, as it's something that's obviously of value to a RH user.
This is, without a doubt, the most horribly incorrect, misleading article I've ever seen.
Real story (a Fedora project member might have additions, but this is pretty close to what's happening). Red Hat realized that Debian was doing something right -- big set of packaged software, auto-updates on 'em, etc. Red Hat was trying to set up their own Debian-style setup called Red Hat Linux Project (RHLP). At some point, Red Hat picked up on the fact that most Red Hat users already like and use Fedora. So they talked to the Fedora folks, and combined RHLP and Fedora. Basically, it means that Red Hat pays for Fedora hosting and distributes Fedora (major value add) *with* their own software packages.
What's the end-user result? From a RH user standpoint, it's something like Powertools being readded to RH plus a lot more. A lot of Debian-style goodness being made available to the masses. There's a much larger package set, so less needing to use checkinstall to automatically produce halfassed RPMs from tarballs. You get a *good* set of download-and-install tools (Fedora uses apt and yum, unlike RH's piss-poor up2date...I've been griping about this on Slashdot for ages). You don't need to add Fedora's apt or yum package to your distro to actually use the large set of well-packaged packages.
This is the *best* thing that's happened for RH users for a long time, and we someone, confused or malicious, posting a "RH is dead" story? What the heck? Is this guy a Mac OS X nut, or just completely and utterly confused?
Clearly, RH should have done a press release, but it was damned irresponsible of Slashdot editors not to add a followup comment, given how significant this is to the Slashdot community. It's like a story claiming "Debian is being acquired by Microsoft" when someone packages WINE for it, or something equally ridiculous.
This is the primary lack on all current consoles (*especially* the PS2). It's incredibly irritating that console manufacturers were so short-sighted here.
Furthermore, in an infinite universe, astronomical odds mean nothing. It had to happen somewhere in the universe; intelligent life just happened to happen here. Unfortunately for us, we're just as screwed when the sun burns out.
Nah. It's an infinite universe, and astronomical odds mean nothing. The sun will suddenly spring back into life.:-)
Wouldn't our bodies be robust, meaning that any part can fail with the rest continuing on?
Actually, if you think about the degree of abuse we constantly take, it is pretty astounding. We're constantly being bombarded with UV and higher frequency rays that chew up our genetic material and cause uncontrolled growth. We're constantly being attacked by zillions of parasites and bacteria. We can lose chunks of almost anything and regrow it, and in many cases other, less damaged parts are capable of compensating. We have multiple central processing components, for God's sake -- separating the two halves of the brain produces a person that can continue functioning. We can lose a lung or a kidney, pretty fundamental components.
Now, we don't think of these as a big deal, because it's stuff that we just shrug off, like a 3000 foot tall armored robotic space ninja shrugs off small missiles and doesn't think about it.
To steal a line from Neal Stephenson, we're all stupendous badasses. If we weren't, we'd be dead.
...which is normal and resasonable. It is not acceptable to post private information about your company's relationship problems with other companies that you're doing business with anywhere I've worked at. Anonymized comments are winked at, because they don't implicate your company.
It makes your mail server do essentially what your mail client on Mac OS or Windows normally does.
It has some significant technical disadvantages, but thanks to folks who cater to the least common denominator, it's becoming the only available option.
but SpamAssassin does use blocklists by default (as described in the FAQ). It is the existence of such blocklists that has forced certain major ISPs to stop writing "pink contracts" to known spammers and they are the only anti-spam measure that reduces the cost that ISPs have to bear in terms of mail-server storage and excess bandwidth that spam causes. Rest assured that the spam epidemic would be far worse without DNSBLs and the cost of Internet access far
Many crucial points:
1) SA uses blacklists, not blocklists. The behavior I find objectionable is the blocking of email based on IP. Providing notification to the user that the ISP thinks that email may be spam is not bad -- I can't see how it would be anything but good. SA does not (by default) *eat* email. It may mark it up.
2) I don't use said features of SA.
3) As I've posted elsewhere in the thread, there are better technical fixes (limiting amplification is a good, simple one) to attempting to keep network costs from being unacceptable. Conflating the problem of dealing with network costs on the server and the problem of avoiding wasted human time on the client is the major reason antispam folks have cause others so much pain.
4) Vendor support shouldn't be automatically dropping questionable email *anyway*. All email originating from dialup IPs is decidedly not spam. It'd be pretty awful if someone sends out a question and then just doesn't get a response.
So don't use the extremist ones like SPEWS. There are plenty of other DNSBLs to choose from.
In a sane world, your response would be correct. Everyone could choose their own degree of filtering.
Unfortunately, that just isn't the case. I can't control the degree of filtering that happens that the compay where I work, as I'm not a member of IT. Furthermore, I cannot control the degree of filtering that happens to other people that I need to send mail to from *their* IT departments.
ISPs aren't so bad on this front. Business IT departments are *awful*. CEOs get pissy about spam and frequently don't deal directly with other companies via email (voice messages are more personal and don't get archived, plus they may have secretaries do contacts for them). IT feels pressure to block spam, so they promptly take a heavy-handed approach. Blam, false positives.
IMO, in a business environment, a 2% false positive rate is unacceptable. You frequently cannot afford to have emails not go through. However, that is also when emails are frequently filtered the most harshly.
IME the situation is even worse than that. If DNSBLs were run by people who made an effort to only blacklist specific IPs that were known to be generating spam right now then it may work better. But they aren't. They're run by people who think it is a good idea to blacklist entire datacentre netblocks because one guy was running a vulnerable formmail, and once blacklisted getting off the blacklist is often nearly impossible because they seem to want everything up to, and including, stone tablets carved by the hand of God as proof that the problem has been delt with.
IME the situation is even worse than that. Compaq IT chooses to use the DUL -- a mind-bogglingly idiotic system which attempts to catalog blacklist all dialup addresses, regardless of whether there ever was a spammer on said network.
"NetBSD's COMPAT_DARWIN Adds XDarwin Support" What the fuck is that? It's not even vaguely english. Probably the majority of people who know what it means are reading this site right now.
Which seems to be to be a good argument for putting it on Slashdot.
This was listed under Software, BSD, and Operating Systems (all tech forums on a website frequented by technical people). If you can't handle reading about any of the three above topics from a tech standpoint, then why the hell are you even on Slashdot, at least in these sections? If all you care about is anime news, then uncheck everything else from your preferences.
It's like someone walking into a psychology convention and complaining that they can't understand why everyone won't shut up about human thought.
You're obviously sitting in front of a web browser. Use it! There's a whole Web of information out there *other* than this article!
NetBSD is multi-platform. So? Why would anyone want to use it? What has it really contributed to BSD? What has it really contributed to computing?
You know, you could make a better "shouldn't use it" argument about the systems you listed as vital above. I'd rather use Linux for any of the above things (secure system, stable system, desktop system), but while Linux runs on many, many devices, NetBSD still runs on systems that Linux can't. So if I needed a free *IX fix on some systems, I'd need to use NetBSD.
Even more entertaining, you appear to have been modded "Redundant", so apparently there is an excess of folks calling Slashdot posters "functionally illiterate".:-)
Understand -- most folks (sadly enough, including those on Slashdot) are not particularly technically-minded, aren't interested in learning how things work and aren't interested thinking about anything. They want their questions answered, preferably quickly and by someone else. They certainly don't want to read anything.
Because Aqua is mind-bogglingly inefficient and *isn't* the best user interface around. In Apple's golden days, yes, they could claim the best user interface around. However, they lost that claim over time, lost a lot of their HCI people, and now make something that looks like Enlightenment -- emphasis on eye candy over usability.
I've watched people using Aqua and a ton of other interfaces. About the fastest you'll see anyone is when they're using a fully keyboard-driven interface and are extremely familiar with the particular application they're using. Secretaries with DOS WordPerfect are a good example. A lot of crufty UNIX people with console or minimal X setups and a ton of automation crud they hacked up also fit in this category.
Mac OS X users rank among the *slowest* users I've ever seen use a user interface. There's lots of waiting and watching as things shift and move around and fade in and out and applications start up. This may be partly due to the fact that many OS X users use laptops, and are stuck with a trackpad, which significantly slows them down.
All the visual effects make sense *if* they improve coordination. For example, it may be "worth" a half-second of zoom animation if the extra half second avoids two seconds of a confused user trying to figure out where a new window came from -- this is the sort of mentality that drove the introduction of ZoomRects on classic Mac OS. However, I just don't see the kind of delay after doing something with a window.
I have Windows-T on my keyboard (Linux/X11/sawfish) set up to launch a new terminal in my home directory. Frequently, I whack that combination and start typing immediately. There is no input-device-changing context switch time, there is no waiting for the program to launch, and there is no time required to consult the contents of the screen.
Um, I use Darwin on an x86 as my primary firewall and work machine. You might be surprised to learn that unix does not necessarily require a goofy gnome foot dropping cores on your desktop every few seconds.
Um, folks use GNOME on Darwin on x86.
And while I don't use GNOME, it's matured a *lot* since the 1.0 days, and is pretty stable, so your jibes aren't exactly accurate.
and the performance hit of doing this will be tremendous.
This is interesting and valid. There's no way to avoid the hit of dealing with the fact that the x86 has far fewer general-purpose registers than the PowerPC. It'd be significantly more efficient to emulate the x86 on a PowerPC than the PowerPC on an x86.
The best bet for good-speed x86 usage would require a recompiler that recalculates register allocation. It would be a serious PITA to do, significantly harder than just a compiler to efficiently compile for x86.
Readline is a particularly irritating example of something that really should be LGPL (not that the original authors "should" have made their work GPLed, but the most popular library to provide this sort of functionality should really be LGPLed. A library like readline provides important services to a number of applications. Ensuring that one library does all this ensures a consistent interface -- an important goal, and one that must be achieved in the absence of forcing everyone to use the same license.
A huge number of console-based applications use (or should use) readline-style functionality. Unfortunately, readline is the only extremely popular library to provide this functionality (line editing, history). There are lots of non-GPL cousins, but not with the same degree of uses that readline enjoys.
I'd like to see readline be LGPL for the same reason that like to see glibc be LGPL. For bash, on the other hand, GPL makes a tremendous amount of sense.
Because FBSD's TCP stack isn't superior in any way that I've heard of. It's popular with closed-source vendors because they don't have to pay for it, however.
Apple might have a proprietary OS in Panther but it is based on standards that allow for easy networking and integration into existing frameworks.
This is just an aside, and doesn't directly relate to MacOS.
For a long time, I used to think "standards good, propriatary bad". I wanted everything I used to be standards compliant.
Then I got into the industry, and ran into some of the standards-setting folks.
The good news is that generally folks involved with setting standards are reasonably (not necessarily the best) competent. It's not as good a situation as the brutally harsh meritocracy of Linux development, where code with vast amounts of time and effort can get thrown out because someone else came up with a better/faster system, but it ensures some degree of sanity.
However, politicking involved in standards committees is horrible. Generally, standards are set by industry consortiums, a recipe for disaster. Everyone has their personal pet features they want in, for starters. They then have to advance the interests of their company, so they try to exclude things that might benefit their competitors, and include support for things they're working on (even if they're technically inferior -- so if IBM is making a worse system than Dinky Company, Inc., it's likely that the technically inferior method gets used.). People are under pressure to finalize standards in time for products based on them to come out -- if there are still issues, too bad. Because different companies may prefer different methods of doing something/have different methods under work already, standards need to include support for both. Standards are frequently bad about exluding redundant methods of doing something. Finally, standards are frequently designed for companies doing a product implementation. They often cost money, and while complete they may not be particularly clear. This compares poorly against the RFCs that provide specifications for traditional Internet protocols today (yes, traditionally RFCs weren't final specs, but they are today).
I've come to realize that "open" is more important than "standardized". If you write a good specification for something, distribute it freely, and you've done a good job with designing the system, others can (and will) adopt the system (if it's better than the alternatives). yEnc, gzip and png were originally "open", though not standardized, and (perhaps more crucially) none were produced by industry consortiums.
Slashdot Mirror
Feel free to rebut them. I'd be facinated to hear what, if any, evidence you can produce.
As for being a spammer...heh. Not bloodly likely. Not everyone annoyed by swaths of IPs being blocked is a spammer. As I said, spammers and overreaching antispammers both piss me off. You're as justified in that claim as I would be in saying that you were a member of the DUL-producing group.
Many are reporting, e.g., that up2date is broken.
They're *just merging it in*! Thousands of packages being combined! Fedora never *used* up2date! You bet your ass there's going to be some interesting times as the two are combined.
I don't mind running Debian Testing, but I'm very selective about what I accept from unstable.
Fedora *has* stable, unstable, testing, etc. I'm not involved with the team, but I'd be somewhat surprised if they don't place the ol' RH packages in a "core"/"redhat-produced" category so that you can just use RH-produced packages, same as before, if you want. Or RH+Fedora stable. Or RH+Fedora stable+Fedora unstable. You name it.
The problem is that the article submitted was *wildly* inaccurate. (...RH going away...pointing people to the free Fedora project...) It'll take months for people to figure out that it was a load of BS.
My guess is that the decision to re-name the free version came from the marketing group.
Actually, RH *tried* to set up the "Red Hat Linux Project", got a bunch of people confused, said "forget this" and happily merged with the largest person already doing what they wanted to do -- Fedora.
I can tell you there is NO way we are going to replace 500 workstations with an unproven OS costing $800/box.
RHEE is not intended for workstation use. You'd be stupid to put it on workstations.
As RH has pointed out, no, that's not the case. RHLP, like Fedora, is a community project that lots of folks have been happily packaging things for for ages. You don't have to pay money for it, you don't have to conform with ideas of the maintainers any more than you would Debian maintainers or the old Fedora maintainers.
For a long time, people have been maintaining RPM package repositories. Fedora became the largest, but there was also dag, freshrpms, and a number of others. These rapidly became incompatible with each other, and only stayed compatible with Red Hat. Basically, you only got to choose one.
Red Hat got a lot of griping from RH users (including myself) that they wanted all these non-RH packages to work properly. So RH runs out and sets up a big repository with their own testing system and whatnot that anyone that wants to can maintain packages for.
The "seeding system for RHEE" is *ridiculous*. *Nobody* uses RHEE on the desktop or for anything but the sort of thing you'd normally use OpenBSD for -- not many updates, small package set, emphasis on binary compatibility and security. Not very much fun to use, but there are folks that want this, and the fluid, rapidly-changing Linux community hasn't traditionally made these folks happy. Since a large number of them have money, RH started selling a server setup to them. Guess where that money goes...back into paying full-time developers to work on gcc, XFree86, GNOME, etc, on the less exciting things that people aren't already working on. Just as Debian has people like Jeff Garzick (sp?) that work on software, so does Red Hat have people like Alan Cox.
Nobody would ever transition from RH to RHEE. They're totally different systems. A developer's system would be an exceptionally poor place to install RHEE, even ignoring the price.
That being said, Debian is quite politically different from RH and Mandrake and everyone else. It's a unique and interesting place. But neither is RH some corporate, evil, nasty set of people. Maybe someday it'll get there (SCO did, but I'm not entirely sure that Caldera wasn't always like that).
Rather than paying people to develop a free version they are getting other to do it for free.
You didn't even *read* the parent's post, did you? RH *still* pays their developers to package the *same goddamn* code that always have. On the *other* hand, there is a large number of things that are not packaged. Previously, volunteers have produced a lot of duplication and incompatibility in tiny repositories all over the Internet. RH is simply saying that they're hosting and trying to make it easier to use these, as it's something that's obviously of value to a RH user.
This is, without a doubt, the most horribly incorrect, misleading article I've ever seen.
Real story (a Fedora project member might have additions, but this is pretty close to what's happening). Red Hat realized that Debian was doing something right -- big set of packaged software, auto-updates on 'em, etc. Red Hat was trying to set up their own Debian-style setup called Red Hat Linux Project (RHLP). At some point, Red Hat picked up on the fact that most Red Hat users already like and use Fedora. So they talked to the Fedora folks, and combined RHLP and Fedora. Basically, it means that Red Hat pays for Fedora hosting and distributes Fedora (major value add) *with* their own software packages.
What's the end-user result? From a RH user standpoint, it's something like Powertools being readded to RH plus a lot more. A lot of Debian-style goodness being made available to the masses. There's a much larger package set, so less needing to use checkinstall to automatically produce halfassed RPMs from tarballs. You get a *good* set of download-and-install tools (Fedora uses apt and yum, unlike RH's piss-poor up2date...I've been griping about this on Slashdot for ages). You don't need to add Fedora's apt or yum package to your distro to actually use the large set of well-packaged packages.
This is the *best* thing that's happened for RH users for a long time, and we someone, confused or malicious, posting a "RH is dead" story? What the heck? Is this guy a Mac OS X nut, or just completely and utterly confused?
Clearly, RH should have done a press release, but it was damned irresponsible of Slashdot editors not to add a followup comment, given how significant this is to the Slashdot community. It's like a story claiming "Debian is being acquired by Microsoft" when someone packages WINE for it, or something equally ridiculous.
The problem is lack of primary memory.
This is the primary lack on all current consoles (*especially* the PS2). It's incredibly irritating that console manufacturers were so short-sighted here.
Furthermore, in an infinite universe, astronomical odds mean nothing. It had to happen somewhere in the universe; intelligent life just happened to happen here. Unfortunately for us, we're just as screwed when the sun burns out.
:-)
Nah. It's an infinite universe, and astronomical odds mean nothing. The sun will suddenly spring back into life.
Wouldn't our bodies be robust, meaning that any part can fail with the rest continuing on?
Actually, if you think about the degree of abuse we constantly take, it is pretty astounding. We're constantly being bombarded with UV and higher frequency rays that chew up our genetic material and cause uncontrolled growth. We're constantly being attacked by zillions of parasites and bacteria. We can lose chunks of almost anything and regrow it, and in many cases other, less damaged parts are capable of compensating. We have multiple central processing components, for God's sake -- separating the two halves of the brain produces a person that can continue functioning. We can lose a lung or a kidney, pretty fundamental components.
Now, we don't think of these as a big deal, because it's stuff that we just shrug off, like a 3000 foot tall armored robotic space ninja shrugs off small missiles and doesn't think about it.
To steal a line from Neal Stephenson, we're all stupendous badasses. If we weren't, we'd be dead.
...which is normal and resasonable. It is not acceptable to post private information about your company's relationship problems with other companies that you're doing business with anywhere I've worked at. Anonymized comments are winked at, because they don't implicate your company.
Yes.
It makes your mail server do essentially what your mail client on Mac OS or Windows normally does.
It has some significant technical disadvantages, but thanks to folks who cater to the least common denominator, it's becoming the only available option.
Hate to rain on your parade here
You aren't. No need to worry.
but SpamAssassin does use blocklists by default (as described in the FAQ). It is the existence of such blocklists that has forced certain major ISPs to stop writing "pink contracts" to known spammers and they are the only anti-spam measure that reduces the cost that ISPs have to bear in terms of mail-server storage and excess bandwidth that spam causes. Rest assured that the spam epidemic would be far worse without DNSBLs and the cost of Internet access far
Many crucial points:
1) SA uses blacklists, not blocklists. The behavior I find objectionable is the blocking of email based on IP. Providing notification to the user that the ISP thinks that email may be spam is not bad -- I can't see how it would be anything but good. SA does not (by default) *eat* email. It may mark it up.
2) I don't use said features of SA.
3) As I've posted elsewhere in the thread, there are better technical fixes (limiting amplification is a good, simple one) to attempting to keep network costs from being unacceptable. Conflating the problem of dealing with network costs on the server and the problem of avoiding wasted human time on the client is the major reason antispam folks have cause others so much pain.
4) Vendor support shouldn't be automatically dropping questionable email *anyway*. All email originating from dialup IPs is decidedly not spam. It'd be pretty awful if someone sends out a question and then just doesn't get a response.
So don't use the extremist ones like SPEWS. There are plenty of other DNSBLs to choose from.
In a sane world, your response would be correct. Everyone could choose their own degree of filtering.
Unfortunately, that just isn't the case. I can't control the degree of filtering that happens that the compay where I work, as I'm not a member of IT. Furthermore, I cannot control the degree of filtering that happens to other people that I need to send mail to from *their* IT departments.
ISPs aren't so bad on this front. Business IT departments are *awful*. CEOs get pissy about spam and frequently don't deal directly with other companies via email (voice messages are more personal and don't get archived, plus they may have secretaries do contacts for them). IT feels pressure to block spam, so they promptly take a heavy-handed approach. Blam, false positives.
IMO, in a business environment, a 2% false positive rate is unacceptable. You frequently cannot afford to have emails not go through. However, that is also when emails are frequently filtered the most harshly.
IME the situation is even worse than that. If DNSBLs were run by people who made an effort to only blacklist specific IPs that were known to be generating spam right now then it may work better. But they aren't. They're run by people who think it is a good idea to blacklist entire datacentre netblocks because one guy was running a vulnerable formmail, and once blacklisted getting off the blacklist is often nearly impossible because they seem to want everything up to, and including, stone tablets carved by the hand of God as proof that the problem has been delt with.
IME the situation is even worse than that. Compaq IT chooses to use the DUL -- a mind-bogglingly idiotic system which attempts to catalog blacklist all dialup addresses, regardless of whether there ever was a spammer on said network.
"NetBSD's COMPAT_DARWIN Adds XDarwin Support" What the fuck is that? It's not even vaguely english. Probably the majority of people who know what it means are reading this site right now.
Which seems to be to be a good argument for putting it on Slashdot.
This was listed under Software, BSD, and Operating Systems (all tech forums on a website frequented by technical people). If you can't handle reading about any of the three above topics from a tech standpoint, then why the hell are you even on Slashdot, at least in these sections? If all you care about is anime news, then uncheck everything else from your preferences.
It's like someone walking into a psychology convention and complaining that they can't understand why everyone won't shut up about human thought.
You're obviously sitting in front of a web browser. Use it! There's a whole Web of information out there *other* than this article!
NetBSD is multi-platform. So? Why would anyone want to use it? What has it really contributed to BSD? What has it really contributed to computing?
You know, you could make a better "shouldn't use it" argument about the systems you listed as vital above. I'd rather use Linux for any of the above things (secure system, stable system, desktop system), but while Linux runs on many, many devices, NetBSD still runs on systems that Linux can't. So if I needed a free *IX fix on some systems, I'd need to use NetBSD.
"COMPAT_DARWIN?" Was "Darwin Compatibility" something or other too ungeeky
It's a dark day on "News for Nerds".
Even more entertaining, you appear to have been modded "Redundant", so apparently there is an excess of folks calling Slashdot posters "functionally illiterate". :-)
Understand -- most folks (sadly enough, including those on Slashdot) are not particularly technically-minded, aren't interested in learning how things work and aren't interested thinking about anything. They want their questions answered, preferably quickly and by someone else. They certainly don't want to read anything.
Because Aqua is mind-bogglingly inefficient and *isn't* the best user interface around. In Apple's golden days, yes, they could claim the best user interface around. However, they lost that claim over time, lost a lot of their HCI people, and now make something that looks like Enlightenment -- emphasis on eye candy over usability.
I've watched people using Aqua and a ton of other interfaces. About the fastest you'll see anyone is when they're using a fully keyboard-driven interface and are extremely familiar with the particular application they're using. Secretaries with DOS WordPerfect are a good example. A lot of crufty UNIX people with console or minimal X setups and a ton of automation crud they hacked up also fit in this category.
Mac OS X users rank among the *slowest* users I've ever seen use a user interface. There's lots of waiting and watching as things shift and move around and fade in and out and applications start up. This may be partly due to the fact that many OS X users use laptops, and are stuck with a trackpad, which significantly slows them down.
All the visual effects make sense *if* they improve coordination. For example, it may be "worth" a half-second of zoom animation if the extra half second avoids two seconds of a confused user trying to figure out where a new window came from -- this is the sort of mentality that drove the introduction of ZoomRects on classic Mac OS. However, I just don't see the kind of delay after doing something with a window.
I have Windows-T on my keyboard (Linux/X11/sawfish) set up to launch a new terminal in my home directory. Frequently, I whack that combination and start typing immediately. There is no input-device-changing context switch time, there is no waiting for the program to launch, and there is no time required to consult the contents of the screen.
Um, I use Darwin on an x86 as my primary firewall and work machine. You might be surprised to learn that unix does not necessarily require a goofy gnome foot dropping cores on your desktop every few seconds.
Um, folks use GNOME on Darwin on x86.
And while I don't use GNOME, it's matured a *lot* since the 1.0 days, and is pretty stable, so your jibes aren't exactly accurate.
The PPC is a far better designed chip, of course,
By what do you base your claims on?
and the performance hit of doing this will be tremendous.
This is interesting and valid. There's no way to avoid the hit of dealing with the fact that the x86 has far fewer general-purpose registers than the PowerPC. It'd be significantly more efficient to emulate the x86 on a PowerPC than the PowerPC on an x86.
The best bet for good-speed x86 usage would require a recompiler that recalculates register allocation. It would be a serious PITA to do, significantly harder than just a compiler to efficiently compile for x86.
Readline is a particularly irritating example of something that really should be LGPL (not that the original authors "should" have made their work GPLed, but the most popular library to provide this sort of functionality should really be LGPLed. A library like readline provides important services to a number of applications. Ensuring that one library does all this ensures a consistent interface -- an important goal, and one that must be achieved in the absence of forcing everyone to use the same license.
A huge number of console-based applications use (or should use) readline-style functionality. Unfortunately, readline is the only extremely popular library to provide this functionality (line editing, history). There are lots of non-GPL cousins, but not with the same degree of uses that readline enjoys.
I'd like to see readline be LGPL for the same reason that like to see glibc be LGPL. For bash, on the other hand, GPL makes a tremendous amount of sense.
Because FBSD's TCP stack isn't superior in any way that I've heard of. It's popular with closed-source vendors because they don't have to pay for it, however.
Apple might have a proprietary OS in Panther but it is based on standards that allow for easy networking and integration into existing frameworks.
This is just an aside, and doesn't directly relate to MacOS.
For a long time, I used to think "standards good, propriatary bad". I wanted everything I used to be standards compliant.
Then I got into the industry, and ran into some of the standards-setting folks.
The good news is that generally folks involved with setting standards are reasonably (not necessarily the best) competent. It's not as good a situation as the brutally harsh meritocracy of Linux development, where code with vast amounts of time and effort can get thrown out because someone else came up with a better/faster system, but it ensures some degree of sanity.
However, politicking involved in standards committees is horrible. Generally, standards are set by industry consortiums, a recipe for disaster. Everyone has their personal pet features they want in, for starters. They then have to advance the interests of their company, so they try to exclude things that might benefit their competitors, and include support for things they're working on (even if they're technically inferior -- so if IBM is making a worse system than Dinky Company, Inc., it's likely that the technically inferior method gets used.). People are under pressure to finalize standards in time for products based on them to come out -- if there are still issues, too bad. Because different companies may prefer different methods of doing something/have different methods under work already, standards need to include support for both. Standards are frequently bad about exluding redundant methods of doing something. Finally, standards are frequently designed for companies doing a product implementation. They often cost money, and while complete they may not be particularly clear. This compares poorly against the RFCs that provide specifications for traditional Internet protocols today (yes, traditionally RFCs weren't final specs, but they are today).
I've come to realize that "open" is more important than "standardized". If you write a good specification for something, distribute it freely, and you've done a good job with designing the system, others can (and will) adopt the system (if it's better than the alternatives). yEnc, gzip and png were originally "open", though not standardized, and (perhaps more crucially) none were produced by industry consortiums.
Correction -- instead of "just bounces the mail", I should have said "just drops the mail".