You like CDE on Sun? The $4000 UltraSparcs (266 mHz, I think) we have here on campus display graphics MUCH slower than my PII-350 with Linux, which was $1000 in the same era. CDE frequently locks up on its fancy splash screen (this is Solaris 8, too), so many of us just use failsafe logins now. The Display PostScript seems like such overkill for the graphics that these things display: mostly just windows/web pages or OpenGL graphics (which aren't exactly postscript material). I just don't see the benefit to relying on it (I've written plenty of postscript and I know how odd, but interesting it is). --JRZ
The "Man and Machine" store cites lab use as one of the primary reasons why you might want waterproof/chemicalproof keyboards and mice. But, really, if you're working in a lab where you routinely spill chemicals all over the place, don't you have bigger issues to worry about than what kind of keyboard you have?
Man, people get DAMN religious about this one. I totally support back-end components, because they increase the readability/maintainability of code and enable code re-use. However, I CONSTANTLY hear about people taking this to unnecessary extremes.
For instance, I really enjoy working with JSPs. The "purists" complain that they encourage you to put code in HTML, but, damn it, there are times when you need code in HTML, such as loops, if/else logic, and tiny utility functions. Forcing all of these into the back-end components ends up putting too much presentation into the logic, so the components lose their generality.
If you constrain your Java-writing to the syntax you learned in the first week of "Teach Yourself Java in 21 Days" (i.e., don't do any serious coding, and don't import packages other than your custom components and java.util in most cases), you'll be in good shape. Why use a separate macro system (as I used to do before I switched to JSPs), which will simply force you to learn another syntax? Just don't go making frickin' SQL queries from your JSPs, either!
By the way, I do recommend Resin from caucho.com if you're interested in JSPs. It handles some cool things, like database connection pooling (very important!) for you and, coolest of all, it supports JavaScript as a for JSP development. Just as serious Java coders shouldn't have to go learn some other macro syntax to code pages, web designers should be able to use a language familiar to them, which, in almost all cases, is JavaScript.
--JRZ
Re:Non-x86 Linux users in the dust (of course!)
on
IBM JDK 1.3 For Linux
·
· Score: 3
IBM wants to sell more hardware. IBM doesn't sell Sparc or Alpha hardware, so those would clearly be silly ports (they'd just help Sun and Compaq, who are direct competitors). As for PowerPC, maybe IBM would consider a port if they saw a substantial number of serious, enterprise customers buying PPC hardware to run Linux. But, frankly, very few people are doing that right now. It is NOT just an issue of "grab a PPC and compile", because much of a good JVM's performance comes from a good JIT. JITs are, of course, highly architecture-specific. And, as for their failure to distribute source, remember that they license code from Sun (it's not a true "clean room" JVM). Thus, at best, they could consider a SCSL license. Remember how popular the SCSL was? But then Sun (public enemy #1 for IBM right now) would get the benefit of all their JVM enhancements (and IBM has PLENTY). Doesn't sound like a compelling business case. --JRZ
I'd let each module provide one line of valid sponsorship information. No pure "ads" (you couldn't, say, advertise for a product or make an offer to sell something), but mention of sponsoring companies/individuals seems completely fair. If we keep it down to one or two lines, it won't get out of hand (how often do you load/unload modules anyways?).
Public television and radio, for instance, both pride themselves on being ad-free. But you always hear the names of their sponsors mentioned in a reasonably dignified tagline. As long as we don't end up with periods where our software stops working for an hour to encourage us to phone in our pledges. . .
Actually, that may be a valid analogy. Does free software have something to learn from public television? Since federal support for PBS has dwindled in recent years, the organization has come to rely more on corporate donations (which they always had) and merchandising (remember, these folks invented Sesame Street). I think this is different from, but possibly compatible with, the common open source model in which a company hires developers to work on a piece of free software as full time employees (such as Red Hat does with many projects or IBM does with Apache). Besides ReiserFS, I know that the Linux Scalability project has a real sponsorship model, but I'm wondering if anybody else does. --JRZ
If you belirve in distributed computation. . .
on
Solving Chess?
·
· Score: 2
then I think you would have to be against the idea that chess is solveable, at least for a win. We've had a few hundred years of powerful distributed nodes (grandmasters, teachers, and prodigies, not to mention recent, silicon-based additions) hacking away at the problem with pretty good algorithms (check on Amazon.com for a good chess book) without even a hint of success.
Besides the two very different development models, what do you see as the primary differences between UnixWare and Linux on a technical level? What do you see as the greatest assets and weaknesses of each?
Since "Unix" is a registered trademark of The Open Group, couldn't X/Open then sue the domain holder for domain squatting? It seems like a pretty straightfoward case, since the TM preceeds the registration of the name.
--JRZ
I thought it was a pretty intelligent move on Microsoft's part to incorporate Media Player (which is actually pretty good on Windows) into PocketPC. After all, that's a great technology for consumers that Palm can't easily duplicate. But then I stopped and thought: even the heaviest PDAs have at most 32 megs of memory, much of which will already be consumed by the OS (especially for a Windows-based one), applications, and real work. So that leave, what, 16 megs in which to store your movies? This will be a key feature, say, two years down the line when technologies like the memory stick expand their storage capabilities and gain widespread acceptance. Until then, just a novelty. . .
The production company owns the characters in virtually all of these arrangements. That's why you can NOT go and produce a "Simpsons" movie without Fox's permission, and you can't write (duh) a Star Trek movie without Paramount's permission. Same goes for a video game, etc.
Linux stocks are disproportionately down, because they were disproportionately UP to begin with. Come on, no serious investor ever believed that VA Linux actually deserved a market cap of $8 billion, or that Red Hat should be worth more than Apple. Traders were buying on momentum, hoping to ride out the move to its real peak. The danger of this momentum-based pricing is its incredible volatility, and we've definitely seen that in the past few months. Once Linux stocks hit a true fair value (which, in my opinion, they are approaching, but they still haven't hit), they can start to fluctuate based on real changes in the market, real earnings reports, and other "real world" phenomena. That will be a great development for the Linux business community, because it'll prompt these companies to think in terms of real, sustainable business plans, rather than making blind, trendy acquisitions (ahem, Andover!). Red Hat and VA need to figure out how to build serious, profitable businesses to guarantee that they won't be a couple of flashes in the pan. As long as the market was rewarding them based solely on hype, that was never going to happen. So, as a Linux user, I'm glad to see the stocks fall to real values today, rather than seeing them fall into bankruptcy a few years down the line. --JEZ
that the danger wasn't a signal conflict, but rather the fact that games tend (or at least tended in the 1980s) to have more stationary images than regular TV programs. Projection TVs have a risk of "burn-in" like older monitors, so putting a game on pause for a while, for example, might leave you with a permanent image of Mario's face etched into your screen. 'Course, that was in the 80s, and I'm not sure if the problem still exists.
>Just likeGuns and the 4th Ammendment! Shoot >someone and go to jail...but feel free to own a >gun.
Hmm.. interesting. Are you saying that because the fourth Ammendment protects us from unreasonable search and seizure, we should feel free to own a gun, because the government can't come looking for it?
I'm not sure that's really what the founding fathers had in mind with that one. . .
Hmm... well, I'm not sure we've gotta give them credit, because their business model seems pretty weak. I mean, these guys are still pouring money into not just Tru64 (a not-particularly popular Unix), but also OpenVMS?!? Come on guys, you're willing to drop support for WinNT on Alpha, but not your frickin' proprietary minicomputer OS? No one can really understand their strategy for the chip, with on-again, off-again support for Linux. Read interviews with their execs, who really haven't seen all that much demand for Linux on Alpha. It just doesn't make sense for servers on a price/performance level, so it's relegated to the (important, but unpredictable) scientific market. I guess a lot of this comes down to whether or not McKinley lives up to expectations. --JRZ
Well, I'm one of the many who has worked with both Qt and MFC, and, like virtually everybody in that boat, I vastly prefer Qt. All the reasons have been said before, so I don't want to beat them to death. I did, however, just see a lecture by Bjarne Stroustrup in which he was talking about good vs. bad object oriented design. He used MFC as his example of how to write a really, really bad OO library. I don't really know anybody who would disagree. Really, Qt was invented for people like the author of this question: excellent, fast, cross-platform C++ GUIs. --JRZ
But use of Altivec, despite what Apple and Motorola will tell you, is very limited. And it's just now becoming experimental in LinuxPPC. You really need a compiler that knows Altivec inside and out in order to get a real advantage for numerical code, and gcc simply will not fall into that category in the forseeable future. --JRZ
Well, I'd really like to vote for a dual P-III Xeon at 1 GHz with 1MB of L2 cache per chip, but Intel has been lagging behind with their newest Xeons. They used to give a 15% boost over a comparable non-Xeon, due heavily to their much larger cache, but Intel has had a hard time selling them because they cost SOOO much more than a comparable P-III standard, and the performance gap between the two models seems to be closing. Cache size (and speed) is a lot more important in these calculation-intensive benchmarks than it is in other uses, so it's really something you should look out for. It's also one of many small minusses that really make the dual celeron suggestion a less-than-optimal configuration for real scientific use. Today's best high-performance compilers do a reasonably good job of exploiting special P-III instructions and optimizing to squeeze the right data into the cache. Although the celeron will soon have SSE, it will still be configured with 128k of L2 cache, I believe (though I could be wrong. Anybody?). The real killer to the celeron idea is that you do still have to hit your RAM pretty often, and Rambus or DDR running on a fast bus can really, really help you here. So, if it comes down to the Athlon or the P-III (non-Xeon), I'd still have to go with the P-III. The biggest advantage is the ability to use multiple processors, as number-crunching code can REALLY benefit from SMP. AMD has been promising SMP Athlons for ages, but they're still basically vaporware. Another factor is the availability of (extremely pricey) Rambus RAM, while DDR is just starting to be accepted. Finally, Intel puts out some pretty fast compilers, while a lot of compiler developers fail to optimize for the Athlon as much as they could. Within the next year, however, we should see faster RAM for AMD chips, SMP Athlon boards, better compiler support (now that people no longer think of AMD as just a low-end provider), and a full-speed L2 cache on the Athlon. Then the chip's FPU can really shine. This is all assuming that we're talking about scientific crunching on x86 PCs. If you can go for an Alpha, you really should. Check out www.spec.org for benchmarks. Yes, we're all wary of benchmarks, but when a chip routinely beats its competition by a factor of 2 or more in a very respected, industry-standard benchmark, you have to assume that there really is a difference. I have a lot of hope for Intel's second-generation of IA-64 chips, though. They're doing some really interesting things with compiler/architecture design that could blow away the competition. --JRZ
Check out interbase.com or interbase.org. Interbase has been in use in enterprise environments for something like 15 years. It has very advanced crash recovery features and replication throught a commercial plug-in. Version 6.0 is under the MPL and in beta right now for Solaris, Windows, and Linux. No, I don't work for them, I just sound like that. --JRZ
Hmm... I understand your point about introducing a programming mindset, which I think is an important general skill (like learning liberal arts). But I think that we geeks can often forget how computer-illiterate most people actually are. Even in college (Princeton) most people have a fairly limited ability to get any real work done with, say, a good spreadsheet. These students will some day be typical, white-collar workers: management consultants, ad/marketing folks, etc. They have a real and serious need to develop these skills, but they will likely never have any need for C in their entire lives. I think the more important thing, though, is very much like what you were saying: it takes a long time to get good at programming. People who only take one computer course in their lives will not learn a useful amount of programming, so I think we would do better to focus on skills that they can productively learn in one course. --JRZ
I'm assuming this is intro-level, in which case, as much as I love Unix and Linux, I think they would be a pretty poor choice. People who will probably grow up to be white-collar workers need to learn real word processing, presentation, spreadsheet, and database skills much more than they need to know how to switch modes in vi. Basic computer concepts would also be important: how does the internet work? What is HTML? What is a microprocessor?
I would encourage cross-disciplinary projects along the lines of the "choose your own topic" possibilities that others suggested. Have people prepare a web presentation with detailed charts and graphics about the growth of the internet or the changes in the use of computers in the workplace. If they are restricted to choose good, on-topic projects, everybody would learn from them.
So, if I had 12 segments (weeks or whatever), I'd do:
Brief history of computing
Components of a PC
Spreadsheets/Charts
Presentations
Databases (Access/Paradox)
Networking basics (how file sharing works, a little bit about ethernet, using FTP)
How the internet works (what's a server? where do these pages come from? What does a browser do?)
HTML (nothing too fancy)
More HTML, basic graphics (paint shop pro?)
Security issues
Social issues in computing
Final projects/presenatations due
It's a big help if you can emphasize hands-on learning, and that's part of what's so great about computer classes. Topics (like intro to networking or social issues) that don't lend themselves well to hands on work provide a great opportunity for students to hone their charts/presentations/HTML skills by using them to format simple research projects. This is more of a plan for a full-year high school class or a one-semester college class, I guess, now that I think back on how easy it is to waste time in high school classes.
If people have experience with one version of Linux, and it's a bad experience, are they likely to go run out and buy a different distribution to see if it works better? Doubtful. It's much more likely that they'll conclude that "Linux sux" and go back to their familiar NT, Unix, or NetWare environments. That's one reason why it's important to see strong collaboration and "mutual idea stealing" between the distributions so that ALL the major player get better: they all have an impact on Linux's public image. --JRZ
I noticed that Bero was posting a fair amount here, so I wondered if he, or anybody else, could answer a couple of quick questions. When will Red Hat include a general-purpose security tool or hardening script? In particular, I'm thinking of Bastille Linux, which was designed specifically for RH6.0 and 6.1. And when I saw "include" I don't mean "stick it on the CD in between XEyes and an ancient version of GNUChess, I mean, actually making users aware of it and even incorporating it into a post-install stage. Around here, Linux has gotten a really bad reputation for security, becuase RH6 had a fair number of holes and admins didn't bother to plug them. One of the biggest differences between a Linux distribution and a commercial Unix distribution is that most of the Unices ship with very, very, very little software (how the hell do they still take up so many CDs without a frickin' copy of bash?!?). However, this does put an extra responsibility on Linux companies to provide a centralized set of tools to remove, shut down, or otherwise patch included utilities that might be hazardous to the system. Also, when is Red Hat going to make it easier and more foolproof to install necessary fixes? I think the priority FTP access is a nice start, and a good way to add value for your serious customers. But (and I haven't used Red Hat since 6.0, please correct me where I'm wrong) do you have a tool to automatically download secure updates when they become available? And are registered customers automatically notified by email of potential security holes or show-stopping bugs, along with steps to correct them? A lot of Linux systems don't have full-time administrators who can afford to read security sites every day, but that's the kind of service that we all want to pay a Linux distributor to do for us. Thanks a lot, and I wish you guys well with 6.2! --JRZ
I think this is an extremely smart move, especially considering the large number of current ASP users/developers. It's just not realistic to ask a small company to retrain all of its developers from VB/InterDev/ASP to PHP. The costs of doing that would far outweigh the return on investment for switching to Linux in most cases. If I were Cobalt, I'd start bundling two more things: a high performance JSP/Servlet implementation and management interface (Resin + a web front end), and a serious database. MySQL is nice if you're writing code from the ground up that can work around its lack of SQL standards compliance and other features, but it can be difficult to port code from other DBs to it. Once InterBase 6.0 is out for real, Cobalt will have a full presentation(ASP/JSP) and backend (InterBase) solution with near-zero administration (IB was made for exactly this sort of use). I think that sounds like a pretty damn cool solution-in-a-box, much more sophisticated and maintainable than the current server appliances. --JRZ
>Too many employers brush off the recent grads who >didn't choose to work at low or no-pay >"internships" *ahem!*slavery*ahem!*
Hmm... Don't know what internships you were looking at. After my freshman year I made $18 and hour programming and gained a HUGE amount of real-world experience that made me a MUCH better programmer. Most CS students I know had similar (and often higher-paying/more-productive!) experiences. If I were an employer looking at recent grads, I would definitely look for strong internship experience, because there is, as has been discussed a lot on this board, a big difference between academic and hands-on experience (though both are valuable). --JRZ
Wow, I haven't touched a role-playing game in years, and I had no idea how much the business had changed until I read this article and did some investigating. Basically, following the huge success of the Magic and Pokemon card games and a general decline in standard RPG sales, Wizards of the Coast dwarfed TSR, SJG, and the other RPG companies. Wizards of the Coast then acquired TSR (which I always thought of as the number 1 gaming powerhouse) somewhere around 1998. They later acquired the chain of "The Game Keeper" stores, after opening a few of their own retail outlets. Finally, Hasbro acquired Wizards in 1999, but they're giving them pretty strong independence. Pretty crazy stuff, no? Of course, the better system to open source would've been GURPS from SJG, which is already designed to work for any era, genre, etc. GURPS, though not without its flaws, was just amazing because SJG put out an unbelievably cool line of expansions/world books to hit genres most people had never thought of (e.g. GURPS Russia, GURPS Vodoo), and they even did games based on popular books (which weren't as high quality, from my experience), with a persistent rumor that Orson Scott Card was collaborating on an Alvin Maker series (I swear I read an excerpt from its beta version years ago, but I can't find any info on what happened to it, anybody know?). Wizards' point about the network effects and the general prevalence of D&D players, however, is well taken. I think that most other game companies would probably avoid supporting it, because it would cannibalize their own sales (think Sun/Linux), but smaller game companies could do pretty well by putting out adventures, expansions, and so on. --JRZ
Slashdot Mirror
You like CDE on Sun? The $4000 UltraSparcs (266 mHz, I think) we have here on campus display graphics MUCH slower than my PII-350 with Linux, which was $1000 in the same era. CDE frequently locks up on its fancy splash screen (this is Solaris 8, too), so many of us just use failsafe logins now. The Display PostScript seems like such overkill for the graphics that these things display: mostly just windows/web pages or OpenGL graphics (which aren't exactly postscript material). I just don't see the benefit to relying on it (I've written plenty of postscript and I know how odd, but interesting it is).
--JRZ
The "Man and Machine" store cites lab use as one of the primary reasons why you might want waterproof/chemicalproof keyboards and mice. But, really, if you're working in a lab where you routinely spill chemicals all over the place, don't you have bigger issues to worry about than what kind of keyboard you have?
Man, people get DAMN religious about this one. I totally support back-end components, because they increase the readability/maintainability of code and enable code re-use. However, I CONSTANTLY hear about people taking this to unnecessary extremes.
For instance, I really enjoy working with JSPs. The "purists" complain that they encourage you to put code in HTML, but, damn it, there are times when you need code in HTML, such as loops, if/else logic, and tiny utility functions. Forcing all of these into the back-end components ends up putting too much presentation into the logic, so the components lose their generality.
If you constrain your Java-writing to the syntax you learned in the first week of "Teach Yourself Java in 21 Days" (i.e., don't do any serious coding, and don't import packages other than your custom components and java.util in most cases), you'll be in good shape. Why use a separate macro system (as I used to do before I switched to JSPs), which will simply force you to learn another syntax? Just don't go making frickin' SQL queries from your JSPs, either!
By the way, I do recommend Resin from caucho.com if you're interested in JSPs. It handles some cool things, like database connection pooling (very important!) for you and, coolest of all, it supports JavaScript as a for JSP development. Just as serious Java coders shouldn't have to go learn some other macro syntax to code pages, web designers should be able to use a language familiar to them, which, in almost all cases, is JavaScript.
--JRZ
IBM wants to sell more hardware. IBM doesn't sell Sparc or Alpha hardware, so those would clearly be silly ports (they'd just help Sun and Compaq, who are direct competitors).
As for PowerPC, maybe IBM would consider a port if they saw a substantial number of serious, enterprise customers buying PPC hardware to run Linux. But, frankly, very few people are doing that right now. It is NOT just an issue of "grab a PPC and compile", because much of a good JVM's performance comes from a good JIT. JITs are, of course, highly architecture-specific.
And, as for their failure to distribute source, remember that they license code from Sun (it's not a true "clean room" JVM). Thus, at best, they could consider a SCSL license. Remember how popular the SCSL was? But then Sun (public enemy #1 for IBM right now) would get the benefit of all their JVM enhancements (and IBM has PLENTY). Doesn't sound like a compelling business case.
--JRZ
Public television and radio, for instance, both pride themselves on being ad-free. But you always hear the names of their sponsors mentioned in a reasonably dignified tagline. As long as we don't end up with periods where our software stops working for an hour to encourage us to phone in our pledges. . .
Actually, that may be a valid analogy. Does free software have something to learn from public television? Since federal support for PBS has dwindled in recent years, the organization has come to rely more on corporate donations (which they always had) and merchandising (remember, these folks invented Sesame Street). I think this is different from, but possibly compatible with, the common open source model in which a company hires developers to work on a piece of free software as full time employees (such as Red Hat does with many projects or IBM does with Apache). Besides ReiserFS, I know that the Linux Scalability project has a real sponsorship model, but I'm wondering if anybody else does.
--JRZ
then I think you would have to be against the idea that chess is solveable, at least for a win. We've had a few hundred years of powerful distributed nodes (grandmasters, teachers, and prodigies, not to mention recent, silicon-based additions) hacking away at the problem with pretty good algorithms (check on Amazon.com for a good chess book) without even a hint of success.
Besides the two very different development models, what do you see as the primary differences between UnixWare and Linux on a technical level? What do you see as the greatest assets and weaknesses of each?
Since "Unix" is a registered trademark of The Open Group, couldn't X/Open then sue the domain holder for domain squatting? It seems like a pretty straightfoward case, since the TM preceeds the registration of the name.
--JRZ
I thought it was a pretty intelligent move on Microsoft's part to incorporate Media Player (which is actually pretty good on Windows) into PocketPC. After all, that's a great technology for consumers that Palm can't easily duplicate. But then I stopped and thought: even the heaviest PDAs have at most 32 megs of memory, much of which will already be consumed by the OS (especially for a Windows-based one), applications, and real work. So that leave, what, 16 megs in which to store your movies?
This will be a key feature, say, two years down the line when technologies like the memory stick expand their storage capabilities and gain widespread acceptance. Until then, just a novelty. . .
The production company owns the characters in virtually all of these arrangements. That's why you can NOT go and produce a "Simpsons" movie without Fox's permission, and you can't write (duh) a Star Trek movie without Paramount's permission. Same goes for a video game, etc.
Linux stocks are disproportionately down, because they were disproportionately UP to begin with. Come on, no serious investor ever believed that VA Linux actually deserved a market cap of $8 billion, or that Red Hat should be worth more than Apple. Traders were buying on momentum, hoping to ride out the move to its real peak. The danger of this momentum-based pricing is its incredible volatility, and we've definitely seen that in the past few months.
Once Linux stocks hit a true fair value (which, in my opinion, they are approaching, but they still haven't hit), they can start to fluctuate based on real changes in the market, real earnings reports, and other "real world" phenomena. That will be a great development for the Linux business community, because it'll prompt these companies to think in terms of real, sustainable business plans, rather than making blind, trendy acquisitions (ahem, Andover!).
Red Hat and VA need to figure out how to build serious, profitable businesses to guarantee that they won't be a couple of flashes in the pan. As long as the market was rewarding them based solely on hype, that was never going to happen.
So, as a Linux user, I'm glad to see the stocks fall to real values today, rather than seeing them fall into bankruptcy a few years down the line.
--JEZ
that the danger wasn't a signal conflict, but rather the fact that games tend (or at least tended in the 1980s) to have more stationary images than regular TV programs. Projection TVs have a risk of "burn-in" like older monitors, so putting a game on pause for a while, for example, might leave you with a permanent image of Mario's face etched into your screen.
'Course, that was in the 80s, and I'm not sure if the problem still exists.
>Just likeGuns and the 4th Ammendment! Shoot >someone and go to jail...but feel free to own a >gun.
Hmm.. interesting. Are you saying that because the fourth Ammendment protects us from unreasonable search and seizure, we should feel free to own a gun, because the government can't come looking for it?
I'm not sure that's really what the founding fathers had in mind with that one. . .
Hmm... well, I'm not sure we've gotta give them credit, because their business model seems pretty weak. I mean, these guys are still pouring money into not just Tru64 (a not-particularly popular Unix), but also OpenVMS?!? Come on guys, you're willing to drop support for WinNT on Alpha, but not your frickin' proprietary minicomputer OS? No one can really understand their strategy for the chip, with on-again, off-again support for Linux. Read interviews with their execs, who really haven't seen all that much demand for Linux on Alpha. It just doesn't make sense for servers on a price/performance level, so it's relegated to the (important, but unpredictable) scientific market. I guess a lot of this comes down to whether or not McKinley lives up to expectations. --JRZ
Well, I'm one of the many who has worked with both Qt and MFC, and, like virtually everybody in that boat, I vastly prefer Qt. All the reasons have been said before, so I don't want to beat them to death.
I did, however, just see a lecture by Bjarne Stroustrup in which he was talking about good vs. bad object oriented design. He used MFC as his example of how to write a really, really bad OO library. I don't really know anybody who would disagree.
Really, Qt was invented for people like the author of this question: excellent, fast, cross-platform C++ GUIs.
--JRZ
But use of Altivec, despite what Apple and Motorola will tell you, is very limited. And it's just now becoming experimental in LinuxPPC. You really need a compiler that knows Altivec inside and out in order to get a real advantage for numerical code, and gcc simply will not fall into that category in the forseeable future.
--JRZ
Well, I'd really like to vote for a dual P-III Xeon at 1 GHz with 1MB of L2 cache per chip, but Intel has been lagging behind with their newest Xeons. They used to give a 15% boost over a comparable non-Xeon, due heavily to their much larger cache, but Intel has had a hard time selling them because they cost SOOO much more than a comparable P-III standard, and the performance gap between the two models seems to be closing.
Cache size (and speed) is a lot more important in these calculation-intensive benchmarks than it is in other uses, so it's really something you should look out for. It's also one of many small minusses that really make the dual celeron suggestion a less-than-optimal configuration for real scientific use. Today's best high-performance compilers do a reasonably good job of exploiting special P-III instructions and optimizing to squeeze the right data into the cache. Although the celeron will soon have SSE, it will still be configured with 128k of L2 cache, I believe (though I could be wrong. Anybody?). The real killer to the celeron idea is that you do still have to hit your RAM pretty often, and Rambus or DDR running on a fast bus can really, really help you here.
So, if it comes down to the Athlon or the P-III (non-Xeon), I'd still have to go with the P-III. The biggest advantage is the ability to use multiple processors, as number-crunching code can REALLY benefit from SMP. AMD has been promising SMP Athlons for ages, but they're still basically vaporware. Another factor is the availability of (extremely pricey) Rambus RAM, while DDR is just starting to be accepted. Finally, Intel puts out some pretty fast compilers, while a lot of compiler developers fail to optimize for the Athlon as much as they could.
Within the next year, however, we should see faster RAM for AMD chips, SMP Athlon boards, better compiler support (now that people no longer think of AMD as just a low-end provider), and a full-speed L2 cache on the Athlon. Then the chip's FPU can really shine.
This is all assuming that we're talking about scientific crunching on x86 PCs. If you can go for an Alpha, you really should. Check out www.spec.org for benchmarks. Yes, we're all wary of benchmarks, but when a chip routinely beats its competition by a factor of 2 or more in a very respected, industry-standard benchmark, you have to assume that there really is a difference. I have a lot of hope for Intel's second-generation of IA-64 chips, though. They're doing some really interesting things with compiler/architecture design that could blow away the competition.
--JRZ
Check out interbase.com or interbase.org. Interbase has been in use in enterprise environments for something like 15 years. It has very advanced crash recovery features and replication throught a commercial plug-in. Version 6.0 is under the MPL and in beta right now for Solaris, Windows, and Linux. No, I don't work for them, I just sound like that.
--JRZ
Hmm... I understand your point about introducing a programming mindset, which I think is an important general skill (like learning liberal arts). But I think that we geeks can often forget how computer-illiterate most people actually are. Even in college (Princeton) most people have a fairly limited ability to get any real work done with, say, a good spreadsheet. These students will some day be typical, white-collar workers: management consultants, ad/marketing folks, etc. They have a real and serious need to develop these skills, but they will likely never have any need for C in their entire lives.
I think the more important thing, though, is very much like what you were saying: it takes a long time to get good at programming. People who only take one computer course in their lives will not learn a useful amount of programming, so I think we would do better to focus on skills that they can productively learn in one course.
--JRZ
I'm assuming this is intro-level, in which case, as much as I love Unix and Linux, I think they would be a pretty poor choice. People who will probably grow up to be white-collar workers need to learn real word processing, presentation, spreadsheet, and database skills much more than they need to know how to switch modes in vi. Basic computer concepts would also be important: how does the internet work? What is HTML? What is a microprocessor?
I would encourage cross-disciplinary projects along the lines of the "choose your own topic" possibilities that others suggested. Have people prepare a web presentation with detailed charts and graphics about the growth of the internet or the changes in the use of computers in the workplace. If they are restricted to choose good, on-topic projects, everybody would learn from them.
So, if I had 12 segments (weeks or whatever), I'd do:
It's a big help if you can emphasize hands-on learning, and that's part of what's so great about computer classes. Topics (like intro to networking or social issues) that don't lend themselves well to hands on work provide a great opportunity for students to hone their charts/presentations/HTML skills by using them to format simple research projects. This is more of a plan for a full-year high school class or a one-semester college class, I guess, now that I think back on how easy it is to waste time in high school classes.
--JRZ
If people have experience with one version of Linux, and it's a bad experience, are they likely to go run out and buy a different distribution to see if it works better? Doubtful. It's much more likely that they'll conclude that "Linux sux" and go back to their familiar NT, Unix, or NetWare environments. That's one reason why it's important to see strong collaboration and "mutual idea stealing" between the distributions so that ALL the major player get better: they all have an impact on Linux's public image.
--JRZ
I noticed that Bero was posting a fair amount here, so I wondered if he, or anybody else, could answer a couple of quick questions.
When will Red Hat include a general-purpose security tool or hardening script? In particular, I'm thinking of Bastille Linux, which was designed specifically for RH6.0 and 6.1. And when I saw "include" I don't mean "stick it on the CD in between XEyes and an ancient version of GNUChess, I mean, actually making users aware of it and even incorporating it into a post-install stage. Around here, Linux has gotten a really bad reputation for security, becuase RH6 had a fair number of holes and admins didn't bother to plug them.
One of the biggest differences between a Linux distribution and a commercial Unix distribution is that most of the Unices ship with very, very, very little software (how the hell do they still take up so many CDs without a frickin' copy of bash?!?). However, this does put an extra responsibility on Linux companies to provide a centralized set of tools to remove, shut down, or otherwise patch included utilities that might be hazardous to the system.
Also, when is Red Hat going to make it easier and more foolproof to install necessary fixes? I think the priority FTP access is a nice start, and a good way to add value for your serious customers. But (and I haven't used Red Hat since 6.0, please correct me where I'm wrong) do you have a tool to automatically download secure updates when they become available? And are registered customers automatically notified by email of potential security holes or show-stopping bugs, along with steps to correct them? A lot of Linux systems don't have full-time administrators who can afford to read security sites every day, but that's the kind of service that we all want to pay a Linux distributor to do for us.
Thanks a lot, and I wish you guys well with 6.2!
--JRZ
I think this is an extremely smart move, especially considering the large number of current ASP users/developers. It's just not realistic to ask a small company to retrain all of its developers from VB/InterDev/ASP to PHP. The costs of doing that would far outweigh the return on investment for switching to Linux in most cases.
If I were Cobalt, I'd start bundling two more things: a high performance JSP/Servlet implementation and management interface (Resin + a web front end), and a serious database. MySQL is nice if you're writing code from the ground up that can work around its lack of SQL standards compliance and other features, but it can be difficult to port code from other DBs to it. Once InterBase 6.0 is out for real, Cobalt will have a full presentation(ASP/JSP) and backend (InterBase) solution with near-zero administration (IB was made for exactly this sort of use).
I think that sounds like a pretty damn cool solution-in-a-box, much more sophisticated and maintainable than the current server appliances.
--JRZ
>Too many employers brush off the recent grads who
>didn't choose to work at low or no-pay
>"internships" *ahem!*slavery*ahem!*
Hmm... Don't know what internships you were looking at. After my freshman year I made $18 and hour programming and gained a HUGE amount of real-world experience that made me a MUCH better programmer. Most CS students I know had similar (and often higher-paying/more-productive!) experiences. If I were an employer looking at recent grads, I would definitely look for strong internship experience, because there is, as has been discussed a lot on this board, a big difference between academic and hands-on experience (though both are valuable).
--JRZ
Wow, I haven't touched a role-playing game in years, and I had no idea how much the business had changed until I read this article and did some investigating.
Basically, following the huge success of the Magic and Pokemon card games and a general decline in standard RPG sales, Wizards of the Coast dwarfed TSR, SJG, and the other RPG companies. Wizards of the Coast then acquired TSR (which I always thought of as the number 1 gaming powerhouse) somewhere around 1998. They later acquired the chain of "The Game Keeper" stores, after opening a few of their own retail outlets. Finally, Hasbro acquired Wizards in 1999, but they're giving them pretty strong independence. Pretty crazy stuff, no?
Of course, the better system to open source would've been GURPS from SJG, which is already designed to work for any era, genre, etc. GURPS, though not without its flaws, was just amazing because SJG put out an unbelievably cool line of expansions/world books to hit genres most people had never thought of (e.g. GURPS Russia, GURPS Vodoo), and they even did games based on popular books (which weren't as high quality, from my experience), with a persistent rumor that Orson Scott Card was collaborating on an Alvin Maker series (I swear I read an excerpt from its beta version years ago, but I can't find any info on what happened to it, anybody know?).
Wizards' point about the network effects and the general prevalence of D&D players, however, is well taken. I think that most other game companies would probably avoid supporting it, because it would cannibalize their own sales (think Sun/Linux), but smaller game companies could do pretty well by putting out adventures, expansions, and so on.
--JRZ