It's pretty clear that Adobe didn't want to drop this case at all, otherwise they could have persuaded the government to drop it and they wouldn't have spent lots of money trying to track down copyright violations.
Adobe simply didn't want the bad PR of going against a harmless, hardworking programmer and causing a father of two to rot in American prisons for several months over their substandard ebook encryption. So, the position they are taking is "Uncle Sam made us do it".
I have recently run MS Office XP and MS Office X. I try to use it for actual work as little as possible, however.
Office 2000 or XP for Windows is slick and fast.
Microsoft Office is more bloated and more CPU intensive than ever, and about as buggy as has always been (meaning, usable, but expect crashes). The only reason why it seems to be getting a little better is because machines have gotten so much faster and have so much memory. Also, Microsoft plays some dirty tricks with pre-loading code so that it seems like it's starting up fast even though it isn't.
If Open Office is sluggish, that's a very bad thing.
OpenOffice runs better than MS Office on equivalent hardware. The thing that's "sluggish" about it is mostly the startup, which takes distressingly long for a Linux program, but is about par for a Windows program. It's just that traditional UNIX and Linux users are used to programs starting up almost instantaneously and not consuming dozens of megabytes of memory to do something as simple as word processing or calculations.
It is, though, what the market seems to want. You can buy the various Office products individually, but people still buy Office instead.
That has nothing to do with what people want. It's because Microsoft makes site licensing deals for the whole thing, because lots of people get it with their PC, and if you want any two components, you might as well get the whole thing. It's also because the way office is set up, if you buy just one or two components, it feels vaguely incomplete.
In fact, many people don't want to run MS Office at all--they only do it because people send them proprietary documents that they need to read somehow. That's certainly the only reason why I run it.
The current 800MHz EPIA is more like a 300MHz PII, although it can be better on some apps. The new EPIA-M runs at 933MHz and has a number of other improvements.
It's hard to tell how fast the XScale will be; floating point may well be much worse than even the EPIA. But if you want good CPU performance, neither the EPIA nor the XScale is a good choice.
People who don't matter for ideology behind free OSes won't bother switching. ANd I'm afraid this means a lot of users...
Windows running GNU software is still Windows, with all its warts, usability problems,and inefficiencies. End-users notice, believe me. They notice when their shiny new 2GHz machine crawls through problems slowly. They notice even more when their Windows machines fail, as they are prone to after running for a few months, and people stop giving them free technical support and suggest installing a more reliable OS instead.
Overall, I think bringing some open source software to Windows is good, namely software that workes like entrenched Microsoft products but costs less: Mozilla, OpenOffice, lots of utilities and games. When a Linux program does something that isn't easily available under Windows otherwise, it should not get ported: those programs provide additional motivation to switch.
Sometimes, that's a good reason. But here, I just don't see it. Moving code between such huge projects is usually a lot of effort--more than it's worth. And Gobe has the additional problem that it was written originally for a specific platform.
You may think that there is nothing wrong with a handwriting recognizer that blithely assigns random strings to doodles, but it really does point to a deeper problem with the Tablet PC handwriting recognizer.
If you give it anything, it picks whatever seems closest among a dictionary of known words. That is really an indication that the recognizer makes up for a lack of shape recognition performance through a limited vocabulary. And the problem with that is that it has a hard time with words it doesn't know.
A good recognizer should reject junk that is fed to it rather than hallucinating meaning into it in an effort to pretend that it's better than it actually is.
Tablet PCs have 800MHz-1.5GHz Pentiums--they get more CPU cycles than are allocated to most web sites (which only get a fraction of a, usually older, rack-mounted server).
I was totally blown away by how good the handwriting recognition was.
The handwriting recognition on the Tablet PC is better than the kinds of hacks that the Palm, Newton, and many other "commercial" systems have used before, but the technology isn't particularly new.
Much of what it does is by using a lot of dictionary constraints. Try writing some nonsense words, and you'll see that it will turn them into whatever word seems most similar.
As far as "it needs a doodle setting", the apps that I used saved things as digital ink by default,
Applications like Word, Excel, etc. running on Tablet PC don't use digital ink by default, and the integration of ink into those applications is pretty lousy in my opinion. That's particularly ironic given how much Microsoft has bragged about the supposedly good job they have been doing on integrating ink into applications.
It seems to me that OpenOffice fills the software category of "Microsoft Office clone" expertly. It is very full featured, XML-based, and is actively being developed by many people. Sure, it's a bit big and sluggish, but that should only make MS Office users feel more at home, and there is no guarantee that Gobe won't be as big and sluggish once it has been made cross-platform and equivalent functionality has been added.
It seems to me that, going beyond OpenOffice, the notion of an "integrated office suite" itself is broken. Gobe may be a little better than OpenOffice in design (I doubt it's as functional), but somehow that strikes me as just a meaner sabre tooth tiger--a better implementation of an evolutionary dead end. Even Microsoft has seen the light and claims that they will be trying to redefine what an office suite is in the future.
Unless there is some groundbreaking new functionality in Gobe that just can't be added to OpenOffice, the efforts that would go into porting Gobe to Linux and enhancing it would seem to be better spent on tuning, modularizing, and enhancing OpenOffice.
Actually, society has already advanced much further than that. Many people rely on "instant optical networking". Availability, social status, hobbies, religious affiliation, sexual interests, profession, and personality are encoded in a wide variety of wearable shapes, patterns, and accessories. It allows them to scan a crowd of hundreds or thousands and instantly pick out potential mates, friends, or colleagues.
Such broadcasting and recognition is followed by point-to-point communications, commonly referred to as "flirting" (if optical) or small talk (if verbal). Various other optical signaling devices are used and selectively made accessible to the other party in order indicate other interests for point-to-point communications, like "books", "newspapers", "wedding rings previously invisible under clothing", etc.
Over the years, the signaling system has changed somewhat. For example, a near-perfect association between actual social status or wealth and clothing used to be assured, but today, many people advertise more of their inner attitudes and desires than actual status using clothing.
What has also deteriorated somewhat is the ability of some people to read and respond to these cues. For example, some people can't tell the difference between "flirting" and "solicitation". That is perhaps while some people are looking for rule-based electronic alternatives. But where is the fun in that? That's like playing chess by having a chess computer tell you all the moves.
Here is the main idea, introduced by Gerd Kortuem, a 38-year-old assistant professor
No, it wasn't "introduced" by him. The idea has been kicking around for many, many years. It's found its way into numerous science fiction stories. There have been a number of experiments and demonstrations already as well.
If you get a Mini-ITX machine instead, you get something that not only runs Pentium-based software, including Linux and Windows, you also get a smaller motherboard, more ports, and much cooler cases. And I suspect the Mini-ITX systems use less power and are quieter, too.
The point of building an XScale-based desktop PC and then sticking it into such a big, ugly package really eludes me. It's not like you can add a lot of expansion boards to it anyway.
On the other hand, I've seen this promissing language that appears to blend Python and C in a smooth manner.
I find the blend of Python and C anything but smooth: the Python C API is complex and error prone, and once you load a C module into Python, all bets are off when it comes to safety.
What blends very nicely is Python and Java: the mix is secure and safe and Python objects appear as Java objects and vice versa.
What I'd like is a version of Eiffel that both captured the flexibility of Python, and could link transparently to Static Eiffel for efficiency.
That isn't sufficient: that kind of mixture, in which only the Python-like part is dynamic, imposes too many restrictions on the static part; it basically means that all the efficient code remains inflexible, and all the flexible code remains inefficient.
While Java and C# have lots of warts as languages, I think their kind of runtimes are the future. If you don't like the Java or C# languages, you can use compilers like SmartEiffel to compile for those runtimes (although I think SmartEiffel itself is still not quite flexible enough for even that to be all that useful).
Eiffel is about as far from being what is referred to a "functional programming language" as any language can be. Until recently, Eiffel didn't even allow you to manipulate functions or methods as data. Eiffel should feel right at home to any Java or C# programmer: it's a fairly simple statically typed object-oriented programming language with multiple inheritance and genericity.
I think Eiffel's lack of success has to do with some serious problems and limitations in the early design of the language, which have only been addressed in the last few years in the main commercial Eiffel compiler. And SmartEiffel does not even implement the full, commercial Eiffel system.
As a language, SmartEiffel is similar to Java or C#, but it has language support for genericity, operator overloading, multiple inheritance, lexical closures, expanded types, and pre/post-conditions. Eiffel's syntax is more similar to Pascal (probably the most annoying part of Eiffel's syntax is that you cannot declare variables at the point of first use).
What SmartEiffel lacks is good support for dynamic loading and reflection. Those are crucial features for many real-world applications these days, and given SmartEiffel's compilation strategy, they'll be very difficult to add.
SmartEiffel's performance was disappointing last time I benchmarked it--Sun Java beat it handily on equivalent problems. In principle, given its compilation strategy and static semantics, SmartEiffel should be able to yield very high performance code.
Eiffel is an advanced object-oriented programming language that emphasizes the design and construction of high-quality and reusable software. [...] Eiffel supports the concept of "Design by Contract" to improve software correctness.
Of course, those are merely claims. Sure, Eiffel is almost certainly better than C/C++ in terms of reuse and correctness, but then, what isn't? But is it better than Java, C#, or O'CAML? Or Python, for that matter? Where is the experimental evidence to support those claims?
Eiffel strongly encourages OO programming and does not allow dangerous practices from previous generation languages although it does interface to other languages such as C and C++.
By now, Eiffel itself is, in a sense, a "previous generation language". The baseline these days isn't C or C++, it's languages like Java, C#, and O'CAML.
C, C++, Java, C#, and Objective-C, have extensive support for dynamic class/code loading and manipulating objects with types not known at compile time. These are crucial features in modern systems and applications programming languages because many modern software systems are built out of dynamically loadable components and have plug-in architectures. Support for these features is probably at the core of the success of these languages.
Java and C# are particularly interesting in this regard because they not only support dynamic class/code loading, they also support it safely and with full reflection. That's really the future.
SmartEiffel, on the other hand, takes a static, global program analysis approach to compilation and optimization. It provides almost no reflection or dynamic loading (if you compile to JVM, you may be able to rig something up). I think ultimately, that makes it a fairly unattractive choice for many applications. Even the commercial Eiffel systems only had those features retrofitted over the last few years, which probably accounts in part for the very limited success of Eiffel as a language.
SmartEiffel is a really great concept, and for some niche applications, it is very useful (I have used it for some prototyping). I would very much like to see a safe, batch-compiled language catch on for Linux system programming as an alternative to C/C++. But I just don't think SmartEiffel is it, at least not yet.
I don't think so. Intel already has a good compiler for Itanium and there are lots of language X -> C scripts which don't increase code execution times.
X-to-C compilation is an efficient solution only for a very limited set of languages: C just doesn't make a good backend, and, furthermore, many languages require frequent runtime code generations, which is simply too expensive with an external C compiler.
Further I think there is strong evidence that Intel is going to make sure that GCC does a good job (which gets you about 20 languages).
Yes, and they all roughly have the same world view as C.
At the same time Parrot is going excellently.
Parrot is a byte code interpreter. Of course, you can write byte code interpreters in C and then compile them with a C compiler. That is not a very efficient use of processor resources: you'd be better off compiling natively to a much simpler processor than an Itanium, without the VLIW features. And that's my point: Itanium further and unnecessarily enshrines the C view of the world, putting any alternatives at a grave disadvantage. That's not the way to make progress in software.
The band isn't regulated, so you can do what you want.
First of all, it's not unregulated; like any form of wireless, there are already lots of regulations that affect its use. For example, you can't build a 5 MW transmitter in the 2.4GHz band.
Second, my point is that it should be regulated more because if it isn't, there will be no band left for the purposes that this band was intended for.
That is, if the 2.4GHz and 5GHz start getting used for providing wireless services, you can kiss your corporate and home wireless networking infrastructure "good-bye": companies like IBM and AT&T have deep enough pockets to deploy enough access points to make any other use of 802.11 infeasible.
We need bands for home networking, wireless LANs, local wireless phones, and other in-house services. 2.4GHz and 5GHz bands are it, and other uses of those bands will interfere with their intended use. If it becomes a free-for-all, the intended use will lose out. And that's particularly unfair because those bands really only became economically interesting to wireless service providers after demand by consumers and businesses for equipment has driven the prices down so much.
If 802.11 is a viable way of providing commercial wireless services, the right solution would be for the FCC to allocate neighboring bands to such services and have providers pay for the use of those bands. That way, they can use essentially the same equipment, and they won't be interfering with the intended uses.
Why don't we just give up on urban plannning and let everybody build where they want? Why don't we just get rid of the police or military and let everybody defend themselves? Maybe you'd like to live that way, but most societies figured out that government is better than anarchy.
Why would someone pay for rainbow when they could get free service?
If people start using 802.11b for providing commercial services in a big way, there won't be any free service anymore because the bandwidth will be used up. That's exactly the problem.
I find this rather disturbing. The spectrum that 802.11a/b uses was not intended for for-profit service providers. Their use of this spectrum will degrade the performance of the intended users.
Where is this going to end? Are cellular companies going to offer phone service using VoIP over 802.11, complete with roaming via IP roaming?
I think whenever spectrum like that used for 802.11b/a is assigned, the FCC should prohibit people from selling services based on it--users that sell services should buy their own spectrum. Otherwise, such companies will just take over what was supposed to be a public resource. It's kind of like allowing businesses to just take over parts of the public park or street. Such restrictions wouldn't mean you can't use it for business purposes: you can still buy the equipment and use it internally, and you can still give service away to your friends.
It's probably not developers versus non-developers.
When it comes to open source software, it is. That's because open source developers write the software they use and therefore give it the user interface they like.
I'm a developer, but for rarely performed tasks, I prefer a tool with an easy UI.
Sure, and developers create those kinds of tools ("easy" for a developer is still different from "easy" for the general public). For example, "icewm" has "icepref"--something that's great for casual use by programmers, but too hard for non-programmers.
Slashdot Mirror
Adobe simply didn't want the bad PR of going against a harmless, hardworking programmer and causing a father of two to rot in American prisons for several months over their substandard ebook encryption. So, the position they are taking is "Uncle Sam made us do it".
With 100000 pirated ebooks, I think it's already been proven that their "ebook technology" doesn't work.
In fact, calling something as kludgy and retrofitted as PDF with its bogus "encryption" a "technology" seems like giving it too much credit.
I have recently run MS Office XP and MS Office X. I try to use it for actual work as little as possible, however.
Office 2000 or XP for Windows is slick and fast.
Microsoft Office is more bloated and more CPU intensive than ever, and about as buggy as has always been (meaning, usable, but expect crashes). The only reason why it seems to be getting a little better is because machines have gotten so much faster and have so much memory. Also, Microsoft plays some dirty tricks with pre-loading code so that it seems like it's starting up fast even though it isn't.
If Open Office is sluggish, that's a very bad thing.
OpenOffice runs better than MS Office on equivalent hardware. The thing that's "sluggish" about it is mostly the startup, which takes distressingly long for a Linux program, but is about par for a Windows program. It's just that traditional UNIX and Linux users are used to programs starting up almost instantaneously and not consuming dozens of megabytes of memory to do something as simple as word processing or calculations.
It is, though, what the market seems to want. You can buy the various Office products individually, but people still buy Office instead.
That has nothing to do with what people want. It's because Microsoft makes site licensing deals for the whole thing, because lots of people get it with their PC, and if you want any two components, you might as well get the whole thing. It's also because the way office is set up, if you buy just one or two components, it feels vaguely incomplete.
In fact, many people don't want to run MS Office at all--they only do it because people send them proprietary documents that they need to read somehow. That's certainly the only reason why I run it.
It's hard to tell how fast the XScale will be; floating point may well be much worse than even the EPIA. But if you want good CPU performance, neither the EPIA nor the XScale is a good choice.
Windows running GNU software is still Windows, with all its warts, usability problems,and inefficiencies. End-users notice, believe me. They notice when their shiny new 2GHz machine crawls through problems slowly. They notice even more when their Windows machines fail, as they are prone to after running for a few months, and people stop giving them free technical support and suggest installing a more reliable OS instead.
Overall, I think bringing some open source software to Windows is good, namely software that workes like entrenched Microsoft products but costs less: Mozilla, OpenOffice, lots of utilities and games. When a Linux program does something that isn't easily available under Windows otherwise, it should not get ported: those programs provide additional motivation to switch.
Sometimes, that's a good reason. But here, I just don't see it. Moving code between such huge projects is usually a lot of effort--more than it's worth. And Gobe has the additional problem that it was written originally for a specific platform.
If you give it anything, it picks whatever seems closest among a dictionary of known words. That is really an indication that the recognizer makes up for a lack of shape recognition performance through a limited vocabulary. And the problem with that is that it has a hard time with words it doesn't know.
A good recognizer should reject junk that is fed to it rather than hallucinating meaning into it in an effort to pretend that it's better than it actually is.
Tablet PCs have 800MHz-1.5GHz Pentiums--they get more CPU cycles than are allocated to most web sites (which only get a fraction of a, usually older, rack-mounted server).
The handwriting recognition on the Tablet PC is better than the kinds of hacks that the Palm, Newton, and many other "commercial" systems have used before, but the technology isn't particularly new.
Much of what it does is by using a lot of dictionary constraints. Try writing some nonsense words, and you'll see that it will turn them into whatever word seems most similar.
As far as "it needs a doodle setting", the apps that I used saved things as digital ink by default,
Applications like Word, Excel, etc. running on Tablet PC don't use digital ink by default, and the integration of ink into those applications is pretty lousy in my opinion. That's particularly ironic given how much Microsoft has bragged about the supposedly good job they have been doing on integrating ink into applications.
It seems to me that, going beyond OpenOffice, the notion of an "integrated office suite" itself is broken. Gobe may be a little better than OpenOffice in design (I doubt it's as functional), but somehow that strikes me as just a meaner sabre tooth tiger--a better implementation of an evolutionary dead end. Even Microsoft has seen the light and claims that they will be trying to redefine what an office suite is in the future.
Unless there is some groundbreaking new functionality in Gobe that just can't be added to OpenOffice, the efforts that would go into porting Gobe to Linux and enhancing it would seem to be better spent on tuning, modularizing, and enhancing OpenOffice.
Such broadcasting and recognition is followed by point-to-point communications, commonly referred to as "flirting" (if optical) or small talk (if verbal). Various other optical signaling devices are used and selectively made accessible to the other party in order indicate other interests for point-to-point communications, like "books", "newspapers", "wedding rings previously invisible under clothing", etc.
Over the years, the signaling system has changed somewhat. For example, a near-perfect association between actual social status or wealth and clothing used to be assured, but today, many people advertise more of their inner attitudes and desires than actual status using clothing.
What has also deteriorated somewhat is the ability of some people to read and respond to these cues. For example, some people can't tell the difference between "flirting" and "solicitation". That is perhaps while some people are looking for rule-based electronic alternatives. But where is the fun in that? That's like playing chess by having a chess computer tell you all the moves.
No, it wasn't "introduced" by him. The idea has been kicking around for many, many years. It's found its way into numerous science fiction stories. There have been a number of experiments and demonstrations already as well.
The point of building an XScale-based desktop PC and then sticking it into such a big, ugly package really eludes me. It's not like you can add a lot of expansion boards to it anyway.
I find the blend of Python and C anything but smooth: the Python C API is complex and error prone, and once you load a C module into Python, all bets are off when it comes to safety.
What blends very nicely is Python and Java: the mix is secure and safe and Python objects appear as Java objects and vice versa.
What I'd like is a version of Eiffel that both captured the flexibility of Python, and could link transparently to Static Eiffel for efficiency.
That isn't sufficient: that kind of mixture, in which only the Python-like part is dynamic, imposes too many restrictions on the static part; it basically means that all the efficient code remains inflexible, and all the flexible code remains inefficient.
While Java and C# have lots of warts as languages, I think their kind of runtimes are the future. If you don't like the Java or C# languages, you can use compilers like SmartEiffel to compile for those runtimes (although I think SmartEiffel itself is still not quite flexible enough for even that to be all that useful).
I think Eiffel's lack of success has to do with some serious problems and limitations in the early design of the language, which have only been addressed in the last few years in the main commercial Eiffel compiler. And SmartEiffel does not even implement the full, commercial Eiffel system.
What SmartEiffel lacks is good support for dynamic loading and reflection. Those are crucial features for many real-world applications these days, and given SmartEiffel's compilation strategy, they'll be very difficult to add.
SmartEiffel's performance was disappointing last time I benchmarked it--Sun Java beat it handily on equivalent problems. In principle, given its compilation strategy and static semantics, SmartEiffel should be able to yield very high performance code.
One of the things people should learn about OOP is when not to use it. If you force them to, they'll end up using it inappropriately.
Of course, those are merely claims. Sure, Eiffel is almost certainly better than C/C++ in terms of reuse and correctness, but then, what isn't? But is it better than Java, C#, or O'CAML? Or Python, for that matter? Where is the experimental evidence to support those claims?
Eiffel strongly encourages OO programming and does not allow dangerous practices from previous generation languages although it does interface to other languages such as C and C++.
By now, Eiffel itself is, in a sense, a "previous generation language". The baseline these days isn't C or C++, it's languages like Java, C#, and O'CAML.
Java and C# are particularly interesting in this regard because they not only support dynamic class/code loading, they also support it safely and with full reflection. That's really the future.
SmartEiffel, on the other hand, takes a static, global program analysis approach to compilation and optimization. It provides almost no reflection or dynamic loading (if you compile to JVM, you may be able to rig something up). I think ultimately, that makes it a fairly unattractive choice for many applications. Even the commercial Eiffel systems only had those features retrofitted over the last few years, which probably accounts in part for the very limited success of Eiffel as a language.
SmartEiffel is a really great concept, and for some niche applications, it is very useful (I have used it for some prototyping). I would very much like to see a safe, batch-compiled language catch on for Linux system programming as an alternative to C/C++. But I just don't think SmartEiffel is it, at least not yet.
X-to-C compilation is an efficient solution only for a very limited set of languages: C just doesn't make a good backend, and, furthermore, many languages require frequent runtime code generations, which is simply too expensive with an external C compiler.
Further I think there is strong evidence that Intel is going to make sure that GCC does a good job (which gets you about 20 languages).
Yes, and they all roughly have the same world view as C.
At the same time Parrot is going excellently.
Parrot is a byte code interpreter. Of course, you can write byte code interpreters in C and then compile them with a C compiler. That is not a very efficient use of processor resources: you'd be better off compiling natively to a much simpler processor than an Itanium, without the VLIW features. And that's my point: Itanium further and unnecessarily enshrines the C view of the world, putting any alternatives at a grave disadvantage. That's not the way to make progress in software.
First of all, it's not unregulated; like any form of wireless, there are already lots of regulations that affect its use. For example, you can't build a 5 MW transmitter in the 2.4GHz band.
Second, my point is that it should be regulated more because if it isn't, there will be no band left for the purposes that this band was intended for.
That is, if the 2.4GHz and 5GHz start getting used for providing wireless services, you can kiss your corporate and home wireless networking infrastructure "good-bye": companies like IBM and AT&T have deep enough pockets to deploy enough access points to make any other use of 802.11 infeasible.
We need bands for home networking, wireless LANs, local wireless phones, and other in-house services. 2.4GHz and 5GHz bands are it, and other uses of those bands will interfere with their intended use. If it becomes a free-for-all, the intended use will lose out. And that's particularly unfair because those bands really only became economically interesting to wireless service providers after demand by consumers and businesses for equipment has driven the prices down so much.
If 802.11 is a viable way of providing commercial wireless services, the right solution would be for the FCC to allocate neighboring bands to such services and have providers pay for the use of those bands. That way, they can use essentially the same equipment, and they won't be interfering with the intended uses.
Why don't we just give up on urban plannning and let everybody build where they want? Why don't we just get rid of the police or military and let everybody defend themselves? Maybe you'd like to live that way, but most societies figured out that government is better than anarchy.
Why would someone pay for rainbow when they could get free service?
If people start using 802.11b for providing commercial services in a big way, there won't be any free service anymore because the bandwidth will be used up. That's exactly the problem.
Where is this going to end? Are cellular companies going to offer phone service using VoIP over 802.11, complete with roaming via IP roaming?
I think whenever spectrum like that used for 802.11b/a is assigned, the FCC should prohibit people from selling services based on it--users that sell services should buy their own spectrum. Otherwise, such companies will just take over what was supposed to be a public resource. It's kind of like allowing businesses to just take over parts of the public park or street. Such restrictions wouldn't mean you can't use it for business purposes: you can still buy the equipment and use it internally, and you can still give service away to your friends.
When it comes to open source software, it is. That's because open source developers write the software they use and therefore give it the user interface they like.
I'm a developer, but for rarely performed tasks, I prefer a tool with an easy UI.
Sure, and developers create those kinds of tools ("easy" for a developer is still different from "easy" for the general public). For example, "icewm" has "icepref"--something that's great for casual use by programmers, but too hard for non-programmers.
No, but usability engineers target a "narrowly defined community". Just look at how usability testing is usually done.