i think you're absolutely right. and, much as the Linux crowd here's going to hate me for suggesting it, i see exactly one alternative. who does have the ability to absorb 1M additional users into their existing support base without getting killed by the weight? two OS vendors: M$ and Apple. Apple's also got a significant leg up on Linux in the educational field, so it wouldn't be nearly as much of a stretch for the people who have to make these boxes run. in addition, the point here, as someone earlier noted, is to penalize M$. the best way to do that, aside from short-term punative damages in cash (which is also a good idea) is to create or encourage a viable long-term alternative. and, sorry, guys, but Apple's got a better shot at that. further, if the penalty has to benefit someone, it should be those people M$'s abusive monopoly most hurt, and Apple's been taking M$'s abuse for much longer than Linux has been a factor. and that says nothing of the comparative qualities of the OSs...:-)
The Xbox being a PC inside really isn't a bad thing...
it's not that it's bad, more that it's inefficient. PCs arn't optimized for games. they use an Intel x86 chip, which is very burdened with legacy code and crap. the x86 chip is favored in the desktop world not because it's good, but for compatability. when that's not an issue (as it's not in games), the x86 begins to look alot less interesting compared to things like MIPS (in N64 and PS2) and PowerPC (in Gamecube, and Macs). and it's even a low-end PC: it's a fairly unimpressive processor, and they're not even using the highest end video cards available, which is, of course, crucial for a game console. the use of DirectX is another thing, however. in terms of PC compatability (not interesting to me, since i don't use M$ ever, but it's still a market factor worth talking about), it helps alot, and that's really apealing to a game designer. the problem is the M$ doesn't know crap about portable code, so DirectX is pretty closely tied to x86 architectures, without major work. which is why they put an Intel chip in there, which costs them in terms of performance. which does not look good to a game designer. it remains to be seen whether they made the correct tradeoff. what i'd like to see is someone design the game interfaces around something more cross-platform, like OpenGL. that'd open the way to more games on more platforms, and PCs running varous OSs. but most console makers don't want that. M$ was willing to "compromise" with DirectX because they own the only other place it runs, too! (excluding small, not-really-relavant-to-the-market hack jobs for other OSs, with poor performance and not-quite-finished functionality)
first of all, if M$ is worried about supporting two different APIs, why not just support one game API... and then supply it on both the Xbox and XP? you guys totally forget about code portability? not suprising, when GNU's answer to portable code is 'configure'. bah. also, there's arguably several other good reasons for M$ to support games on both... like the fact that lots of people will have PCs, or Xboxes, but not both? and it's much more attractive to a game producer to be able to say "look, write to this API, and you can run on XP or Xbox". nobody else can say that today.
problems here:
first, what's the first script to be written in, that it'll run on any unix? i guess this is easier than the general case, but still not an issue to ignore. also, this more than duplicates the work of writing and maintaining these scripts. you've got the install scripts twice, plus the selector script.
i'm almost afraid if i comment here your head'll explode...
...ksh, the unquestioned pinnacle of scripting shells...
unquestioned, huh? go tell that to the bash guys. or the ash guys. or, heck, me. ksh is pretty good, but it's certainly not the unquestioned anything, and i'd question whether it's the best scripting shell available (even using a narrow definition of shells that exclude things like perl).
...zsh, the unquestioned epitome of user shells?
again, tell that to the bash folks, or the dozens of other user shells out there. personally, i love rc, for both scripting and interactive use. doesn't have all the features of the others, but is much less complex, much smaller, and simpler and more consistent to use. but the point is that there's no unquestioned shell for anything. not to mention the fact that your "suggestion" totally ignore the guys problem: writing a cross-platform install script. zsh is totally non-standard, so that's out. ksh is pretty common, but not totally common, and is installed as different things in different places. there's definatly a place for a standard (you linux guys remember those, don't you?), and, for the time being, bourne shell's it. so either linux gets with the standard program, or it continues to be a pain.
it's not a double standard. it's a choice. the writers of fink and most other software projects make a choice as to what terms they want to license that software to users. fink, and lots of other people, choose to release it open source. others do not. a double standard would be for some projects to have that choice, and others not to.
MAPS is opt-in, but only on a mail-server level. for users who get mail from an IPS's mail server, they often have no say in the decision. what's more, MAPS (i believe) only works on site-level blocking, nothing with finer granularity. for example, on sites i run, i block mail from *opt-out*@*. MAPS is also somewhat heavy-handed about how they decide to add people, and what it takes to get off the list. overall, though, i don't really see the argument for MAPS as a rights violation, the way EFF is talking. i choose not to go that route because i think i and my users want more fine grain controls over who we don't want to talk with.
you're making a false comparison. you say "the internet" did well - maybe, but so did "the phone network". i live outside Manhattan, but in the NY Metro area, and i had no problems with my phone connectivity, cel or land-line. by contrast, my ISP went down shortly after the towers, when their upstream provider's emergency generators ran out of fuel. your comparison is (intentionaly, i suspect) unfair becuase you're comparing the fact that a small area of the phone network went down to the fact that the Internet overall continued to work. it's a stupid comparison. your "analysys" is also ignorant of the physical network underlying both the phone network and the Internet. the phone network is built on top of a series of actual, physical links. the Internet is built partly on top of this, partly with additional links. lost of my friends in Manhattan lost IP connectivity because - suprise! - their phone service, which they use for IP connectivity, wasn't working. sure, my IP connections to California were unaffected by the WTC going down. but i made phone calls from 15 min. outside the city, that day, all over the country, with no problem (other than into Manhattan). for all that talk of redundant routing on the internet, how many lines do most people have protruding from the back of their box? 1. how many ISPs do most people have? 1. how many upstream providers do most of those ISPs have? 1. all single points of failure. ask someone you know familiar with the net what would happen if someone took out MAE-East or MAE-West, among a handfull of other very important Internet sites. it'd be much easier, in fact, to make the Internet useless by taking out ten or so buildings than to take out the phone network by taking down 50.
...this is also why growth and development has been much faster than on the phone...
uh, yeah, but it's also why my phone crashes so much less often (uh, never?) than my PC (rarely, 'cuase i run good stuff), and why my telephone company won't let me connect so much less often (once in my lifetime, while the line up my street was being worked on) than my ISP (once every month or two).
good observation, and good question. while you're correct that Crusoe and IA64 are the only two commercial VLIW architectures (that i've seen, anyway), the concept is not new. VLIW's been around for many years, and has been tried by lots of chip manufacturers in research. i believe some non-mainstream chip manufacturers (like pre-split AT&T) have tried it commercially in the past, as well. the results are always the same: poor performance. Intel's been very careful (initially anyway; they may have loosened up a bit) to avoid using the term VLIW in reference to their IA64 chip, for exactly this reason. they talk about EPIC as the design architecture, but EPIC's basically one impelementation of VLIW. Intel and their chips performance will both be further hit by the fact that VLIW - including EPIC - is notoriously hard to write compilers for, particularly ones that perform even reasonably. i've heard very little about AMD's 64-bit architecture, but if they're avoiding the VLIW mess, i'm quite hopeful that they'll blow past Intel's performance there.
of course, none of this really proves the VLIW concept is flawed, but the implementations sure all have been. and it does prove that VLIW - even in its EPIC form - isn't the magic bullet Intel's hoping it is.
first off, the current version of the definity software runs on Unixware 2, not Unixware 1. it's a minor improvement, i ran it while it was towards the end of beta. the developer types were looking towards UW 7 already, but who knows what's up with that with the current state of Lucent and here derivatives. also, i've run both UW1 and UW2 based Audix systems, and neither one relied on a windows program. i didn't even know such a thing existed. i did all my administration via xterms or on console, using the pre-bundled tool set. nothing special going on. and that kinda makes me very uninterested in your Linux work. i mean, if all i'm using now is xterm, why would i want any special program, regardless of platform?
troll, huh? this from an AC? not too good at recognizing trolls, huh? anyway...
The kernel is written in C & (small bits of) asm.
oh. interesting, and someone else informed me of that and managed to not be insulting, too. just to be clear, the (aparently incorrect) information i was given was from a Be employee, while talking about their first port, from AT&T's Hobbit chip to the PPC. and if you consider larger than 64K "larger projects", you're working in the wrong decade. it's quite easy to blow past that limit while neither trying very hard nor doing anything particularly odd. and for someone denouncing posts as trolls, you aparently don't read very well. i explicitly stated that the MetroWorks folks probably have their act together, and i've seen their compilers (for other architectures) do quite nicely. my complaint - as i said - was that they felt tying all their potential developers to that compiler was sufficient.
how recently have you priced apple hardware? their price/performance ratio is actually quite competative, and has been for about two years now. sorry, buddy. to clear up some confusion, the fact the the number before the "Mhz" on the chip description tends to be lower with Macs isn't relavant. once you move accross chip architectures, those numbers are next to meaningless. do you really think your 100Mhz 486 and my 100 Mhz MIPS chip perform comprably? sorry, not even close. the PowerPC chip design is much cleaner, faster, and more efficient than the x86 design, especially the P-III grade design. hz for hz, a PPC chip'll beat an x86 chip any time. to be fair, even if you take a more "enlightened" view of the performance, apple's price/performance ratio isn't quite as good as many x86 desktop models (although it's close, and better than many of the big-name boxes). but there's much more to buying a computer than that. Apple hardware is actually engineered, in ways that most other PCs certainly don't seem to be. the hardware is well-designed and well-built. on desktop systems, i've not seen anything in the x86 market that comes close, and that's probably because of some fundamental facts of that market. the x86 world does a bit better with laptops, but Apple's still got them beat there, too. add to that the usability issues, battery life, screen size and clarity, and general slickness, and Apple comes out well worth the extra ~$100 (if that) they're behind in a strict price/performance comparison. the current iBook line starts at $1300, list. nothing in the x86 laptop world comes close for under $1500. the iMac starts at $1000, roughly comparable to many of the $900-1100 low-end boxes being offered by the big x86 producers. and, of cource, there's the OS to consider, which is kinda what this is about. in my book, a box shipping with OS X is a huge win over a box shipping with more M$ crap. and i'm talking for people like my mom, for whom linux (or any other non-OS X unix) isn't even a remote posability.
i really liked be. i was a registered developer back when that gave you a four-didgit number (3860). i bought a dual-133 BeBox, and love it. they did a number of things right, particularly in the areas of user interface and multimedia, and even did a reasonably good job in partnering relationships. i was quite happy with their developer support (i've twice gotten email from JLG himself). but they also did a number of things wrong. here's what i think:
first, on the technical front, Be was an improvement, but not the revolution they liked to pretend to be. they had an incrementally better UI, kernel, and networking than Mac or Win32. but they were not revolutionary, nor were their approaches to these areas truely innovative. the GUI and file sharing models were examples of existing models done better. second, there's C++. regardless of what you think of it as an applications language, it's just not a good choice for kernels, particularly ones with real-time or low-latency requirements. and it's not a good idea to make it the only real choice for applications development, either. third was development environment. probably because of their history at Apple, the Be folks were quite happy giving Metroworks control of their development environment. which meant no (unrestricted) free compiler (at least on PPC chips). the wouldn't help other compler efforts (like gcc) with their object format. and while Metroworks may be good, they're just not the toolset many developers are most productive (or comfortable) with. they also wasted much of their effort on things that didn't matter. there's plenty of kernels suitable for real-time or low-latency operation. many of these are available either open source or under reasonable licensing terms. Be would have been better served taking the OS X approach - build on somebody else's work, concentrating on what you're really good at (in Be's case, the multimedia aspect). but i think what really killed Be was the path of least resistance. i first fell in love with the company for the hardware. a reasonably inexpensive dual-proc box with great numbers, and software that could use it. wow. okay, maybe they were a bit late there, but there's always been at least a niche market for high-end workstations. then they canned the hardware to concentrate on the software. which could've been okay, if they had reason to believe Apple would be more co-operative. they didn't; it was a gamble. and they were wrong. Apple closed up just as the hardware started getting really interesting again, and Be was stuck. then they moved their focus to intel hardware - a much broader market, but with correspondingly wider demands. it's much easier to support every Mac sound card than to support every PC sound card. then, when that didn't even go as well as they'd hoped, they moved on to the IA market, with much less defined power structures and less entrenched players (read: no Micro$oft monopoly). at each stage, Be chose to find an easier path rather than finding the path right for what they had. like it or not, an OS originally designed for media content creation is not ideally suited to IAs. nor should one expect it to be.
anyway, if anyone's got any suggestions on what to do with my BeBox, let me know (don't even talk to me about Linux PPC).
that's not quite acurate. first of all, remember that loads of people still have per-minute charges on net connections, either through their provider, like AOL, or via telephone charges. that's a direct cost. also, keep in mind that this method is the only real option in many parts of the world outside the U.S. - again, a very real, direct cost. another direct cost - although a much smaller one - is the storage of that email on my system. this is generally neglegable and recoverable, but i've worked in environments where everything is backed up permenantly to WORM media. that's a direct, tangible cost in terms of a used-up resource. also, in cases where the cost of spam isn't directly on my shoulders - such as when my ISP bears it by way of providing the bandwidth or storage, don't think for a second they're not passing that cost on to the end user. for even less direct costs, there's the issue of my time.
so no, i'm afraid pager spam isn't the only spam with direct end-user costs; it's just more easialy aparent.
Re:...I thought open source was bad for business??
on
Red Hat In The Black
·
· Score: 1
...linux can be profitable, if not as a product than for customer support
uh, just to be clear, arn't you basically saying RH is making money off selling software that needs their support? gee, M$ has already proved that's a succesfull business strategy!
what? um, linus is gonna be a little disapointed when he finds that one out, since the rest of the world credits him with inventing Linux. surely you mean that Red Hat was the first distribution! oh, but wait, that's not true, either. the first commercial company to back it? nope. so what're you talking about?
So, to think that companies like ATI and TiVo would go together in a venutre like this is rediculous.
yet, there they are. along with a few other companies that are pretty improtant in the industry (despite the stupid editorial commentary in the intial/. posting).
this isn't about them all uniting in peace and harmony. standars processes are often frought with political issues (both among countries and companies). but often what's in their best interests is in our best interests, too. sometimes.
uh, in what sense is QNX a Linux clone? i think maybe you're a little Linux-happy here. QNX is arguably a Unix clone, in the same some of the same ways that Linux is, but i've seen no evidence of QNX being a Linux clone. indeed, it's real-time, embeded nature targets very different things than Linux does, with very different priorities.
oh, and many of the important standards for the Internet or modern computing were contributed largely to by major companies. it's not so much the who's involved that's often problematic (although it certainly can be), but more often the nature of the process that's broken, resulting in broken standards.
hate to say it, buddy, but are you serious? first of all, these comparisons are problematic and dificult enough when compairng two OSs, yet you want them all compared? how do you deal with the fact that many have very different models for many things? second, two words: Installed Base. you may love Linux or FreeBSD or BeOS, but would these really find a place in a comparison of "all major OSes"? There's still way more Mac boxes on people's desks than LInux boxes. and that's to say nothing of FreeBSD or BeOS (which Be doesn't even market any more). what does "major" mean in your proposed comparison? oh, and these comparisons tend to be targeted at non-techies. do you really think Linux or FreeBSD is going to hold much weight agains MacOS X for these people? in terms of things like GUI quality or adding new hardware?
i think it's kinda funny that MacOS X will almost immediatly surpas Linux - and shortly thereafter all other Unix-oid systems combined - in finally bringing Unix to the desktop. good fer them.
i love rc. i use it on plan 9 all the time. it's my default shell on all my Unix boxes. i've even gone so far as to re-write a number of my Unix (solaris) administrative scripts into it. for programing, i find it far better than any other shell i've seen, and the fact that it's so much smaller is a huge win, too (although fewer and fewer people seem to really care about code bloat, unless it means we can point fingers at Micro$oft). but this is a bigger trend, isn't it? all the *sh Unix shells are basicaly retreads and mods of the bourne shell (even csh was written with it in mind), without fixing the fundamental problems. i think this is quite similar to the ever-increasing number of Linux distributions basicaly being retreads of Unix, but again without fixing any of the fundamental problems. rc, as you pointed out, was written for plan 9, a system written from the ground up, keeping what's good in Unix, but fixing the fundamental problems. when you ask:
...what's the point, if monstrosities like zsh and bash continue to exist?
you could just as well s/zsh and bash/Linux and Unix/ and be asking about plan 9. well, if nothing else, it means i don't have to use crap. it provides positive alternatives. some people need crutches. some people think X is as good as window systems get. some people don't see problems with ttys and ioctls. and, sad as it is, some people like having command completion in their shells, or command history, or two (!) editors (good lord when will it end...). i've seen shells with half of/bin built in, or screen, or various mouse-aware thingies. people are trying to compensate for the fundamental problems that none of their systems will address. i used to demand a searchable command history in my shell - once moving to rc and rio (the plan 9 window system), i've never missed it.
no, that's the point. the recording industry wants money from every production, regardless of whether they own the copyright or not. the want to be able to keep the number of producers small - that's the only way they can force premium prices out of the market. alright, i need to find that article...
your arguement is based on a hugely faulty assumption, and one the recording industry is trying very hard to propagate: that they own all the copyrights. let's say i produce a CD. i wrote the music, i ran the recording equipment, i mixed it... everything. it's all mine. the recording industry still wants money from it - they want to be able to restrict who can produce, or profit from every production. but i should be able to do what i want with that recording - including making mp3s of my tracks and distributing them anywhere i want, without RIAA, or anyone else, getting a cent. i should be able to make mp3s, plop them on Napster or Gnutella or whatever, and encourage everyone to take them, without paying me or anyone else, if that's what i want. the RIAA should not be able to restrict this, nor should anyone else.
your argument also ignores the "fair use" realm of copyright law. if i have a Rio, i should be able to (freely) encode mp3s for my own enjoyment, if i've already bought the CD. this is exactly the same as burning copies of my CDs so i don't have to have one copy for work, one for home, and one for my car.
oh, and for the record, this is already practiced in related areas. lots of digital recording devices, like MiniDisc players, either only provide analog in or only provide analog out - the prohibit you from making full-quality digital reproductions. regardless of the copyright status. it's an institutionalized version of exactly what you're suggesting, and all it does is exactly what the big corps want: restrict who can produce. there was a really good article i read on this (maybe even on/.), but i can't find it right now...
first of all, the FBI'd have to be pretty damn close to monitor these things given the distances involved. but more to the point, this is just transport medium. what you put over it is up to you. as, for that mater, is whether to even use it or not. if you're uncomfortable with having your hard drive contents travel raw over the air, encrypt them. if the latency increase bothers you (which would likely be quite small, given good techniques), than just don't use the technology. the availability of this technology doesn't automatically make things less secure for you.
first of all, "proof" in this context is a bit useless. what's it mean to be provably secure? most cryptographers agree quantum computing will make pretty much everything we've got today a waste of time (for the one trying to protect the data). heck, we even know how to do that, even if nobody's managed to do it yet... even beyond that, this concept is a reach at best. most modern encryption techniques depend on factoring certain kinds of numbers, or other similarly time-intesive operations. they all rely on nobody being able to find a shortcut to do the math. by your arguement, no encryption method is sufficiently secure: just because nobody's found such a shortcut yet doesn't mean they won't. but it's a good enough bet for me, and loads of other people who think cryptography is important.
and even were it true that PK systems had a greater risk, your conclusion that they're therefore not worth it does not follow. PK systems have a number of other benefits beyond the strenght of their encryption, such as being able to encrypt to various distinct recipients who share no knowledge other than what you give them, being able to sign and/or encrypt data seperatly, the ability to have a repository or infrastructure for PK discovery... the list goes on. these attributes definatly make PK systems worth consideration in any "serious computing environment" in which data security is important.
Slashdot Mirror
i think you're absolutely right. and, much as the Linux crowd here's going to hate me for suggesting it, i see exactly one alternative. who does have the ability to absorb 1M additional users into their existing support base without getting killed by the weight? two OS vendors: M$ and Apple. Apple's also got a significant leg up on Linux in the educational field, so it wouldn't be nearly as much of a stretch for the people who have to make these boxes run.
in addition, the point here, as someone earlier noted, is to penalize M$. the best way to do that, aside from short-term punative damages in cash (which is also a good idea) is to create or encourage a viable long-term alternative. and, sorry, guys, but Apple's got a better shot at that.
further, if the penalty has to benefit someone, it should be those people M$'s abusive monopoly most hurt, and Apple's been taking M$'s abuse for much longer than Linux has been a factor.
and that says nothing of the comparative qualities of the OSs...:-)
and it's even a low-end PC: it's a fairly unimpressive processor, and they're not even using the highest end video cards available, which is, of course, crucial for a game console.
the use of DirectX is another thing, however. in terms of PC compatability (not interesting to me, since i don't use M$ ever, but it's still a market factor worth talking about), it helps alot, and that's really apealing to a game designer. the problem is the M$ doesn't know crap about portable code, so DirectX is pretty closely tied to x86 architectures, without major work. which is why they put an Intel chip in there, which costs them in terms of performance. which does not look good to a game designer. it remains to be seen whether they made the correct tradeoff.
what i'd like to see is someone design the game interfaces around something more cross-platform, like OpenGL. that'd open the way to more games on more platforms, and PCs running varous OSs. but most console makers don't want that. M$ was willing to "compromise" with DirectX because they own the only other place it runs, too! (excluding small, not-really-relavant-to-the-market hack jobs for other OSs, with poor performance and not-quite-finished functionality)
first of all, if M$ is worried about supporting two different APIs, why not just support one game API... and then supply it on both the Xbox and XP? you guys totally forget about code portability? not suprising, when GNU's answer to portable code is 'configure'. bah. also, there's arguably several other good reasons for M$ to support games on both... like the fact that lots of people will have PCs, or Xboxes, but not both? and it's much more attractive to a game producer to be able to say "look, write to this API, and you can run on XP or Xbox". nobody else can say that today.
problems here:
first, what's the first script to be written in, that it'll run on any unix? i guess this is easier than the general case, but still not an issue to ignore.
also, this more than duplicates the work of writing and maintaining these scripts. you've got the install scripts twice, plus the selector script.
not to mention the fact that your "suggestion" totally ignore the guys problem: writing a cross-platform install script. zsh is totally non-standard, so that's out. ksh is pretty common, but not totally common, and is installed as different things in different places. there's definatly a place for a standard (you linux guys remember those, don't you?), and, for the time being, bourne shell's it. so either linux gets with the standard program, or it continues to be a pain.
it's not a double standard. it's a choice. the writers of fink and most other software projects make a choice as to what terms they want to license that software to users. fink, and lots of other people, choose to release it open source. others do not.
a double standard would be for some projects to have that choice, and others not to.
further reason why folks might think MAPS is way to restrictive. the less options you have for not using MAPS, the more restrictive on you it becomes.
MAPS is opt-in, but only on a mail-server level. for users who get mail from an IPS's mail server, they often have no say in the decision. what's more, MAPS (i believe) only works on site-level blocking, nothing with finer granularity. for example, on sites i run, i block mail from *opt-out*@*. MAPS is also somewhat heavy-handed about how they decide to add people, and what it takes to get off the list.
overall, though, i don't really see the argument for MAPS as a rights violation, the way EFF is talking. i choose not to go that route because i think i and my users want more fine grain controls over who we don't want to talk with.
funny, but isn't NaN where computers divide by zero?
your comparison is (intentionaly, i suspect) unfair becuase you're comparing the fact that a small area of the phone network went down to the fact that the Internet overall continued to work. it's a stupid comparison.
your "analysys" is also ignorant of the physical network underlying both the phone network and the Internet. the phone network is built on top of a series of actual, physical links. the Internet is built partly on top of this, partly with additional links. lost of my friends in Manhattan lost IP connectivity because - suprise! - their phone service, which they use for IP connectivity, wasn't working.
sure, my IP connections to California were unaffected by the WTC going down. but i made phone calls from 15 min. outside the city, that day, all over the country, with no problem (other than into Manhattan).
for all that talk of redundant routing on the internet, how many lines do most people have protruding from the back of their box? 1. how many ISPs do most people have? 1. how many upstream providers do most of those ISPs have? 1. all single points of failure.
ask someone you know familiar with the net what would happen if someone took out MAE-East or MAE-West, among a handfull of other very important Internet sites. it'd be much easier, in fact, to make the Internet useless by taking out ten or so buildings than to take out the phone network by taking down 50.
uh, yeah, but it's also why my phone crashes so much less often (uh, never?) than my PC (rarely, 'cuase i run good stuff), and why my telephone company won't let me connect so much less often (once in my lifetime, while the line up my street was being worked on) than my ISP (once every month or two).
good observation, and good question. while you're correct that Crusoe and IA64 are the only two commercial VLIW architectures (that i've seen, anyway), the concept is not new. VLIW's been around for many years, and has been tried by lots of chip manufacturers in research. i believe some non-mainstream chip manufacturers (like pre-split AT&T) have tried it commercially in the past, as well. the results are always the same: poor performance.
Intel's been very careful (initially anyway; they may have loosened up a bit) to avoid using the term VLIW in reference to their IA64 chip, for exactly this reason. they talk about EPIC as the design architecture, but EPIC's basically one impelementation of VLIW.
Intel and their chips performance will both be further hit by the fact that VLIW - including EPIC - is notoriously hard to write compilers for, particularly ones that perform even reasonably. i've heard very little about AMD's 64-bit architecture, but if they're avoiding the VLIW mess, i'm quite hopeful that they'll blow past Intel's performance there.
of course, none of this really proves the VLIW concept is flawed, but the implementations sure all have been. and it does prove that VLIW - even in its EPIC form - isn't the magic bullet Intel's hoping it is.
first off, the current version of the definity software runs on Unixware 2, not Unixware 1. it's a minor improvement, i ran it while it was towards the end of beta. the developer types were looking towards UW 7 already, but who knows what's up with that with the current state of Lucent and here derivatives.
also, i've run both UW1 and UW2 based Audix systems, and neither one relied on a windows program. i didn't even know such a thing existed. i did all my administration via xterms or on console, using the pre-bundled tool set. nothing special going on.
and that kinda makes me very uninterested in your Linux work. i mean, if all i'm using now is xterm, why would i want any special program, regardless of platform?
and if you consider larger than 64K "larger projects", you're working in the wrong decade. it's quite easy to blow past that limit while neither trying very hard nor doing anything particularly odd.
and for someone denouncing posts as trolls, you aparently don't read very well. i explicitly stated that the MetroWorks folks probably have their act together, and i've seen their compilers (for other architectures) do quite nicely. my complaint - as i said - was that they felt tying all their potential developers to that compiler was sufficient.
how recently have you priced apple hardware? their price/performance ratio is actually quite competative, and has been for about two years now. sorry, buddy.
to clear up some confusion, the fact the the number before the "Mhz" on the chip description tends to be lower with Macs isn't relavant. once you move accross chip architectures, those numbers are next to meaningless. do you really think your 100Mhz 486 and my 100 Mhz MIPS chip perform comprably? sorry, not even close. the PowerPC chip design is much cleaner, faster, and more efficient than the x86 design, especially the P-III grade design. hz for hz, a PPC chip'll beat an x86 chip any time.
to be fair, even if you take a more "enlightened" view of the performance, apple's price/performance ratio isn't quite as good as many x86 desktop models (although it's close, and better than many of the big-name boxes). but there's much more to buying a computer than that. Apple hardware is actually engineered, in ways that most other PCs certainly don't seem to be. the hardware is well-designed and well-built. on desktop systems, i've not seen anything in the x86 market that comes close, and that's probably because of some fundamental facts of that market. the x86 world does a bit better with laptops, but Apple's still got them beat there, too. add to that the usability issues, battery life, screen size and clarity, and general slickness, and Apple comes out well worth the extra ~$100 (if that) they're behind in a strict price/performance comparison.
the current iBook line starts at $1300, list. nothing in the x86 laptop world comes close for under $1500. the iMac starts at $1000, roughly comparable to many of the $900-1100 low-end boxes being offered by the big x86 producers.
and, of cource, there's the OS to consider, which is kinda what this is about. in my book, a box shipping with OS X is a huge win over a box shipping with more M$ crap. and i'm talking for people like my mom, for whom linux (or any other non-OS X unix) isn't even a remote posability.
i really liked be. i was a registered developer back when that gave you a four-didgit number (3860). i bought a dual-133 BeBox, and love it. they did a number of things right, particularly in the areas of user interface and multimedia, and even did a reasonably good job in partnering relationships. i was quite happy with their developer support (i've twice gotten email from JLG himself). but they also did a number of things wrong. here's what i think:
first, on the technical front, Be was an improvement, but not the revolution they liked to pretend to be. they had an incrementally better UI, kernel, and networking than Mac or Win32. but they were not revolutionary, nor were their approaches to these areas truely innovative. the GUI and file sharing models were examples of existing models done better.
second, there's C++. regardless of what you think of it as an applications language, it's just not a good choice for kernels, particularly ones with real-time or low-latency requirements. and it's not a good idea to make it the only real choice for applications development, either.
third was development environment. probably because of their history at Apple, the Be folks were quite happy giving Metroworks control of their development environment. which meant no (unrestricted) free compiler (at least on PPC chips). the wouldn't help other compler efforts (like gcc) with their object format. and while Metroworks may be good, they're just not the toolset many developers are most productive (or comfortable) with.
they also wasted much of their effort on things that didn't matter. there's plenty of kernels suitable for real-time or low-latency operation. many of these are available either open source or under reasonable licensing terms. Be would have been better served taking the OS X approach - build on somebody else's work, concentrating on what you're really good at (in Be's case, the multimedia aspect).
but i think what really killed Be was the path of least resistance. i first fell in love with the company for the hardware. a reasonably inexpensive dual-proc box with great numbers, and software that could use it. wow. okay, maybe they were a bit late there, but there's always been at least a niche market for high-end workstations. then they canned the hardware to concentrate on the software. which could've been okay, if they had reason to believe Apple would be more co-operative. they didn't; it was a gamble. and they were wrong. Apple closed up just as the hardware started getting really interesting again, and Be was stuck. then they moved their focus to intel hardware - a much broader market, but with correspondingly wider demands. it's much easier to support every Mac sound card than to support every PC sound card. then, when that didn't even go as well as they'd hoped, they moved on to the IA market, with much less defined power structures and less entrenched players (read: no Micro$oft monopoly).
at each stage, Be chose to find an easier path rather than finding the path right for what they had. like it or not, an OS originally designed for media content creation is not ideally suited to IAs. nor should one expect it to be.
anyway, if anyone's got any suggestions on what to do with my BeBox, let me know (don't even talk to me about Linux PPC).
that's not quite acurate. first of all, remember that loads of people still have per-minute charges on net connections, either through their provider, like AOL, or via telephone charges. that's a direct cost. also, keep in mind that this method is the only real option in many parts of the world outside the U.S. - again, a very real, direct cost. another direct cost - although a much smaller one - is the storage of that email on my system. this is generally neglegable and recoverable, but i've worked in environments where everything is backed up permenantly to WORM media. that's a direct, tangible cost in terms of a used-up resource.
also, in cases where the cost of spam isn't directly on my shoulders - such as when my ISP bears it by way of providing the bandwidth or storage, don't think for a second they're not passing that cost on to the end user.
for even less direct costs, there's the issue of my time.
so no, i'm afraid pager spam isn't the only spam with direct end-user costs; it's just more easialy aparent.
this isn't about them all uniting in peace and harmony. standars processes are often frought with political issues (both among countries and companies). but often what's in their best interests is in our best interests, too. sometimes.
uh, in what sense is QNX a Linux clone? i think maybe you're a little Linux-happy here. QNX is arguably a Unix clone, in the same some of the same ways that Linux is, but i've seen no evidence of QNX being a Linux clone. indeed, it's real-time, embeded nature targets very different things than Linux does, with very different priorities.
oh, and many of the important standards for the Internet or modern computing were contributed largely to by major companies. it's not so much the who's involved that's often problematic (although it certainly can be), but more often the nature of the process that's broken, resulting in broken standards.
hate to say it, buddy, but are you serious? first of all, these comparisons are problematic and dificult enough when compairng two OSs, yet you want them all compared? how do you deal with the fact that many have very different models for many things? second, two words: Installed Base. you may love Linux or FreeBSD or BeOS, but would these really find a place in a comparison of "all major OSes"? There's still way more Mac boxes on people's desks than LInux boxes. and that's to say nothing of FreeBSD or BeOS (which Be doesn't even market any more). what does "major" mean in your proposed comparison? oh, and these comparisons tend to be targeted at non-techies. do you really think Linux or FreeBSD is going to hold much weight agains MacOS X for these people? in terms of things like GUI quality or adding new hardware?
i think it's kinda funny that MacOS X will almost immediatly surpas Linux - and shortly thereafter all other Unix-oid systems combined - in finally bringing Unix to the desktop. good fer them.
but this is a bigger trend, isn't it? all the *sh Unix shells are basicaly retreads and mods of the bourne shell (even csh was written with it in mind), without fixing the fundamental problems. i think this is quite similar to the ever-increasing number of Linux distributions basicaly being retreads of Unix, but again without fixing any of the fundamental problems. rc, as you pointed out, was written for plan 9, a system written from the ground up, keeping what's good in Unix, but fixing the fundamental problems. when you ask:you could just as well s/zsh and bash/Linux and Unix/ and be asking about plan 9. well, if nothing else, it means i don't have to use crap. it provides positive alternatives. some people need crutches. some people think X is as good as window systems get. some people don't see problems with ttys and ioctls. and, sad as it is, some people like having command completion in their shells, or command history, or two (!) editors (good lord when will it end...). i've seen shells with half of
no, that's the point. the recording industry wants money from every production, regardless of whether they own the copyright or not. the want to be able to keep the number of producers small - that's the only way they can force premium prices out of the market.
alright, i need to find that article...
no, this is exactly the wrong answer!
/.), but i can't find it right now...
your arguement is based on a hugely faulty assumption, and one the recording industry is trying very hard to propagate: that they own all the copyrights. let's say i produce a CD. i wrote the music, i ran the recording equipment, i mixed it... everything. it's all mine. the recording industry still wants money from it - they want to be able to restrict who can produce, or profit from every production. but i should be able to do what i want with that recording - including making mp3s of my tracks and distributing them anywhere i want, without RIAA, or anyone else, getting a cent. i should be able to make mp3s, plop them on Napster or Gnutella or whatever, and encourage everyone to take them, without paying me or anyone else, if that's what i want. the RIAA should not be able to restrict this, nor should anyone else.
your argument also ignores the "fair use" realm of copyright law. if i have a Rio, i should be able to (freely) encode mp3s for my own enjoyment, if i've already bought the CD. this is exactly the same as burning copies of my CDs so i don't have to have one copy for work, one for home, and one for my car.
oh, and for the record, this is already practiced in related areas. lots of digital recording devices, like MiniDisc players, either only provide analog in or only provide analog out - the prohibit you from making full-quality digital reproductions. regardless of the copyright status. it's an institutionalized version of exactly what you're suggesting, and all it does is exactly what the big corps want: restrict who can produce.
there was a really good article i read on this (maybe even on
first of all, the FBI'd have to be pretty damn close to monitor these things given the distances involved. but more to the point, this is just transport medium. what you put over it is up to you. as, for that mater, is whether to even use it or not. if you're uncomfortable with having your hard drive contents travel raw over the air, encrypt them. if the latency increase bothers you (which would likely be quite small, given good techniques), than just don't use the technology. the availability of this technology doesn't automatically make things less secure for you.
FUD, all around.
first of all, "proof" in this context is a bit useless. what's it mean to be provably secure? most cryptographers agree quantum computing will make pretty much everything we've got today a waste of time (for the one trying to protect the data). heck, we even know how to do that, even if nobody's managed to do it yet...
even beyond that, this concept is a reach at best. most modern encryption techniques depend on factoring certain kinds of numbers, or other similarly time-intesive operations. they all rely on nobody being able to find a shortcut to do the math. by your arguement, no encryption method is sufficiently secure: just because nobody's found such a shortcut yet doesn't mean they won't. but it's a good enough bet for me, and loads of other people who think cryptography is important.
and even were it true that PK systems had a greater risk, your conclusion that they're therefore not worth it does not follow. PK systems have a number of other benefits beyond the strenght of their encryption, such as being able to encrypt to various distinct recipients who share no knowledge other than what you give them, being able to sign and/or encrypt data seperatly, the ability to have a repository or infrastructure for PK discovery... the list goes on. these attributes definatly make PK systems worth consideration in any "serious computing environment" in which data security is important.