I agree with both the parent comment: it's not your call it's the publishers. I just wanted to re-emphasize the point made that there is a reason that publishers have a specific "tool chain". Not only are all of your collaborators (tech editors, copy editors, layout, illustrators) already standardized on a set of tools, but they also are going to have an entire suite of standard procedures and technologies built around those tools. Standard art and layout around the specific Word templates they give you, for example.
When I wrote my book, I ended up using StarOffice on Linux for most of it. (This was before OpenOffice.) But I only did so after I verified that the compatibility would work: that I could take their Microsoft Word templates and use them within StarOffice then submit the results back to them without degrading the layout in any way
The same may very well still be true. But don't presume that you'll be able to pick your own tools: that would be like showing up for a job and saying you were going to ignore the tool chain and languages of your employer. That you were going to use.NET even if everyone else on your team had standardized on Java. Not only would it be rude to your team, but it would also be impossible to integrate your end results into the end product.
I still haven't seen any conclusive evidence that Linux on mainframe is a good idea. I'm sure running 30 new mainframes is going to cost less than 4000 aging servers. Just about anything would be less expensive than 4000 aging servers.
But I bet that a small farm of modern medium sized servers running Linux on VMWare would be even less expensive. Or Solaris/Niagara. Why would you want to run an open source operating system, whose major benefits are openness and affordability on the what is literally the most expensive and most proprietary computing platform in the world!
These server consolidation projects are just giant boondoggles spawned because the server sprawl finally got insane. It's an endless cycle:
A. Giant server consolidation project that takes 4000 servers down to 30 servers. B. Department B complains that Department A's application keeps hanging and consuming all of the CPU. They demand their own hardware "for availability reasons". C. Vendor C demands dedicated hardware for licensing/capacity planning/supportability reasons. Rather than constantly bicker with the vendor over supportability they get dedicated hardware. D. Department D complains that the IT department is charging outrageous prices for time sharing on the mainframe. After all a dedicated server only costs $XXX. E. Suddenly there are 4000 servers again. F. IT department spends some insane amount of money on infrastructure to manage the 4000 servers. G. IT department budget gets insanely large trying to manage that much stuff. H. Some CIO gets the idea that all of this money managing servers is ridiculous and we should do a server consolidation project. I. IT department spends an even larger amount of money on the latest super high availability gear and consulting services so that the can run 4000 commodity servers inside a few big servers. All because it will "cost less to maintain". J. Go back to A.
A lot of times consultants/contracts/vendors are going to be using webmail to communicate.
So if you are taking away webmail, you are effectively taking away email for these users. Which, needless to say, won't help their productivity. I once had to go back to my hotel during a workday just to collaborate with some experts within my own organization. After which I came back with a memory stick full of code we had built together offsite. The company wasn't any safer. (Actually they were less so, since the firewall never got to see or inspect my code). And the company was out several billable hours of time that I wasted trying to get the needed information and traveling offsite to get it.
Prevalent Hypothesis:
That there is enough RAM to hold all business objects in your system.
IMO, this hypothesis doesn't hold water for 99% of business applications. Prevalent proposes that even if this hypothesis doesn't hold today, it might soon hold true because of breakthroughs in memory technology. But historically these types of ideas are flawed, as the real world has clearly shown that memory and disk needs will grow even faster than our ability to use those resources.
Sure I can take a 1998 application and run it with breakthrough performance by caching the whole application in memory. But I don't want a 1998 application, I want a 2003/2004 application. Do you think that the entire Slashdot comment database would fit into a couple of gigs of memory? How about the enite customer database for an average enterprise?
Frankly, if my database is so small that it fits into memory then I probably don't have performance as a primary concern anyway. Plus, do I really want to subject my entire database to constant mark and sweep garbage collection if performance is an issue?
I generally have two classes of computer reference books: books I use on a regular basis as a reference and books that I used to learn a topic and thereafter use only occaisionally.
I'm finding Safari really useful for that second category of book. I can use a Safari slot on a Ruby book, read through it over a few weeks to get an understanding of how it compares with what I already know. I can then remove it, putting it back on the Safari "shelf" if I need to use it for reference.
I guess I use Safari a lot like other people would use a traditional library, checking out a book every week or two. But I don't have access to any traditional libraries with the up-to-date technical books that can be found on Safari.
Safari isn't going to mean that I never buy a book again, but it is going to mean that I won't be shelling out as much information on "casual" techical reading.
I understand your desire to teach these conceptual models. I too think that there is too much emphasis on syntax and not enough on good CS theory.
But if this is an introductory course, you can't just start with teaching concepts like design patterns, OOA/D, and relational theory.
First you have to start with basic computing theory: the difference between primary and secondary storage and the difference between machine code, assembly code, byte code, and higher level language code. Then you have to teach the basic concepts of programming: iteration, conditionals, functions, objects, pointers, and references. And the best way to do that is by example, which requires you to teach the basic syntax of a language.
Only after students have a firm mastery of the basic tools can you start to introduce the concepts of good architecture. Without the knowledge of a language to practice their skills with, it would be hard to really grasp the meaning of the theoretical knowledge.
Frankly, if your introductory courses are like my introductory courses were, there are a lot of CS students that still need to be weeded out. There will be some students that can never really understand a pointer, and just want to survive one semester before they change majors. (There may also be some students there because intro to computers is required).
Bottom line: as much as I agree that we need to spend more time on fundamental CS theory, we can't expect to teach the kinds of topics you are talking about to first year undergrads.
While I will be the first to say that thin clients were overhyped and oversold, they still have their place. I use them from time to time and I find them very convenient.
If all your users need is a web browser, email, and StarOffice then thin clients are a much more effective choice of hardware. The downside is that a lot of people need apps that are harder to support: Palm sync, thick client custom apps, IM clients, and so forth.
In cases where a company goes into thin clients with their eyes open about the restrictions, everyone ends up happer. Users because the thin clients "just work", administrators because they get to centralize everything, and management because they end up saving a lot of money and effort.
Snowfox asks: I'm curious; please believe that this isn't a troll: Does GNOME on Sun really matter?
Where are Suns being used as something other than a server? Are there business sectors where Sun workstations are common?
I thought SGI pretty much owned the UNIX workstation market.
Nope. Sun has 76% marketshare for the RISC workstation market. SGI does well in the graphics workstation market, but Sun has the technical workstation space.
Novell's eDirectory is the fastest, most scalable & reliable LDAP directory around, runs on NetWare, Windows, Solaris, Linux, Tru64 Unix and AiX, and comes with some pretty cool LDAP tools.
What crack have you been smoking? Novell's LDAP benchmarks are horrible.
I agree. I've seen many, many organizations where it is a flat out policy not to open ports other than 80/443.
I've always assumed that firewall administrators would soon block non-HTML traffic to eliminate these remote SOAP RPC calls.
That's when I'll make my fortune by patenting the idea of making RPC calls via Steganography. In order to execute a web service, you'll encrypt your SOAP message with gpgp, hide it in a JPG, and post it to a predetermined Ebay auction.
He very carefully laid out the algorithm - I don't have my textbook handy, but it involved elementary mathematical operations on estimated man hours, estimated lines of code, estimated overhead, etc., then at the end -- and I am not making this up -- they multiply the result by a "magic number".
It hit me then that the whole discipline of estimating cost completion is all bullshit. You might as well be estimating with a crystal ball or divining the future with chicken bones. Since I've been working, the best advice I've gotten so far has been "take how long you think it'll take and double it".
Back when I was in middle school my math teacher told me that in order to calculate the area of a circle you had to square the radius and (I am not making this up!) multiply it by a magic number. They even had some hocus-pocus name for the magic number.
It was then that I new the entire field of mathematics had been invented by a bunch of wackos, and that my method was much better. I guess how large I think the area is and then double it. Works for me.
All equations with constants are obviously flawed.
The www.MozillaQuest.com guy is an idiot. He's poked his head up before, and if you take more than a casual look at his site it's pretty clear that he has no idea what he's talking about. Factual errors, spelling errors, bad design, bad writing style, it's all there.
The MozillaQuestQuest
website linked by the previous poster is hysterical after you have explored the MozillaQuestQuest site for a bit.
The 0.9.3 Mozilla build is great. I've started to switch back from Konqueror. I'll miss the favicon's in the title bar and bookmarks, and the ability to enable cookies and JavaScript on a per-site basis. But Mozilla's JavaScript engine is better, its rendering engine is better, and its fonts seem better behaved.
So the whole debate about "1.0" does not interest me. I still want to see progress for Mozilla, but what number they slap on the release is largely irrelevant.
As a Nescape employee, I can't help but ask why Netscape Directory Server wasn't included in these tests? Since Netscape Directory Server has > than 70% market share in the LDAP market, I don't understand how it wouldn't included in a major benchmark.
I don't know the particulars of these benchmarks, but Netscape Directory Server has been benchmarked at speeds almost an order of magnitude higher. Of course, I don't know if that's comparing apples to apples. But I'd like to know!
I always like to check all of the sites that advertise on the superbowl and see which ones had enough forethought to actually build a site that can withstand that type of traffic. If I remember correctly, HotJobs had to apologize to its users last year.
This year the "shot yourself in the foot award" would seem to go to KForce.
First of all, KForce's site didn't go up until today. Given how much extra publicity these sites get in the week before the superbowl, it was a waste of the beneficial side effects of adverising a dot com company on the superbowl.
Second, the site was in yo-yo mode for most of the game. I got the default page for a Domino server a couple of times when accessing KForce's site. Ooops! And it was very slow even when it worked correctly.
Deduct extra points because their home page was bloated and filled with annoying Java and JavaScript. Haven't people learned to make their home pages lightweight yet? Death to scrolling text Applets.
Deduct additional points for running Lotus Domino (yuck) on NT (yuck again). No wonder they are having problems.
A co-worker of mine and I were having a friendly and laid-back discussion about the virtues of restrictive languages (especially Java) versus laissez-faire languages (especially Perl). I was arguing for the more restrictive languages and my friend for Perl. My arguments were largely based on the same maintenance arguments that you make in your post.
Not that you can't write easily maintainable Perl or poorly maintainable Java, it's just that the philosophies of the languages are different. Larry Wall will be the first to tell you that he designed Perl to build quick and dirty programs. He didn't want the language to get in your way of getting something done. (This is not to say that Perl hasn't since developed into a language capable of developing large applications, just that it was designed for a different purpose.
The classic example in my mind is that you can have Perl take an action on a "default" variable. The statement chomp; drives me nuts. Sure it's convenient to not have to specify what you are chomping. But if you put enough of these kinds of statements in a row it quickly becomes hard to tell which variable is being acted upon.
It's perfectly easy to know what is going on when you write the program. But six months later when someone is trying to fix a bug or trying to expand the functionality it can become maddening.
This not to say that I don't use Perl. I think that Perl is great. But I use it as a scripting tool not as an application building tool. For me, it's a great way to get short tasks done. My rule of thumb is that if it take more than two screenfuls of code you should think twice before using Perl. Sometimes I'll break the rule. But when I hit that third screen I'll stop myself and decide if a Java application (or Servlet) might be a better choice.
5x as many moderators could overload gd moderating
on
Moderation Ideas
·
· Score: 1
One of the reasons that I think that Slashdot moderation works so well is that each moderator called upon to do it so infrequently. This makes it a responsibility, like voting.
For example, I usually set my moderation filter pretty high unless I'm really interested in a subject and have the time to sort through several dozen comments. But when I get tagged to moderate I switch over to a 0 filter, and spend a little more time reading every article to watch for anything worth moderating.
If I were to be a moderator every day or two, I wouldn't have the time or inclination to do this. Especially if when I did find something that was worth moderating there would be any 80% chance that I couldn't do anything about it. I'd probably just surf around at my regular filter level and if I happened to spot something worth moderating that I could moderate I would. But the chances of me finding that level 0 or level 1 comment worth bringing to the attention of everybody would be very small.
I would have thought that Java would have been an excellent choice for a first langauage. And yet it's not even mentioned.
It's strongly typed. You can argue for or against strongly typed languages once you are an expert, but I think that most people would agree that its good to start with a strongly typed language.
Cross-platform. Like most of the other languages, but an important requirement nonetheless in a educational environment.
Useful in the real world. This is one of Java's best advantages over Python in my opinion. Java programmers are in great demand right now. Not that there isn't also a market for Python folks, but the Java market is much bigger.
Highly flexible. This isn't a language that is tied tightly to any one type of programming. Network programming can be easily taught from a base understanding of Java. So can multithreaded programming. Or UI programming. Or non-interactive programming. Or even database front end programming. I don't think that most of the other languages mentioned are quite as flexible.
Availability of third-party tools. Not that I want to raise everybody to be dependent on IDE's, but having good IDE's is critical for some beginning programers. Especially ones that have been raised in a Windows world.
Please don't take this as a flame against Python or the other languages mentioned. I actually think Python is pretty cool, even though I don't know it very well. I just think that given the capabilities of Java and the role of Java in the marketplace, Java was at least worth mentioning.
I had to deal with a slightly different matter, but also related to the privacy of e-mail in a corporate environment. Here's how I handled it.
Don't do anything without written instructions from the Head of HR and the Head of IT. Otherwise it will come back to haunt you. Besides it will usually make people back off. No one wants to be the one who's name is on the "snooping" order.
Politely say that you'll comply if you're given written instructions, but you don't agree with the decision.
Spread the word about what's going to happen a couple of days before it will happen. This will let everybody get any personal e-mails out of their mail stores, and will also allow the possibility of a grass roots revolt.
#1 tends to work very well. People tend to be afraid of getting called on the carpet later about privacy issues when word leaks out. Just make sure that when work leaks out that you have your personal butt covered.
I've never done open source development, so I can't speak to that question. But that hasn't stopped anyone else here from giving advice, so I won't let it stop me either.:-)
First of all, and most importantly: Don't use MS Word. I'm serious, it's not just random M$ bashing. MS Word is not cross platform and can't be read on any machine that doesn't have M$ Office installed. You don't want to have to leave the server room to check a document spec. (Even NT servers ususally don't have M$Word installed.) Besides, it seems like whatever version of Word that you use is the version that the client doesn't have yet. HTML is the best document format that I've used. It's cross platform, degrades nicely when people have different tools and versions, and best of all can be posted to a shared webserver for ubiquitous access.
Second, know what purpose each piece of documentation has. Generally, I've found three types of documents although there is some overlap.
One is contractual/philosophical, describing what is to be done and how it will be done. These documents are usually done once at the beginning of a project, are often mostly boilerplate. They are important parts of a project, but require little maintenance. They are great tools to give a new member insight on the big picture and to perform project autopsies.
Another is documents that are stand-ins for working code in the early phases, like use case interactions. I probably disagree with a lot of comp sci books about these. I'm of the mind that they are very important in the beginning, but their importance dwindles rapidly as actual code gets written. After you have a customer sign off on a screen prototype, the written desciption of that screen is just so much paperwork overhead. My advice is after each milestone to decide which documents you no longer need to keep updated. Then mark the documents as obsolete, and move on. If looking at the code would be just as easy to do as reading the docs, it's a clear sign that the docs have become obsolete.
The last type are the "hard-core" design documents. Interface designs, database schemas, etc. Draw these up early. Try to finalize them as soon as you can. (How flexible you must be depends on the kind of project.) These documents then become high-content, low maintenace documents. There are lots of tools to help you keep these documents in sync, so you have no excuses for keeping them up to date. These documents are excellent roadmaps, checkpoints, reality checks, and tutorials to new programmers.
First of all, since I'm an Alliance employee, I want to explicitly include the standard disclaimer. This is my opinion, not that of my employer. Nor is this information "official" communication of any sort.
But, frankly, the ZDNet article doesn't make a whole lot of sense to me. Sure, Netscape announced that it was going start including Linux as a strategic platform. And Netscape has released Linux versions of its Directory and Messaging servers to prove this point. And ASFAIK, they will continue to release Alliance servers on Linux.
But neither the Alliance nor Netscape has suggested that they would release their application servers on Linux. It doesn't even make sense that they would.
First of all, the Java support on Linux just isn't there yet. Both NetDynamics and Netscape Application Server need extremely fast and stable JVMs in order to do their jobs. Blackdown just doesn't cut it.
Secondly, there is absolutely no demand for it. When customers are spending six and seven figures for application server software, and similar amounts for hardware, few clients are willing to use Linux. Whether this is right or wrong, it's true. I've never had a client ask me about Linux support for NAS.
I think that I see your problem. I had assumed that you were working with applets and that's why you were complaining about speed. In reality, its probably just your expectations.
In an NT world you are using at least 32 MB just for the operating system. Add another 16 for application server overhead, and another 16MB for web server overhead and caching, and that means that you are going to be paging to disk constantly even with low system usage. Assuming ten thousand concurrent users, you have just 6.4 KB per user, not even counting the overhead.
Yes, an Apache/mod_perl system will run better under these kinds of conditions. Linux has a much leaner footprint, and Apache can be tweaked for low memory footprints.
On the other hand, if you are going to be paying six figures for application server software (Tengah, now called WebLogic after being bought out by BEA, isn't cheap) why don't you invest some money in hardware? Most application servers require at least 128MB per processor and most recommend a quarter gig to a half gig per processor. (Application servers tend to be much more memory intensive than CPU intensive. I've even seen some systems perform much better with 1GB per processor.) You can get 128MB SIMMS for $300-$400 these days.
The bottom line being: if you have an existing low-end piece of hardware that you need to get the most bang for your buck from, you should be looking at PHP or something similar. If you are looking for something that is scalable to tens of thousands of concurrent users, and is easy to develop and maintain, you should be looking at Java application servers. But if you do, you should expect to have to scale your hardware appropriately.
I know that the hype around Java says that it's slow, but it just isn't true in the app server world. Java is what most of the major commercial projects use as their development language. A lot of major e-commerce sites run on Java based deployments.
Some tests that I've seen indicate that Java only runs 10-15% slower than C/C++ on a good application server. And considering that Java is so much easier to develop in, I think that this tradeoff is worth it. And that was before HotSpot. Once HotSpot is integrated into application servers that performance gap may not even exist. (Yes Java is slow when used for applets, but that's a much different environment.)
And actually, an Apache (and asumably mod_perl) mySQL combination is never going to give you the scalability that a commercial appserver and ORACLE combination can give you. The clustering features of most decent app servers combined with the massive parallelism features of ORACLE just can't be beat if you have the money to spent.
That being said, there are lots of great open source solutions, both for high scale and moderate scale deployments. I just wanted to dispute the claim that Apache/mySQL will be more scalable than any Java-based solution. I've worked with both, and the Java-based solutions were able to scale much further.
Drive speeds have certainly been improving over the last twenty years, but I agree that they haven't followed the same blistering rate of improvement that memory and CPU power have. (I remember having a 10MB, 70ms seek time drive on an XT.)
But more importantly, drive prices have been continuing to fall. And caching technologies have been getting better (as CPU and memory prices continue to fall). So even though the core drive technologies might not have changed in the last ten years, the performance that I can expect from a drive array has. The numbers on the EMC Symmetrix disk arrays and Celerra file servers are astoundingly fast. They do it with lots of drives (drives are cheap enough these days that you can have lots of little ones), combined with great caching and fast networks.
(I'm just using EMC as an example because I know them best. There's lots of disk array vendors out there.)
In short, I'm not sure that disk I/O or capacity is a bottleneck for a lot of computer systems these days. As much as CPU and memory have been getting faster and faster, they still are the limiting factoring in a majority of systems.
It's pretty obvious that these guys are a fraud. If they had a real product, they would have every major hardware in the world lined up to buy them out for a billion dollars. Then they would have the resources to building more than the hundred machines a year they claim to be limited to.
Also, if they had a real product they would have some kind of proof. Like cracking RC5 keys. That would be a great proof! Build a supercomputer, design a distributed.net client for it, and then start beaking records with your demo machines.
So the real question is what these weasels are up to. I'm sure that they know that no one is dumb enough to hand over $26 million for a box full of vaccum tubes. They would have found out a long time ago that no one can award a $26 million contract without an ironclad proof of technology. Besides, their web page doesn't even make sense. They say that they have a proprietary operating system, but then on their hardware page it says that it will run either UNIX (I guess any flavor!) or Windows NT.
I suspect that they may be trying to find suckers willing to get certified in their development language, "Viva". They list a training course as being available. To participate, all you have to do is sign this an NDA and send it right in. Of course, all training will happen over the web. So you won't be able to tell what kind of machine that you are taking your training on. Or complain to someone if you figure out the scam. So even if there is no suckers willing to hand over $26mm, they're probably hoping to find a thousand frustrated postal workers willing to spend $5,000 to be the first to be trained in this technology that will enable them to "ride a great tide of change as one paradigm of computing technology gives way to another". And once they are trained, they get to work for Star Bridge Systems! And they get paid in "valuable computing cycles". I'm not making this up folks!
I guess I misunderstood the amount of code that had been developed outside of TransVirtual. I had assumed that the openly developed code was deeply meshed into the GPL code.
I do realize that TransVirtual can release their code under mutiple licences. But the issue does get legally sticky. Consider the following case:
Company A decides to release the beta version of WebWidget under a GPL licence. After three months of beta testing, and numerous bug fixes submitted by the open source community, Company A announces that it will not open source the full version of the application. It also announces several major new features that it has been developing in the past three months. Company A indicates that it will develop "clean room" versions of the bug fixes.
Company A gets all of their beta bugs fixed for them by the open source community, but without having to open source the final product. The open source community get to keep the beta version of the product, but it won't have the new features or many of Company A's internally fixed bugs. Leaving the open source community with a product that would be difficult to bring to a competitive state.
Is this legal? I guess so. But it seems that somewhere along the line, the debugging process should become intellectual property.
Slashdot Mirror
I agree with both the parent comment: it's not your call it's the publishers. I just wanted to re-emphasize the point made that there is a reason that publishers have a specific "tool chain". Not only are all of your collaborators (tech editors, copy editors, layout, illustrators) already standardized on a set of tools, but they also are going to have an entire suite of standard procedures and technologies built around those tools. Standard art and layout around the specific Word templates they give you, for example.
When I wrote my book, I ended up using StarOffice on Linux for most of it. (This was before OpenOffice.) But I only did so after I verified that the compatibility would work: that I could take their Microsoft Word templates and use them within StarOffice then submit the results back to them without degrading the layout in any way
The same may very well still be true. But don't presume that you'll be able to pick your own tools: that would be like showing up for a job and saying you were going to ignore the tool chain and languages of your employer. That you were going to use .NET even if everyone else on your team had standardized on Java. Not only would it be rude to your team, but it would also be impossible to integrate your end results into the end product.
I still haven't seen any conclusive evidence that Linux on mainframe is a good idea. I'm sure running 30 new mainframes is going to cost less than 4000 aging servers. Just about anything would be less expensive than 4000 aging servers.
But I bet that a small farm of modern medium sized servers running Linux on VMWare would be even less expensive. Or Solaris/Niagara. Why would you want to run an open source operating system, whose major benefits are openness and affordability on the what is literally the most expensive and most proprietary computing platform in the world!
These server consolidation projects are just giant boondoggles spawned because the server sprawl finally got insane. It's an endless cycle:
A. Giant server consolidation project that takes 4000 servers down to 30 servers.
B. Department B complains that Department A's application keeps hanging and consuming all of the CPU. They demand their own hardware "for availability reasons".
C. Vendor C demands dedicated hardware for licensing/capacity planning/supportability reasons. Rather than constantly bicker with the vendor over supportability they get dedicated hardware.
D. Department D complains that the IT department is charging outrageous prices for time sharing on the mainframe. After all a dedicated server only costs $XXX.
E. Suddenly there are 4000 servers again.
F. IT department spends some insane amount of money on infrastructure to manage the 4000 servers.
G. IT department budget gets insanely large trying to manage that much stuff.
H. Some CIO gets the idea that all of this money managing servers is ridiculous and we should do a server consolidation project.
I. IT department spends an even larger amount of money on the latest super high availability gear and consulting services so that the can run 4000 commodity servers inside a few big servers. All because it will "cost less to maintain".
J. Go back to A.
A lot of times consultants/contracts/vendors are going to be using webmail to communicate.
So if you are taking away webmail, you are effectively taking away email for these users. Which, needless to say, won't help their productivity. I once had to go back to my hotel during a workday just to collaborate with some experts within my own organization. After which I came back with a memory stick full of code we had built together offsite. The company wasn't any safer. (Actually they were less so, since the firewall never got to see or inspect my code). And the company was out several billable hours of time that I wasted trying to get the needed information and traveling offsite to get it.
From the Wiki:
Prevalent Hypothesis:
That there is enough RAM to hold all business objects in your system.
IMO, this hypothesis doesn't hold water for 99% of business applications. Prevalent proposes that even if this hypothesis doesn't hold today, it might soon hold true because of breakthroughs in memory technology. But historically these types of ideas are flawed, as the real world has clearly shown that memory and disk needs will grow even faster than our ability to use those resources.
Sure I can take a 1998 application and run it with breakthrough performance by caching the whole application in memory. But I don't want a 1998 application, I want a 2003/2004 application. Do you think that the entire Slashdot comment database would fit into a couple of gigs of memory? How about the enite customer database for an average enterprise?
Frankly, if my database is so small that it fits into memory then I probably don't have performance as a primary concern anyway. Plus, do I really want to subject my entire database to constant mark and sweep garbage collection if performance is an issue?
--
.no sig
ogren
I generally have two classes of computer reference books: books I use on a regular basis as a reference and books that I used to learn a topic and thereafter use only occaisionally.
I'm finding Safari really useful for that second category of book. I can use a Safari slot on a Ruby book, read through it over a few weeks to get an understanding of how it compares with what I already know. I can then remove it, putting it back on the Safari "shelf" if I need to use it for reference.
I guess I use Safari a lot like other people would use a traditional library, checking out a book every week or two. But I don't have access to any traditional libraries with the up-to-date technical books that can be found on Safari.
Safari isn't going to mean that I never buy a book again, but it is going to mean that I won't be shelling out as much information on "casual" techical reading.
I understand your desire to teach these conceptual models. I too think that there is too much emphasis on syntax and not enough on good CS theory.
But if this is an introductory course, you can't just start with teaching concepts like design patterns, OOA/D, and relational theory.
First you have to start with basic computing theory: the difference between primary and secondary storage and the difference between machine code, assembly code, byte code, and higher level language code. Then you have to teach the basic concepts of programming: iteration, conditionals, functions, objects, pointers, and references. And the best way to do that is by example, which requires you to teach the basic syntax of a language.
Only after students have a firm mastery of the basic tools can you start to introduce the concepts of good architecture. Without the knowledge of a language to practice their skills with, it would be hard to really grasp the meaning of the theoretical knowledge.
Frankly, if your introductory courses are like my introductory courses were, there are a lot of CS students that still need to be weeded out. There will be some students that can never really understand a pointer, and just want to survive one semester before they change majors. (There may also be some students there because intro to computers is required).
Bottom line: as much as I agree that we need to spend more time on fundamental CS theory, we can't expect to teach the kinds of topics you are talking about to first year undergrads.
Talk about an overgeneralization.
While I will be the first to say that thin clients were overhyped and oversold, they still have their place. I use them from time to time and I find them very convenient.
If all your users need is a web browser, email, and StarOffice then thin clients are a much more effective choice of hardware. The downside is that a lot of people need apps that are harder to support: Palm sync, thick client custom apps, IM clients, and so forth.
In cases where a company goes into thin clients with their eyes open about the restrictions, everyone ends up happer. Users because the thin clients "just work", administrators because they get to centralize everything, and management because they end up saving a lot of money and effort.
Just MHO.
Snowfox asks: I'm curious; please believe that this isn't a troll: Does GNOME on Sun really matter?
Where are Suns being used as something other than a server? Are there business sectors where Sun workstations are common?
I thought SGI pretty much owned the UNIX workstation market.
Nope. Sun has 76% marketshare for the RISC workstation market. SGI does well in the graphics workstation market, but Sun has the technical workstation space.
Yahoo article on workstation marketshare
What crack have you been smoking? Novell's LDAP benchmarks are horrible.
I agree. I've seen many, many organizations where it is a flat out policy not to open ports other than 80/443.
I've always assumed that firewall administrators would soon block non-HTML traffic to eliminate these remote SOAP RPC calls.
That's when I'll make my fortune by patenting the idea of making RPC calls via Steganography. In order to execute a web service, you'll encrypt your SOAP message with gpgp, hide it in a JPG, and post it to a predetermined Ebay auction.
He very carefully laid out the algorithm - I don't have my textbook handy, but it involved elementary mathematical operations on estimated man hours, estimated lines of code, estimated overhead, etc., then at the end -- and I am not making this up -- they multiply the result by a "magic number".
It hit me then that the whole discipline of estimating cost completion is all bullshit. You might as well be estimating with a crystal ball or divining the future with chicken bones. Since I've been working, the best advice I've gotten so far has been "take how long you think it'll take and double it".
Back when I was in middle school my math teacher told me that in order to calculate the area of a circle you had to square the radius and (I am not making this up!) multiply it by a magic number. They even had some hocus-pocus name for the magic number.
It was then that I new the entire field of mathematics had been invented by a bunch of wackos, and that my method was much better. I guess how large I think the area is and then double it. Works for me.
All equations with constants are obviously flawed.
Bottom line:
The www.MozillaQuest.com guy is an idiot. He's poked his head up before, and if you take more than a casual look at his site it's pretty clear that he has no idea what he's talking about. Factual errors, spelling errors, bad design, bad writing style, it's all there.
The MozillaQuestQuest website linked by the previous poster is hysterical after you have explored the MozillaQuestQuest site for a bit.
The 0.9.3 Mozilla build is great. I've started to switch back from Konqueror. I'll miss the favicon's in the title bar and bookmarks, and the ability to enable cookies and JavaScript on a per-site basis. But Mozilla's JavaScript engine is better, its rendering engine is better, and its fonts seem better behaved.
So the whole debate about "1.0" does not interest me. I still want to see progress for Mozilla, but what number they slap on the release is largely irrelevant.
As a Nescape employee, I can't help but ask why Netscape Directory Server wasn't included in these tests? Since Netscape Directory Server has > than 70% market share in the LDAP market, I don't understand how it wouldn't included in a major benchmark.
I don't know the particulars of these benchmarks, but Netscape Directory Server has been benchmarked at speeds almost an order of magnitude higher. Of course, I don't know if that's comparing apples to apples. But I'd like to know!
I always like to check all of the sites that advertise on the superbowl and see which ones had enough forethought to actually build a site that can withstand that type of traffic. If I remember correctly, HotJobs had to apologize to its users last year.
This year the "shot yourself in the foot award" would seem to go to KForce.
First of all, KForce's site didn't go up until today. Given how much extra publicity these sites get in the week before the superbowl, it was a waste of the beneficial side effects of adverising a dot com company on the superbowl.
Second, the site was in yo-yo mode for most of the game. I got the default page for a Domino server a couple of times when accessing KForce's site. Ooops! And it was very slow even when it worked correctly.
Deduct extra points because their home page was bloated and filled with annoying Java and JavaScript. Haven't people learned to make their home pages lightweight yet? Death to scrolling text Applets.
Deduct additional points for running Lotus Domino (yuck) on NT (yuck again). No wonder they are having problems.
A co-worker of mine and I were having a friendly and laid-back discussion about the virtues of restrictive languages (especially Java) versus laissez-faire languages (especially Perl). I was arguing for the more restrictive languages and my friend for Perl. My arguments were largely based on the same maintenance arguments that you make in your post.
Not that you can't write easily maintainable Perl or poorly maintainable Java, it's just that the philosophies of the languages are different. Larry Wall will be the first to tell you that he designed Perl to build quick and dirty programs. He didn't want the language to get in your way of getting something done. (This is not to say that Perl hasn't since developed into a language capable of developing large applications, just that it was designed for a different purpose.
The classic example in my mind is that you can have Perl take an action on a "default" variable. The statement chomp; drives me nuts. Sure it's convenient to not have to specify what you are chomping. But if you put enough of these kinds of statements in a row it quickly becomes hard to tell which variable is being acted upon.
It's perfectly easy to know what is going on when you write the program. But six months later when someone is trying to fix a bug or trying to expand the functionality it can become maddening.
This not to say that I don't use Perl. I think that Perl is great. But I use it as a scripting tool not as an application building tool. For me, it's a great way to get short tasks done. My rule of thumb is that if it take more than two screenfuls of code you should think twice before using Perl. Sometimes I'll break the rule. But when I hit that third screen I'll stop myself and decide if a Java application (or Servlet) might be a better choice.
One of the reasons that I think that Slashdot moderation works so well is that each moderator called upon to do it so infrequently. This makes it a responsibility, like voting.
For example, I usually set my moderation filter pretty high unless I'm really interested in a subject and have the time to sort through several dozen comments. But when I get tagged to moderate I switch over to a 0 filter, and spend a little more time reading every article to watch for anything worth moderating.
If I were to be a moderator every day or two, I wouldn't have the time or inclination to do this. Especially if when I did find something that was worth moderating there would be any 80% chance that I couldn't do anything about it. I'd probably just surf around at my regular filter level and if I happened to spot something worth moderating that I could moderate I would. But the chances of me finding that level 0 or level 1 comment worth bringing to the attention of everybody would be very small.
I would have thought that Java would have been an excellent choice for a first langauage. And yet it's not even mentioned.
Please don't take this as a flame against Python or the other languages mentioned. I actually think Python is pretty cool, even though I don't know it very well. I just think that given the capabilities of Java and the role of Java in the marketplace, Java was at least worth mentioning.
I had to deal with a slightly different matter, but also related to the privacy of e-mail in a corporate environment. Here's how I handled it.
#1 tends to work very well. People tend to be afraid of getting called on the carpet later about privacy issues when word leaks out. Just make sure that when work leaks out that you have your personal butt covered.
I've never done open source development, so I can't speak to that question. But that hasn't stopped anyone else here from giving advice, so I won't let it stop me either. :-)
First of all, and most importantly: Don't use MS Word. I'm serious, it's not just random M$ bashing. MS Word is not cross platform and can't be read on any machine that doesn't have M$ Office installed. You don't want to have to leave the server room to check a document spec. (Even NT servers ususally don't have M$Word installed.) Besides, it seems like whatever version of Word that you use is the version that the client doesn't have yet. HTML is the best document format that I've used. It's cross platform, degrades nicely when people have different tools and versions, and best of all can be posted to a shared webserver for ubiquitous access.
Second, know what purpose each piece of documentation has. Generally, I've found three types of documents although there is some overlap.
Just MHO.
First of all, since I'm an Alliance employee, I want to explicitly include the standard disclaimer. This is my opinion, not that of my employer. Nor is this information "official" communication of any sort.
But, frankly, the ZDNet article doesn't make a whole lot of sense to me. Sure, Netscape announced that it was going start including Linux as a strategic platform. And Netscape has released Linux versions of its Directory and Messaging servers to prove this point. And ASFAIK, they will continue to release Alliance servers on Linux.
But neither the Alliance nor Netscape has suggested that they would release their application servers on Linux. It doesn't even make sense that they would.
First of all, the Java support on Linux just isn't there yet. Both NetDynamics and Netscape Application Server need extremely fast and stable JVMs in order to do their jobs. Blackdown just doesn't cut it.
Secondly, there is absolutely no demand for it. When customers are spending six and seven figures for application server software, and similar amounts for hardware, few clients are willing to use Linux. Whether this is right or wrong, it's true. I've never had a client ask me about Linux support for NAS.
I think that I see your problem. I had assumed that you were working with applets and that's why you were complaining about speed. In reality, its probably just your expectations.
In an NT world you are using at least 32 MB just for the operating system. Add another 16 for application server overhead, and another 16MB for web server overhead and caching, and that means that you are going to be paging to disk constantly even with low system usage. Assuming ten thousand concurrent users, you have just 6.4 KB per user, not even counting the overhead.
Yes, an Apache/mod_perl system will run better under these kinds of conditions. Linux has a much leaner footprint, and Apache can be tweaked for low memory footprints.
On the other hand, if you are going to be paying six figures for application server software (Tengah, now called WebLogic after being bought out by BEA, isn't cheap) why don't you invest some money in hardware? Most application servers require at least 128MB per processor and most recommend a quarter gig to a half gig per processor. (Application servers tend to be much more memory intensive than CPU intensive. I've even seen some systems perform much better with 1GB per processor.) You can get 128MB SIMMS for $300-$400 these days.
The bottom line being: if you have an existing low-end piece of hardware that you need to get the most bang for your buck from, you should be looking at PHP or something similar. If you are looking for something that is scalable to tens of thousands of concurrent users, and is easy to develop and maintain, you should be looking at Java application servers. But if you do, you should expect to have to scale your hardware appropriately.
I know that the hype around Java says that it's slow, but it just isn't true in the app server world. Java is what most of the major commercial projects use as their development language. A lot of major e-commerce sites run on Java based deployments.
Some tests that I've seen indicate that Java only runs 10-15% slower than C/C++ on a good application server. And considering that Java is so much easier to develop in, I think that this tradeoff is worth it. And that was before HotSpot. Once HotSpot is integrated into application servers that performance gap may not even exist. (Yes Java is slow when used for applets, but that's a much different environment.)
And actually, an Apache (and asumably mod_perl) mySQL combination is never going to give you the scalability that a commercial appserver and ORACLE combination can give you. The clustering features of most decent app servers combined with the massive parallelism features of ORACLE just can't be beat if you have the money to spent.
That being said, there are lots of great open source solutions, both for high scale and moderate scale deployments. I just wanted to dispute the claim that Apache/mySQL will be more scalable than any Java-based solution. I've worked with both, and the Java-based solutions were able to scale much further.
Drive speeds have certainly been improving over the last twenty years, but I agree that they haven't followed the same blistering rate of improvement that memory and CPU power have. (I remember having a 10MB, 70ms seek time drive on an XT.)
But more importantly, drive prices have been continuing to fall. And caching technologies have been getting better (as CPU and memory prices continue to fall). So even though the core drive technologies might not have changed in the last ten years, the performance that I can expect from a drive array has. The numbers on the EMC Symmetrix disk arrays and Celerra file servers are astoundingly fast. They do it with lots of drives (drives are cheap enough these days that you can have lots of little ones), combined with great caching and fast networks.
(I'm just using EMC as an example because I know them best. There's lots of disk array vendors out there.)
In short, I'm not sure that disk I/O or capacity is a bottleneck for a lot of computer systems these days. As much as CPU and memory have been getting faster and faster, they still are the limiting factoring in a majority of systems.
It's pretty obvious that these guys are a fraud. If they had a real product, they would have every major hardware in the world lined up to buy them out for a billion dollars. Then they would have the resources to building more than the hundred machines a year they claim to be limited to.
Also, if they had a real product they would have some kind of proof. Like cracking RC5 keys. That would be a great proof! Build a supercomputer, design a distributed.net client for it, and then start beaking records with your demo machines.
So the real question is what these weasels are up to. I'm sure that they know that no one is dumb enough to hand over $26 million for a box full of vaccum tubes. They would have found out a long time ago that no one can award a $26 million contract without an ironclad proof of technology. Besides, their web page doesn't even make sense. They say that they have a proprietary operating system, but then on their hardware page it says that it will run either UNIX (I guess any flavor!) or Windows NT.
I suspect that they may be trying to find suckers willing to get certified in their development language, "Viva". They list a training course as being available. To participate, all you have to do is sign this an NDA and send it right in. Of course, all training will happen over the web. So you won't be able to tell what kind of machine that you are taking your training on. Or complain to someone if you figure out the scam. So even if there is no suckers willing to hand over $26mm, they're probably hoping to find a thousand frustrated postal workers willing to spend $5,000 to be the first to be trained in this technology that will enable them to "ride a great tide of change as one paradigm of computing technology gives way to another". And once they are trained, they get to work for Star Bridge Systems! And they get paid in "valuable computing cycles". I'm not making this up folks!
I guess I misunderstood the amount of code that had been developed outside of TransVirtual. I had assumed that the openly developed code was deeply meshed into the GPL code.
I do realize that TransVirtual can release their code under mutiple licences. But the issue does get legally sticky. Consider the following case:
Is this legal? I guess so. But it seems that somewhere along the line, the debugging process should become intellectual property.