On more than one occasion an outgoing member of our sales force has returned a laptop with pr0n all over it.
We once received a CD-ROM of artwork from a client where they accidentally included some nasty hardcore stuff involving farm animals (bonus points - it was sent to a female staff member at our company).
The best one however was from an IT guy at a place I used to work - the company bought IBM laptops in large batches, and the IT guys would provide preconfigured Windows NT4 network install images (using Norton Ghost or similar) for each model (I dual booted and mostly used Red Hat, but the corporate email and expense reporting system was Lotus Domino R4, and the applet client sucked big time:-)
One hapless IT chap released a Norton image where he'd been testing the browser using various, ahem, websites, complete with all the cookies to prove it stored under his NT domain login in WinNT/Profiles/r****
Luckily for him it was a laid back place, and no-one lost any sleep over it.
The only way to be really sure is to use an acetylene torch.
When I worked for the M.o.D. we had an engineering workshop on site. A 100-tonne press or an 18" angle grinder is also quite efficient at permanent erasure of most magnetic media.
I think you are being both harsh and unfair; you're also incorrect - they aren't even asking you to pay for Windows, they will use a license key YOU provide. They are easily in the top 1% of vendors when it comes to not supporting the MS hegemony - most simply say "it comes with Windows, buy it or f**k off."
They are company at least willing to consider way to not have you pay for Windows, but they need to make a profit too - shipping only an installed machine is wholly sensible of them, and they are quite honest and pragmatic; the last thing they need is Joe public costing them hours of support time because he can't run "make bzImage". It sounds like if they got enough Linux requests, they'd start shipping it.
A lot of small retailers used to ship bare boxes and just turn a blind eye to the fact that customers would pirate Win98 (or indeed, some would provide a "blank" CD-R with the machine).
For example, Sony, by contrast, offers a bunch of spiel attempting to fend off the EULA refund clause with their laptops, along the lines of "we wnat you to have the best possible experience using our laptop, and that will only happen if you get Windows with it". Maybe they think everyone likes blue:-)
BTW, small OEM's are not compelled to pay per box - they pay per license.
The "pay for every box, Win or not" thing was a device MS used to push OS/2 etc. off the market; they'd offer large OEM's a deal whereby Win3.x was (e.g.) $29 a box if you paid per box, $79 if you paid per license. Well, guess what they chose....
IIUC one of the few successful parts of the toothless anti-trust suit was to rule this anti-competitive, and they can no longer make this incentive.
So, Dell doesn't have to pay for Win98 when selling you a Linux box any more, but because so few people want Linux boxes from them, they may decide on their own to only offer bundles with WinXP - IIRC Dell has stopped selling Red Hat desktops, and only offers servers with Linux. The servers are, however, a fair bit cheaper (OEM Win2k small server license is around $300)
The era of adding genuinely useful features to productivity software is long past. I defy you to find any company (including Microsoft) where more than 5% of the people use more than 5% of the features in MS-Office. Feature creep in that product is addressing a diminimus minority. Sure, you can do all kinds of clever stuff with VBA - who actually needs to? Very few people.
The one and only time in recent memory I have tangled with VBA was to borrow from a colleague a script which implements a basic feature that MS-Access (2000) is simply missing - save a table as CSV. That's right, it can't do it. It can put it on the clipboard, but as any non-techie who wangs data around using Excel will tell you, the world stops at row 65,535. Lame.
Why do people upgrade from MS-Office 97 to 2000 to XP? Not for features, for one of two reasons - (a) they get a new computer and the old version won't run, or far more commonly, (b) they start receiving too many.DOC files by email that their software won't read. MS not only has the sense to stick with the impenetrable binary format, but to make an incompatible change to the default save format each release to force the upgrade path. Forget XML - the.DOC is the lingua franca of non-techie document exchange. There is a 3-way tie for second place between.PPT,.XLS and those little winmail.dat calendar thingies from Outlook.
I use StarOffice 5.2 for day to day munging of MS-Office files, for which it is fine, and it has come a long way from earlier versions, but it still needs work in the one word processor feature that really matters - handling.DOC - nowadays it supports even fancy stuff like change tracking, fonts are mostly their though it suffers from more "layout creep" than exchanging files from one setup of MS-Word to the next (what a bunch of lameness, making layout depend on the print driver, Word's worst bug IMHO).
ISTR that MS was originally proposing to use XML in Office 2000 when it was first on the drawing board. Some PM pulled that piece of business suicide away right quick.
We will see once Office 11 is released who is right. Contact me by email if you are willing to make a wager.
I'll make you a different wager - either (a) the so-called XML format will be so in name only, (e.g. a bunch of attributes will be Office COM objects serialised in base64, or undefined enumeration types) or (b) it will never happen, and they'll go on using.doc and.xls (modified of course to be incomaptible with Office XP to force upgrades on everyone who gets Office files by email), or (c) they'll do something funky to produce a copyright-enforced monopoly on the format (e.g. Word only processes files digitally signed with an MS PKI key which is "copyrighted") c.f. the Sony PS/PS2 trick.
If MS produces an open or easily reverse-engineerable* format I'll eat my shorts.
* before the Americans jump, reverse engineering for the purposes of developing interoperable products (not just software) is not only legal but in fact a protected right in many developed countries, i.e. it can't be taken from you by a monopolist with an EULA even with your consent.
It's disingenuous to compare the support fees for a commercial product to the cost of acquiring knowledge of an open source one, as if the support fees were the sole cost and an untrained person with no IT expertise could act as the go-between between your systems and the vendor's support people. The fees paid to the vendor are merely one element of the true support costs.
In practice, to run a successful production setup you're going to need to have your IT staff acquire expertise in the products used, open source or not. In most cases, except for extremely expensive software, this cost far outwieghs the license fees.
Certain vendors would have you believe their products are "fire and forget" and that because most point operations are UI based you can just hire anyone off the street to run them and send them for a two-week certification in mouse-holding at the local tech college, but the reality is quite different - a knowledgeable and skilled sysadmin is a rare find, and indispensable in running real services.
I am CTO at an ASP software provider; our production infrastructure runs our own code with a mixture of open and closed sourced tools. Rarely is it necessary for us to get in the hairy details, but when we do, in my experience the ultimate resort option of being able to look into the source and see what is going on outweighs the benefit of having a formal support contract, even if you never touch the code.
For example...
1. there was a long standing issue with Apache whereby mod_redirect had been designed to URLescape constant strings in the httpd.conf file used in its output; in my view this was a minor design oversight (if I wanted them URLescaped, and it didn't do it, I could always URLescape them myself, whereas because it did and I didn't, I was stuck) and a number of Apache bugDB entries were open against it. As someone with very rusty C skills (we use Java) and who had never touched Apache source before, it took me only a couple of hours to look into the code and see what was happening, make the one line change to remove the URLencode call, and recompile it. One happy camper. I wrote up an explanation for the Apache dev list, and the maintainer of the module added an option (ships from 1.3.20 on) to switch the auto-encoding off. Many happy campers.
2. (To be topical) We use Inktomi as our search engine, and in my 10+ years of experience with tech support from all kinds of vendors form PC builders to Cray Research, their support desk is pretty good. We had a problem with their crawler whereby it was getting tangled up in session id's in URLs vs session id's in cookies, and it was generating a lot of unnecessary duplicates before figuring out they were identical and pruning them. We called their support, who suggested we hook our own URL filtering code into an API they provide (the crawler is Python). This didn't fix the issue, and it quickly became apparent (without having source to examine) that the call-out to customer-supplied URL filter code only happens after it has fetched, indexed and de-duped all the pages, no help in this case. Merely *communicating* this difference took several emails, culminating in sending them a block diagram of how we had deduced the internals of their product worked, and arrowing the two points (where we needed the API, and where it was) and getting a developer on the phone. Ultimately, we resolved the problem by special-casing the URL generation in our own product to work around this limitation.
And I am still waiting for an option in MS-Word to NOT repaginate when changing between a B/W and colour printer with the same paper size:-) I can't be the only one that wants it, can I?
I have also been in situations where I have had the benefit of access to the source code for a commercial product which was otherwise nominally closed source, and the extra flexibility is a great benefit when resolving complex issues; on more than one occasion got on the phone with the vendor, exchanged ideas, made a quick fix and rebuilt the binary so work could proceed, and let them send us a tidy / proper fix in the fullness of time.
In short, if you have an open source product with a vibrant community around it, you have several more options than with a closed product. I would not advocate using open source code from a project that has withered on the vine for mission critical work, just like I wouldn't recommend using a commercial product that has been end-of-lifed. However, if you ARE prepared to take over maintaining the code base as an in-house product you always have that option with open source; with closed source it's extremely rare to get the chance (though I have taken over a commercial source base once before).
This has been done many times before, from consumer products (Commodore Amiga 600/1200 in the early 90's supported proto-PCMCIA flash memory cards) right up to Cray Research (the Cray 2, targeted for the CFD market, had optional "normal" speed memory add-ons which could be addressed like filesystems called "SSD")
On a slightly different tack - the Sleipner A oil platform sank because of a bad design, caused by inaccurate computer based modelling (using an FEA tool inappropriately). In this case it was the data not the software.
NT's kernel does indeed have a rich security model - it was done by the guys who did VMS, and it plagiarises VMS extensively. It is neither more nor less flexible or powerful than simple Unix models (Linux setgid) nor the more complex ones (Unicos MLS, Trusted Solaris).
All the security models in the world are however worthless if every damn thing installs and runs with full root (Administrator) privilege, as everything on NT does, IIS included. I will cheerfully bet that less than 0.1% of NT based web servers have *any* daemons (services) which *don't* run with full Administrator.
Even *MS-Office* requires root privilege to install, no single-user option; it's not kernel modules, it's a damn word processor!
Have you ever tried running user NT desktops without giving them Administrator? I have, and it's a support nightmare. They can't install so much as a screensaver, which may be fine for controlled environments like a telesales CTI terminal bank "Would you like the porn channel?", but it doesn't work in an office environment; the masses rebel.
Your wonderful NT kernel security model is a waste of bits.
Likewise, your $100k Checkpoint firewall isn't going to do anything about Code Red, port 80 is supposed to be open to the world. You need secure web server software. Period. IIS is not that. If anyone ought to be a MSFT shill it's analysts like Gartner who they commission in droves to write unbiased "studies", and Gartner has broken ranks to say IIS sucks for security, lose it and use Apache.
The fact is, as they come out of the box, Unix-like systems are in general more secure than NT, and require more skills to administer. Red Hat is probably the least secure of the Unices (you can't say Linux - this is a distro thing, not the kernel), but it isn't intended as a real server OS any more than NT, and to give them credit it is more secure than a default load of Win2K server.
The fact also is that most people running servers out there on the web, NT, Unix or otherwise, do not have the security skillset to do it properly.
Everyone seems to have their heads so immersed in "computers == x86" they can't see the obvious:
A point I'm suprised no-one has made yet - GCC is a great compiler, and it's optimiser kicks ass, on sensible (read: orthogonal etc.) CPU architectures (Sparc, PA-RISC) and even semi sensible ones (Motorola 68k).
HP compiles the HP-UX kernel for PA-RISC with gcc, and not their own compiler, because it produces the tightest code there is for their platform.
The 80386 is definitely non-sensible; an ungodly mess nothing short of Byzantine - 16 different registers, with no two with instruction sets alike. 80 bit data formats. 8 and 16-bit legacy modes. It shares the unqiue distinction of being even uglier than VAX. Intel would have scrapped the whole steaming turd many moons ago instead of reinventing the 1970's and microcode, were it not for the Wintel monopoly fuelling the fire for faster 80x86 compatibles.
This has chicken-and-egged its way into the open soruce world - the ultimate reason I'm running Linux on P3 and not a Sparc, PA-RISC, 88100, MIPS, RS6k or whatever is because of Microsoft; yes really - the Wintel (or DOStel) hegemony made x86 the best bang for buck architecture through economies of mass production, even though it ***sucks***, which is why Linus Torvalds had one as an impecunious student in 1986.
Now, I'm trapped in the Wintel sheep model on a smaller scale - I have a P3 for the same reason that most people have Windows; I'd have a Sparc or Merced based Linux box in a heartbeat, but all the Linux software I like to use comes ready-rolled for x86, and no I don't enjoy typing "make" 15 times just to install intant messaging.
It's hardly surprising that Intel's code optimiser does better on their archtecture (including 3rd party implementations thereof). It's very goofy to try to optimise for x86. I think you'll find the Intel / GCC gap to be a lot smaller on Merced (IA-64), which is a more sensible setup.
This is way too right wing for/. and is going to end up at -2000, but it needs to be aired:
I am not familiar with the details of the Oz handling of refugees, and no doubt they could do with cleaning up their act a bit, but the basic principle of imprisonment and repatriation is sound. Why?
Because if you make it too easy, you attract a ton of economic migrants which become a drain on your economy and social services, and it becomes unfair to your own citizens.
In the UK right now, an illegal immigrant who is a false asylum seeker and is in no danger at home has a far higher standard of living and far better government benefits than a UK citizen who has paid taxes all their life and is now retired and dependent on the paltry state old age pension. It's immoral.
The rules were written for a small handful of people being persecuted by regimes like Pol Pot, and are being exploited by hordes of people who can't be bothered to work for a living.
These people are supposedly fleeing for their lives from places like *Turkey* (UK travel agents sell package cruise holidays to Turkey for f***'s sake ) and yet somehow manage to travel across 7 or 8 countries and end up "seeking asylum" in the UK. Why? Because the UK is a soft touch.
It's far from an ideal way to filter, but for someone who *is* a genuine asylum seeker, 3 months in an internment camp where they are safe will seem like a holiday, and it's the best way possible of advertising to the rest that they ought to just stay at home.
The volume of these immigrants entering the UK is second only to the number of Mexicans entering the USA across the land border - the big difference is that illegal Mexicans come here to *work* not to sponge off Uncle Sam, because Uncle Sam doesn't do handouts; hence why they are tolerated and in most cases openly welcomed. My house in Austin TX was built largely by Mexican illegals - it's a good house.
Just ask any UK citizen which system they think is better, Australia's or their own.
The problem is nothing to do with owning the media - what you do not have, and need, is a license from the copyright holder to *use* the copyrighted material by loading the code onto a computer and executing it. I don't know US law to this level of detail, but in many countries mere posession of the media is a minor offence or none at all, likely to be ignored.
Unlike with printed matter, software licensing is totally divorced from copies of media - it's perfectly possible and legal to write a software license that says you can only use the program on Wendesdays, or that you have to pay by the number of CPU-hours the code runs for (I have actually licensed CAE software under the latter).
A more down to earth example is DVD's - you may buy one for $19.95 in Best Buy, while Blockbuster has paid $50-$80 a pop for discs with the same sequence of bits in a slightly different wrapper; theirs came with a license to rent them out, yours didn't.
It's not uncommon for enterprise software media to be freely available - with the advent of CD-ROM, Digital (DEC) used to do this with VAX/VMS; anyone with any number of machines on software support got a full media set, including install kits for *all* VMS software, whether or not they had it licensed. Oracle install "media" is freely available - you can download their full product set from the technet web site.
Software is the ultimate in mass production goods - the cost is all R&D, and the unit manufacturing cost is effectively zero.
Licensing terms are all about price discrimination - they allow the licensor to systematically charge different licensees different amounts, based upon the value delivered, or more cynically, ability to pay, and thus maximise their revenue.
It's not even uncommon for enterprise *hardware* to work this way - Sun will ship you an E12000 with 32 CPU's installed, and only charge you for and activate 24 of them - and you can pay to activate more on request. When you consider that most of Sun's cost for these $2k-4k CPU chips is R&D, it makes perfect sense as an upsell opportunity.
Microsoft does the similar things with server-side software - the primary differences between basic MS-Exchange and the "enterprise" version is that the former (a) is at a much higher price point, and (b) is not crippled by having an arbitrary limit on the total amount of stored email (the former does, 18Gb I think - we of course use sendmail at work:-).
For a wide range of software, up until now, per-desktop has been a pretty good metric as the sole axis of price discrimination; as internet-based services become more nebulous, expect to see a who range of more sophisticated enterprise pricing models you've never heard of make it down to the consumer, as well as completely new ones.
Combined with micropayment technologies, you may one day literally end up paying $0.003 every time you press a key in MS-Word-2008-.NET running in your Mozilla 3.0 browser on FreeBSD:-)
I don't think that your point holds now, though it may have when you first signed up with AOL UK.
Over the holidays I was back to the UK and just switched my mother over to BT openworld's 24x7 thing - unlimited use via 0800 number, 15 quid a month all in, works fine with Linux (I even used RH7.2 GUI dialup config). I don't see a big benefit of using AOL over that.
Being stuck with AOL just because you have an aol.co.uk address is a different matter - I guess you could use AOL's mail server from someone else's dialup, but that adds cost and defeats the purpose
Maybe OFTEL should get involved and enforce "email portability" on ISP's?
Windows has the widest driver support, because it has the largest need - it is a consumer desktop OS. The only third party driver on my Solaris boxes at work is from EMC, and it is 100% reliable. I could care less if I can hook a $39 webcam to my Sun server.
OTOH I can tolerate my home Linux box falling over when I insmod an experimental driver.
Win2k is far more stable than Win 3.1, but it has not yet reached the reliability of Linux, never mind Solaris. It still has the good old "unexplained BSOD", it's just rarer. This has now been relegated to being a minor nuisance for a consumer desktop - it's still a *big deal* for a production server. When did you last see Solaris or FreeBSD kernel panic due to an OS bug?
On the other hand, it isn't so long ago (Amiga, Win 3.x) that home machines had to be rebooted to get out of a game. System stability and scalability just isn't a big deal, and consumers now expect software to crash; the concept of software systems which don't routinely fail is a novelty to non-techies.
The kernel engineering of most Unix-like systems is on the whole superior to NT, a lot of which is based concept-wise on VMS and has a number of silly legacy hangovers like drive letters and expensive processes; operability is a bigger issue - the registry is a murky swamp, and it's hard to run a proper security policy when everything (including MS products) insists on blatting DLL's everywhere. Ever found a production MS shop where everything under the sun doesn't run as Administrator?
Most of that huge software library (like anything else) is worthless crap - if you actually look at what most home consumers *use* on their Windows machines, it's an email client (AOL or Outlook), a pirate copy of MS-Office, and one or two games.
Unix is far from being "dead end" technology - it's 30 year history speaks to (a) how well it was designed to begin with, (b) how mature it is, and (c) how well it has evolved. Do you still think NT will be around in 2015?
Yes, you could make a better consumer OS than Windows by putting more GUI candy on top of Unix - perhaps Apple will show us how. As to usability, in many ways, the newer X11 window managers (Gnome) have better HCI and are more powerful than Windows (cut and paste is the day-to-day obvious one for me), what lacks is the vendor packaging support and app-level integration. The average user could care less whether they click SETUP.EXE or foo.rpm as long as it works, but having to add MIME types to NS4.7 by hand is a drag.
It meets the requirement exactly - it offers management by HTTP, which is a form of TCP/IP protocol. You can just hit the thing from a browser (or Perl script with LWP) and flick the sockets on and off (of course, don't use a browser on a machine it's powering:-)
I have one here under my desk (no troll, it isn't on the internet).
I work for a startup which is now a bit less than 2 years old. We have about 70 people. I am the CTO which for me is my dream job - it involves a wonderful variety of things from the deeply technical to the purely business oriented. The best days are when I cover the full spectrum of the role; dealing with vendors, whiteboarding with senior engineers, some people stuff, and a bit of pre-sales chalk talk.
Building a startup company from scratch is a tremedous personal growth experience, and I've gotten a lot out of it. It's extremely hard work, but extremely rewarding too.
In contrast to the dot-coms, we have been very conservative with spending our modest venture capital investment, and have concentrated on steady success - we have put out three software releases, we have successful paying customers to whom we deliver real value, and a 99.93% (and growing) uptime.
It's the company culture which is most important to me - we value people most highly. We have an open information culture (and after all, everyone is a shareholder). Mutual respect, integrity and a work hard play hard attitude are all important to us. We have a highly capable technical team, and many of them could easily find a higher paying job with a larger company even in this market; the reason they are with us is because they believe in what they do, and they enjopy the contribution they can make and impact they can have at a small company.
A lot of people posting in this forum will spout a lot of wibble about how everything should be run by techies and how marketing and sales people aren't as important, yada yada. Get this - a company needs to be strong in all areas to be successful, and the folks who produce the glossy collateral slicks are just as important as the Java coders. We succeed because we are one team.
We also have the usual little things that help alleviate stress: the junk food stocked kitchen; ping-pong, pool and foosball tables. When people are as driven as our team are, they need to unwind too.
We're not hiring techies right now, we're in a phase of focusing on growing revenue, but there are still good startup opportunities out there, and I'd advise anyone to give it a try. Even if the company isn't successful, you'll learn a lot and have a good time doing so.
Having gone myself from a 50,000 person company to a 1,000 person to 2 person startup (myself and our other founder) I can say it's truly unique and worthwhile career move.
I once found something kind of similar in a non-trivial case, which demostrates a more realistic scenario.
A company I used to work for had an object data model stored in an RDBMS, with its own abstraction layer and tools to automatically generate the persister code, demand loading, etc. There were two implementations - one in Microsoft COM, the other in Java. This abstraction layer requires dynamic linkage of the kind not easily possible in plain C++, so it used COM objects for that in the C++/Windows version, and weak references and so forth in Java.
One of the apps had a batch mode "engine" which ran overnight to do number crunching on the data; this was only avalable in a C++/COM version, hence only for NT (this predates COM porting tools). One large customer found Windows NT Server not to be man enough for the job (in those days, a quad Xeon 300MHz was your limit for Microsoft) and wanted the engine ported to their IBM SP/2,; as an experiment, rather than trying to port all the infrastrcture from COM to plain C++, one of the developers quickly recoded the engine in Java over a weekend (note the development time advantage).
Well, as you've guessed, the Java version on the SP/2 was much faster and the customer was happy. This was in the days of JDK 1.1.7 when Java performance was not what it is today, but we expected that result with using hardware that was so much more powerful.
More interestingly the Java 1.1 version was also faster than the C++/COM version on Windows NT - further testing revealed that the cost of the COM dynamic linkage over Java's much more elegant linkage model outweighed the then significant difference in computation performance of the plain compiled C++ vs Java bytecode.
Clearly this can only have moved further in Java's favour with advances in the garbage collector and things like HotSpot - I don't think COM has advanced much in the last 3-4 years, at least not in performance.
What's non-standard about HotSpot? It implements the bytecode perfectly. It may not be the most common JVM, but it's certainly standard.
That's like saying you have to do all performance tests of C++ using MS-Visual Studio on an Intel P3 running Windows 98, because it is the most common platform for compiled C++ code.
Here's the code I tested - when I posted I thought it wouldn't fit in the above comment, but actually the < signs were being truncated by the Slashcode parser:
/* speedtest.c */
#include
#include
#include
int main(void)
{
float x = 0;
int counter;
clock_t start, end;
float cpu;
As promised, some tests with the timing rolled into the runtime environment. I did a couple of things:
1. Tried to get more accurate timing resolution - for this I used System.currentTimeMillis() in Java, which is a wallclock time, and clock() in C which is CPU time, but since this is an approximate, compute intensive test I didn't feel it was a big issue. In 15 mins of man page archaeology I couldn't find a C or POSIX system call which gave sub-second resolution on wallclock, making part of my my point about C:-)
2. Move the timing inside the programs, so it was only timing the loop (see speedtest.c and Compute.java below)
3. Tried a couple of different versions of the Java VM - Sun's 1.2 JDK with no JIT, and IBM's 1.3 JDK with JIT, to see the difference there - this is not just JIT but also VM general improvements from version to version.
4. Did a test of bundling the loop off into a subroutine so it would get the full benefit of the JIT; to trigger this I call it twice and measure the second pass.
A further baseline observation: your "school's big Sun box" is clearly quite heavily loaded, because I tested using a cheesy old 500MHz P3 and it ran rings around those times. I know the Sun should be faster. This is another problem with benchmarking - what exactly are you measuring? The generally accepted rule is that wallclock on an otherwise idle system is the true measure, but if you're using a shared system, then **for this kind of test** CPU time is a fair proxy.
I tested on the following platform:
Intel Pentium 3, 500MHz, 100MHz FSB, 384Mb RAM
Linux 2.2.12 (Red Hat 6.1)
Running multi-user system, but largely idle
I used the following compilers / JDK's:
[glenfarg:dave]speedtest: gcc -v
Reading specs from/usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/sp ecs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
[glenfarg:dave]speedtest:/usr/local/sun/jdk1.2.2/bin/java -version
java version "1.2.2"
Classic VM (build 1.2.2-L, green threads, nojit)
[glenfarg:dave]speedtest:/usr/local/ibm/IBMJava2-13/bin/java -version
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cx130-20001124 (JIT enabled: jitc))
[glenfarg:dave]speedtest:
One interesting point - when I first tried Compute2.java, it was 10% slower than Compute.java on the Sun JDK, and about a wash on the IBM JDK. The default setting of Java VM's is to start with a modest heap size and dynamically increase it; I found that with the Compute2.java program, increasing the starting heap size with "-ms32M" improved performance in both cases, and those numbers are quoted below. You might argue that this makes Java seem very memory hungry, but that heap includes a lot of stuff besides your 10 lines of code - it doesn't mean it takes a 128M heap to efficiently run 40 line programs:-)
The average quoted times over 10 runs each by the code, using the built in measurement, were as follows:
C version-----------------: 0.78 sec
Compute.java, Sun 1.2 JDK-: 3.39 sec
Compute2.java, Sun 1.2 JDK: 3.51 sec
Compute.java, IBM 1.3 JDK-: 1.24 sec
Compute2.java, IBM 1.3 JDK: 1.09 sec
As you can see, the performance once the JIT gets up to speed is not a million miles away from the compiled C - the latter shows about 28% saving in run time; making both use wallclock timing to get a like for like comparison might bring it one or two points closer.
One might be amused to note that using "gcc -O2" instead of the default option made the C version about 6% SLOWER.
As ever, a benchmark is only a benchmark - if you want a real test, use real code in a real scenario. YMWV.
Your test isn't very comparable, because you are also measuring the startup time of a compiled binary (crt0.o) against the startup time of the JVM and byte-compile. Unless of course part of your point is that Java isn't suitable for writing Unix-style command line data filters and other apps with a short life of only 5-10 secs CPU, which I agree, it isn't.
A better test would be to put the "date" commands into the code in both cases; perhaps I'll re-run them that way and post the results. Don't get me wrong, C will still win, the gap will just be a bit narrower.
Having said that, I wouldn't advocate Java (yet) for something compute intensive, you are right on in that respect; however, you must note this:
- very little software these days has CPU time as its limiting performance factor
- in terms of the total cost of doing computation, CPU performance is getting cheaper and cheaper (Moore's Law) while developer time is getting more and more expensive.
The cost in $$ to develop a straight line block of code of the compelxity of your loop body there is literally trillions of times the cost in $$ to execute it once, so unless it is in a place where it will be run trillions of times and performance matters, an easier to code language wins out over a faster one. There is a reason we aren't still all hand coding machine code in hex, and it's not a yes/no thing, it's a sliding scale moving effort form people to machines.
Assembly -> C -> C++ -> Java -> ???
We use pure Java for our server side web application. It runs with a servlet runner (Apache JServ) and we typically run a single VM ("java" command) for about 3-6 weeks, accumulating a couple of hundred hours CPU.
The thing I find most interesting in your test is the speed ratio - despite the disadvantage that you've given Java, it's less than 2:1 which is better than I suspect most people would expect. This is number cruching, it's not what Java does well, althoguh the gap has closed enough for it not to be a concern. I saw a paper about 18 months ago (can't remember the reference)
Nowadays, very few apps do enough computation to redline the CPU in any useful sense - the limiting factor is I/O.
The real advantage of Java is not so easy to benchmark, and that is indeed developer productivity; the app is not rocket science, but it has some very useful platform layer caching between itself and the database. There is no way we could have gotten as far as we did with this with so few people in this amount of time if we had to build it in C++ and worry about type issues and garbage collection.
This productivity advantage far outweighs the 25 to 50% performance penalty of using Java - the limiting factor in our app is not CPU, depending on the individual screen it's either I/O bandwidth to the browser or I/O speed to disk. Not much we can do about the former for end users (though we make sure customers using our admin tool get a cable modem / DSL) and our caching is making good strides at the latter. I have yet to ask a developer to recode an algorithm for **CPU efficiency**, though I do keep a close eye on database and filesystem I/O load, memory footprint (JVM heap), and HTML page weight.
Assuming we can deliver pages to browsers close to as fast as the users' connections can handle them, the efficiency of the overall system to our business is measured in $$$, and includes the cost of developer time (lots) and the cost of hardware (small) - throwing hardware at it here **is** the right solution.
For appservers, we use rackmount dual Pentium 3 pizza boxes, running two Sun 1.2.2 green threads JVM's on Linux; I picked up **twenty-two** of these, less than a year old, at the deja.com sell off in Feb 2001 for about 10 grand total. That won't even cover the fully loaded cost (salary, taxes, medical and Mountain Dew:) of one senior engineer for a month.
Bear in mind guys, I'm not a suit, I'm a techie - I have a Ph.D not an MBA, and my background curiously enough is in one of the few areas where the CPU performance **does** matter, doing compute intensive stuff, mostly FORTRAN and C and mostly on hardware made by Cray Research. This gives me the perspective to know when and where performance matters, and I chose Java with that in mind.
It's a nice intellectual tech question, to which the answer seems to be (a) no, it's not that simple, because (b) no demand == no engineering effort to make it work.
There's also a practical question - how do you get a decent amount of upstream bandwidth from your home? The best answer appears to be the higher tiers of ADSL; here in Austin TX, the top tier is 1.5M/6.0M and hence you're getting (almost) T1 speed up. A colleague of mine runs a mini hosting service from his house as a sideline, using this technology. Comes with a static subnet for around $300 pcm, which is still a good bit cheaper than a T1. Like most minor pushers, he does it to feed his own bandwidth habit; 5.8M of that downstream is his to play with:-)
T1's are also coming down a lot, and $700 is now the bottom end of pricing - this may be viable if you have some $$$ coming in to support it.
For myself, I use a $45 pcm cable modem, which only allows 0.3M up, but it's plenty for the range of services I host off my home box - my own usage is still msotly down (esp big downloads) and the steady 2.0M down at this price is good value.
The lack of a static IP on my service is an annoyance, but dynamic DNS is a good substitute, andI only ever change IP's on a reboot, which is typically once every 2-3 months; I have the source code for the specialised DHCP client daemon so I guess I could hack it to request the previous IP over again.
On more than one occasion an outgoing member of our sales force has returned a laptop with pr0n all over it.
:-)
We once received a CD-ROM of artwork from a client where they accidentally included some nasty hardcore stuff involving farm animals (bonus points - it was sent to a female staff member at our company).
The best one however was from an IT guy at a place I used to work - the company bought IBM laptops in large batches, and the IT guys would provide preconfigured Windows NT4 network install images (using Norton Ghost or similar) for each model (I dual booted and mostly used Red Hat, but the corporate email and expense reporting system was Lotus Domino R4, and the applet client sucked big time
One hapless IT chap released a Norton image where he'd been testing the browser using various, ahem, websites, complete with all the cookies to prove it stored under his NT domain login in WinNT/Profiles/r****
Luckily for him it was a laid back place, and no-one lost any sleep over it.
When I worked for the M.o.D. we had an engineering workshop on site. A 100-tonne press or an 18" angle grinder is also quite efficient at permanent erasure of most magnetic media.
I think you are being both harsh and unfair; you're also incorrect - they aren't even asking you to pay for Windows, they will use a license key YOU provide. They are easily in the top 1% of vendors when it comes to not supporting the MS hegemony - most simply say "it comes with Windows, buy it or f**k off."
:-)
They are company at least willing to consider way to not have you pay for Windows, but they need to make a profit too - shipping only an installed machine is wholly sensible of them, and they are quite honest and pragmatic; the last thing they need is Joe public costing them hours of support time because he can't run "make bzImage". It sounds like if they got enough Linux requests, they'd start shipping it.
A lot of small retailers used to ship bare boxes and just turn a blind eye to the fact that customers would pirate Win98 (or indeed, some would provide a "blank" CD-R with the machine).
For example, Sony, by contrast, offers a bunch of spiel attempting to fend off the EULA refund clause with their laptops, along the lines of "we wnat you to have the best possible experience using our laptop, and that will only happen if you get Windows with it". Maybe they think everyone likes blue
BTW, small OEM's are not compelled to pay per box - they pay per license.
The "pay for every box, Win or not" thing was a device MS used to push OS/2 etc. off the market; they'd offer large OEM's a deal whereby Win3.x was (e.g.) $29 a box if you paid per box, $79 if you paid per license. Well, guess what they chose....
IIUC one of the few successful parts of the toothless anti-trust suit was to rule this anti-competitive, and they can no longer make this incentive.
So, Dell doesn't have to pay for Win98 when selling you a Linux box any more, but because so few people want Linux boxes from them, they may decide on their own to only offer bundles with WinXP - IIRC Dell has stopped selling Red Hat desktops, and only offers servers with Linux. The servers are, however, a fair bit cheaper (OEM Win2k small server license is around $300)
The era of adding genuinely useful features to productivity software is long past. I defy you to find any company (including Microsoft) where more than 5% of the people use more than 5% of the features in MS-Office. Feature creep in that product is addressing a diminimus minority. Sure, you can do all kinds of clever stuff with VBA - who actually needs to? Very few people.
The one and only time in recent memory I have tangled with VBA was to borrow from a colleague a script which implements a basic feature that MS-Access (2000) is simply missing - save a table as CSV. That's right, it can't do it. It can put it on the clipboard, but as any non-techie who wangs data around using Excel will tell you, the world stops at row 65,535. Lame.
Why do people upgrade from MS-Office 97 to 2000 to XP? Not for features, for one of two reasons - (a) they get a new computer and the old version won't run, or far more commonly, (b) they start receiving too many .DOC files by email that their software won't read. MS not only has the sense to stick with the impenetrable binary format, but to make an incompatible change to the default save format each release to force the upgrade path. Forget XML - the .DOC is the lingua franca of non-techie document exchange. There is a 3-way tie for second place between .PPT, .XLS and those little winmail.dat calendar thingies from Outlook.
I use StarOffice 5.2 for day to day munging of MS-Office files, for which it is fine, and it has come a long way from earlier versions, but it still needs work in the one word processor feature that really matters - handling .DOC - nowadays it supports even fancy stuff like change tracking, fonts are mostly their though it suffers from more "layout creep" than exchanging files from one setup of MS-Word to the next (what a bunch of lameness, making layout depend on the print driver, Word's worst bug IMHO).
ISTR that MS was originally proposing to use XML in Office 2000 when it was first on the drawing board. Some PM pulled that piece of business suicide away right quick.
I'll make you a different wager - either (a) the so-called XML format will be so in name only, (e.g. a bunch of attributes will be Office COM objects serialised in base64, or undefined enumeration types) or (b) it will never happen, and they'll go on using .doc and .xls (modified of course to be incomaptible with Office XP to force upgrades on everyone who gets Office files by email), or (c) they'll do something funky to produce a copyright-enforced monopoly on the format (e.g. Word only processes files digitally signed with an MS PKI key which is "copyrighted") c.f. the Sony PS/PS2 trick.
If MS produces an open or easily reverse-engineerable* format I'll eat my shorts.
* before the Americans jump, reverse engineering for the purposes of developing interoperable products (not just software) is not only legal but in fact a protected right in many developed countries, i.e. it can't be taken from you by a monopolist with an EULA even with your consent.
In practice, to run a successful production setup you're going to need to have your IT staff acquire expertise in the products used, open source or not. In most cases, except for extremely expensive software, this cost far outwieghs the license fees.
Certain vendors would have you believe their products are "fire and forget" and that because most point operations are UI based you can just hire anyone off the street to run them and send them for a two-week certification in mouse-holding at the local tech college, but the reality is quite different - a knowledgeable and skilled sysadmin is a rare find, and indispensable in running real services.
I am CTO at an ASP software provider; our production infrastructure runs our own code with a mixture of open and closed sourced tools. Rarely is it necessary for us to get in the hairy details, but when we do, in my experience the ultimate resort option of being able to look into the source and see what is going on outweighs the benefit of having a formal support contract, even if you never touch the code.
For example...
1. there was a long standing issue with Apache whereby mod_redirect had been designed to URLescape constant strings in the httpd.conf file used in its output; in my view this was a minor design oversight (if I wanted them URLescaped, and it didn't do it, I could always URLescape them myself, whereas because it did and I didn't, I was stuck) and a number of Apache bugDB entries were open against it. As someone with very rusty C skills (we use Java) and who had never touched Apache source before, it took me only a couple of hours to look into the code and see what was happening, make the one line change to remove the URLencode call, and recompile it. One happy camper. I wrote up an explanation for the Apache dev list, and the maintainer of the module added an option (ships from 1.3.20 on) to switch the auto-encoding off. Many happy campers.
2. (To be topical) We use Inktomi as our search engine, and in my 10+ years of experience with tech support from all kinds of vendors form PC builders to Cray Research, their support desk is pretty good. We had a problem with their crawler whereby it was getting tangled up in session id's in URLs vs session id's in cookies, and it was generating a lot of unnecessary duplicates before figuring out they were identical and pruning them. We called their support, who suggested we hook our own URL filtering code into an API they provide (the crawler is Python). This didn't fix the issue, and it quickly became apparent (without having source to examine) that the call-out to customer-supplied URL filter code only happens after it has fetched, indexed and de-duped all the pages, no help in this case. Merely *communicating* this difference took several emails, culminating in sending them a block diagram of how we had deduced the internals of their product worked, and arrowing the two points (where we needed the API, and where it was) and getting a developer on the phone. Ultimately, we resolved the problem by special-casing the URL generation in our own product to work around this limitation.
And I am still waiting for an option in MS-Word to NOT repaginate when changing between a B/W and colour printer with the same paper size
I have also been in situations where I have had the benefit of access to the source code for a commercial product which was otherwise nominally closed source, and the extra flexibility is a great benefit when resolving complex issues; on more than one occasion got on the phone with the vendor, exchanged ideas, made a quick fix and rebuilt the binary so work could proceed, and let them send us a tidy / proper fix in the fullness of time.
In short, if you have an open source product with a vibrant community around it, you have several more options than with a closed product. I would not advocate using open source code from a project that has withered on the vine for mission critical work, just like I wouldn't recommend using a commercial product that has been end-of-lifed. However, if you ARE prepared to take over maintaining the code base as an in-house product you always have that option with open source; with closed source it's extremely rare to get the chance (though I have taken over a commercial source base once before).
This has been done many times before, from consumer products (Commodore Amiga 600/1200 in the early 90's supported proto-PCMCIA flash memory cards) right up to Cray Research (the Cray 2, targeted for the CFD market, had optional "normal" speed memory add-ons which could be addressed like filesystems called "SSD")
On a slightly different tack - the
Sleipner A oil platform sank because of a bad design, caused by inaccurate computer based modelling (using an FEA tool inappropriately). In this case it was the data not the software.
NT's kernel does indeed have a rich security model - it was done by the guys who did VMS, and it plagiarises VMS extensively. It is neither more nor less flexible or powerful than simple Unix models (Linux setgid) nor the more complex ones (Unicos MLS, Trusted Solaris).
All the security models in the world are however worthless if every damn thing installs and runs with full root (Administrator) privilege, as everything on NT does, IIS included. I will cheerfully bet that less than 0.1% of NT based web servers have *any* daemons (services) which *don't* run with full Administrator.
Even *MS-Office* requires root privilege to install, no single-user option; it's not kernel modules, it's a damn word processor!
Have you ever tried running user NT desktops without giving them Administrator? I have, and it's a support nightmare. They can't install so much as a screensaver, which may be fine for controlled environments like a telesales CTI terminal bank "Would you like the porn channel?", but it doesn't work in an office environment; the masses rebel.
Your wonderful NT kernel security model is a waste of bits.
Likewise, your $100k Checkpoint firewall isn't going to do anything about Code Red, port 80 is supposed to be open to the world. You need secure web server software. Period. IIS is not that. If anyone ought to be a MSFT shill it's analysts like Gartner who they commission in droves to write unbiased "studies", and Gartner has broken ranks to say IIS sucks for security, lose it and use Apache.
The fact is, as they come out of the box, Unix-like systems are in general more secure than NT, and require more skills to administer. Red Hat is probably the least secure of the Unices (you can't say Linux - this is a distro thing, not the kernel), but it isn't intended as a real server OS any more than NT, and to give them credit it is more secure than a default load of Win2K server.
The fact also is that most people running servers out there on the web, NT, Unix or otherwise, do not have the security skillset to do it properly.
NT = more holes out of the box = more worms.
You're missing the point:
Visa does not have 94% market share. Neither does Mastercard, Amex, Discover, Access, Switch, Bancontact or anyone else.
Monopoly != free market capitalism
Everyone seems to have their heads so immersed in "computers == x86" they can't see the obvious:
A point I'm suprised no-one has made yet - GCC is a great compiler, and it's optimiser kicks ass, on sensible (read: orthogonal etc.) CPU architectures (Sparc, PA-RISC) and even semi sensible ones (Motorola 68k).
HP compiles the HP-UX kernel for PA-RISC with gcc, and not their own compiler, because it produces the tightest code there is for their platform.
The 80386 is definitely non-sensible; an ungodly mess nothing short of Byzantine - 16 different registers, with no two with instruction sets alike. 80 bit data formats. 8 and 16-bit legacy modes. It shares the unqiue distinction of being even uglier than VAX. Intel would have scrapped the whole steaming turd many moons ago instead of reinventing the 1970's and microcode, were it not for the Wintel monopoly fuelling the fire for faster 80x86 compatibles.
This has chicken-and-egged its way into the open soruce world - the ultimate reason I'm running Linux on P3 and not a Sparc, PA-RISC, 88100, MIPS, RS6k or whatever is because of Microsoft; yes really - the Wintel (or DOStel) hegemony made x86 the best bang for buck architecture through economies of mass production, even though it ***sucks***, which is why Linus Torvalds had one as an impecunious student in 1986.
Now, I'm trapped in the Wintel sheep model on a smaller scale - I have a P3 for the same reason that most people have Windows; I'd have a Sparc or Merced based Linux box in a heartbeat, but all the Linux software I like to use comes ready-rolled for x86, and no I don't enjoy typing "make" 15 times just to install intant messaging.
It's hardly surprising that Intel's code optimiser does better on their archtecture (including 3rd party implementations thereof). It's very goofy to try to optimise for x86. I think you'll find the Intel / GCC gap to be a lot smaller on Merced (IA-64), which is a more sensible setup.
This is way too right wing for /. and is going to end up at -2000, but it needs to be aired:
I am not familiar with the details of the Oz handling of refugees, and no doubt they could do with cleaning up their act a bit, but the basic principle of imprisonment and repatriation is sound. Why?
Because if you make it too easy, you attract a ton of economic migrants which become a drain on your economy and social services, and it becomes unfair to your own citizens.
In the UK right now, an illegal immigrant who is a false asylum seeker and is in no danger at home has a far higher standard of living and far better government benefits than a UK citizen who has paid taxes all their life and is now retired and dependent on the paltry state old age pension. It's immoral.
The rules were written for a small handful of people being persecuted by regimes like Pol Pot, and are being exploited by hordes of people who can't be bothered to work for a living.
These people are supposedly fleeing for their lives from places like *Turkey* (UK travel agents sell package cruise holidays to Turkey for f***'s sake ) and yet somehow manage to travel across 7 or 8 countries and end up "seeking asylum" in the UK. Why? Because the UK is a soft touch.
It's far from an ideal way to filter, but for someone who *is* a genuine asylum seeker, 3 months in an internment camp where they are safe will seem like a holiday, and it's the best way possible of advertising to the rest that they ought to just stay at home.
The volume of these immigrants entering the UK is second only to the number of Mexicans entering the USA across the land border - the big difference is that illegal Mexicans come here to *work* not to sponge off Uncle Sam, because Uncle Sam doesn't do handouts; hence why they are tolerated and in most cases openly welcomed. My house in Austin TX was built largely by Mexican illegals - it's a good house.
Just ask any UK citizen which system they think is better, Australia's or their own.
The problem is nothing to do with owning the media - what you do not have, and need, is a license from the copyright holder to *use* the copyrighted material by loading the code onto a computer and executing it. I don't know US law to this level of detail, but in many countries mere posession of the media is a minor offence or none at all, likely to be ignored.
:-).
:-)
Unlike with printed matter, software licensing is totally divorced from copies of media - it's perfectly possible and legal to write a software license that says you can only use the program on Wendesdays, or that you have to pay by the number of CPU-hours the code runs for (I have actually licensed CAE software under the latter).
A more down to earth example is DVD's - you may buy one for $19.95 in Best Buy, while Blockbuster has paid $50-$80 a pop for discs with the same sequence of bits in a slightly different wrapper; theirs came with a license to rent them out, yours didn't.
It's not uncommon for enterprise software media to be freely available - with the advent of CD-ROM, Digital (DEC) used to do this with VAX/VMS; anyone with any number of machines on software support got a full media set, including install kits for *all* VMS software, whether or not they had it licensed. Oracle install "media" is freely available - you can download their full product set from the technet web site.
Software is the ultimate in mass production goods - the cost is all R&D, and the unit manufacturing cost is effectively zero.
Licensing terms are all about price discrimination - they allow the licensor to systematically charge different licensees different amounts, based upon the value delivered, or more cynically, ability to pay, and thus maximise their revenue.
It's not even uncommon for enterprise *hardware* to work this way - Sun will ship you an E12000 with 32 CPU's installed, and only charge you for and activate 24 of them - and you can pay to activate more on request. When you consider that most of Sun's cost for these $2k-4k CPU chips is R&D, it makes perfect sense as an upsell opportunity.
Microsoft does the similar things with server-side software - the primary differences between basic MS-Exchange and the "enterprise" version is that the former (a) is at a much higher price point, and (b) is not crippled by having an arbitrary limit on the total amount of stored email (the former does, 18Gb I think - we of course use sendmail at work
For a wide range of software, up until now, per-desktop has been a pretty good metric as the sole axis of price discrimination; as internet-based services become more nebulous, expect to see a who range of more sophisticated enterprise pricing models you've never heard of make it down to the consumer, as well as completely new ones.
Combined with micropayment technologies, you may one day literally end up paying $0.003 every time you press a key in MS-Word-2008-.NET running in your Mozilla 3.0 browser on FreeBSD
I don't think that your point holds now, though it may have when you first signed up with AOL UK.
Over the holidays I was back to the UK and just switched my mother over to BT openworld's 24x7 thing - unlimited use via 0800 number, 15 quid a month all in, works fine with Linux (I even used RH7.2 GUI dialup config). I don't see a big benefit of using AOL over that.
Being stuck with AOL just because you have an aol.co.uk address is a different matter - I guess you could use AOL's mail server from someone else's dialup, but that adds cost and defeats the purpose
Maybe OFTEL should get involved and enforce "email portability" on ISP's?
You're confusing your points.
Windows has the widest driver support, because it has the largest need - it is a consumer desktop OS. The only third party driver on my Solaris boxes at work is from EMC, and it is 100% reliable. I could care less if I can hook a $39 webcam to my Sun server.
OTOH I can tolerate my home Linux box falling over when I insmod an experimental driver.
Win2k is far more stable than Win 3.1, but it has not yet reached the reliability of Linux, never mind Solaris. It still has the good old "unexplained BSOD", it's just rarer. This has now been relegated to being a minor nuisance for a consumer desktop - it's still a *big deal* for a production server. When did you last see Solaris or FreeBSD kernel panic due to an OS bug?
On the other hand, it isn't so long ago (Amiga, Win 3.x) that home machines had to be rebooted to get out of a game. System stability and scalability just isn't a big deal, and consumers now expect software to crash; the concept of software systems which don't routinely fail is a novelty to non-techies.
The kernel engineering of most Unix-like systems is on the whole superior to NT, a lot of which is based concept-wise on VMS and has a number of silly legacy hangovers like drive letters and expensive processes; operability is a bigger issue - the registry is a murky swamp, and it's hard to run a proper security policy when everything (including MS products) insists on blatting DLL's everywhere. Ever found a production MS shop where everything under the sun doesn't run as Administrator?
Most of that huge software library (like anything else) is worthless crap - if you actually look at what most home consumers *use* on their Windows machines, it's an email client (AOL or Outlook), a pirate copy of MS-Office, and one or two games.
Unix is far from being "dead end" technology - it's 30 year history speaks to (a) how well it was designed to begin with, (b) how mature it is, and (c) how well it has evolved. Do you still think NT will be around in 2015?
Yes, you could make a better consumer OS than Windows by putting more GUI candy on top of Unix - perhaps Apple will show us how. As to usability, in many ways, the newer X11 window managers (Gnome) have better HCI and are more powerful than Windows (cut and paste is the day-to-day obvious one for me), what lacks is the vendor packaging support and app-level integration. The average user could care less whether they click SETUP.EXE or foo.rpm as long as it works, but having to add MIME types to NS4.7 by hand is a drag.
It meets the requirement exactly - it offers management by HTTP, which is a form of TCP/IP protocol. You can just hit the thing from a browser (or Perl script with LWP) and flick the sockets on and off (of course, don't use a browser on a machine it's powering :-)
I have one here under my desk (no troll, it isn't on the internet).
I work for a startup which is now a bit less than 2 years old. We have about 70 people. I am the CTO which for me is my dream job - it involves a wonderful variety of things from the deeply technical to the purely business oriented. The best days are when I cover the full spectrum of the role; dealing with vendors, whiteboarding with senior engineers, some people stuff, and a bit of pre-sales chalk talk.
Building a startup company from scratch is a tremedous personal growth experience, and I've gotten a lot out of it. It's extremely hard work, but extremely rewarding too.
In contrast to the dot-coms, we have been very conservative with spending our modest venture capital investment, and have concentrated on steady success - we have put out three software releases, we have successful paying customers to whom we deliver real value, and a 99.93% (and growing) uptime.
It's the company culture which is most important to me - we value people most highly. We have an open information culture (and after all, everyone is a shareholder). Mutual respect, integrity and a work hard play hard attitude are all important to us. We have a highly capable technical team, and many of them could easily find a higher paying job with a larger company even in this market; the reason they are with us is because they believe in what they do, and they enjopy the contribution they can make and impact they can have at a small company.
A lot of people posting in this forum will spout a lot of wibble about how everything should be run by techies and how marketing and sales people aren't as important, yada yada. Get this - a company needs to be strong in all areas to be successful, and the folks who produce the glossy collateral slicks are just as important as the Java coders. We succeed because we are one team.
We also have the usual little things that help alleviate stress: the junk food stocked kitchen; ping-pong, pool and foosball tables. When people are as driven as our team are, they need to unwind too.
We're not hiring techies right now, we're in a phase of focusing on growing revenue, but there are still good startup opportunities out there, and I'd advise anyone to give it a try. Even if the company isn't successful, you'll learn a lot and have a good time doing so.
Having gone myself from a 50,000 person company to a 1,000 person to 2 person startup (myself and our other founder) I can say it's truly unique and worthwhile career move.
I once found something kind of similar in a non-trivial case, which demostrates a more realistic scenario.
A company I used to work for had an object data model stored in an RDBMS, with its own abstraction layer and tools to automatically generate the persister code, demand loading, etc. There were two implementations - one in Microsoft COM, the other in Java. This abstraction layer requires dynamic linkage of the kind not easily possible in plain C++, so it used COM objects for that in the C++/Windows version, and weak references and so forth in Java.
One of the apps had a batch mode "engine" which ran overnight to do number crunching on the data; this was only avalable in a C++/COM version, hence only for NT (this predates COM porting tools). One large customer found Windows NT Server not to be man enough for the job (in those days, a quad Xeon 300MHz was your limit for Microsoft) and wanted the engine ported to their IBM SP/2,; as an experiment, rather than trying to port all the infrastrcture from COM to plain C++, one of the developers quickly recoded the engine in Java over a weekend (note the development time advantage).
Well, as you've guessed, the Java version on the SP/2 was much faster and the customer was happy. This was in the days of JDK 1.1.7 when Java performance was not what it is today, but we expected that result with using hardware that was so much more powerful.
More interestingly the Java 1.1 version was also faster than the C++/COM version on Windows NT - further testing revealed that the cost of the COM dynamic linkage over Java's much more elegant linkage model outweighed the then significant difference in computation performance of the plain compiled C++ vs Java bytecode.
Clearly this can only have moved further in Java's favour with advances in the garbage collector and things like HotSpot - I don't think COM has advanced much in the last 3-4 years, at least not in performance.
Horse output.
What's non-standard about HotSpot? It implements the bytecode perfectly. It may not be the most common JVM, but it's certainly standard.
That's like saying you have to do all performance tests of C++ using MS-Visual Studio on an Intel P3 running Windows 98, because it is the most common platform for compiled C++ code.
Here's the code I tested - when I posted I thought it wouldn't fit in the above comment, but actually the < signs were being truncated by the Slashcode parser:
/* speedtest.c */
#include
#include
#include
int main(void)
{
float x = 0;
int counter;
clock_t start, end;
float cpu;
start = clock();
for(counter = 0; counter < 10000000; counter++)
x += (counter / 3.14159265359);
end = clock();
printf("%f\n", x);
cpu = (end - start) / (1.0 * CLOCKS_PER_SEC);
printf("%f\n",cpu);
return 0;
}
::::::::::::::
Compute.java
::::::::::::::
// Compute.java - moves timing inside JVM
public class Compute
{
public static void main(String args[])
{
float x = 0;
int counter = 0;
long start = System.currentTimeMillis();
for(counter = 0; counter < 10000000; counter++)
x += (counter / 3.14159265359);
long end = System.currentTimeMillis();
System.out.println("" + x);
System.out.println("Time: " + ((end-start) / 1000.0));
}
}
::::::::::::::
Compute2.java
::::::::::::::
// Compute2 - puts code in method and pre-seeds JIT
public class Compute2
{
public static void main(String args[])
{
float discard = do_Compute();
long start = System.currentTimeMillis();
float x = do_Compute();
long end = System.currentTimeMillis();
System.out.println("" + x);
System.out.println("Time: " + ((end-start) / 1000.0));
}
private static float do_Compute() {
float x = 0;
int counter = 0;
for(counter = 0; counter < 10000000; counter++)
x += (counter / 3.14159265359);
return x;
}
}
As promised, some tests with the timing rolled into the runtime environment. I did a couple of things:
:-)
/usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/sp ecs
/usr/local/sun/jdk1.2.2/bin/java -version
/usr/local/ibm/IBMJava2-13/bin/java -version
:-)
1. Tried to get more accurate timing resolution - for this I used System.currentTimeMillis() in Java, which is a wallclock time, and clock() in C which is CPU time, but since this is an approximate, compute intensive test I didn't feel it was a big issue. In 15 mins of man page archaeology I couldn't find a C or POSIX system call which gave sub-second resolution on wallclock, making part of my my point about C
2. Move the timing inside the programs, so it was only timing the loop (see speedtest.c and Compute.java below)
3. Tried a couple of different versions of the Java VM - Sun's 1.2 JDK with no JIT, and IBM's 1.3 JDK with JIT, to see the difference there - this is not just JIT but also VM general improvements from version to version.
4. Did a test of bundling the loop off into a subroutine so it would get the full benefit of the JIT; to trigger this I call it twice and measure the second pass.
A further baseline observation: your "school's big Sun box" is clearly quite heavily loaded, because I tested using a cheesy old 500MHz P3 and it ran rings around those times. I know the Sun should be faster. This is another problem with benchmarking - what exactly are you measuring? The generally accepted rule is that wallclock on an otherwise idle system is the true measure, but if you're using a shared system, then **for this kind of test** CPU time is a fair proxy.
I tested on the following platform:
Intel Pentium 3, 500MHz, 100MHz FSB, 384Mb RAM
Linux 2.2.12 (Red Hat 6.1)
Running multi-user system, but largely idle
I used the following compilers / JDK's:
[glenfarg:dave]speedtest: gcc -v
Reading specs from
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
[glenfarg:dave]speedtest:
java version "1.2.2"
Classic VM (build 1.2.2-L, green threads, nojit)
[glenfarg:dave]speedtest:
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cx130-20001124 (JIT enabled: jitc))
[glenfarg:dave]speedtest:
One interesting point - when I first tried Compute2.java, it was 10% slower than Compute.java on the Sun JDK, and about a wash on the IBM JDK. The default setting of Java VM's is to start with a modest heap size and dynamically increase it; I found that with the Compute2.java program, increasing the starting heap size with "-ms32M" improved performance in both cases, and those numbers are quoted below. You might argue that this makes Java seem very memory hungry, but that heap includes a lot of stuff besides your 10 lines of code - it doesn't mean it takes a 128M heap to efficiently run 40 line programs
The average quoted times over 10 runs each by the code, using the built in measurement, were as follows:
C version-----------------: 0.78 sec
Compute.java, Sun 1.2 JDK-: 3.39 sec
Compute2.java, Sun 1.2 JDK: 3.51 sec
Compute.java, IBM 1.3 JDK-: 1.24 sec
Compute2.java, IBM 1.3 JDK: 1.09 sec
As you can see, the performance once the JIT gets up to speed is not a million miles away from the compiled C - the latter shows about 28% saving in run time; making both use wallclock timing to get a like for like comparison might bring it one or two points closer.
One might be amused to note that using "gcc -O2" instead of the default option made the C version about 6% SLOWER.
As ever, a benchmark is only a benchmark - if you want a real test, use real code in a real scenario. YMWV.
Enjoy
Dave
Your test isn't very comparable, because you are also measuring the startup time of a compiled binary (crt0.o) against the startup time of the JVM and byte-compile. Unless of course part of your point is that Java isn't suitable for writing Unix-style command line data filters and other apps with a short life of only 5-10 secs CPU, which I agree, it isn't.
:) of one senior engineer for a month.
A better test would be to put the "date" commands into the code in both cases; perhaps I'll re-run them that way and post the results. Don't get me wrong, C will still win, the gap will just be a bit narrower.
Having said that, I wouldn't advocate Java (yet) for something compute intensive, you are right on in that respect; however, you must note this:
- very little software these days has CPU time as its limiting performance factor
- in terms of the total cost of doing computation, CPU performance is getting cheaper and cheaper (Moore's Law) while developer time is getting more and more expensive.
The cost in $$ to develop a straight line block of code of the compelxity of your loop body there is literally trillions of times the cost in $$ to execute it once, so unless it is in a place where it will be run trillions of times and performance matters, an easier to code language wins out over a faster one. There is a reason we aren't still all hand coding machine code in hex, and it's not a yes/no thing, it's a sliding scale moving effort form people to machines.
Assembly -> C -> C++ -> Java -> ???
We use pure Java for our server side web application. It runs with a servlet runner (Apache JServ) and we typically run a single VM ("java" command) for about 3-6 weeks, accumulating a couple of hundred hours CPU.
The thing I find most interesting in your test is the speed ratio - despite the disadvantage that you've given Java, it's less than 2:1 which is better than I suspect most people would expect. This is number cruching, it's not what Java does well, althoguh the gap has closed enough for it not to be a concern. I saw a paper about 18 months ago (can't remember the reference)
Nowadays, very few apps do enough computation to redline the CPU in any useful sense - the limiting factor is I/O.
The real advantage of Java is not so easy to benchmark, and that is indeed developer productivity; the app is not rocket science, but it has some very useful platform layer caching between itself and the database. There is no way we could have gotten as far as we did with this with so few people in this amount of time if we had to build it in C++ and worry about type issues and garbage collection.
This productivity advantage far outweighs the 25 to 50% performance penalty of using Java - the limiting factor in our app is not CPU, depending on the individual screen it's either I/O bandwidth to the browser or I/O speed to disk. Not much we can do about the former for end users (though we make sure customers using our admin tool get a cable modem / DSL) and our caching is making good strides at the latter. I have yet to ask a developer to recode an algorithm for **CPU efficiency**, though I do keep a close eye on database and filesystem I/O load, memory footprint (JVM heap), and HTML page weight.
Assuming we can deliver pages to browsers close to as fast as the users' connections can handle them, the efficiency of the overall system to our business is measured in $$$, and includes the cost of developer time (lots) and the cost of hardware (small) - throwing hardware at it here **is** the right solution.
For appservers, we use rackmount dual Pentium 3 pizza boxes, running two Sun 1.2.2 green threads JVM's on Linux; I picked up **twenty-two** of these, less than a year old, at the deja.com sell off in Feb 2001 for about 10 grand total. That won't even cover the fully loaded cost (salary, taxes, medical and Mountain Dew
Bear in mind guys, I'm not a suit, I'm a techie - I have a Ph.D not an MBA, and my background curiously enough is in one of the few areas where the CPU performance **does** matter, doing compute intensive stuff, mostly FORTRAN and C and mostly on hardware made by Cray Research. This gives me the perspective to know when and where performance matters, and I chose Java with that in mind.
David Crooke
Chief Technology Officer
Convio
Osama Bin Laden is the only nutter with the will and resources to pull this off. Lone psychotics like McVeigh do not hijack four aircraft.
It's a nice intellectual tech question, to which the answer seems to be (a) no, it's not that simple, because (b) no demand == no engineering effort to make it work.
:-)
There's also a practical question - how do you get a decent amount of upstream bandwidth from your home? The best answer appears to be the higher tiers of ADSL; here in Austin TX, the top tier is 1.5M/6.0M and hence you're getting (almost) T1 speed up. A colleague of mine runs a mini hosting service from his house as a sideline, using this technology. Comes with a static subnet for around $300 pcm, which is still a good bit cheaper than a T1. Like most minor pushers, he does it to feed his own bandwidth habit; 5.8M of that downstream is his to play with
T1's are also coming down a lot, and $700 is now the bottom end of pricing - this may be viable if you have some $$$ coming in to support it.
For myself, I use a $45 pcm cable modem, which only allows 0.3M up, but it's plenty for the range of services I host off my home box - my own usage is still msotly down (esp big downloads) and the steady 2.0M down at this price is good value.
The lack of a static IP on my service is an annoyance, but dynamic DNS is a good substitute, andI only ever change IP's on a reboot, which is typically once every 2-3 months; I have the source code for the specialised DHCP client daemon so I guess I could hack it to request the previous IP over again.
There are liars, damned liars, and statisticians. Then someone in marketing gets the graphs....