>Sony, which manufactures the top-selling Playstation games, said it had never received any feedback or
>complaints about hand-arm vibration syndrome after 61 million sales world-wide of Playstations I and II.
>
>It stressed that there was occasional, but no constant vibration during either game.
Dude, like, I was playing a mean game of PlayStation II all night. I can't wait to see how it ends.
>It's good to see the developers of Apache continuing to improve their software because if they were to
>stop doing so, Microsoft would soon provide something as good or better. As a company, Microsoft
>is ferociously competitive.
Um, no. If they were to stop, Microsoft would soon stop also. There would be new releases but they wouldn't really add much.
Seen IE 5.5 or 6? Back when Netscape owned the browser market, each new release came with something earth-shattering like tables, LiveScript (now called JavaScript), frames, SSL, plugins, applets, animated GIFs... yeah, they gave us the blink tag too, and many of those other technologies have been abused by some content providers (flashing popup ad windows!) but seriously, every new release made a huge difference in what a browser was capable of. Huge. Then Microsoft came and killed Netscape by using monopoly profits from Windows to fund a web browser project that cloned Navigator, and a web server project that more or less cloned NCSA httpd, and giving both away for free.
Now Microsoft gives us IE 6, which includes some UI changes and some minor updates to stuff like CSS support. This is the amazing innovation that Bill Gates loves to brag about, that an antitrust remedy would prevent. Don't get me wrong, improved compliance with standards is a good thing, but the browser market is basically dead, and there's not much innovation going on anymore. Of course there's Mozilla, but that's basically cloning IE 5, which is no surprise since open source projects seldom innovate either (they just clone closed-source products or implement existing open standards).
Apache will continue to incorporate support for new standards, but don't expect it to blow your mind. Look at the 2.0 new features list... new threading model? New module API? Wow, my web sites will never be the same! Well, WebDAV is a welcome addition, but it's not as though Apache just invented WebDAV; that's been available for Apache 1.3.x for over a year and a half.
Microsoft knows that the web server market is dead, from a profit standpoint - you can't sell a standalone web server anymore. They'll just keep updating it and bundling it with Windows so that the overall Windows platform checks out OK versus the competition. Since there's no money to be made here, why bother innovating?
>Java is infinitely preferable to C#+CLR, simply
>because there is no platform lockin, or vendor
>lockin (you can get great JVMs from IBM, for
>instance).
You couldn't be more confused about this issue. You have it exactly backwards.
I've been a Java developer for over four years now and although I trust Sun a whole lot more than Microsoft, the fact is, Java is a proprietary standard owned and licensed solely by Sun, whereas C# and the CLR are open standards managed by ECMA. Microsoft has been looking for a chink in Java's armor for years, and the only thing they could find was the fact that open-standards folks hated the proprietary nature of Java. So, they made the basic parts of.NET open.
Java and everything about it are controlled by Sun. There is an IBM JVM because IBM licensed the rights to do so from Sun. Even a clean-room JVM implementation still has to sign a license with Sun to call itself Java, and has to be tested with the compatibility suite from Sun, which costs money and requires that the implementor sign a license agreement with Sun. Microsoft played games with their JVM and Sun sued them for breaking the license agreement, remember? Please explain how there is no platform or vendor lockin in this situation. So far Java has experienced vendor lockin, just to a benevolent vendor (so far). They have been good about allowing other vendors to influence the specs they publish, but in the end, the J2SE, J2ME, J2EE, and other Java specifications all come from Sun and belong to Sun 100%.
Oh, yeah, there's Kaffe, and GNU Classpath for Java, which are cleanroom implementations with no license and no permission to call themselves Java, and guess what, they are still broken, not compliant with even JDK 1.1, and have been under development for something like five years now. I dare you to try to get JBuilder running on them. I really, really wish them good luck, but so far they are a major disappointment.
On the other hand, C#, the CLR, and the core classes of.NET are an ECMA standard. You can choose not to trust Microsoft, and still look at the standards and see if they are worth using or not. This is what Ximian has done, and they decided the standards were worth using. If Microsoft then chooses to go off and violate the ECMA standard, that doesn't lock you into their proprietary version; you can still stick with the ECMA standard, and all the implementations that adhere to it, and tell MS to take a flyng leap.
The real thing that people need to be concerned about is how objective and open ECMA is going forward. Microsoft has been known to try to hijack standards bodies before; if they can control ECMA, then they can claim that it's an open standard when in fact it would be a sham.
Population is something strongly in China's favor. For example, for a university that will take 1000 CS students a year, if you get to pick 1000 from 1,000,000 applicants, those 1000 will probably be smarter (and more motivated) than if you get to pick from 10,000 applicants. Also, if you have 1000 Chinese firms competing for a US project, that would tend to give the US company more leverage to go cheap or go for the best firm out of 1000, than 100.
That's the theory, anyway. Still, managing offshore development is tough, to say the least.
>There was a serious issue with degradation though.
>The longer the light was trapped in the gas, the
>poorer the quality the beam of light was when it
>was reanimated.
How many consumer type people (meaning non computer weenies) do you know who say things like, "my computer has Windows 98 on it now but I want to get a new one with Linux on it soon"?
Most people don't actually like messing with their computer; they want to use a few applications and get off of it. IM, Napster, email, Word, Excel, and a web browser are the kind of thing that make people put up with computers. They also don't like shopping for computers.
So the most recent Linux distros are marginally faster at some tasks than Win2k? Well gee, switching would make your 1.7GHz P4 run like a 1.8GHz P4! What a compelling selling point. That's worth about $30 right now based on dell.com's pricing.
On the other hand, a consumer is going to have a lot better chance finding someone to help them install Windows apps than Linux apps. Also, take a look at apps like InstallShield, and compare that to rpm or gnorpm. It's no contest, the Windows or MacOS installation experience is so much better.
AFAIK, nobody is trying to make Linux easy to use. They're trying to make one app easy to use, and there's no UI consistency. MacOS, Windows, and even Java have user interface guidelines that application developers follow. Apple and Microsoft also look at the whole system and try to make it more usable overall. Windows falls down in the "installing a new network card driver" department, for example; don't get me wrong. But with Linux, everything requires you to learn a whole new skill set. Want to install software? Maybe it's./configure make make install. Maybe it's an RPM. Maybe it's a tarball with a shell script that you have to run. Who knows?
Until Linux does something that a whole lot of people really really want, which Windows doesn't, it won't become popular. The threshold of how cool that something has to be is set by the extremely poor usability of Linux.
I dare anyone to put Windows, MacOS, and Linux (pick your distro) in a room and time a computer newbie trying to get all this done:
- install the OS from CD onto an unpartitioned brand-new 60GB IDE hard disk.
- install a CD burner, network card, digital still camera, digital videocamera, 2 monitors, USB optical mouse, USB MP3 player, low-end laser printer; perform a basic test to make sure each is working.
- install Microsoft Office or StarOffice or whatever app suite you like; launch each app to make sure it works
- connect to an existing e-mail account and download an attachment in Excel format. Print it.
- install a browser that has 128-bit crypto
- connect to an online banking site that requires 128-bit crypto, and print a current statement
- Create an MS Word formatted document and save it.
- install a chat client for AOL, MSN, and Yahoo; send the new Word document to a friend on each of AIM, MSN, and YIM.
- install a USB webcam; have a chat session with a friend on YIM.
I predict that Linux won't be the OS on which the newbie will be able to get all this done most quickly. That's the kind of benchmark that Linux needs to win in order for ordinary people to care about it.
P2P = catchall buzzword; lacks a killer app.
on
P2P in 2001
·
· Score: 3, Insightful
If you define P2P to include distributed computing, where a central server tells a bunch of nodes what to do (which seems outside of the scope of P2P to me), then wow, P2P has really taken off. Heck, with that definition, Pixar uses P2P render farms for their movies.
On the other hand, if you define peer-to-peer in a more pure sense, where each node is a peer, doing its own thing and maybe using one or more directory servers or repeaters to find others, then Napster looks like the only winner I can think of, and it's clearly dead now that it's gone legit. Most IM apps look like client-server to me, although they have some P2P aspects such as file transfer... they're not any different from IRC + DCC, really.
I interviewed with a couple of local (SF) "P2P" companies (really internet-based distributed computing platform vendors) a year ago, and they were having trouble selling their concept even then. Yes, there are CPU-intensive tasks out there that companies would pay to accomplish, but they tend to operate on a lot of data, and that data tends to be sensitive/confidential. One company was refocusing on internal deployments only - using corporate desktops inside the firewall to run distributed tasks at night. That mostly solves the bandwidth and sensitivity issues, although in a WAN environment you might not be able to use remote LANs if the pipe to the remote LANs are too small for the amount of data being crunched.
It's hard to think of too many true P2P applications. P2P architectures that don't include central directory servers or reflectors tend not to scale - think back to old LAN protocols that didn't scale well a WAN context. It's the same problem but at a higher level. The more scalable protocols use some form of central servers or at least a group of more centralized peers (routers, PDCs, whatever) to find one another. Pure P2P doesn't scale due to network inefficiencies (think Gnutella without repeaters); pure client-server doesn't scale due to node scalability limits. A hybrid such as Napster or the WWW scales very well, though. (The whole web isn't on one big server...)
With appropriate signatures, open-source software distribution might be a good P2P application. Instead of hunting around for a fast mirror, why not grab it from a peer, provided the signature is valid? Only the signature has to come from the main server (or a mirror).
The problem with that is the same as what everybody finds when using Bearshare, Kazaa, etc. - upstream bandwidth from peers is very limited. ADSL, "56K" modems, and cable modems all tend to be asymmetric, limiting a P2P network run over them to the collective upstream bandwidth. Imagine 10 people with DSL, trying to swap 10 files - no matter how you slice it, everybody might as well be downloading from one guy. A P2P file sharing program called eDonkey2000 tried to avoid the single-source problem Napster and Gnutella face by using hashes to request files by hash rather than filename, so multiple peers can send you slices of the file even if the name differs, and even if some of them drop out over time. It's nice for big files because you will eventually get all the parts from somebody, but it's still slow.
I think that perhaps multicasting is the only solution for this. P2P plus multicasting would eliminate the problem of popular servers being swamped by requests.
I can't be bothered to look up the reference, but at some point I read about some folks who tried to make up a binary protocol to be as compact as possible, and they couldn't make it more efficient than a gzipped text protocol. Even if you're within 10%, don't bother, just gzip it and move on.
Well, margins are razor thin, and various PC companies (Compaq and IBM, for example) have publicly expressed that they may give up soon, and stop making PC's. Network appliance makers couldn't seem to get their products under the $400-$500 price range without removing a critical component such as the hard disk. Many years ago when I was selling PC's in college, the minimum price was about $1200, below which the mfrs would just give up and discontinue the product. Apparently some combination of obsolescence and shrinking profit made it pointless to keep making them at that time.
Of course, PC's are much cheaper now. From what I've experienced in the past 2 weeks while visiting friends who are normal people (not computer weenies like me), the reason they upgrade is mostly to fix software configuration problems that make the computer ridiculously slow, and less to get new features, although that's nice too. Stuff that power users wouldn't put up with, like a 4-5 minute freeze at boot time due to a configuration problem, are things that normal users put up with. "This computer is so slow, I need a new one" is a real quote from a person I know who had a problem like that.
I think that disposable PC's might be a viable idea, if someone could figure out how to make the important data survive while killing the worthless corrupted data. My parents had an old black-and-white TV set with old-style knobs to change the channel, and it went on the fritz. Did they fix it? Hell no, they tossed it and bought a new one. If PC's reach the $100 price point, that's what people would do with them, too. But the data is an issue.
Maybe instead of NC's using broadband to get to a central server, we could have a central server in the house and NC's running the apps? Separate the data three ways: app installers, data, and user profile info. Apps install on the local machine, data is on the server, and profiles are on the server. If the apps hose each other, nuke the local macine and reinstall apps as needed. No more DLL rot. If your profile is broken, nuke it but your data is safe.
Regardless, it's clear to me that complexity is the issue, not price point. If PC's were free, there would still be people who wouldn't want one.
Bloat, no. Abstraction, yes. The problem that most people have with Microsoft's software is that as Mr. Gates is happy to explain, they target current/future hardware and expect users to upgrade. That would be OK, *if* there were high-quality releases that users could buy and stay with indefinitely. However, this is not the case - M$ software is notoriously buggy, and the only fix for the bugs you suffer today is to buy the next version, which requires a new computer. At some point, which I argue was reached with Win2K and Office 97, the features people use work, and the features that are broken are unimportant, so the upgrade treadmill breaks.
I don't mind the fact that Linux is written in a portable assembly-language called C. I want my kernel code and drivers to be as fast as possible. I do mind the fact that people are still writing end-user and server applications in C, and are still trying to get all the goddamned buffer overflow and memory management bugs out. Come on, it's been what, about 30 years now? C++ fixes a lot of these problems, as do the higher-level garbage collected languages.
The pity is that there is this constant murmur of bitching by the/. and Linux community that [insert high level OO language here] is so slow that it can't be used. Really? How fast is/bin/sh at running that floating point benchmark? How fast are sendmail rules? I don't see anybody benchmarking the code used for Linux's "make xconfig". That's because IT DOESN'T MATTER.
Unix gets a certain idea right, and it isn't "everything has to be written in C for maximum speed". Look around a *nix system and tell me that everything is written in C. It isn't. The idea that Unix gets right is that of well-written modular components which can be assembled to do various different tasks. In Unix that happens to be accomplished by components which are written in C, and which are carefully tested, which are then glued together with slower, higher-level languages (shell scripts etc.). Contrast that with Windows, where everything is a C API that is implemented by a native DLL, but you are expected to use C or VB in an IDE to automate anything. That's not nearly as flexible or powerful as the way Unix does the same thing - with slow, garbage-collected, high-level scripting languages. This is why application installers on Windows use commercial installer products (written in native languages with proprietary scripting languages built on top of them) while Unix apps use/bin/sh scripts to install themselves. (Have you benchmarked autoconf lately? But I bet you've used it...)
The more CPU power we have, the better, because it will allow us to push more code into the flexible, high-level, safe, garbage-collected languages which don't have seg faults, buffer overflows, endian issues, etc.
If people buld software properly and write performance-intensive code in low-level languages, and write functionality-intensive code in high-level languages, we'll actually be able to use Moore's law to get better software written faster. If we keep bitching about Java, Smalltalk, Python, Eiffel, C#, VB, etc. being too slow for any purpose, we'll still be patching daemons every other week to avoid buffer overrun vulnerabilities in C code, and downloading & installing ever newer versions of each our crappy GUI apps in hopes that this one won't bomb when we actually try to do work with it.
I read Joel's original article on this subject("Things You Should Never Do, Part I") a few months ago. Despite the rampant/. kiddie practice of posting a strong opinion without reading the article being referenced, I encourage you to read it now:
OK, so you didn't read it, I'll quote a juicy part: "You are putting yourself in an extremely dangerous position where you will be shipping an old version of the code for several years, completely unable to make any strategic changes or react to new features that the market demands, because you don't have shippable code. You might as well just close for business for the duration."
The point is that if you have all the time and money in the world, of course you should rewrite from scratch when things get yucky. The problem is that in the real world, companies need new releases to keep selling upgrades, so you need to keep steadily improving the product. Similarly, customers adopt the product, use it a bit, and then learn what they want next - they want to invest in the product more. Meanwhile, the purist coders at the vendor are busy taking three years to make the architecture pretty, which will pay off big-time in year 4 and 5 when they'll be able to add new features at a breathtaking pace. Customers get pissed and go find someone who will sell them a product which is about as buggy as the one the first company made, but which now has a few key features.
Coders don't necessarily understand the sales angle of this, because they're trying to avoid inefficiencies in development, such as wasting time hacking on a crufty code base to try and add a feature. They'd rather invest early and reap rewards later. The problem is, most software companies don't have the luxury of investing heavily from a payroll standpoint, not even considering the customer attrition problem.
As a perfectionist myself, I really hate the fact that this is true, but it is. Business realities suck sometimes. There's a sci-fi business parable about this...
Two space empires are at war. One side is starting to lose, but one day their leader announces that they will soon be victorious! Their scientists are working on a doomsday device which will wipe out the enemy. Time passes and the war is going badly, but no one is worried about the heavy casualties because they know they will win any day now. Planet after planet is captured, ship after ship destroyed. Finally, one day the lead scientist who is working on the homeworld screams "Eureka!" because he knows that the device finally works. He races to the office of the imperial leader and bursts in, full of excitement, only to see enemy soldiers standing over him with guns drawn as he signs his name to articles of surrender, because they've lost.
Unfortunately for the scientist and his empire, they didn't think to refactor, or design APIs between modules...:) If they had they'd be able to clean things up module by module, because they designed robust APIs early and then wrote quick and dirty implementations that could be fixed later when there was both time and need.
eXtreme Programming has some interesting things to say about this too. Basically, don't implement anything that isn't in the requirements now (that is, don't overgeneralize to a fancy-pants API and module system if you're only gonna write one module on top of that API), also known as DoTheSimplestThingThatCouldPossiblyWork, and RefactorMercilessly to clean up code continuously as you maintain it.
Finally, remember that testing makes maintenance immeasurably easier. The reason that maintenance sucks so bad is usually that some cowboy coder thought that documentation is what you do when the code is finished, which of course (a) is wrong and (b) never actually happens. If docs are demanded up front, including test cases, coding is much easier as is maintenance, and you don't have to bite your fingernails wondering if your tiny bug fix un-fixed 100 other "fixed" bugs. If you have tests, you can RefactorMercilessly and rip out the most egregiously gross code, and get it all back together and working, without it blowing up in your face. So make sure somebody writes a basic spec, then write test cases and code that performs them so you can code with impunity and so you can go on vacation:)
OK, so Microsoft has a practice of hiring freshly graduated CS majors so they can begin brainwashing them early about what working at a software company is like. Fine. That drains the young'uns of real world programming experience, where inventing five new opaque binary file formats with every program is not OK, nor is obsessing over making Solitaire's shuffling algorithm O(N) instead of O(log(N)) worthy of a semester project for a team of six.
However, Microsoft's insular cluelessness aside, do you really think that the gub-mint Windows sysadmins languishing in some mildewy room in the basement of a federal ofice building are going to know what they're doing? Have you seen government salaries lately? These are the people who convert several 700yd runs of bare-pair phone cable to Ethernet using only a crimper, and wonder why they can't seem to get sustained 10MBps throughput across it. The lucky ones learn on Uncle Sam's dime and move on to a Real Job making Real Money eventually. Others just fester there forever, making technical decisions so horrible that others refuse to believe you when you describe them.
I worked for the government very early in my career. I was definitely clueless, and more importantly, we were insanely understaffed. Microsoft is huge and has "R&D" teams working on stupid crap like vibrating joysticks and general-purpose speech recognition - ever notice that EVERYBODY in your office wears headphones? Now wait until you have to yell at your computer all day just to get work done - meanwhile the government is busily trying to roll out Win95 to the last few field offices that still have 66Mhz Pentiums.
In case you are unclear, I'm saying that monopoly-funded hordes of inexperienced but smart and college-educated Microsofties are more likely to get a code something properly than an overextended handful of unmotivated, underpaid, self-taught recent help-desk graduates are to install it properly.
There's a more specific benefit to clustered persistence via application-level session replication: less load on the database. Allow me to elaborate.
For a stateless app, such as a public web site with static content, IP based load balancing works fine. For a stateful app, there are actually 3 options, not 2 as mentioned above.
1) Neither save nor replicate state. App dies, user fails over to another server, back to login. Lame.
2) Save state in the database after every page view. App dies, user fails over to another server (doesn't matter which one), other server notices it doesn't have the user's state in memory and loads it. Acceptable, but complex, and beats up the database quite a bit. If I am not mistaken, this is the only option for most non-Java app server situations (CF, ASP, PHP).
3) Replicate state directly from app server to app server. After every request, the app server copies the state info for each user to a failover server. Server dies, load balancer redirects the user to another server, that server has the state info in memory, ta da, no loss of state, and no load on the DB. The new app server starts publishing the user's state info in case it also dies.
For a concrete example, imagine an e-commerce app with a shopping cart or complex product search as your main state. In #1, you lose your shopping cart and get logged out; log back in and your cart is empty. Suckage. In #2, it works but the developer has to save the shopping cart or search criteria to the database every time the app services a request, because any request could be the first one that goes to the failover server. OK for you, super suckage for the developer, and the DBA, because every time you ask the server to do something, it does that and then also saves your shopping cart, so the DB is constantly doing updates to a single table no matter what else it's doing. (In case you don't know about databases, writes are far more costly than reads for an RDBMS, so it's much more work to save a shopping cart again and again than it is to fetch product info, show all products whose vendor name is 'Sony', etc.) In #3, it's pretty much transparent to the developer, and the DB is just doing the work you would expect would be needed based on user activity. You just need a slick app server to make it work.
Clearly, keeping state info small is necessary to prevent session replication from eating up all your bandwidth. Also, every app server I've seen which does this picks a single backup app server to send session info to (rather than copying each session to several other servers each time). This means that the load balancer must choose the right server to failover to; this is done by encoding the IP address of the primary and backup app server in the session cookie, so the load balancer can use that info as it recieves a request to decide which server will get the hit. When the backup server gets hit, it changes the cookie to say it's the new primary, and to say which new IP is the one for the new failover server. If I understand correctly, in an imaginary server farm of 8 app servers, each user might have a backup session on any of the other 7 servers - the app servers choose this dynamically.
Anyway, the big idea here is that you tell all the app servers what all the IP addresses are for the other app servers, and keep your session object small, and It Just Works. No need to copy junk to the DB all the time; no need to check if you have the info cached. But your load balancer has to support your app server so it can do the "session affinity" thing - returning a user to the same app server again and again unless the server dies.
If "sold out" == "best selling", Macs would have outsold PCs a few years ago, when Apple was transitioning to just-in-time manufacturing and hadn't yet abandoned all their wierd custom ASIC to support their proprietary hardware interfaces. They had obscene hardware shortages all the time (6-8 weeks was typical between a retailer ordering a machine and actually getting it; hot high-end models were more like 12 weeks) which obviously limited their market share... if you have no inventory to sell, it's awfully hard to ship more than your competition.
Looking at retail stock levels doesn't tell you anything. Unit sales are what you should be looking at, and it looks like Nintendo did a great job of meeting (and exceeding) demand. The real question is, once the pent-up demand has been satisfied, how many will have been sold, and what will the ongoing unit sales rate look like? In January, once Xmas sales are over and restocking has allowed folks to say "dammit I didn't get it as a gift, gotta buy it for myself" etc., sales will very likely level off.
But... will The Bedazzler theme allow sub-themes, written in XML with MPEG-4 animation movies and dts surround sounds when you drag windows?
Go read asktog.com and ask yourself why in Win2K, a left click at any edge of the screen does nothing, even though that's the easiest part of the screen to hit and the default key. Then ask why all the rebellious Linux GUI developers are just cloning Windows' look and feel. Oh, it's to make Windows users feel more comfortable? Well then by all means, add C:\ and regedit and COM1/2/3/4 and cmd.exe and... oh wait.
No, we'd be better off adding network plumbing, replacing all the file formats with [slower-parsing, bigger] XML based formats, making more themes, supporting new and even more radical component models, and other shit that only developers care about. After all, why bother with usability testing? That foofy stuff is just for "lusers", and everybody knows Linux has way too many users and not enough developers.
Q: What is the #1 GUI application category for Linux?
A: Screenshot maker.
Q: What are the #2 and #3 application categories for Linux?
A: Terminal and MP3 player.
Q: Why don't Linux users just use a serial terminal and an MP3 player, since it would be cheaper and require less configuration effort?
A: You can't take a screenshot of a serial terminal or an MP3 player, and ASCII porn just doesn't cut it.
Q: Why won't open source eliminate commercial software developers?
A: Because open-source developers solve problems faced by open-source developers, while commercial software developers solve problems for everybody else.
I know, I'm being too harsh, I run a few Linux boxen at home and have for years. This is a bitter rant made in jest. Laugh, but recognize the part that rings true.
Believe it or not, there is this thing called "open source", based on the little-known fact that if you get information from someone, they still have it. Or at least I think some guys named Thomas Jefferson, Richard Stallman, and Eric Raymond were saying something about that. I think they, like, said something about how it's different from material things because you don't deprive the original owner of it when you "steal" it.
Yes, javac is written in Java, and that's why it's hella slow. Try putting it in a Makefile sometime. Ugh. That's why IBM's Jikes compiler is written in C++... much faster startup and compilation. In my tests Jikes is 7-20 times faster. I haven't tried Jikes on any of the new Java 1.4 stuff (assertions) so it may not be an option in that case.
Another possible interpretation is that Apple is OK with a non-native Aqua implementation as long as its look and feel are *exactly* like the native implementation, thereby providing a 100% consistent experience. Just a thought. I don't think Apple cares as much about APIs as they do about user experience, so it seems they would be more concerned about a half-assed Aqua clone annoying users than they would about a perfect Aqua clone that didn't happen to make the right API calls under the covers. So the info they would be giving would be the spec for how Aqua behaves, not the API docs which are already available.
>Failure to do this results in customers switching to
>another provider. This is *especially* true of DSL
>customers for whom other providers are nearly
>guaranteed to exist (since DSL has open access).
Huh? You must not have been paying attention to the DSL market in the last year or so. All the CLECs are going out of business, leaving the ILECs as a de facto monopoly. Covad is the poster child for this:
I run Win2k pro on my desktop (for s/w development) and IIS is not part of the install... I doubt that a typical user's machine on DSL or a cable modem is running IIS at all. NT 4 is a different matter.
The definition of an "interactive digital device" is incredibly broad:
"any machine, device, product, software, or technology, whether or not included with or as part of some other machine, device, product, software, or technology, that is designed, marketed or used for the primary purpose of, and that is capable of, storing, retrieving, processing, performing, transmitting, receiving, or copying information in digital form."
When I was a teenager I was an electronics hobbyist and I assembled a simple computer based on a 68000 CPU I bought at a computer flea market. Total parts cost something like US$50. That would be illegal if this law were passed. MindStorms would also need DRM hardware. Electrical Engineering students would need to incorporate DRM in all their projects if they were sufficiently complex. That raises another question - exactly how sophisticated does a device need to be for this law to require that it have DRM? According to the draft, all of the following would apply:
A potato clock?
A digital thermostat (has a CPU in it...)?
The digital time clock at the 7-11?
A digital watch with text memo capability (it could hold the DeCSS algorithm! Oh no!)?
A router?
A modem?
An Ethernet switch?
An Ethernet hub?
An Ethernet cable?
A can of soup carrying a UPC code?
A carrier pigeon with a TCP/IP packet strapped to its leg?
It's pretty clear that it would be illegal to build your own PC without incorporating a government-approved DRM component.
[troll] Hmm, what if the component only comes with a driver for Windows on x86 hardware? Installing Linux becomes a federal crime, since you're disabling the DRM hardware by deleting the driver! Wheeee![/troll]
As for penalties, let's all think about whether getting an EE degree involves private financial gain. That's the idea, right? So building a project computer sans DRM is punishable by 5 years in jail. Neat!
Send money to the EFF as soon as possible; let's make sure this law gets clobbered.
You said it. It's hard for a Linux zealot to think this way, but normal businesses don't care about the FSF and the open source crusade; they don't care about X11 or gcc or ssh. Most IT folks in real businesses barely know WTF they are doing, so they pick the mainstream vendor with the GUI interface and firmly believe that market share proves quality and that anything they can't get working is due to their own problems.
Against this backdrop, they're not going to go out looking for obscure platforms (meaning !=Windows to them) and companies which only support these obscure platforms. They're going to pick a big company that will help them with what they have now, and who can make a convincing argument about having skills for more complex needs and future enhancements. A company like IBM could plausibly get some Linux boxes in because they're not spouting irrelevant platitudes about freedom; they're talking business and are fully capable of dealing with the answer "I don't care, do it with Windows anyway".
>My guess is that the 64 bit x86 (Intel or AMD) will become far cheaper than the Sun counterparts
Solaris runs on x86 now and is free on machines with less than 8 CPUS. It was demonstrated as working on Itanium almost 2 years ago:
http://www.sun.com/smi/Press/sunflash/9910/sunfl as h.991025.4.html
I would be surprised if Sun doesn't ship a production IA-64 release of Solaris when IA64 hardware is widely available.
That means that there are multiple independent axes of competition:
-- IA-64 vs. UltraSPARC III
It's pretty commonly believed that IA-64 will dominate, but then again, IA-64 is very late, and Intel has shown weakness in its engineering with the P4, so it's not exactly in the bag. Linux and Solaris server buyers will happily buy whichever seems like a better deal (based on price/performance, availability, etc.), because they can just recompile their apps, or demand that their vendors do so (which works if enough customers are asking for it). Windows server buyers will buy IA-64 because they have no choice.
-- 64-bit Solaris vs. 64-bit Windows (vs. 64-bit Linux)
Here's where things get a bit more interesting. Except for the most trivial or acrobatically-coded apps, you can't just recompile to jump from one OS to the other, so the choice of OS will be more carefully made than the choice of hardware IMO. And here's where the scalability of Windows and Linux is called into question: can you run 64-bit Windows effectively on a 16, 32, or 64-way multiprocessing server? Because if you can't, Solaris is the only one of the three which scales from the little 1-CPU boxen up to a 64-way box such as the Ultra Enterprise 10000. Obviously IBM, HP, Compaq, et alia are also up in the high end there, but for a customer who's trying to consolidate OS's so that little and very big servers alike run the same OS, Solaris stands out. I'm not saying that it is or isn't wise to consolidate OSs, nor that there are zillions of companies who need 64-way processing, just making a point about Solaris's seemingly unique scalability in both directions. Anyone who has used all three of these OS's will also note that Solaris and especially Linux scale *down* better than Win32.
In short, the really interesting question is, "how many CPUs can 64-bit Windows on IA-64 use effectively?" Not "how much will it cost", since that doesn't matter if its performance is unacceptable. Linux is quite capable of not performing acceptably on large MP machines, and it's free:)
Of course, if a cluster of small MP machines suits your app, this is all irrelevant, because perhaps all you really needed was more RAM per cluster member.
Most importantly, what do they plan to do once the system decides there's a match? Let's say the system is approximately as good at face recognition as a human (not sure this is the case but for the sake of argument assume it is). Imagine that there are hundreds of security officers looking at all the security cameras in the store all the time. Remember, in a retail store you're already under constant surveillance and you're being recorded as well. The difference is, your presence is being used as a chance to compare your face to a bunch of head shots of "known shoplifters". The technology is not the issue, unless it results in lots of false positive matches. The issue is what happens when they think you're a known shoplifter. Do store security guards try to detain you? Eject you? Restrain you? Search your person? Demand to see your identification?
In the US, a shoplifter has to be seen in the act of concealing something. You can't just see someone with a book go around a corner and come back without it. If you don't catch them in the act of concealing it then you can't bust them.
Does Border's think they can harass people who they suspect of prior shoplifting? Do their security guards? I think that's the interesting question, because videotaped surveillance cameras and "wanted" posters are hardly anything new, even if made more efficient thru technology.
Slashdot Mirror
>Sony, which manufactures the top-selling Playstation games, said it had never received any feedback or
>complaints about hand-arm vibration syndrome after 61 million sales world-wide of Playstations I and II.
>
>It stressed that there was occasional, but no constant vibration during either game.
Dude, like, I was playing a mean game of PlayStation II all night. I can't wait to see how it ends.
>It's good to see the developers of Apache continuing to improve their software because if they were to
>stop doing so, Microsoft would soon provide something as good or better. As a company, Microsoft
>is ferociously competitive.
Um, no. If they were to stop, Microsoft would soon stop also. There would be new releases but they wouldn't really add much.
Seen IE 5.5 or 6? Back when Netscape owned the browser market, each new release came with something earth-shattering like tables, LiveScript (now called JavaScript), frames, SSL, plugins, applets, animated GIFs... yeah, they gave us the blink tag too, and many of those other technologies have been abused by some content providers (flashing popup ad windows!) but seriously, every new release made a huge difference in what a browser was capable of. Huge. Then Microsoft came and killed Netscape by using monopoly profits from Windows to fund a web browser project that cloned Navigator, and a web server project that more or less cloned NCSA httpd, and giving both away for free.
Now Microsoft gives us IE 6, which includes some UI changes and some minor updates to stuff like CSS support. This is the amazing innovation that Bill Gates loves to brag about, that an antitrust remedy would prevent. Don't get me wrong, improved compliance with standards is a good thing, but the browser market is basically dead, and there's not much innovation going on anymore. Of course there's Mozilla, but that's basically cloning IE 5, which is no surprise since open source projects seldom innovate either (they just clone closed-source products or implement existing open standards).
Apache will continue to incorporate support for new standards, but don't expect it to blow your mind. Look at the 2.0 new features list... new threading model? New module API? Wow, my web sites will never be the same! Well, WebDAV is a welcome addition, but it's not as though Apache just invented WebDAV; that's been available for Apache 1.3.x for over a year and a half.
Microsoft knows that the web server market is dead, from a profit standpoint - you can't sell a standalone web server anymore. They'll just keep updating it and bundling it with Windows so that the overall Windows platform checks out OK versus the competition. Since there's no money to be made here, why bother innovating?
>Java is infinitely preferable to C#+CLR, simply
.NET open.
.NET are an ECMA standard. You can choose not to trust Microsoft, and still look at the standards and see if they are worth using or not. This is what Ximian has done, and they decided the standards were worth using. If Microsoft then chooses to go off and violate the ECMA standard, that doesn't lock you into their proprietary version; you can still stick with the ECMA standard, and all the implementations that adhere to it, and tell MS to take a flyng leap.
>because there is no platform lockin, or vendor
>lockin (you can get great JVMs from IBM, for
>instance).
You couldn't be more confused about this issue. You have it exactly backwards.
I've been a Java developer for over four years now and although I trust Sun a whole lot more than Microsoft, the fact is, Java is a proprietary standard owned and licensed solely by Sun, whereas C# and the CLR are open standards managed by ECMA. Microsoft has been looking for a chink in Java's armor for years, and the only thing they could find was the fact that open-standards folks hated the proprietary nature of Java. So, they made the basic parts of
Java and everything about it are controlled by Sun. There is an IBM JVM because IBM licensed the rights to do so from Sun. Even a clean-room JVM implementation still has to sign a license with Sun to call itself Java, and has to be tested with the compatibility suite from Sun, which costs money and requires that the implementor sign a license agreement with Sun. Microsoft played games with their JVM and Sun sued them for breaking the license agreement, remember? Please explain how there is no platform or vendor lockin in this situation. So far Java has experienced vendor lockin, just to a benevolent vendor (so far). They have been good about allowing other vendors to influence the specs they publish, but in the end, the J2SE, J2ME, J2EE, and other Java specifications all come from Sun and belong to Sun 100%.
Oh, yeah, there's Kaffe, and GNU Classpath for Java, which are cleanroom implementations with no license and no permission to call themselves Java, and guess what, they are still broken, not compliant with even JDK 1.1, and have been under development for something like five years now. I dare you to try to get JBuilder running on them. I really, really wish them good luck, but so far they are a major disappointment.
On the other hand, C#, the CLR, and the core classes of
The real thing that people need to be concerned about is how objective and open ECMA is going forward. Microsoft has been known to try to hijack standards bodies before; if they can control ECMA, then they can claim that it's an open standard when in fact it would be a sham.
Population is something strongly in China's favor. For example, for a university that will take 1000 CS students a year, if you get to pick 1000 from 1,000,000 applicants, those 1000 will probably be smarter (and more motivated) than if you get to pick from 10,000 applicants. Also, if you have 1000 Chinese firms competing for a US project, that would tend to give the US company more leverage to go cheap or go for the best firm out of 1000, than 100.
That's the theory, anyway. Still, managing offshore development is tough, to say the least.
>There was a serious issue with degradation though.
:)
>The longer the light was trapped in the gas, the
>poorer the quality the beam of light was when it
>was reanimated.
Sounds like DRAM. Problem already solved.
How many consumer type people (meaning non computer weenies) do you know who say things like, "my computer has Windows 98 on it now but I want to get a new one with Linux on it soon"?
./configure make make install. Maybe it's an RPM. Maybe it's a tarball with a shell script that you have to run. Who knows?
Most people don't actually like messing with their computer; they want to use a few applications and get off of it. IM, Napster, email, Word, Excel, and a web browser are the kind of thing that make people put up with computers. They also don't like shopping for computers.
So the most recent Linux distros are marginally faster at some tasks than Win2k? Well gee, switching would make your 1.7GHz P4 run like a 1.8GHz P4! What a compelling selling point. That's worth about $30 right now based on dell.com's pricing.
On the other hand, a consumer is going to have a lot better chance finding someone to help them install Windows apps than Linux apps. Also, take a look at apps like InstallShield, and compare that to rpm or gnorpm. It's no contest, the Windows or MacOS installation experience is so much better.
AFAIK, nobody is trying to make Linux easy to use. They're trying to make one app easy to use, and there's no UI consistency. MacOS, Windows, and even Java have user interface guidelines that application developers follow. Apple and Microsoft also look at the whole system and try to make it more usable overall. Windows falls down in the "installing a new network card driver" department, for example; don't get me wrong. But with Linux, everything requires you to learn a whole new skill set. Want to install software? Maybe it's
Until Linux does something that a whole lot of people really really want, which Windows doesn't, it won't become popular. The threshold of how cool that something has to be is set by the extremely poor usability of Linux.
I dare anyone to put Windows, MacOS, and Linux (pick your distro) in a room and time a computer newbie trying to get all this done:
- install the OS from CD onto an unpartitioned brand-new 60GB IDE hard disk.
- install a CD burner, network card, digital still camera, digital videocamera, 2 monitors, USB optical mouse, USB MP3 player, low-end laser printer; perform a basic test to make sure each is working.
- install Microsoft Office or StarOffice or whatever app suite you like; launch each app to make sure it works
- connect to an existing e-mail account and download an attachment in Excel format. Print it.
- install a browser that has 128-bit crypto
- connect to an online banking site that requires 128-bit crypto, and print a current statement
- Create an MS Word formatted document and save it.
- install a chat client for AOL, MSN, and Yahoo; send the new Word document to a friend on each of AIM, MSN, and YIM.
- install a USB webcam; have a chat session with a friend on YIM.
I predict that Linux won't be the OS on which the newbie will be able to get all this done most quickly. That's the kind of benchmark that Linux needs to win in order for ordinary people to care about it.
If you define P2P to include distributed computing, where a central server tells a bunch of nodes what to do (which seems outside of the scope of P2P to me), then wow, P2P has really taken off. Heck, with that definition, Pixar uses P2P render farms for their movies.
On the other hand, if you define peer-to-peer in a more pure sense, where each node is a peer, doing its own thing and maybe using one or more directory servers or repeaters to find others, then Napster looks like the only winner I can think of, and it's clearly dead now that it's gone legit. Most IM apps look like client-server to me, although they have some P2P aspects such as file transfer... they're not any different from IRC + DCC, really.
I interviewed with a couple of local (SF) "P2P" companies (really internet-based distributed computing platform vendors) a year ago, and they were having trouble selling their concept even then. Yes, there are CPU-intensive tasks out there that companies would pay to accomplish, but they tend to operate on a lot of data, and that data tends to be sensitive/confidential. One company was refocusing on internal deployments only - using corporate desktops inside the firewall to run distributed tasks at night. That mostly solves the bandwidth and sensitivity issues, although in a WAN environment you might not be able to use remote LANs if the pipe to the remote LANs are too small for the amount of data being crunched.
It's hard to think of too many true P2P applications. P2P architectures that don't include central directory servers or reflectors tend not to scale - think back to old LAN protocols that didn't scale well a WAN context. It's the same problem but at a higher level. The more scalable protocols use some form of central servers or at least a group of more centralized peers (routers, PDCs, whatever) to find one another. Pure P2P doesn't scale due to network inefficiencies (think Gnutella without repeaters); pure client-server doesn't scale due to node scalability limits. A hybrid such as Napster or the WWW scales very well, though. (The whole web isn't on one big server...)
With appropriate signatures, open-source software distribution might be a good P2P application. Instead of hunting around for a fast mirror, why not grab it from a peer, provided the signature is valid? Only the signature has to come from the main server (or a mirror).
The problem with that is the same as what everybody finds when using Bearshare, Kazaa, etc. - upstream bandwidth from peers is very limited. ADSL, "56K" modems, and cable modems all tend to be asymmetric, limiting a P2P network run over them to the collective upstream bandwidth. Imagine 10 people with DSL, trying to swap 10 files - no matter how you slice it, everybody might as well be downloading from one guy. A P2P file sharing program called eDonkey2000 tried to avoid the single-source problem Napster and Gnutella face by using hashes to request files by hash rather than filename, so multiple peers can send you slices of the file even if the name differs, and even if some of them drop out over time. It's nice for big files because you will eventually get all the parts from somebody, but it's still slow.
I think that perhaps multicasting is the only solution for this. P2P plus multicasting would eliminate the problem of popular servers being swamped by requests.
I can't be bothered to look up the reference, but at some point I read about some folks who tried to make up a binary protocol to be as compact as possible, and they couldn't make it more efficient than a gzipped text protocol. Even if you're within 10%, don't bother, just gzip it and move on.
Well, margins are razor thin, and various PC companies (Compaq and IBM, for example) have publicly expressed that they may give up soon, and stop making PC's. Network appliance makers couldn't seem to get their products under the $400-$500 price range without removing a critical component such as the hard disk. Many years ago when I was selling PC's in college, the minimum price was about $1200, below which the mfrs would just give up and discontinue the product. Apparently some combination of obsolescence and shrinking profit made it pointless to keep making them at that time.
Of course, PC's are much cheaper now. From what I've experienced in the past 2 weeks while visiting friends who are normal people (not computer weenies like me), the reason they upgrade is mostly to fix software configuration problems that make the computer ridiculously slow, and less to get new features, although that's nice too. Stuff that power users wouldn't put up with, like a 4-5 minute freeze at boot time due to a configuration problem, are things that normal users put up with. "This computer is so slow, I need a new one" is a real quote from a person I know who had a problem like that.
I think that disposable PC's might be a viable idea, if someone could figure out how to make the important data survive while killing the worthless corrupted data. My parents had an old black-and-white TV set with old-style knobs to change the channel, and it went on the fritz. Did they fix it? Hell no, they tossed it and bought a new one. If PC's reach the $100 price point, that's what people would do with them, too. But the data is an issue.
Maybe instead of NC's using broadband to get to a central server, we could have a central server in the house and NC's running the apps? Separate the data three ways: app installers, data, and user profile info. Apps install on the local machine, data is on the server, and profiles are on the server. If the apps hose each other, nuke the local macine and reinstall apps as needed. No more DLL rot. If your profile is broken, nuke it but your data is safe.
Regardless, it's clear to me that complexity is the issue, not price point. If PC's were free, there would still be people who wouldn't want one.
Bloat, no. Abstraction, yes. The problem that most people have with Microsoft's software is that as Mr. Gates is happy to explain, they target current/future hardware and expect users to upgrade. That would be OK, *if* there were high-quality releases that users could buy and stay with indefinitely. However, this is not the case - M$ software is notoriously buggy, and the only fix for the bugs you suffer today is to buy the next version, which requires a new computer. At some point, which I argue was reached with Win2K and Office 97, the features people use work, and the features that are broken are unimportant, so the upgrade treadmill breaks.
/. and Linux community that [insert high level OO language here] is so slow that it can't be used. Really? How fast is /bin/sh at running that floating point benchmark? How fast are sendmail rules? I don't see anybody benchmarking the code used for Linux's "make xconfig". That's because IT DOESN'T MATTER.
/bin/sh scripts to install themselves. (Have you benchmarked autoconf lately? But I bet you've used it...)
I don't mind the fact that Linux is written in a portable assembly-language called C. I want my kernel code and drivers to be as fast as possible. I do mind the fact that people are still writing end-user and server applications in C, and are still trying to get all the goddamned buffer overflow and memory management bugs out. Come on, it's been what, about 30 years now? C++ fixes a lot of these problems, as do the higher-level garbage collected languages.
The pity is that there is this constant murmur of bitching by the
Unix gets a certain idea right, and it isn't "everything has to be written in C for maximum speed". Look around a *nix system and tell me that everything is written in C. It isn't. The idea that Unix gets right is that of well-written modular components which can be assembled to do various different tasks. In Unix that happens to be accomplished by components which are written in C, and which are carefully tested, which are then glued together with slower, higher-level languages (shell scripts etc.). Contrast that with Windows, where everything is a C API that is implemented by a native DLL, but you are expected to use C or VB in an IDE to automate anything. That's not nearly as flexible or powerful as the way Unix does the same thing - with slow, garbage-collected, high-level scripting languages. This is why application installers on Windows use commercial installer products (written in native languages with proprietary scripting languages built on top of them) while Unix apps use
The more CPU power we have, the better, because it will allow us to push more code into the flexible, high-level, safe, garbage-collected languages which don't have seg faults, buffer overflows, endian issues, etc.
If people buld software properly and write performance-intensive code in low-level languages, and write functionality-intensive code in high-level languages, we'll actually be able to use Moore's law to get better software written faster. If we keep bitching about Java, Smalltalk, Python, Eiffel, C#, VB, etc. being too slow for any purpose, we'll still be patching daemons every other week to avoid buffer overrun vulnerabilities in C code, and downloading & installing ever newer versions of each our crappy GUI apps in hopes that this one won't bomb when we actually try to do work with it.
I read Joel's original article on this subject("Things You Should Never Do, Part I") a few months ago. Despite the rampant /. kiddie practice of posting a strong opinion without reading the article being referenced, I encourage you to read it now:
:) If they had they'd be able to clean things up module by module, because they designed robust APIs early and then wrote quick and dirty implementations that could be fixed later when there was both time and need.
:)
Things You Should Never Do, Part I
OK, so you didn't read it, I'll quote a juicy part: "You are putting yourself in an extremely dangerous position where you will be shipping an old version of the code for several years, completely unable to make any strategic changes or react to new features that the market demands, because you don't have shippable code. You might as well just close for business for the duration."
The point is that if you have all the time and money in the world, of course you should rewrite from scratch when things get yucky. The problem is that in the real world, companies need new releases to keep selling upgrades, so you need to keep steadily improving the product. Similarly, customers adopt the product, use it a bit, and then learn what they want next - they want to invest in the product more. Meanwhile, the purist coders at the vendor are busy taking three years to make the architecture pretty, which will pay off big-time in year 4 and 5 when they'll be able to add new features at a breathtaking pace. Customers get pissed and go find someone who will sell them a product which is about as buggy as the one the first company made, but which now has a few key features.
Coders don't necessarily understand the sales angle of this, because they're trying to avoid inefficiencies in development, such as wasting time hacking on a crufty code base to try and add a feature. They'd rather invest early and reap rewards later. The problem is, most software companies don't have the luxury of investing heavily from a payroll standpoint, not even considering the customer attrition problem.
As a perfectionist myself, I really hate the fact that this is true, but it is. Business realities suck sometimes. There's a sci-fi business parable about this...
Two space empires are at war. One side is starting to lose, but one day their leader announces that they will soon be victorious! Their scientists are working on a doomsday device which will wipe out the enemy. Time passes and the war is going badly, but no one is worried about the heavy casualties because they know they will win any day now. Planet after planet is captured, ship after ship destroyed. Finally, one day the lead scientist who is working on the homeworld screams "Eureka!" because he knows that the device finally works. He races to the office of the imperial leader and bursts in, full of excitement, only to see enemy soldiers standing over him with guns drawn as he signs his name to articles of surrender, because they've lost.
Unfortunately for the scientist and his empire, they didn't think to refactor, or design APIs between modules...
eXtreme Programming has some interesting things to say about this too. Basically, don't implement anything that isn't in the requirements now (that is, don't overgeneralize to a fancy-pants API and module system if you're only gonna write one module on top of that API), also known as DoTheSimplestThingThatCouldPossiblyWork, and RefactorMercilessly to clean up code continuously as you maintain it.
Finally, remember that testing makes maintenance immeasurably easier. The reason that maintenance sucks so bad is usually that some cowboy coder thought that documentation is what you do when the code is finished, which of course (a) is wrong and (b) never actually happens. If docs are demanded up front, including test cases, coding is much easier as is maintenance, and you don't have to bite your fingernails wondering if your tiny bug fix un-fixed 100 other "fixed" bugs. If you have tests, you can RefactorMercilessly and rip out the most egregiously gross code, and get it all back together and working, without it blowing up in your face. So make sure somebody writes a basic spec, then write test cases and code that performs them so you can code with impunity and so you can go on vacation
OK, so Microsoft has a practice of hiring freshly graduated CS majors so they can begin brainwashing them early about what working at a software company is like. Fine. That drains the young'uns of real world programming experience, where inventing five new opaque binary file formats with every program is not OK, nor is obsessing over making Solitaire's shuffling algorithm O(N) instead of O(log(N)) worthy of a semester project for a team of six.
However, Microsoft's insular cluelessness aside, do you really think that the gub-mint Windows sysadmins languishing in some mildewy room in the basement of a federal ofice building are going to know what they're doing? Have you seen government salaries lately? These are the people who convert several 700yd runs of bare-pair phone cable to Ethernet using only a crimper, and wonder why they can't seem to get sustained 10MBps throughput across it. The lucky ones learn on Uncle Sam's dime and move on to a Real Job making Real Money eventually. Others just fester there forever, making technical decisions so horrible that others refuse to believe you when you describe them.
I worked for the government very early in my career. I was definitely clueless, and more importantly, we were insanely understaffed. Microsoft is huge and has "R&D" teams working on stupid crap like vibrating joysticks and general-purpose speech recognition - ever notice that EVERYBODY in your office wears headphones? Now wait until you have to yell at your computer all day just to get work done - meanwhile the government is busily trying to roll out Win95 to the last few field offices that still have 66Mhz Pentiums.
In case you are unclear, I'm saying that monopoly-funded hordes of inexperienced but smart and college-educated Microsofties are more likely to get a code something properly than an overextended handful of unmotivated, underpaid, self-taught recent help-desk graduates are to install it properly.
There's a more specific benefit to clustered persistence via application-level session replication: less load on the database. Allow me to elaborate.
For a stateless app, such as a public web site with static content, IP based load balancing works fine. For a stateful app, there are actually 3 options, not 2 as mentioned above.
1) Neither save nor replicate state. App dies, user fails over to another server, back to login. Lame.
2) Save state in the database after every page view. App dies, user fails over to another server (doesn't matter which one), other server notices it doesn't have the user's state in memory and loads it. Acceptable, but complex, and beats up the database quite a bit. If I am not mistaken, this is the only option for most non-Java app server situations (CF, ASP, PHP).
3) Replicate state directly from app server to app server. After every request, the app server copies the state info for each user to a failover server. Server dies, load balancer redirects the user to another server, that server has the state info in memory, ta da, no loss of state, and no load on the DB. The new app server starts publishing the user's state info in case it also dies.
For a concrete example, imagine an e-commerce app with a shopping cart or complex product search as your main state. In #1, you lose your shopping cart and get logged out; log back in and your cart is empty. Suckage. In #2, it works but the developer has to save the shopping cart or search criteria to the database every time the app services a request, because any request could be the first one that goes to the failover server. OK for you, super suckage for the developer, and the DBA, because every time you ask the server to do something, it does that and then also saves your shopping cart, so the DB is constantly doing updates to a single table no matter what else it's doing. (In case you don't know about databases, writes are far more costly than reads for an RDBMS, so it's much more work to save a shopping cart again and again than it is to fetch product info, show all products whose vendor name is 'Sony', etc.) In #3, it's pretty much transparent to the developer, and the DB is just doing the work you would expect would be needed based on user activity. You just need a slick app server to make it work.
Clearly, keeping state info small is necessary to prevent session replication from eating up all your bandwidth. Also, every app server I've seen which does this picks a single backup app server to send session info to (rather than copying each session to several other servers each time). This means that the load balancer must choose the right server to failover to; this is done by encoding the IP address of the primary and backup app server in the session cookie, so the load balancer can use that info as it recieves a request to decide which server will get the hit. When the backup server gets hit, it changes the cookie to say it's the new primary, and to say which new IP is the one for the new failover server. If I understand correctly, in an imaginary server farm of 8 app servers, each user might have a backup session on any of the other 7 servers - the app servers choose this dynamically.
Anyway, the big idea here is that you tell all the app servers what all the IP addresses are for the other app servers, and keep your session object small, and It Just Works. No need to copy junk to the DB all the time; no need to check if you have the info cached. But your load balancer has to support your app server so it can do the "session affinity" thing - returning a user to the same app server again and again unless the server dies.
If "sold out" == "best selling", Macs would have outsold PCs a few years ago, when Apple was transitioning to just-in-time manufacturing and hadn't yet abandoned all their wierd custom ASIC to support their proprietary hardware interfaces. They had obscene hardware shortages all the time (6-8 weeks was typical between a retailer ordering a machine and actually getting it; hot high-end models were more like 12 weeks) which obviously limited their market share... if you have no inventory to sell, it's awfully hard to ship more than your competition.
Looking at retail stock levels doesn't tell you anything. Unit sales are what you should be looking at, and it looks like Nintendo did a great job of meeting (and exceeding) demand. The real question is, once the pent-up demand has been satisfied, how many will have been sold, and what will the ongoing unit sales rate look like? In January, once Xmas sales are over and restocking has allowed folks to say "dammit I didn't get it as a gift, gotta buy it for myself" etc., sales will very likely level off.
But... will The Bedazzler theme allow sub-themes, written in XML with MPEG-4 animation movies and dts surround sounds when you drag windows?
Go read asktog.com and ask yourself why in Win2K, a left click at any edge of the screen does nothing, even though that's the easiest part of the screen to hit and the default key. Then ask why all the rebellious Linux GUI developers are just cloning Windows' look and feel. Oh, it's to make Windows users feel more comfortable? Well then by all means, add C:\ and regedit and COM1/2/3/4 and cmd.exe and... oh wait.
No, we'd be better off adding network plumbing, replacing all the file formats with [slower-parsing, bigger] XML based formats, making more themes, supporting new and even more radical component models, and other shit that only developers care about. After all, why bother with usability testing? That foofy stuff is just for "lusers", and everybody knows Linux has way too many users and not enough developers.
Q: What is the #1 GUI application category for Linux?
A: Screenshot maker.
Q: What are the #2 and #3 application categories for Linux?
A: Terminal and MP3 player.
Q: Why don't Linux users just use a serial terminal and an MP3 player, since it would be cheaper and require less configuration effort?
A: You can't take a screenshot of a serial terminal or an MP3 player, and ASCII porn just doesn't cut it.
Q: Why won't open source eliminate commercial software developers?
A: Because open-source developers solve problems faced by open-source developers, while commercial software developers solve problems for everybody else.
I know, I'm being too harsh, I run a few Linux boxen at home and have for years. This is a bitter rant made in jest. Laugh, but recognize the part that rings true.
Believe it or not, there is this thing called "open source", based on the little-known fact that if you get information from someone, they still have it. Or at least I think some guys named Thomas Jefferson, Richard Stallman, and Eric Raymond were saying something about that. I think they, like, said something about how it's different from material things because you don't deprive the original owner of it when you "steal" it.
Good analogy, otherwise. *cough*
Yes, javac is written in Java, and that's why it's hella slow. Try putting it in a Makefile sometime. Ugh. That's why IBM's Jikes compiler is written in C++... much faster startup and compilation. In my tests Jikes is 7-20 times faster. I haven't tried Jikes on any of the new Java 1.4 stuff (assertions) so it may not be an option in that case.
Another possible interpretation is that Apple is OK with a non-native Aqua implementation as long as its look and feel are *exactly* like the native implementation, thereby providing a 100% consistent experience. Just a thought. I don't think Apple cares as much about APIs as they do about user experience, so it seems they would be more concerned about a half-assed Aqua clone annoying users than they would about a perfect Aqua clone that didn't happen to make the right API calls under the covers. So the info they would be giving would be the spec for how Aqua behaves, not the API docs which are already available.
>Failure to do this results in customers switching to
>another provider. This is *especially* true of DSL
>customers for whom other providers are nearly
>guaranteed to exist (since DSL has open access).
Huh? You must not have been paying attention to the DSL market in the last year or so. All the CLECs are going out of business, leaving the ILECs as a de facto monopoly. Covad is the poster child for this:
Yahoo Finance page for Covad
Ouch! Their resellers got squeezed out, and then they got squeezed out, and are barely alive right now.
I run Win2k pro on my desktop (for s/w development) and IIS is not part of the install... I doubt that a typical user's machine on DSL or a cable modem is running IIS at all. NT 4 is a different matter.
The definition of an "interactive digital device" is incredibly broad:
"any machine, device, product, software, or technology, whether or not included with or as part of some other machine, device, product, software, or technology, that is designed, marketed or used for the primary purpose of, and that is capable of, storing, retrieving, processing, performing, transmitting, receiving, or copying information in digital form."
When I was a teenager I was an electronics hobbyist and I assembled a simple computer based on a 68000 CPU I bought at a computer flea market. Total parts cost something like US$50. That would be illegal if this law were passed. MindStorms would also need DRM hardware. Electrical Engineering students would need to incorporate DRM in all their projects if they were sufficiently complex. That raises another question - exactly how sophisticated does a device need to be for this law to require that it have DRM? According to the draft, all of the following would apply:
A potato clock?
A digital thermostat (has a CPU in it...)?
The digital time clock at the 7-11?
A digital watch with text memo capability (it could hold the DeCSS algorithm! Oh no!)?
A router?
A modem?
An Ethernet switch?
An Ethernet hub?
An Ethernet cable?
A can of soup carrying a UPC code?
A carrier pigeon with a TCP/IP packet strapped to its leg?
It's pretty clear that it would be illegal to build your own PC without incorporating a government-approved DRM component.
[troll] Hmm, what if the component only comes with a driver for Windows on x86 hardware? Installing Linux becomes a federal crime, since you're disabling the DRM hardware by deleting the driver! Wheeee![/troll]
As for penalties, let's all think about whether getting an EE degree involves private financial gain. That's the idea, right? So building a project computer sans DRM is punishable by 5 years in jail. Neat!
Send money to the EFF as soon as possible; let's make sure this law gets clobbered.
You said it. It's hard for a Linux zealot to think this way, but normal businesses don't care about the FSF and the open source crusade; they don't care about X11 or gcc or ssh. Most IT folks in real businesses barely know WTF they are doing, so they pick the mainstream vendor with the GUI interface and firmly believe that market share proves quality and that anything they can't get working is due to their own problems.
Against this backdrop, they're not going to go out looking for obscure platforms (meaning !=Windows to them) and companies which only support these obscure platforms. They're going to pick a big company that will help them with what they have now, and who can make a convincing argument about having skills for more complex needs and future enhancements. A company like IBM could plausibly get some Linux boxes in because they're not spouting irrelevant platitudes about freedom; they're talking business and are fully capable of dealing with the answer "I don't care, do it with Windows anyway".
But I wouldn't want to live down in the southwest corner near all those storage tanks. I bet there are some nasty chemicals down there.
Isn't aerial photography wonderful?
Oh wait, you're saying that's a laptop?
>My guess is that the 64 bit x86 (Intel or AMD) will become far cheaper than the Sun counterparts
l as h.991025.4.html
:)
Solaris runs on x86 now and is free on machines with less than 8 CPUS. It was demonstrated as working on Itanium almost 2 years ago:
http://www.sun.com/smi/Press/sunflash/9910/sunf
I would be surprised if Sun doesn't ship a production IA-64 release of Solaris when IA64 hardware is widely available.
That means that there are multiple independent axes of competition:
-- IA-64 vs. UltraSPARC III
It's pretty commonly believed that IA-64 will dominate, but then again, IA-64 is very late, and Intel has shown weakness in its engineering with the P4, so it's not exactly in the bag. Linux and Solaris server buyers will happily buy whichever seems like a better deal (based on price/performance, availability, etc.), because they can just recompile their apps, or demand that their vendors do so (which works if enough customers are asking for it). Windows server buyers will buy IA-64 because they have no choice.
-- 64-bit Solaris vs. 64-bit Windows (vs. 64-bit Linux)
Here's where things get a bit more interesting. Except for the most trivial or acrobatically-coded apps, you can't just recompile to jump from one OS to the other, so the choice of OS will be more carefully made than the choice of hardware IMO. And here's where the scalability of Windows and Linux is called into question: can you run 64-bit Windows effectively on a 16, 32, or 64-way multiprocessing server? Because if you can't, Solaris is the only one of the three which scales from the little 1-CPU boxen up to a 64-way box such as the Ultra Enterprise 10000. Obviously IBM, HP, Compaq, et alia are also up in the high end there, but for a customer who's trying to consolidate OS's so that little and very big servers alike run the same OS, Solaris stands out. I'm not saying that it is or isn't wise to consolidate OSs, nor that there are zillions of companies who need 64-way processing, just making a point about Solaris's seemingly unique scalability in both directions. Anyone who has used all three of these OS's will also note that Solaris and especially Linux scale *down* better than Win32.
In short, the really interesting question is, "how many CPUs can 64-bit Windows on IA-64 use effectively?" Not "how much will it cost", since that doesn't matter if its performance is unacceptable. Linux is quite capable of not performing acceptably on large MP machines, and it's free
Of course, if a cluster of small MP machines suits your app, this is all irrelevant, because perhaps all you really needed was more RAM per cluster member.
Most importantly, what do they plan to do once the system decides there's a match? Let's say the system is approximately as good at face recognition as a human (not sure this is the case but for the sake of argument assume it is). Imagine that there are hundreds of security officers looking at all the security cameras in the store all the time. Remember, in a retail store you're already under constant surveillance and you're being recorded as well. The difference is, your presence is being used as a chance to compare your face to a bunch of head shots of "known shoplifters". The technology is not the issue, unless it results in lots of false positive matches. The issue is what happens when they think you're a known shoplifter. Do store security guards try to detain you? Eject you? Restrain you? Search your person? Demand to see your identification?
In the US, a shoplifter has to be seen in the act of concealing something. You can't just see someone with a book go around a corner and come back without it. If you don't catch them in the act of concealing it then you can't bust them.
Does Border's think they can harass people who they suspect of prior shoplifting? Do their security guards? I think that's the interesting question, because videotaped surveillance cameras and "wanted" posters are hardly anything new, even if made more efficient thru technology.