There is such as thing as usability for expert users. AutoCAD is probably the best example: Grandma can't pick it up in 5 minutes of use, but Sally the engineer can absolutely rock out with it. But, you have to pick a target audience. If you are building software for Sally the Engineer, you still have to design it carefully, and test it to make sure it makes sense to her and is designed to maximize her productivity. A crap UI is still a crap UI.
There is still a serious "fuck the user" attitude problem among developers. "We had to memorize arbitrary and even counterintuitive commands and conceptual models of badly designed software while we were learning about computers; why shouldn't they have to do the same?" It's pathetic. It's purely due to laziness on the part of developers, but the defense is always based on ego. Why bother doing all that extra coding to make it easy to use, the users are just stupid and won't get it anyway, so let's just code it the easy way. Right. User hostile developers create user hostile user interfaces. Just because there are *some* truly stupid users, and *some* cowardly folks who just assume they can't figure it out without trying, that's no excuse for throwing in the towel and designing junky software.
The more complex your application, the *harder* you should be trying to make it easier to understand. That doesn't mean Clippy. That means giving it a solid, predictable conceptual model, that people can learn and feel comfortable with. Interaction designers know all about this - read a usability or information design book sometime. It's not about printing a 900 page manual, although that isn't obsolete. It's about thinking about the design of your software before firing up the text editor and coding, and testing it with real users to see if your hunch about terminology was right.
It's time to get developers to base their ego on how *good* the user interface it is, instead of how *exclusive* it is. This ain't a bloody nightclub. It's the code you want people to use (buy?). Look down on them and tell them they're not worthy of a manual and you're just giving a competitor an opportunity to kick you in the nuts.
Other reply-ers have contradicted the parent post effectively, except...
Wizards are not always idiotic. Some tasks *require* multiple steps that are not well suited to a modeless UI. For example there is the Excel text file import wizard, which perhaps could have some teeny improvements in each stage, but in general is a good idea. The only other option I can think of for that is to have some kind of preference about how all future text files will be imported that you have to set, and then a 1-step import that uses that preference to import a file. That's a lot more obscure than just asking how to import the file when you open it.
Another good example of a wizard is better known as the checkout process. All online stores have a multistage wizard UI for the purchase process, starting with a selection in the form of a shopping cart. Amazon did a good job with the 1-click thing by letting you create default checkout settings, but that doesn't cover all cases. Sometimes you need to ship it to Dad. Sometimes to work, sometimes to home.
Don't yiz on wizards in general just because you have been frustrated by an inappropriately used one in the past.
>Working behind the scenes, a small government agency headquartered outside of Denver >operates a network of 14 servers capable of changing the operating systems on your >PC--and millions of others--in less than a second.
Sniff... sniff... what's that I smell? Ahh, the stench of yellow journalism.
You mean that NIST can change the OS on my G4 from MacOS X to LinuxPPC? On my PIII from Win2K to Win3.1? In less than a second? Amazing! They should sell this technology to Symantec for the next version of Norton Ghost! In my world it takes several minutes at best, maybe hours ("hours would seem like days" - Spock/TWoK), to install a new OS.
Oh, you mean, they can change the TIME VALUE STORED IN THE CLOCK. Is the clock part of the OS? No, as far as I can tell the clock is part of the HARDWARE. There is some clock functionality in the OS to get to the hardware clock and to provide time services to apps, but really, the clock is a hardware device. (I'm sure some/. kiddie will be happy to split hairs with me on that.) A more accurate lead paragraph would have ended:
>capable of changing the time on your PC--and millions of others--in less than a second.
Oh my god, no! NOOOOOOOOOO!
But wait a second. Doesn't he also say that WinXP syncs once a week, and OS X syncs at an unknown interval ('cos he didn't bother to research it and find out, he just looked at the UI and it doesn't say)? That means it really should say:
>capable of changing the time on your PC or Mac--and millions of others-- >in no more than a week. Unless you configure it otherwise, in which case your clock will be wrong.
OK, let's try that again: Oh my god, no! NOOOOOOOOOO!
Microsoft has discontinued its UltimateTV hardware, leaving only the DirectTV/UltimateTV option. It's not doing fine, just ask one of the 400 people cut from the team (leaving ~100). ZDNet has a nice story about this entitled Why UltimateTV was an ultimate failure. Now, this doesn't necessarily mean that ReplayTV/SonicBlue or Tivo are kicking their asses; none of the PVR vendors is too healthy. It's a tough market and they're all struggling. Still, Microsoft is in a compromised position because they are at the same time trying to fight software piracy and be buddies with the DRM crowd, and to make a device which really screws with the entertainment industry's business model.
The Xbox is a different matter. The best argument I've seen any Microsoft zealot put forth so far is that this is 1.0, and the fact that they sold anything at all is a victory. Riiight. True, Microsoft has monopoly profits and can use them to fund failing projects indefinitely until competitors (who actually have to make money off their products) run out of money. Did somebody say Netscape? But Sony *is* making money on the PS2, and Microsoft is losing money on the Xbox. Even so, Microsoft reduced their sales projections for the Xbox, and are now estimating that they will ship 3.5 to 4 million units by the end of June 2002. Meanwhile, first week the PS2 was available, 980,000 units were sold. The first four days the PS2 game Final Fantasy X was on sale, 1.9 million units were sold. By the end of January 2002, over 4 million copies of Final Fantasy X had been sold worldwide. That means that in the same amount of time (~7 months), one PS2 game outsold the Xbox console. Apparently Gord knows what he's talking about when he said (a year ago!) that "This console race was over before it started." Microsoft needs to pull an maneuver like the IIS/IE one they used to kill Netscape: just give away the Xbox with the purchase of Halo. Eventually Sony will run out of money and give up. Riiiight.
As for PocketPC vs. Palm, that's a matter of speculation and only time will tell if Palm will get it together or if they will continue sitting on their asses while MS gets around to producing a useful PDA for less than $400 (remember that the Palm 105 costs $99 so they aren't really direct competitors - Palm makes the cheap simple ones, PocketPC licensees make the high-end fancy ones).
>This contrasts to a large number of individuals in an organisation who >know the code very well and work with it day in day out.
I infer that you mean "at a commercial software company". In my experience, few companies actually do pair programming or even code reviews, so on a project with 100 programmers you have 100 people, each of whom know ~1% of the code. So on average, one set of eyeballs sees the code. Not good. Worse, that one average set of eyeballs isn't attached to one brain - what I mean is, if you had one person reviewing all the source, you could make sure to have them check the entire app for a given kind of bug. Instead you have 100 different brains looking with 100 sets of eyeballs, each at 1% of the code. So something that Betty knows not to do will be done as a matter of personal style by Dave and due to inexperience by Hank.
At least open-source *allows* more brains and sets of eyeballs to look over the code. In a commercial context either it's baked into the process and is part of the development project plan (making time in the schedule for code reviews and maybe pair programming) or it's not, and if it's not, the alternative is "Stop looking at Dave's code, get your own damn code done and then let's ship this thing."
There's a flaw in your argument. First you dismiss all non-remote exploits, then you dismiss Apache remote exploits since they will have to "rehack the box from the inside". Well, here come those non-remote exploits back into the spotlight again. Script kiddies definitely favor the remote root exploit, but nevertheless, if a cracker gets a shell running as "nobody" or "www" that gives them a chance to start hammering on those *local* root exploits.
It's definitely better from a probability standpoint to run those services as nobody or www anyway, just in case the cracker has a dumb script that expects them to run as root, and will fail otherwise. But don't dismiss all those local exploits that could be used by a non-root remote exploit to get root.
Seriously, have you never heard of the Web Standards Project? http://www.webstandards.org/
Web developers are sick of coding HTML, JavaScript, and CSS for one browser, and then debugging it for every other browser they have to support. Netscape 4.x and 6.0 are definitely high on the list of sucky browsers to have to support, but IE 5, 5.5, and 6 aren't perfect. Also, IE 5, 5.5, and 6 differ greatly, not to mention the Mac versions of IE which also differ. You can't just target one IE version and get 100% compatibility with the others.
So, rather than looking at the ridiculous statistics that say stuff like "97% of browser users use MSIE" (which I just don't believe), start looking at stats about which browser AND VERSION your users are using. Surprise, chances are there are a hell of a lot of IE 5 and 5.5 users. Chances are there is no one browser+version that covers the majority of your site's users. Doh! So much for just targeting "one" browser.
So, forget about this silly notion of "IE won, all web sites will be IE sites from now on." That's not financially viable, since IE is actually serveral products which must be QA'd for separately. The solution that web designers are rallying around is "code to the standard, and debug for supported browsers from there." Screw IE 5, make people upgrade to IE 6. Screw Netscape 4.x, make them upgrade to 6.2, 7.x, or Mozilla 1.0.
Otherwise, why even bother with HTML at all? If you're going to target Windows only, you're wasting your time trying to get a good GUI user experience and robust application functionality implemented with tools as crappy as HTML, JavaScript and CSS. The only reason to use them is to get thin-client, cross-platform, cross-browser functionality with zero download time. Use Delphi or Visual C++ or Java or something if you want total control over the user experience and you don't care about porting.
> Now I haven't used Mozilla 1.0 extensively yet, what with it just having come out, > but I can tell you that Netscape 6 and espically 4 have problems of just rendering > HTML WRONG.
Netscape 6 came out a *year and a half* ago. The excuse of "Mozilla 1.0 just came out" is totally bogus - Netscape 6.1 and 6.2 have been released since then, and are much better than 6.0. If you really wanted to keep an eye on Mozilla's progress, you could have downloaded nightly builds or stable milestone builds every few weeks, or months. The downloadable installers have been out there, 1 click away from www.mozilla.org, all along. Mozilla 1.0 RC1 has been out for over a month.
Why not do this: 1) download Mozilla 1.0 and see how your stuff works 2) post a comment describing how good or bad Mozilla 1.0 is
Nobody really cares how Mozilla 0.6 stacks up against IE 6 anymore.
Bravo! Fad coding is a very real problem, and in the OO world, over-abstracting and over-design-pattern-ing is a real problem, even though those aren't real words.:)
There are requirements that can make abstracted designs a good idea - things like i18n, which suggests that all the text in your UI should be ripped out of constants and put in config files. So in that case Hello World would need a way to read the config file in order to easily morph into Bonjour Monde or Hola Mundo or whatever.
I can't tell you how many times I've seen an object model in a project that starts with EVERYTHING being based on some GenericItem object that all the others inherit from, and GenericItem has no real value. The designer just wanted to use inheritance a lot. Oy.
I like OO and all, I just don't like OO developers who read 10 books on OO and try and apply 100% of what they've read in their first project... and spend all their time building more and more goofy infrastructure instead of actually implementing any functionality.
>Any mission critical application (OS kernel, NASA spacecraft software > etc etc) is done in Z type languages.
Really? Can you back that up? Specifically, can you prove that any of Windows NT / VMS / Solaris / FreeBSD / Linux / MacOS X have a kernel that was written in a "Z type language" as opposed to just coded directly in C/C++/whatever and tested the hard way?
Think about it, you can sell X number of copies of your game due to your cheesy graphics and story (*cough* QUAKE *cough*) and then sell 2x more to die hard gamers who will download a free TC and replace your crappy creative work with stuff done by someone else. Basically you get paid for your engine, and somebody else donates the creative work for "cred". Not a bad scam. Maybe the TC folks get paid too, big friggin deal. Still, it's entirely reasonable given that game engines have separated the engine from the creative content for so long, to allow parallel development of the storyline and graphics from the rendering engine, combat system, etc.
I disagree with the statement that law should not be up for interpretation. Check out Philip K. Howard's book, "The Death of Common Sense" (ISBN 0-446-67228-9) which details many, many cases where extremely specific laws and regulations have prevented courts and regulators from doing the reasonable, sensible thing.
The fear is that law that's open to interpretation will be abused. True, it will be abused to a certain degree. However, law that's overly specific forces the hand of law enforcement even if they don't want to do something, and that is very harmful as well. Laws should be specific in favor of the citizen, restricting what's illegal rather than trying to enumerate all possible ways to represent or convey kiddie porn. Writing ultra-detailed laws is like trying to write source code for a regulatory body, and there are inevitably huge bugs. But people aren't as stupid as computers and can make judgements. There are other ways to prevent corruption and abuse than writing a 400 page law, or saying "anything that anyone might ever think looks like a minor having sex, even an ink blot that Sheriff Inbred thinks looks kinda dirty, is child porn".
Also, you can't solve all problems by passing a law against them.
The reason Be failed as a dual-boot option is that Microsoft forced the OEMs not to! Read the lawsuit Be has filed against Microsoft. Microsoft also strongarmed OEMs (Dell) not to ship Linux at all, even as a single-boot option on servers. Microsoft uses whatever leverage it has to get its way, and since it has a monopoly, some of their tactics illegal. They do it anyway.
It's not the OEMs who aren't giving users the opportunity to choose. They would love to sell more PCs by selling to folks who want FreeBSD and Linux and OpenBSD and BeOS preloaded. That's a competitive differentiator and they'd love to have that kind of offering. Their hands are completely tied by Microsoft as to what they can put on the PCs they sell. The only option they have is to drop Windows entirely and ship ONLY Be, Linux, or FreeBSD, and you can ask VA Linux, I mean, VA Software Corporation, how well that worked.
It's interesting that it took this long for an ancient problem to be sorta kinda attacked, if not solved. Maybe this is because the Usenet infrastructure has changed to the point where 7-bit is silly, but why is this something that's just being addressed now? Don't tell me this is a brand new problem that the best minds of the news admin community couldn't have figured out by now.
One approach to short-circuit standards is to take the rogue approach that Netscape did, which is very different from the one folks keep accusing Microsoft of. That approach is to take an almost-suitable standard and extend it, in the same spirit, with the intent that your well-thought-out extension will be adopted later. Of course they did a less than perfect job, but the idea is sound: don't wait for the spec, lead it, while making it possible for it to remain open. That's different from the Microsoft approach of "Embrace, Extend [and Exterminate]" wherein you add undocumented proprietary features that lock you into a single vendor's solution. A hell of a lot of what's in the HTML 4 standard was released as a non-standard but documented extension by Netscape in 1.1 and 2.0. Some of that was bad (blink, and arguably frames), but when you judge Netscape, try to separate the new HTML tags from the bugs, because it's the bugs (and having to code around them) that make the web such tower of Babel.
So basically what I'm saying is, if MIME is almost there, CAREFULLY THINK THROUGH and implement the extensions you want, and implement it already. Or, pick something other than MIME. But, don't start from scratch and make mistakes that have already been learned from and solved. Build on the good decisions of the past. The real crime is solving the same problem, badly, over and over; getting ahead of a standards body while keeping intentions pure and decisions wise is not nearly as bad.
Great idea! Take *nix and put a great user interface over it. Then put it on a unit with a 15" LCD display, 10/100 Ethernet, a DVD burner, a high-end grpahics card, and maybe an optional wireless card.
It's called an iMac, dude.
"Linux people" are real. They are all about "no, god dammit, I want to configure it all myself, compile it all myself, and run developer snapshots of everything." Not exactly Grandma, nor what AOL or any other sane company would want to support. Linux is the new tinkerer's OS, and if it became untinkerable, what would be the point? Who would buy it? Every time some company releases a Linux based appliance, the Linux community goes nuts trying to figure out how to crack it open and hack on it. Linux wants to be tinkered with. And, of course, the company goes under or kills the product, because aside from the occasional Linux tinkerer who bought it because it has Linux Inside(tm), nobody else really cares about these things. When you take the tinkerability out of Linux, it's boring, and Grandma starts asking why she can't just have Windows like everybody else.
I agree that a limited, locked-down platform would be ideal for a web terminal, but sorry, Linux distros aren't there. Have you ever had to configure device drivers on your cable box, DVD player, PVR, or cell phone? Of course not. Have you had to "just recompile the kernel" on your thermostat? Of course not. "But a PC is more complicated than a thermostat!" Exactly.
OK, now you've crossed over from debating an idea, to name-calling and cursing. Your arguments here support my point, while you make ad hominem attacks. You play at condescending to me, but you refer to Newton, who was not a chemist, in order to take my examples that repudiated your argument, and elaborate on why they work, supporting my argument. Then you call me a moron several times. I think you need to concentrate on the topic at hand, which is not a grade-school cutdown contest, because your topical arguments are weak, and name-calling will not make you more correct.
You say it's all about rigidity, but your examples are incorrect. You use the example of a bullet hitting a block of steel, and not leaving a dent. In fact, a lead bullet hitting a steel block leaves a sizable dent in the steel block, and can even vaporize part of the steel block. Go to a shooting range with a steel plate a few inches thick sometime, and try it out. The steel plate is clearly more rigid, but is deformed nonetheless. Also, when a bullet hits flesh, it is definitely deformed, especially in the case of hollow point bullets, which are made of metal that is certainly harder than flesh, but the shape of the bullet is specifically designed to deform maximally upon impact with flesh to do more damage (leaving a bigger hole). A bullet which pierces a bone (such as a skull) also deforms, which doesn't fit with the way you think ridigity and impact works. In your explanation, either the bone would deform, or the bullet would, but not both. In fact, both do. This link is a bit gory but shows photographic evidence of the behavior I'm describing: http://www.plusp.com/gallery3.htm
As yet another real-world example, water is not very rigid at all, but over time, even with minimal velocity, it can deform stone. Go have a look at the Grand Canyon if you're not sure this is true.
If you want to say that a physical fracture caused by an impact is a "chemical" process just because the fracture involves electromagnetic forces lumped in with "atomic chemistry", that's definitely stretching. Does that make Bruce Lee a chemical weapon, too? After all, he could break a stack of bricks, or boards, or blocks of ice, using his fist. If he punched someone and broke their rib, does that make his fist a chemical weapon? It never even came into contact with the bone which was fractured, but you're saying that since fores of atomic chemistry are involved, it is. Well, I guess that makes the skin and muscle of the person who's being punched a chemical weapon too, since that was what actually carried the force from Bruce's fist to the bone in this example.
One might also argue that a bullet is a quantum weapon, since there are quantum forces underlying atomic chemistry. That too would be stretching things, and "any good chemist" wouldn't say that bullets should be considered chemical weapons, any more that whacking someone with a two-by-four is a nuclear attack, even though all those molecules in the two-by-four have nuclei.
It seems that you're arguing for the sake of arguing, either to show off how much you know about physics and chemistry (which apparently isn't a lot), or to try to obscure the definition of chemical weapons for reasons I can't guess.
I hope you will take some time to research your assertions next time before making incorrect statments about physics. Lots of examples are out there and it has nothing to do with me vs. you nor whether I'm a moron as you claim; it's reality vs. lack of knowledge, and your assertions are incorrect. Basing your argument on invalid statements about physics doesn't help you prove your point. And, of course, changing the subject to whether I'm worthy of arguing with you doesn't make your incorrect arguments more valid.
>why are lead bullets not considered chemical weapons? I'd say a bullet piercing flesh is a very >chemical action. Any good chemist could explain to you the atomic chemistry of why the lead bullet >traveling at considerable speed can pierce a less rigid entity such as a human's skin and internal >organs.
Um, maybe it's because bullets *aren't* chemical weapons. A bullet piercing flesh is most definitely not a chemical action, and frankly it's a damn silly statement to make that it is. Licking a lead bullet, or gently swallowing it whole, might lead to death eventually, I guess.
It's not just about rigidity, either. You can pierce a thin sheet of ice with a jet of water. You can pierce skin with a forcefully propelled liquid. In fact, you can pierce skin with a forcefully prepared gas. If you don't believe me, load a gun with blanks, place your hand firmly over the end of the barrel, and fire.
If it's about a chemical reaction, hold a lead bullet up to your skin for a few hours, or tape it next to the skin for a few weeks, and see if the bullet ends up on the other side, having blasted a huge hole through your body. Nope. Try the skin-contact test with a strong acid, or perhaps some nerve gas, and see if the results differ.
Seriously, how can you assert that a lead bullet is a chemical weapon? C'mon. I'd say you were a troll but the tone of your message implies you take your statement seriously.
Analogy: cop-detector weapons law
on
SSSCA Hearing
·
· Score: 1
OK, here's an analogy that even our breathtakingly retarded politicians can understand, even if they're just pretending to be stupid because they are in the back pocket of some of the wealthiest human beings on earth (who clearly need laws passed to protect them from the minimum wage making masses):
Imagine a law proposed by law enforcement agencies, that requires that anything that could be used as a weapon, to make a weapon, to harm or by inaction come to be harmed a law enforcement officer, would be required to incorporate technology to detect whether it was about to harm a law enforcement officer, and refuse to operate in that case.
Obviously the MPAA is thinking about PC's, hard disks, and audio/video entertainment devices here. What they've crafted is something so overbroad, it's like saying that every lead pipe, brick, or 2x4 made must by law fail to operate if it's about to whack a cop upside the head. This is *totally* insane. Let's think of a few devices capable or storing, transmitting, or processing digital data. DNA. A flashlight. A penny. Your mom. Photographic paper. A VHS videotape. A light switch. An ethernet cable. A piece of wire.
Vendor salespeople are paid to convince the Big IT Boss to commit to huge implementations as the first purchase. Screw that. Set up a single lab, buy a dozen client licenses and a single server, and see how it goes. Make NO committment to go any further.
Maybe try a couple of different options (the Unix based thin client approach, the Citrix or MS Terminal Server approach, the Ghost/Imagecast reinstalled PC approach) at once in different labs. Then you'll have *actual experience* with *the vendor's actual shipping product* that you can base your decision on.
Also, definitely ask for several client references from each vendor. Compare notes with other folks who have implemented the solution in question - maybe they figured out a workaround that the vendor doesn't know about, that would work for you.
Perl 5 will not handle most of these requirements. It will handle about a third of the requirements. Simplified GUI design? Perl doesn't even have a concept of a GUI built into the language, nor an event model. Advanced object-oriented design, my ass. Perl's OO lacks basic data hiding features (public / private / friend / package / protected type modifiers on data members and methods) on purpose, because Larry Wall doesn't think encapsulation is a good idea (it restricts what a developer can do). Operator overloading, AFAIK you can't do that in Perl at all.
Perl is very portable, has garbage collection, supports inline documentation with man-page and HTML doc generation, is astonishingly fast at text processing even with enormous files, and is great for system-level scripting.
It has exceptions, and is sorta-kinda OO (I consider encapsulation a must-have for any OO language), but the problem is, nobody uses either of these. Go look on CPAN, and decide for yourself whether that code is as object-oriented as the classes that come with Java, Python, C#/.NET, etc. When you use the Foo::Whatever module, the typical approach is to have it import a bunch of functions into your namespace that you can then use on a standalone basis. Classes should model real entities in the problem domain, but that's not how people use Perl classes... they use them as function libraries that have a bit of control over namespace importing. And of course nobody uses exceptions in Perl, falling back on C-style nested IFs from hell, or just not testing for errors at all.
Don't get me wrong; you *can* make objects in Perl (if you don't care about encapsulation), and you *can* use exceptions. It's just that nobody does, so any code you reuse will have a totally different design style that looks more like a monter shell script or C program than a robust, maintainable, well-factored OO application.
Slashdot Mirror
Will it run on a ThinkPad that has the TCPA/Palladium option installed? Hop to it! I need my DRM, and xeyes too!!!
There is such as thing as usability for expert users. AutoCAD is probably the best example: Grandma can't pick it up in 5 minutes of use, but Sally the engineer can absolutely rock out with it. But, you have to pick a target audience. If you are building software for Sally the Engineer, you still have to design it carefully, and test it to make sure it makes sense to her and is designed to maximize her productivity. A crap UI is still a crap UI.
There is still a serious "fuck the user" attitude problem among developers. "We had to memorize arbitrary and even counterintuitive commands and conceptual models of badly designed software while we were learning about computers; why shouldn't they have to do the same?" It's pathetic. It's purely due to laziness on the part of developers, but the defense is always based on ego. Why bother doing all that extra coding to make it easy to use, the users are just stupid and won't get it anyway, so let's just code it the easy way. Right. User hostile developers create user hostile user interfaces. Just because there are *some* truly stupid users, and *some* cowardly folks who just assume they can't figure it out without trying, that's no excuse for throwing in the towel and designing junky software.
The more complex your application, the *harder* you should be trying to make it easier to understand. That doesn't mean Clippy. That means giving it a solid, predictable conceptual model, that people can learn and feel comfortable with. Interaction designers know all about this - read a usability or information design book sometime. It's not about printing a 900 page manual, although that isn't obsolete. It's about thinking about the design of your software before firing up the text editor and coding, and testing it with real users to see if your hunch about terminology was right.
It's time to get developers to base their ego on how *good* the user interface it is, instead of how *exclusive* it is. This ain't a bloody nightclub. It's the code you want people to use (buy?). Look down on them and tell them they're not worthy of a manual and you're just giving a competitor an opportunity to kick you in the nuts.
Other reply-ers have contradicted the parent post effectively, except...
Wizards are not always idiotic. Some tasks *require* multiple steps that are not well suited to a modeless UI. For example there is the Excel text file import wizard, which perhaps could have some teeny improvements in each stage, but in general is a good idea. The only other option I can think of for that is to have some kind of preference about how all future text files will be imported that you have to set, and then a 1-step import that uses that preference to import a file. That's a lot more obscure than just asking how to import the file when you open it.
Another good example of a wizard is better known as the checkout process. All online stores have a multistage wizard UI for the purchase process, starting with a selection in the form of a shopping cart. Amazon did a good job with the 1-click thing by letting you create default checkout settings, but that doesn't cover all cases. Sometimes you need to ship it to Dad. Sometimes to work, sometimes to home.
Don't yiz on wizards in general just because you have been frustrated by an inappropriately used one in the past.
>Working behind the scenes, a small government agency headquartered outside of Denver
/. kiddie will be happy to split hairs with me on that.) A more accurate lead paragraph would have ended:
>operates a network of 14 servers capable of changing the operating systems on your
>PC--and millions of others--in less than a second.
Sniff... sniff... what's that I smell? Ahh, the stench of yellow journalism.
You mean that NIST can change the OS on my G4 from MacOS X to LinuxPPC? On my PIII from Win2K to Win3.1? In less than a second? Amazing! They should sell this technology to Symantec for the next version of Norton Ghost! In my world it takes several minutes at best, maybe hours ("hours would seem like days" - Spock/TWoK), to install a new OS.
Oh, you mean, they can change the TIME VALUE STORED IN THE CLOCK. Is the clock part of the OS? No, as far as I can tell the clock is part of the HARDWARE. There is some clock functionality in the OS to get to the hardware clock and to provide time services to apps, but really, the clock is a hardware device. (I'm sure some
>capable of changing the time on your PC--and millions of others--in less than a second.
Oh my god, no! NOOOOOOOOOO!
But wait a second. Doesn't he also say that WinXP syncs once a week, and OS X syncs at an unknown interval ('cos he didn't bother to research it and find out, he just looked at the UI and it doesn't say)? That means it really should say:
>capable of changing the time on your PC or Mac--and millions of others--
>in no more than a week. Unless you configure it otherwise, in which case your clock will be wrong.
OK, let's try that again: Oh my god, no! NOOOOOOOOOO!
Microsoft has discontinued its UltimateTV hardware, leaving only the DirectTV/UltimateTV option. It's not doing fine, just ask one of the 400 people cut from the team (leaving ~100). ZDNet has a nice story about this entitled Why UltimateTV was an ultimate failure. Now, this doesn't necessarily mean that ReplayTV/SonicBlue or Tivo are kicking their asses; none of the PVR vendors is too healthy. It's a tough market and they're all struggling. Still, Microsoft is in a compromised position because they are at the same time trying to fight software piracy and be buddies with the DRM crowd, and to make a device which really screws with the entertainment industry's business model.
The Xbox is a different matter. The best argument I've seen any Microsoft zealot put forth so far is that this is 1.0, and the fact that they sold anything at all is a victory. Riiight. True, Microsoft has monopoly profits and can use them to fund failing projects indefinitely until competitors (who actually have to make money off their products) run out of money. Did somebody say Netscape? But Sony *is* making money on the PS2, and Microsoft is losing money on the Xbox. Even so, Microsoft reduced their sales projections for the Xbox, and are now estimating that they will ship 3.5 to 4 million units by the end of June 2002. Meanwhile, first week the PS2 was available, 980,000 units were sold. The first four days the PS2 game Final Fantasy X was on sale, 1.9 million units were sold. By the end of January 2002, over 4 million copies of Final Fantasy X had been sold worldwide. That means that in the same amount of time (~7 months), one PS2 game outsold the Xbox console. Apparently Gord knows what he's talking about when he said (a year ago!) that "This console race was over before it started." Microsoft needs to pull an maneuver like the IIS/IE one they used to kill Netscape: just give away the Xbox with the purchase of Halo. Eventually Sony will run out of money and give up. Riiiight.
As for PocketPC vs. Palm, that's a matter of speculation and only time will tell if Palm will get it together or if they will continue sitting on their asses while MS gets around to producing a useful PDA for less than $400 (remember that the Palm 105 costs $99 so they aren't really direct competitors - Palm makes the cheap simple ones, PocketPC licensees make the high-end fancy ones).
>This contrasts to a large number of individuals in an organisation who
>know the code very well and work with it day in day out.
I infer that you mean "at a commercial software company". In my experience, few companies actually do pair programming or even code reviews, so on a project with 100 programmers you have 100 people, each of whom know ~1% of the code. So on average, one set of eyeballs sees the code. Not good. Worse, that one average set of eyeballs isn't attached to one brain - what I mean is, if you had one person reviewing all the source, you could make sure to have them check the entire app for a given kind of bug. Instead you have 100 different brains looking with 100 sets of eyeballs, each at 1% of the code. So something that Betty knows not to do will be done as a matter of personal style by Dave and due to inexperience by Hank.
At least open-source *allows* more brains and sets of eyeballs to look over the code. In a commercial context either it's baked into the process and is part of the development project plan (making time in the schedule for code reviews and maybe pair programming) or it's not, and if it's not, the alternative is "Stop looking at Dave's code, get your own damn code done and then let's ship this thing."
There's a flaw in your argument. First you dismiss all non-remote exploits, then you dismiss Apache remote exploits since they will have to "rehack the box from the inside". Well, here come those non-remote exploits back into the spotlight again. Script kiddies definitely favor the remote root exploit, but nevertheless, if a cracker gets a shell running as "nobody" or "www" that gives them a chance to start hammering on those *local* root exploits.
It's definitely better from a probability standpoint to run those services as nobody or www anyway, just in case the cracker has a dumb script that expects them to run as root, and will fail otherwise. But don't dismiss all those local exploits that could be used by a non-root remote exploit to get root.
Seriously, have you never heard of the Web Standards Project?
http://www.webstandards.org/
Web developers are sick of coding HTML, JavaScript, and CSS for one browser, and then debugging it for every other browser they have to support. Netscape 4.x and 6.0 are definitely high on the list of sucky browsers to have to support, but IE 5, 5.5, and 6 aren't perfect. Also, IE 5, 5.5, and 6 differ greatly, not to mention the Mac versions of IE which also differ. You can't just target one IE version and get 100% compatibility with the others.
So, rather than looking at the ridiculous statistics that say stuff like "97% of browser users use MSIE" (which I just don't believe), start looking at stats about which browser AND VERSION your users are using. Surprise, chances are there are a hell of a lot of IE 5 and 5.5 users. Chances are there is no one browser+version that covers the majority of your site's users. Doh! So much for just targeting "one" browser.
So, forget about this silly notion of "IE won, all web sites will be IE sites from now on." That's not financially viable, since IE is actually serveral products which must be QA'd for separately. The solution that web designers are rallying around is "code to the standard, and debug for supported browsers from there." Screw IE 5, make people upgrade to IE 6. Screw Netscape 4.x, make them upgrade to 6.2, 7.x, or Mozilla 1.0.
Otherwise, why even bother with HTML at all? If you're going to target Windows only, you're wasting your time trying to get a good GUI user experience and robust application functionality implemented with tools as crappy as HTML, JavaScript and CSS. The only reason to use them is to get thin-client, cross-platform, cross-browser functionality with zero download time. Use Delphi or Visual C++ or Java or something if you want total control over the user experience and you don't care about porting.
> Now I haven't used Mozilla 1.0 extensively yet, what with it just having come out,
> but I can tell you that Netscape 6 and espically 4 have problems of just rendering
> HTML WRONG.
Netscape 6 came out a *year and a half* ago. The excuse of "Mozilla 1.0 just came out" is totally bogus - Netscape 6.1 and 6.2 have been released since then, and are much better than 6.0. If you really wanted to keep an eye on Mozilla's progress, you could have downloaded nightly builds or stable milestone builds every few weeks, or months. The downloadable installers have been out there, 1 click away from www.mozilla.org, all along. Mozilla 1.0 RC1 has been out for over a month.
Why not do this:
1) download Mozilla 1.0 and see how your stuff works
2) post a comment describing how good or bad Mozilla 1.0 is
Nobody really cares how Mozilla 0.6 stacks up against IE 6 anymore.
Is that supposed to be like "I only read Playboy for the articles?"
echo 5050
Bravo! Fad coding is a very real problem, and in the OO world, over-abstracting and over-design-pattern-ing is a real problem, even though those aren't real words. :)
There are requirements that can make abstracted designs a good idea - things like i18n, which suggests that all the text in your UI should be ripped out of constants and put in config files. So in that case Hello World would need a way to read the config file in order to easily morph into Bonjour Monde or Hola Mundo or whatever.
I can't tell you how many times I've seen an object model in a project that starts with EVERYTHING being based on some GenericItem object that all the others inherit from, and GenericItem has no real value. The designer just wanted to use inheritance a lot. Oy.
I like OO and all, I just don't like OO developers who read 10 books on OO and try and apply 100% of what they've read in their first project... and spend all their time building more and more goofy infrastructure instead of actually implementing any functionality.
>Any mission critical application (OS kernel, NASA spacecraft software
> etc etc) is done in Z type languages.
Really? Can you back that up? Specifically, can you prove that any of Windows NT / VMS / Solaris / FreeBSD / Linux / MacOS X have a kernel that was written in a "Z type language" as opposed to just coded directly in C/C++/whatever and tested the hard way?
New career for ChrisD: editor in chief at Time Canada... :)
get it... iMac leak... sigh.
Think about it, you can sell X number of copies of your game due to your cheesy graphics and story (*cough* QUAKE *cough*) and then sell 2x more to die hard gamers who will download a free TC and replace your crappy creative work with stuff done by someone else. Basically you get paid for your engine, and somebody else donates the creative work for "cred". Not a bad scam. Maybe the TC folks get paid too, big friggin deal. Still, it's entirely reasonable given that game engines have separated the engine from the creative content for so long, to allow parallel development of the storyline and graphics from the rendering engine, combat system, etc.
I disagree with the statement that law should not be up for interpretation. Check out Philip K. Howard's book, "The Death of Common Sense" (ISBN 0-446-67228-9) which details many, many cases where extremely specific laws and regulations have prevented courts and regulators from doing the reasonable, sensible thing.
The fear is that law that's open to interpretation will be abused. True, it will be abused to a certain degree. However, law that's overly specific forces the hand of law enforcement even if they don't want to do something, and that is very harmful as well. Laws should be specific in favor of the citizen, restricting what's illegal rather than trying to enumerate all possible ways to represent or convey kiddie porn. Writing ultra-detailed laws is like trying to write source code for a regulatory body, and there are inevitably huge bugs. But people aren't as stupid as computers and can make judgements. There are other ways to prevent corruption and abuse than writing a 400 page law, or saying "anything that anyone might ever think looks like a minor having sex, even an ink blot that Sheriff Inbred thinks looks kinda dirty, is child porn".
Also, you can't solve all problems by passing a law against them.
The reason Be failed as a dual-boot option is that Microsoft forced the OEMs not to! Read the lawsuit Be has filed against Microsoft. Microsoft also strongarmed OEMs (Dell) not to ship Linux at all, even as a single-boot option on servers. Microsoft uses whatever leverage it has to get its way, and since it has a monopoly, some of their tactics illegal. They do it anyway.
It's not the OEMs who aren't giving users the opportunity to choose. They would love to sell more PCs by selling to folks who want FreeBSD and Linux and OpenBSD and BeOS preloaded. That's a competitive differentiator and they'd love to have that kind of offering. Their hands are completely tied by Microsoft as to what they can put on the PCs they sell. The only option they have is to drop Windows entirely and ship ONLY Be, Linux, or FreeBSD, and you can ask VA Linux, I mean, VA Software Corporation, how well that worked.
It's interesting that it took this long for an ancient problem to be sorta kinda attacked, if not solved. Maybe this is because the Usenet infrastructure has changed to the point where 7-bit is silly, but why is this something that's just being addressed now? Don't tell me this is a brand new problem that the best minds of the news admin community couldn't have figured out by now.
One approach to short-circuit standards is to take the rogue approach that Netscape did, which is very different from the one folks keep accusing Microsoft of. That approach is to take an almost-suitable standard and extend it, in the same spirit, with the intent that your well-thought-out extension will be adopted later. Of course they did a less than perfect job, but the idea is sound: don't wait for the spec, lead it, while making it possible for it to remain open. That's different from the Microsoft approach of "Embrace, Extend [and Exterminate]" wherein you add undocumented proprietary features that lock you into a single vendor's solution. A hell of a lot of what's in the HTML 4 standard was released as a non-standard but documented extension by Netscape in 1.1 and 2.0. Some of that was bad (blink, and arguably frames), but when you judge Netscape, try to separate the new HTML tags from the bugs, because it's the bugs (and having to code around them) that make the web such tower of Babel.
So basically what I'm saying is, if MIME is almost there, CAREFULLY THINK THROUGH and implement the extensions you want, and implement it already. Or, pick something other than MIME. But, don't start from scratch and make mistakes that have already been learned from and solved. Build on the good decisions of the past. The real crime is solving the same problem, badly, over and over; getting ahead of a standards body while keeping intentions pure and decisions wise is not nearly as bad.
Great idea! Take *nix and put a great user interface over it. Then put it on a unit with a 15" LCD display, 10/100 Ethernet, a DVD burner, a high-end grpahics card, and maybe an optional wireless card.
It's called an iMac, dude.
"Linux people" are real. They are all about "no, god dammit, I want to configure it all myself, compile it all myself, and run developer snapshots of everything." Not exactly Grandma, nor what AOL or any other sane company would want to support. Linux is the new tinkerer's OS, and if it became untinkerable, what would be the point? Who would buy it? Every time some company releases a Linux based appliance, the Linux community goes nuts trying to figure out how to crack it open and hack on it. Linux wants to be tinkered with. And, of course, the company goes under or kills the product, because aside from the occasional Linux tinkerer who bought it because it has Linux Inside(tm), nobody else really cares about these things. When you take the tinkerability out of Linux, it's boring, and Grandma starts asking why she can't just have Windows like everybody else.
I agree that a limited, locked-down platform would be ideal for a web terminal, but sorry, Linux distros aren't there. Have you ever had to configure device drivers on your cable box, DVD player, PVR, or cell phone? Of course not. Have you had to "just recompile the kernel" on your thermostat? Of course not. "But a PC is more complicated than a thermostat!" Exactly.
OK, now you've crossed over from debating an idea, to name-calling and cursing. Your arguments here support my point, while you make ad hominem attacks. You play at condescending to me, but you refer to Newton, who was not a chemist, in order to take my examples that repudiated your argument, and elaborate on why they work, supporting my argument. Then you call me a moron several times. I think you need to concentrate on the topic at hand, which is not a grade-school cutdown contest, because your topical arguments are weak, and name-calling will not make you more correct.
You say it's all about rigidity, but your examples are incorrect. You use the example of a bullet hitting a block of steel, and not leaving a dent. In fact, a lead bullet hitting a steel block leaves a sizable dent in the steel block, and can even vaporize part of the steel block. Go to a shooting range with a steel plate a few inches thick sometime, and try it out. The steel plate is clearly more rigid, but is deformed nonetheless. Also, when a bullet hits flesh, it is definitely deformed, especially in the case of hollow point bullets, which are made of metal that is certainly harder than flesh, but the shape of the bullet is specifically designed to deform maximally upon impact with flesh to do more damage (leaving a bigger hole). A bullet which pierces a bone (such as a skull) also deforms, which doesn't fit with the way you think ridigity and impact works. In your explanation, either the bone would deform, or the bullet would, but not both. In fact, both do. This link is a bit gory but shows photographic evidence of the behavior I'm describing:
http://www.plusp.com/gallery3.htm
As yet another real-world example, water is not very rigid at all, but over time, even with minimal velocity, it can deform stone. Go have a look at the Grand Canyon if you're not sure this is true.
If you want to say that a physical fracture caused by an impact is a "chemical" process just because the fracture involves electromagnetic forces lumped in with "atomic chemistry", that's definitely stretching. Does that make Bruce Lee a chemical weapon, too? After all, he could break a stack of bricks, or boards, or blocks of ice, using his fist. If he punched someone and broke their rib, does that make his fist a chemical weapon? It never even came into contact with the bone which was fractured, but you're saying that since fores of atomic chemistry are involved, it is. Well, I guess that makes the skin and muscle of the person who's being punched a chemical weapon too, since that was what actually carried the force from Bruce's fist to the bone in this example.
One might also argue that a bullet is a quantum weapon, since there are quantum forces underlying atomic chemistry. That too would be stretching things, and "any good chemist" wouldn't say that bullets should be considered chemical weapons, any more that whacking someone with a two-by-four is a nuclear attack, even though all those molecules in the two-by-four have nuclei.
It seems that you're arguing for the sake of arguing, either to show off how much you know about physics and chemistry (which apparently isn't a lot), or to try to obscure the definition of chemical weapons for reasons I can't guess.
I hope you will take some time to research your assertions next time before making incorrect statments about physics. Lots of examples are out there and it has nothing to do with me vs. you nor whether I'm a moron as you claim; it's reality vs. lack of knowledge, and your assertions are incorrect. Basing your argument on invalid statements about physics doesn't help you prove your point. And, of course, changing the subject to whether I'm worthy of arguing with you doesn't make your incorrect arguments more valid.
>why are lead bullets not considered chemical weapons? I'd say a bullet piercing flesh is a very
>chemical action. Any good chemist could explain to you the atomic chemistry of why the lead bullet
>traveling at considerable speed can pierce a less rigid entity such as a human's skin and internal
>organs.
Um, maybe it's because bullets *aren't* chemical weapons. A bullet piercing flesh is most definitely not a chemical action, and frankly it's a damn silly statement to make that it is. Licking a lead bullet, or gently swallowing it whole, might lead to death eventually, I guess.
It's not just about rigidity, either. You can pierce a thin sheet of ice with a jet of water. You can pierce skin with a forcefully propelled liquid. In fact, you can pierce skin with a forcefully prepared gas. If you don't believe me, load a gun with blanks, place your hand firmly over the end of the barrel, and fire.
If it's about a chemical reaction, hold a lead bullet up to your skin for a few hours, or tape it next to the skin for a few weeks, and see if the bullet ends up on the other side, having blasted a huge hole through your body. Nope. Try the skin-contact test with a strong acid, or perhaps some nerve gas, and see if the results differ.
Seriously, how can you assert that a lead bullet is a chemical weapon? C'mon. I'd say you were a troll but the tone of your message implies you take your statement seriously.
OK, here's an analogy that even our breathtakingly retarded politicians can understand, even if they're just pretending to be stupid because they are in the back pocket of some of the wealthiest human beings on earth (who clearly need laws passed to protect them from the minimum wage making masses):
Imagine a law proposed by law enforcement agencies, that requires that anything that could be used as a weapon, to make a weapon, to harm or by inaction come to be harmed a law enforcement officer, would be required to incorporate technology to detect whether it was about to harm a law enforcement officer, and refuse to operate in that case.
Obviously the MPAA is thinking about PC's, hard disks, and audio/video entertainment devices here. What they've crafted is something so overbroad, it's like saying that every lead pipe, brick, or 2x4 made must by law fail to operate if it's about to whack a cop upside the head. This is *totally* insane. Let's think of a few devices capable or storing, transmitting, or processing digital data. DNA. A flashlight. A penny. Your mom. Photographic paper. A VHS videotape. A light switch. An ethernet cable. A piece of wire.
Vendor salespeople are paid to convince the Big IT Boss to commit to huge implementations as the first purchase. Screw that. Set up a single lab, buy a dozen client licenses and a single server, and see how it goes. Make NO committment to go any further.
Maybe try a couple of different options (the Unix based thin client approach, the Citrix or MS Terminal Server approach, the Ghost/Imagecast reinstalled PC approach) at once in different labs. Then you'll have *actual experience* with *the vendor's actual shipping product* that you can base your decision on.
Also, definitely ask for several client references from each vendor. Compare notes with other folks who have implemented the solution in question - maybe they figured out a workaround that the vendor doesn't know about, that would work for you.
Perl 5 will not handle most of these requirements. It will handle about a third of the requirements. Simplified GUI design? Perl doesn't even have a concept of a GUI built into the language, nor an event model. Advanced object-oriented design, my ass. Perl's OO lacks basic data hiding features (public / private / friend / package / protected type modifiers on data members and methods) on purpose, because Larry Wall doesn't think encapsulation is a good idea (it restricts what a developer can do). Operator overloading, AFAIK you can't do that in Perl at all.
Perl is very portable, has garbage collection, supports inline documentation with man-page and HTML doc generation, is astonishingly fast at text processing even with enormous files, and is great for system-level scripting.
It has exceptions, and is sorta-kinda OO (I consider encapsulation a must-have for any OO language), but the problem is, nobody uses either of these. Go look on CPAN, and decide for yourself whether that code is as object-oriented as the classes that come with Java, Python, C#/.NET, etc. When you use the Foo::Whatever module, the typical approach is to have it import a bunch of functions into your namespace that you can then use on a standalone basis. Classes should model real entities in the problem domain, but that's not how people use Perl classes... they use them as function libraries that have a bit of control over namespace importing. And of course nobody uses exceptions in Perl, falling back on C-style nested IFs from hell, or just not testing for errors at all.
Don't get me wrong; you *can* make objects in Perl (if you don't care about encapsulation), and you *can* use exceptions. It's just that nobody does, so any code you reuse will have a totally different design style that looks more like a monter shell script or C program than a robust, maintainable, well-factored OO application.
./configure --with-booklungs --with-antennae --no-fishybits \
--legs=6 --enable-experimental-wing-thingies
make critter
./critter -buz